When people think about enterprise mobile projects, what typically comes to mind is the process of designing, building and testing a fancy new mobile application. When this new application goes live, life suddenly becomes easier, customers and employees are happier and the company makes more money (for a more comprehensive view, read the benefits of enterprise mobility). So where’s the “but”, you ask? Well, the issue is that not all enterprise mobility projects follow this same pattern. Aside from the development of a new application, it is equally important to ensure that an existing mobile business process continues to operate effectively.
Many companies with a long history of mobile application development 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 and devices and operating systems change. Additionally user expectations increase in conjunction with advances in consumer technology.
In the traditional enterprise mobile space, many organizations in the past 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 support will end. At that point, there is usually a scramble to think about new devices and the options, alternate vendors and solutions that are out there.
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, which has a mobile solution that includes integration to a business system and offline capabilities including some peripheral integration such as printing and/or scanning. Let’s say they are leveraging a rugged mobile device that will shortly become unavailable and out of support. This may be somewhat more complex than users of web applications who are moving from iPhone 6 to iPhone 7. However, the steps are similar in a conceptual sense; the process is 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 mitigated the risks in a cost-effective manner.
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, make sure you 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 method for doing this is to shortlist devices and then bring the hardware manufacturers and/or demo devices to the stakeholders to show the relative pros and cons of each. In our hypothetical scenario, it’s not just the mobile device that is important; one must consider associated peripherals like printers and scanners as well.
Once a subset or a limited number of devices have been established, 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 rundown, 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 the operating system and hardware changes and may require cycling back with the software providers. Once it works from a technical perspective, it’s best to do field tests 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. Changes occur rapidly 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. At the end of this, you should prepare a summary of findings along with a recommendation based on the facts.