This blog covers the practical techniques, trials and tribulations associated with the transformation of IT systems from legacy technologies to systems using SOA and modern open systems. It also includes the occasional interlude with rants about technology in general.
For all the advanced sci-fi paraphernalia in the classic Star Trek series, it would be fair to say that the communicator device Captain Kirk used when on an alien planet was probably surpassed by the Motorola Razr several years back. With millions of apps, an untamed cornucopia of emerging mobile technologies, and a future that everyone agrees will be all about mobility and more mobility, the need to create a mobile strategy seems almost as daunting as the Star Trek deep space explorations.
Creating a mobile strategy is such a bold effort simply because there are so many options and alternatives out there. What functionality are you to provide? What are the target devices to support? (Tablet, Phablet, Smartphone, Kindle, Laptop, Google Glass?) What are the operating systems to use? (Android, iOS, Windows 8) How should you approach the implementation? These are but a few sample questions that appear unanswerable at first.
Thing is, a “mobile strategy” is not very meaningful as a standalone exercise. A mobile strategy should and must be something that naturally emerges from your enterprise’s specific business objectives and priorities. Attempting to articulate a mobile strategy without first understanding the business drivers will make your journey more like a “Harold & Kumar’s Go to White Castle” adventure. Mr. Spock would not approve.
For example, if the business objective is something as straightforward as having smartphones and tablets show the same content as that on the web site and nothing more, your approach would be to normalize the presentation technology to flexibly cover as many devices as possible with a single implementation. HTML 5 would be the way to go in this case.
However, forming a more detailed strategy does quickly become a more nuanced challenge once you try to address specific mobile functionality requirements. Do you need to introduce revenue generating functions across the mobile spectrum? Is the main purpose to provide service and support via mobile devices? Is this primarily an informational and branding exercise? Is the mobile strategy core to future operations?
Only after you have gotten a clearer sense of the answers to these questions will the traditional evaluation of scope of functionality vs time to market vs budget apply (see my prior blog Defining the Project Scope and Requirements for more on this). Compounding the analysis is the fact that a variety of choices regarding target channels, client devices, and technologies is hardly homogeneous. Mobility today is a vendor-driven field, and it will continue to be so until the day it becomes satisfactorily covered by industry standards.
Once the business provides direction of the target market for the mobile applications, you can use this information to decide which devices you should target first. There is a wealth of statistical information on the web to help you. For example, in finding the right choice for the largest demographic, it helps to know that Android devices represent 61% of the market versus 36% for iOS.
Obviously, you will want to get more granular information about device usage based on these demographics. If the target market is West Coast millennials, chances are they are heavier Apple users. If the target market is a mobile sales force with tablets or the corporate staff equipped by internal policy with Windows 8 Nokia Smartphones, knowing what to prioritize becomes self-evident.
In other words, the first steps of a Mobile Strategy are to define the WHAT, the TO WHOM, and even the WHENthings should be accomplished in order to best support the business objectives. Perhaps the decision that’s most open to the IT area is selecting HOWthis strategy will be implemented. But even then, the technology decisions need to be consistent with the business purposes of the strategy. For example, if the functionality being provided is deemed to be mission-critical and generates revenue (say, you are asked to permit purchases of your products from a mobile device), it is sensible to develop a specialized App for the target devices. Furthermore, if the functionality is deemed to be something that provides a competitive advantage or happens to be THE product (e.g. the item is a Game App that you are marketing), then it also makes sense to create the internal core competencies to develop it and maintain it yourself and not try to outsource its development.
If the target market is focused on a specific platform (say Apple’s iOS), and it is expected this will be the case for the foreseeable future, it would make sense to develop the application directly with the Apple development framework. But if performance or long term maintainability is not as important as breadth of support and time to market, then it is best to explore the use of cross platform development tools. However, heed this warning about these tools: These should be viewed mostly as tactical solutions only. They will enable you to cover more devices, more quickly, but you will be restricted to lowest common denomination functions (lest you choose to customize implementations for a particular platform; thus defeating the purpose of having a single solution across the space).
To summarize, a Mobile Strategy should follow something similar to the Table of Contents shown below. Still, you should always keep an eye on the future. You may have an additional section or an appendix with recommendations as how best to understand and position the strategy vis-à-vis emerging mobility trends. The sooner you know what you will do with wearable devices such as Smart-watches or specialized devices such as Fitbit or biometric monitors, the better. It’s never too soon to prototype how mobile functionality might play with the so-called “Internet of Things”. Such research efforts should also be part of the strategy.
You can’t expect to get your initial strategy 100% right. As with any strategy, you should assume your mobile strategy is a living thing. Keep it updated and fresh in light of new developments. In fact, there is a good chance that the business objectives regarding mobility will quickly change as well. Remember, just as with the USS Enterprise, your mission is one that includes a great deal of exploration!
A MOBILE STRATEGY
TABLE OF CONTENTS
The business objectives driving the strategy. This is a recap of the objectives the strategy is seeking to meet. These objectives should reinstate the business purpose as well as timeframe and funding expectations and constraints.
What is the specific business strategy regarding mobility: functionality, priorities, target demographics, etc. Remember that a mobile strategy should also specify the functionality available when the device is offline.
What is the end-to-end architecture supporting the mobile strategy. In the end, all mobility strategies are about making information accessible to the user wherever the user happens to be! The end-to-end architecture must fully describe the component partitioning of user interface, business logic and backend data in accordance with service oriented constructs.
What are the preferred technologies used to support the mobile strategy. This is where you describe the operating systems, languages and development frameworks to be utilized, along with best practice tenets that must be followed. If the mobile strategy deals with employee mobility requirements, you should decide if your company will adopt a BYOD (Bring Your Own Device) approach. Either way, you will need to specify the mobile devices that will be purchased or leased for employees at the brand and model level and what should be supported.
Integration with third part content, applications, and social media. If the strategy calls for integration with third party services such as Facebook, Instagram, Google Maps, etc. you will describe the approach to this integration from a presentation and API perspective.
Implementation strategy. Will you purchase third party applications or toolkits, will you outsource proprietary development to third parties, will you recruit contractors or internal talent, will you use a hybrid approach and if so, for what particular components.
How will you provide support and maintenance. This section should also describe support processes as well as the expected service levels. Emergence of 5G will further dilute the difference between accessing online services via WiFi or carrier networks, but you should try to adjust service levels accordingly (e.g. if the user is about to make a large data transfer via carrier network, warn them about potential cost implications).
Security and Privacy. Here you describe the approach to authentication and encryption, if any.
What is the implementation roadmap? Clearly, cost and funding levels will heavily influence the pace of implementation.
Testing and User Acceptance criteria. Obviously, this section should be fully negotiated with the business so that clear success criteria can be established.
 Take the example of Hilton’s recent announcement that it plans to invest $550M to integrate guest’s Smartphones to its property operations.http://online.wsj.com/articles/hilton-books-upgraded-technology-1406503197. Even though most of this capital will probably be used to upgrade hundreds of thousands of rooms locks rather than on actual mobile technology, this is a good example of a holistic investment.
 The Mobithinking site has a great deal of research on this. Check it out.
 Cross platform tools can force an unwanted dependency on the tool vendor (these vendors do not always last long), and they will likely present some performance issues caused by the sub-optimal use of specific platforms.