The hidden hazards of mobile app development

The transition from desktop to mobile computing is not a question of if, but when. According to Gartner, within the next five years, 70 percent of software interactions in enterprises will occur on mobile devices. Little wonder, then, that organizations that are just embarking on their mobile app development journeys can often be tempted to assume the voyage will be smooth sailing. After all, at the earliest stages their ambitions will likely be modest. Maybe they plan to start slow, with just one or two apps.
 
But not long after the ship has left port, an object looms in the waters ahead. “Nothing to fear,” the mobile project manager thinks. “My crew has navigated obstacles before.” Little does that manager realize that what looks like a minor hazard is but the tip of a much larger and more dangerous problem lurking beneath the surface. Before the project has time to change course, what started out as a leisurely cruise toward mobility has started to feel like a trip on the Titanic.
 
Melodramatic? Maybe. But the truth is that, much like that ill-fated cruise liner, far too many mobile initiatives have been sunk by lack of foresight. The pace of innovation is accelerating, yet if you rush full steam ahead into a mobility project without properly assessing the risks, you’re bound to run into trouble.
 

Iceberg ahoy!

In our Titanic / iceberg analogy, you can think of the part bobbing above the surface of the water as the mobile app itself. Most shops don’t run into much trouble there. Modern mobile development toolkits make it relatively simple to build multichannel apps that can be deployed to a variety of platforms, including Android, iOS and web.
 
Don’t be fooled, though. In today’s networked enterprise mobile apps, the much larger and riskier portion of the project lies beneath the surface, in the often-complex layer of interconnected services that make up the mobile backend. It is here where the real work happens - and unfortunately, it can be far too easy to underestimate just how much work will be involved in implementing it.
 
Judging by the UI alone, even a mission-critical enterprise app can seem deceptively simple. Such apps, however, typically need support from a myriad of backend services, ranging from authentication and identity management, to security and encryption, to data storage and retrieval, to integration with enterprise software like ERP systems or salesforce automation. As the complexity of the backend grows, an API management layer is probably in order, to help manage the overall lifecycle of the various components. All of these services require care and maintenance, further burdening IT and DevOps teams.
 
Further compounding the problem, it’s likely that the plan to start slow with one or two mobile apps was wishful thinking. As organizations of all sizes feel mounting pressure to achieve digital transformation mounting, demand for mobile apps increasingly comes from lines of business from across the organization. Before anyone realizes it, two mobile projects have become six, then six have become twelve…
 
It’s typically at this point that the hull of the mobile initiative really starts springing leaks. With multiple, uncoordinated mobile projects in the works, the organization’s total code base balloons to unmanageable size. Redundant coding efforts sap efficiency. In many cases, app dev teams will have made the mistaken assumption that existing middleware would meet their needs, only to find out that legacy web architectures are poorly suited to mobile. That sinking feeling soon sets in.
 

How to steer clear

Fortunately, there’s hope. As an industry, we’ve learned a lot since the early days of mobile app dev. By observing modern best practices, it’s possible to develop and deploy multichannel mobile apps in a way that’s not only efficient and consistent, but also low-risk - a methodology known as “app factory” style development.
 
One emerging pattern that’s enabling this approach is the use of model-driven development, a practice that will be familiar to enterprise application developers but has only recently been applied to mobile app dev. This development style uses software architectural models to abstract away the low-level complexities of programming, making it easier and faster to develop discrete application components.
 
These components can then be deployed as microservices that can then be composed into complete applications. The microservices architecture not only makes applications easier to deploy and scale, but it can also make them more secure by making it easier to patch and update individual components without service disruption.
 
Adopting these new methods can seem daunting. But fortunately these and other modern features are already available in modern mobile backend-as-a-service (MBaaS) platforms, such as Kony MobileFabric. By standardizing on such a platform across the organization, app dev teams can both minimize redundant efforts and concentrate on responding to changing business objectives, rather than the drudgework of maintaining a poorly integrated mobile backend.
 
The bottom line is that while too many mobile projects end up in Davey Jones’ locker, the journey to mobility needn’t be a doomed voyage. The sinking of the Titanic was the result of too much hubris; app dev teams shouldn’t make the same mistake. By correctly assessing the full scope of the task ahead, applying modern development methods, and choosing the right partners, it’s possible for organizations to avoid hidden hazards and keep their ongoing mobile initiatives for years to come.

---

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

---