The Second “R” of Mobile Enterprise Apps
Ojas Rege | January 03, 2013
“If I had more time, I would have written a shorter letter.” This quote has been attributed to many, including Mark Twain, and it can teach us a lot about mobile enterprise apps.
In the last post, I described how the best practices for mobile enterprise app development are coming out of the experimentation and iteration of the last twelve months. Many of those lessons have revolved around the three new “R”s of Mobile Enterprise Apps: expeRience, aRchitecture, and Role. This post describes the second “R” (aRchitecture), why less is more, and why many companies have struggled to get it right.
The rush to mobile apps in many organizations has resulted in architectural shortcuts that are making many of those apps clunky, unsupportable, and not secure.
Here is an example: The VP Sales wants each salesperson to have all product collateral on his or her iPad. So sales ops hires a contractor to build an app. The contractor is very talented and fast. She builds a beautiful app – easy to use, impressive to clients – and the sales team loves it. But, because all the content is hard-coded into the app, it is 1GB to download and every time a piece of collateral changes, the entire app needs to be updated. As a result, upgrades put a strain on the network, maintenance is manual, content quickly gets out of date, and the app is not supportable in the long-run.
The contractor built the app that was requested. But it did not have a solid architectural foundation or data model.
At the 2012 MobileIron user conference, one of our retail banking customers described their approach to this problem. When they kicked off their mobile apps program, they first identified the main data sources employees would need. They found many of them were already available as web services due to the SOA work they had done over the last decade for electronic banking. The ones that didn’t exist they built. Most of their back-end systems had evolved over the last two decades and had decent, if not perfect, interfaces.
With that infrastructure in place, they can now rapidly build mobile apps. They can use external developers because the services are easy to use and secure. They can be sure content is up-to-date. They can make it easy for the user, because with data separate from presentation and logic, the app download itself is small and quick.
But most importantly, they can move fast - experiment, iterate, and learn.
So the architectural assessment and relatively small preparatory investment has provided a solid foundation for the apps development program. A bit of effort up front will result in competitive advantage moving forward.
The lessons of the past are useful as well. Fifteen years ago, we also had a situation where the business was building apps, architectures were messy, IT’s role was unclear, and success rates were low. It was the early days of e-commerce. The architectural lessons of that era are actually quite relevant for today. And many of the investments made to provide well-formed interfaces to data and systems can be re-purposed for mobile apps.
Mobile enterprise app development will be decentralized. All paths will not lead to IT. So within one large company, many, many developers will be building many, many apps. If the back-end architecture is not in place, most of those apps will have a beautiful face covering an interior of shortcuts, hacks, and band-aids.
In the next post, I’ll cover the final “R” – Role – which will share best practices from MobileIron customers on the evolving role of IT and what IT can actually do to add value to the enterprise app developer and address these issues.