Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why you should be putting mobile app development first

public://pictures/Bernard Golden Photo 3.png
Bernard Golden CEO, Navica

Everywhere you go these days, you see people in the same posture: head bowed, barely perceptible movement, eyes focused downward. They're all doing the same thing, peering intently at a mobile device—at an application made possible by mobile developers.

Mobile is now the dominant way that people interact with the Internet, as Andreesen Horowitz's Benedict Evans points out in his presentation "Mobile is eating the world." It's not surprising, then, that mobile app development is becoming a critical enterprise IT skill. So why do so many IT organizations still outsource it?

While mobile has been a force in Internet use since 2007, when the iPhone launched, today it is the clear leader in Internet client devices. And mobile is only going to get more dominant as more people shift more of their Internet activity to phones and, crucially, as much of the rest of the world adopts smartphones as their initial—and only—Internet device.

That mobile-dominant reality poses a big challenge for enterprise IT because most shops have continued to focus on browsers as the primary client mechanism for applications. Many, if not most, enterprise IT shops have outsourced mobile development to external specialist agencies, treating mobile as a limited, tactical requirement.

This approach has left them woefully unprepared for a future in which mobile isn't just a client option; it's the primary client option. Enterprise IT organizations must implement a mobile development-first strategy, or risk being unresponsive to the primary way that their customers, partners, and employees want to do business.

Developing a mobile-first strategy

So what does a mobile-first strategy look like, and what steps must enterprise IT organizations take to implement one?

Here are three areas that IT organizations must address to achieve a mobile-based future:

Extend the application tool chain to incorporate mobile-focused tools and processes

Mobile devices represent a new client form factor, and you need different tools to write mobile apps. Most organizations focus on the two largest mobile platforms by market share, iOS and Android, which presents an immediate dilemma: Should you choose best-of-breed or cross-platform tools?

While many organizations initially prefer to use cross-platform tools, because a common tool would seem more efficient in terms of code management, cross-training, and so on, most people find that this approach falls short in terms of delivering applications that integrate with the mobile OS. Consequently, they move on to using operating system-specific tools and frameworks and take on the burden of multi-device application development and deployment. While it imposes more work, this approach results in more satisfying applications that are better suited to the platforms on which they're running.

But building and deploying mobile applications requires more than just device-specific client tools. Mobile applications also require other capabilities that surround the application itself and make it more useful.

For example, applications require notifications and alerts, both for application-specific functionality and application updates. Moreover, key issues such as identity and device management inevitably accompany the delivery of mobile applications. In addition, mobile applications often operate in environments with sporadic connectivity, which means applications commonly have to cache enough data locally for the application to continue working while disconnected, with syncing performed in the background once connectivity is re-established.

Beyond device-specific requirements, mobile development typically requires modification to the application development process and tool chain. Because updating the mobile client application is more difficult than updating a web display page, it's important to move testing earlier in the development cycle so that you can identify bugs that would require updates earlier.

Finally, testing itself must be changed, since testing devices requires access to testing environments that operate just like individual devices. In other words, you have to make sure that the application can be installed and will operate properly on multiple versions of iPhones, and on Android devices from different manufacturers. Most organizations start by having a few devices on hand but quickly recognize that this is unwieldy and doesn't scale. Fortunately, mobile device testing services can provide actual or simulated devices to use in testing mobile apps.

Build back-end systems that can support the unique characteristics of mobile applications

Just as mobile applications impose unique development requirements, so too do the back-end systems to which the applications connect. Mobile applications display very different usage patterns when compared to web-based applications.

For example, just as the intermittent connectivity described above means client applications must cache data and then perform background syncing, the back-end systems must accept connections and determine if there is an existing session that should be reinitiated, rather than an entirely new session started.

Likewise, functionality must be added to the back-end system to enable background syncing. In other words, when the client application wants to sync data, the back-end system must be ready to receive it.

APIs represent another element of back-end systems that becomes more important in mobile applications. Mobile clients are external systems that connect to a back-end system endpoint. The most common endpoint interface is a RESTful API. Many IT organizations struggle when beginning to make APIs available because of the complexity in operating them.

One common issue, for example, is how to handle the reality that APIs evolve over time. It might seem as if putting out an updated API is nothing more than redirecting a URL to a new endpoint, but nothing could be further from the truth. Even though new back-end functionality is being exposed, until mobile clients are updated, they will expect to talk to the old functionality. Therefore, IT organizations need a strategy to deliver updated API functionality while keeping the old functionality and URLs operating as before.

A mobile-first world imposes changes on back-end systems behind the API endpoint as well. The traffic patterns of mobile applications are much more volatile than for traditional applications. People expect to use a mobile application when and where the desire strikes them. In addition, mobile applications often experience waves of traffic as users share information about the application on social media.

For example, Microsoft created an application called How-old.net that uses image recognition and machine learning to guess the age of a person whose picture is submitted from a mobile phone. Microsoft expected a few users to try out the application, but as a result of social sharing, hundreds of thousands of people hammered the back-end system that performed the image recognition and machine learning. Microsoft responded quickly, but this experience illustrates what can happen in the mobile world.

One of the techniques IT organizations use to enable rapid scaling is to break up large back-end systems into multiple, smaller functionality pieces that operate independently. When part of an application (e.g., Microsoft's facial-image machine learning) begins to experience high load, more of the processes that execute that piece of the application can be launched, thereby enabling good user response times in the face of heavy load. The different parts of the application communicate by—you guessed it—RESTful API calls, reinforcing the need for good API management.

This emerging best practice for application architecture, which goes by the name of microservices, is poised to become an important trend in enterprise IT environments.

Insource mobile skills

Mobile applications change many aspects of enterprise IT, which brings up this question: Who will implement all the changes just described? In the initial rush to deliver mobile applications, many enterprise IT organizations begin by outsourcing mobile application development to an external agency. This approach makes sense when there's tremendous pressure to deliver a mobile app as soon as possible.

Given that mobile will now be a long-term commitment, however, it's critical that you build in-house mobile skills. Using an external agency makes you dependent on resources you don't control, but more importantly, doing so makes it difficult to get the kind of integrated designs possible when your IT groups collaborate. Beyond that, using an outside party, no matter how talented, inevitably imposes delays in the application life cycle. These can be deadly in an environment of ever-more-demanding customers and accelerated functionality delivery.

How do you build a mobile-capable staff? This might surprise you, but the right strategy is a combination of "buy" and "build." You need to bring in fresh talent experienced with mobile platforms and tool sets. Training existing staff will impose lengthy delays as they get up to speed, making the inevitable mistakes that humans make as they learn new skills.

Beyond the core skills acquisition that hiring mobile-experienced talent enables, hiring people experienced in mobile application development will leaven your organization with people accustomed to the process and culture associated with mobile apps: agile development, continuous integration/continuous deployment, frequent application updates, and the troubleshooting of complex architecture applications.

Hire and retrain: A blended approach to talent management

On the other hand, this is not a clarion call for wholesale staff replacement. Not only would a complete turnover of staff be logistically impossible, it would also be irresponsible. You have employees with deep knowledge of existing systems who will be critical to integrating new mobile client applications. In addition, mobile applications typically require functionality extensions into these systems, and current employees are by far the most capable to implement this. Of course, building out and operating API endpoints, as well as migrating to microservice architectures, will require these employees to build new skills, so you should expect to invest in training and skill building.

The net result of this blended approach to talent management will be an IT organization that's ready to meet the mobile application challenge head-on and emerge successful. In a mobile-first world, preparing an action plan as outlined above is a vital first step.

Keep learning

Read more articles about: App Dev & TestingApp Dev