Almost on a daily basis, I receive an email from a company offering to help me with my mobile app development initiatives – generally they are either offering to build my apps for me, or are offering some tooling or capabilities to help me build and deploy apps myself.
It seems to me that we, as an industry, are rushing in to “mobilize”. What I’d like to do in this blog is to slow down, consider the various drivers and options, and come up with a framework for helping to define your mobile app development strategy.
Part 1 will look at the current landscape. Part 2 will dive into the strategic options and checklist.
Part 1 – The App Development Landscape
Before we start looking at your strategy in Part 2, there are a couple of topics I’d like to touch on. These serve as background to your strategic analysis.
- There is an enormous backlog of enterprise mobile apps waiting to be built.
- The idea of “mobile first”, and what it is evolving into.
- Mobile apps vs the mobile web
- Pros and cons of different mobile app development techniques
1. The Mobile App Development Backlog
Analysts are reporting that their customers are suffering from increasing backlogs in the development of enterprise-class mobile apps. For example, a forthcoming session at Gartner Summit is titled: “As mobile apps become a top concern for CIOs, application development leaders face an increasing backlog of mobile development projects.” Link
Other references to this problem include:
Gartner have estimated that for every business application, somewhere between four and 20 mobile apps are required. From Gartner’s “Top 10 Strategic Technology Trends for 2014” http://www.gartner.com/newsroom/id/2603623
“The unexpected consequence of bring your own device (BYOD) programs is a doubling or even tripling of the size of the mobile workforce. This is placing tremendous strain on IT and finance organizations.”
The central question is: Given that there are so many apps that need to be built, what is your best bang for your buck? This is the key question that this blog tries to investigate.
2. Mobile First? Or Multi-Channel First?
It was only a short while ago that people were frantically creating new versions of their sites called m.mysite.com or mobile.mysite.com. And then more recently, we started hearing about the concept of “mobile first”.
For those of you who don’t know the famous comedy sketch :”Who’s on First?”, here it is: Who’s on first?
For an excellent paper on why we should build for mobile first, see this presentation from a few years ago by Luke Wroblewski: http://static.lukew.com/MobileFirst_LukeW.pdf
However, many in our industry are starting to recognize that mobile first is an over-correction. Yes, it was perhaps a necessary concept to shake up the established ideas of how to develop sites and content, but mobile first is really just as limiting as desktop first – either way, you have to do some additional work to get it working on both types of devices.
The obvious solution is to build, from the start, for multi-channel. This idea is being promoted by many strategists and analysts, such as Forrester, who are talking about multi-channel in many contexts. For example: Digital Channels
I think the concept of multi-channel first is a really important one, and should set the scene for any discussion about mobile app development. Mobile is important, but you should be considering your entire channel from the start.
Multi-channel is more than just catering for mobile and desktop, but also for different modes of transaction, including call center, guided, paper, fax, and more. For example, a customer who starts an application online, but runs into difficulties, may decide to complete the transaction in a branch. However, typically when they enter the branch, they have to start the transaction anew. The goal is to support true cross-channel transactions, where customers can switch from any channel to any other channel, whenever they want to.
3. Mobile Apps vs The Mobile Web
When we think of mobile devices, we tend to think of apps. However, most of us also do a lot of browsing of websites and online Web applications via our mobile browsers.
You can build applications for the “mobile web” instead or as well as building them as mobile apps. These applications are transaction-oriented Web applications that you host online, and which are optimized for mobile device access.
There are a number of advantages of the mobile Web over mobile apps:
- The mobile Web is easy to deploy, upgrade, add features/products, and fix bugs.
- You don’t have to publish your App through an App-store – which can sometimes be a difficult and lengthy process.
- Your users don’t have to install an app before they can interact with you.
- The mobile Web is perfect for occasional or one-time use such as enrolling or applying for a new service, customer onboarding, lodging a complaint.
- You only have to develop on one platform.
- You don’t have to worry about people using an old version of the app.
However, apps do have several advantages – they are particularly well suited to performing repetitive tasks – especially once a user has become a customer:
- They are “sticky” – once installed, they have a presence on a customer’s device.
- They are convenient – it’s much easier to load up an app rather than a website.
- You can work with them offline.
- They can have deeper integration with the device’s capabilities, such as the camera, GPS, etc.
It is also possible to solve certain types of business problems with a combination app plus mobile Web. Using an app for those parts of the business interaction which are used frequently (such as checking my account balance), and using links from the app to the mobile Web for those functions that are used rarely or change frequently (such as applying for a new term deposit or IRA account).
The choice between building for the mobile Web vs building an app should not be one entered lightly.
4. Pros and Cons of Different Approaches to Mobile App Development
From a technical perspective, there are several different ways to build mobile apps. These techniques have evolved over time. When the first smartphones appeared, the only way to build apps was to use the native development tools provided by the phone vendor. However, added-value frameworks and systems quickly appeared, which were driven by the dual needs to be able to build apps quicker, and to build a single app that would run on multiple different types of devices.
Here is a very quick primer on these different approaches, focusing on the pros and cons to both the developers and to the business.
|Native||Use the native tools provided for developing apps on each platform.||Provide full access to all the native features||Require each platform to be developed completely separately.|
|Cross-platform Framework/Tools||Several different vendors provide frameworks and/or tools that work across multiple platforms, but still give access to the native features.||Provides access to most native features, without needing to rewrite the app for multiple platforms.||Requires you to learn and commit to a framework. Lock-in to the vendor can be concerning. You may have to work to a “least common denominator” approach rather than using the best features available on each platform.|
|Composite||Use a mobile app for commonly used functions, and then link to additional capabilities on your mobile website that provide less commonly used functions.||Provides a good balance of mobile app and mobile Web capabilities.||May not provide the most optimal user experience due to “switching” from app to browser.|
We’ll move on to the strategic checklist in Part 2 of this blog.