Mobile applications have become a recurring topic everywhere we turn.
Our customers’ IT departments are being pushed by their business units to create all sorts of mobile interfaces. If you look at the application backlogs at most IT departments, you’ll find more than a couple requests for something mobile.
Most of those requests include extending existing legacy systems to provide mobile interfaces that can be used by customers, partners or employees.
If you’re about to leap into the mobile world and need to provide unique capabilities that are extensions to existing systems, you probably have big plans to customize or upgrade those systems to enable mobile access. If this is the case – Read on before you Leap!
Or consider this an intervention.
So your business says they want mobile; they have to have mobile! We understand. The growth in mobile app usage and the prevalence of mobile phones and tablets in the workplace (and all the BYOD frenzy that everyone is writing about) makes having mobile a necessity and also an opportunity to increase worker productivity.
Think about maintenance before you start:
Please consider this before beginning a mobile adventure– the cost of customizing your legacy systems to implement mobile will grow exponentially year after year. It will eventually create a maintenance nightmare and may even hinder future product upgrades. The older and more monolithic the legacy system, the larger the maintenance problems will be.
The cause for this is simple: mobile applications require a level of flexibility and a pace of change that is completely different from the pace of change of your legacy system. For a mobile application to work and be adopted, you’ll need to focus most of your energy on delivering a great user experience (UX). No matter how many usability tests you do, one thing is certain: when the app is rolled out to your users, you’ll discover a lot more changes that need to happen in order to provide a better UX. What this means is that you’ll need to have the ability to quickly adapt your application (to change it’s interface or even business logic) and redeploy a new version of it, so it can be in the hands of users for another round of validation. This level of flexibility and adaptation is something that simply doesn’t exist in the world of legacy systems.
Two additional items to consider that can make or break you endeavor are performance and security. If you’re extending a legacy system that is used by 100 people and all of a sudden make it accessible to 1000, you’ll definitely hit a scale problem and you’ll see performance go down (of both the original system and the new mobile interface).
In terms of security, besides the obvious user access considerations, you need to think about your data. All of a sudden, the data that was stored inside that old legacy system behind that firewall becomes available on the mobile devices of your users. This leads to architecture choice. And if you decided to go for a native application approach, it is more likely that some of that your data will be stored in the user’s phone! When we consider the number of phones that are lost or stolen every year, the risk of information leakage gets really frightening.
Keep your legacy safe:
Instead of heading down a path that will increase your technical debt and induce performance/security related heart-burn, consider stabilizing your legacy systems – that is, don’t change them. Leave them alone!
Leaving your legacy systems intact allows you to keep the value you have built into them over the years without the risk of “breaking” them, and you will keep the maintenance and operational costs stable. They were built to last, so don’t try to change them!
If you got to this point, then you’re ready to start thinking about extending your legacy with a mobile layer.
Build a mobile layer that’s prepared to change:
With your legacy system untouched and stabilized where it should be, you can start thinking about extending it.
The approach is relatively straightforward (although not simple):
- Leverage your system’s APIs to access data and functionality, by creating a set of integration services that use those APIs and that provide caching, synchronization and security;
- Create a set of business services that will be used to implement the business functionality in your mobile application;
- Focus on designing highly usable mobile interfaces that will lead to high user adoption.
By doing 1 and 2 you’ll be creating an important foundation of software components that can be reused in other applications. That will set the base for a Service Oriented Architecture (SOA) that you can then grow to leverage previous investments and deliver more applications faster and cheaper.
Step 3 requires some additional understanding of UX, and that’s enough for an entire series of posts, so we’ll leave it for another time.
The ultimate trick to make this all work is to ensure that, whatever you’re building, it needs to be extremely flexible and ready change.
Examples from the real world:
It always seems a long way form talking about it to actually making it happen, and the best way to really understand if this works is to see examples of how others have done it.
Last week we ran a webinar with our partner Conigent, where they took the audience through the case study of a mobile application they built for Sheetz, that extended their ERP, built in record time with the Agile Platform.
In the words of Ameet Shah, Conigent CEO, “We were able to deliver highly differentiating applications at record speed, without modifying source code of the ERP application and all the while we were doing this while maintaining quality and preventing ourselves to ever refer to these applications as legacy applications”.
For the full story check out the recorded webinar here.