Mobile App Development — Define Your Strategy (Part 2)
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 looked at the current landscape. Part 2 dives into the strategic options and checklist.
Part 2 – Strategy Checklist
Now that we’ve established the background, let’s get into the actual strategy. Fortunately, if you’ve managed to work your way through the background in Part 1, the strategy checklist is short, simple, and should make a lot of sense.
Checklist Item #1: Can I configure an existing app instead of building a new one?
The first question to ask yourself is whether there is an existing app you can use that will give you what you need, or can be easily configured. There are an increasingly varied and powerful set of enterprise-class mobile apps that you are able to use off the shelf, or customize, to provide the capability that you need.
- Salesforce.com has an excellent mobile client that can bring many sales-force automation functions to a mobile workforce. Most other CRM and ERP vendors provide apps.
- Box, Dropbox, Google Docs and many others, including the more traditional document management vendors, provide apps that give you access to private and shared content.
Put some emphasis on finding and configuring an existing app rather than building your own.
Checklist Item #2: Do I really need an app, or should I use the mobile Web?
In many ways, building your functionality for the mobile Web rather than as an app means that you can probably build it more simply, update it more easily, and add features more quickly. The real question is to understand the nature of the business problem you are trying to solve and decide whether it is an intrinsically “sticky” function.
By “intrinsically sticky”, I mean, “Is it a business function that the user is going to perform often, and which they need to be readily available at all times on their mobile device?”. You cannot make a business function sticky by turning into an app – in fact, you are likely to make your customers less likely to interact with you for non-sticky functions if they need to download an app to do so – they are going to be much happier just hitting your website.
The other good reasons to build a mobile app over using the mobile Web are:
- Your users need to access the app while offline.
- The business function they are performing requires access to device capabilities that aren’t available via a browser.
Only consider building an app if the business function truly is one that customers will want to use regularly, and/or they need to use it offline or need access to device capabilities. Otherwise use the mobile Web, or consider a composite app / mobile Web approach.
Checklist Item #3: Can I use a composite approach?
Whichever approach you take to build your app, give careful consideration to the composite approach. In other words, reserve the more commonly used features for your app, and for the lesser used features, link from your app to the mobile Web.
From Gartner’s “Top 10 Strategic Technology Trends for 2014” http://www.gartner.com/newsroom/id/2603623
“Developers should look for ways to snap together apps to create larger applications. Building application user interfaces that span a variety of devices requires an understanding of fragmented building blocks and an adaptable programming structure that assembles them into optimized content for each device.”
For example, many shopping sites provide an app to drive customer loyalty by providing special offers, coupons, and more, but continue to use the main online site for the primary shopping experience. Cartwheel by Target takes this one step further, with coupons in the app coupled with an in-store shopping experience.
Give careful consideration to the composite approach. This may give you the best path forward to implement the most important parts of your mobile strategy, while keeping other parts on the Web.
Checklist Item #4: What technique should I use to build my app?
Assuming you have decided you need an app, how should you build it? Organizations are faced with an increasingly complicated device landscape, with at least two primary device types (iOS and Android) and several others (including new Windows-based devices, Blackberry, and others.) Anything which helps developers to have a single knowledge-base and code-base across multiple platforms is generally a good thing.
Again, from Gartner’s Strategic Trends report: “For the next few years no single tool will be optimal for all types of mobile application so expect to employ several.”
The high costs associated with developing for multiple platforms, coupled with the backlog of mobile apps, means you should give priority to cross-platform development approaches. The hierarchy looks something like this:
- You should build using a Hybrid / HTML5 approach unless you have extremely good reasons to do otherwise. (Please refer to Part 1 for a refresher on some of these reasons.) Most enterprise aApps seem to fit well with the Hybrid / HTML5 approach in my experience. This also means you can potentially share code and skills across the app and Web development teams.
- If you have good reason to build an app natively, then you should consider a cross-platform framework. You should only do this if you have a large portfolio of apps to build, and have the budget to be able to establish and maintain a large team of developers dedicated to that framework.
- You should only consider using the platform native tools if it is absolutely the only way to achieve the particular functions that you require in your app. You can also consider building a native app if you only have a small number of apps to build, or if you want to outsource development, where using widely used tools is more important than speed or cross-platform capabilities. The final reason to build using native tools is if you are building an app for a closed user group who all use the same device type – however, even in this case, I would still be inclined to use the HTML5 / Hybrid approach in preference.
This is corroborated by articles in the press such as this one.
Checklist Item #5: Can I shift some of the responsibility from IT to the business
One consideration is whether you can effectively empower the business to take some responsibility for the development of content. The modern approach to marketing-type websites is for IT to maintain a web content management system, and for the business to maintain the content that is hosted by that system. Where possible, it makes sense to do something similar with mobile apps – can you find a mobile app platform that allows the business to develop mobile content?
For IT, if you can find a way of enabling the business rather than doing the work for them, you will relieve pressure on yourself as well as making them happier.
Scoring Avoka Transact against these criteria
Avoka Transact is a platform that includes both Web-based and app-based data collection and digital business capabilities. Avoka Transact is particularly useful for larger enterprises who have a large backlog of apps to deploy, and when the focus is around multi-channel business transactions.
|Checklist item||Avoka Transact|
|Can I configure an existing app instead of building a new one?||Avoka Transact is in many ways a pre-built solution that you can buy (rather than developing), and which you configure for different customer transactions by building a form and configuring an end-to-end transaction for each engagement.|
|Do I really need an app, or should I use the mobile Web?||Avoka Transact allows exactly the same business transactions to be deployed on the mobile Web, or within a mobile app on either smartphone or tablet devices. In other words, Avoka Transact is inherently multi-channel. A customer can start a business transaction – such as enrolling for a new product – in an app on their phone – save it and complete it later in their browser on their home computer.|
|Can I use a composite approach?||It is quite possible to build the “sticky” parts of your business as an app, and link or embed Avoka Transact forms for the less frequently used transactions. This allows you to build out your portfolio of online transactions without blowing out the size of your app, or deploying a new app continuously.|
|Can I shift some of the responsibility from IT to the business?||Transact allows the business to create, deploy, and manage the online forms and end-to-end transactions, which frees the IT department to devote resources to other areas.|
Internally, the Avoka Transact Mobile App is built using Hybrid / HTML5 technologies. (Yes, we listen to our own advice.) The forms that are surfaced inside the app are also generated using HTML5 forms, with a large degree of interactivity and responsiveness. This is important because it means that Avoka Transact uses standard technologies, which are less likely to become obsolete or locked-in.