Tuesday, May 12, 2015

Mobile Device End of Life

Mostly when people think of enterprise mobile projects what springs to mind is the process of designing, building, and testing, a fancy new mobile application. When this new application goes live suddenly life is easier, the company makes more money, customers and employees are happier. (For a more comprehensive view read the benefits of enterprise mobility). So where's the "but" you ask? I'm sure you have guessed that not all enterprise mobility projects follow this same pattern. Equally as important as a new application is ensuring that an existing mobile business process continues to operate effectively.

Many companies with a long history of mobile applications have invested next-generation improvements to leverage the benefits of technological advances. Typically aspects of the end to end mobile solution may reach end of life. For example support may become less effective, skills in niche technology become scarce, devices and operating systems change. Additionally user expectations increase along with consumer technology.

In the traditional enterprise mobile space many organisations opted for rugged or military specification devices (and plenty still do). One of the benefits of these devices is that they tend to be supported by their hardware manufacturer for many years. Eventually though this many years does run out. At that point there is usually a scramble to think about new devices and then the doors open to options, alternate vendors, and solutions.

What should you do if you are tasked with taking on an end of device life scenario? Before we get started let's set the scene a little more. Consider Company X has a mobile solution that includes integration to a business system, offline capabilities along with some peripheral integration such as printing and/or scanning, and is leveraging a rugged mobile device that will shortly become unavailable and out of support. This maybe somewhat more complex than users of web applications moving from iPhone 6 to iPhone 7. However in concept the steps are similar, just greatly accelerated in the simpler example.

So now we have some context let's firstly consider the three "environments" of relevance. The legacy, the current, and the future. With all three it's good practice to do due diligence to ensure that you have cost effectively mitigated the risks.

For the existing legacy solution a great starting place is the solution documentation. Anything you can dig up on the existing business case, processes, technology stack, products, application, devices, support and integration will help prepare you for more detailed discussions. Consider for example that the standard operating environment or build of this kind of solution can be quite complex. Prepare a simple one or two page summary of your findings. Once you have the background it's a good time to talk with the stakeholders, users, and support staff to understand the requirements. Again ensure to take notes and prepare a summary.

Next the current environment phase is about understanding what is available in the market and how this will fit with the existing solution. It's time to begin the device evaluation process. For full details of this process check out the following article that covers how to select a device for enterprise mobility. A good process is to shortlist devices and then bring the hardware manufacturers and/or demo devices to the stakeholders to show the relative pros and cons. Don't forget that in our scenario it's not just the mobile device that is important but associated peripherals like printers and scanners.

Once a subset or limited number of devices have been established then it's time to do some testing. Determine the appropriate level of testing by evaluating the delta between your existing and target devices. For a full run down check out this article Testing Enterprise Mobility. A key consideration is to ensure that the software build can be completed. This can be greatly impacted by operating system and hardware changes and may require cycling back with the software providers. Once technically working it's worth field testing with end-users to ensure that any negative and positive aspects of the new device are understood. Ensure that all the testing results have been documented.

Finally consider the future. Change is rapid in the digital space. Is the solution sustainable? Are aspects of the technology now past a point of no return? Is replacing the device the best method to continue to get value from the solution. Perhaps it's more cost effective to replace certain parts of (or the entire) solution based on new software and hardware solutions.  To wrap up prepare a summary of findings along with a recommendation based on the facts.