When you are faced with the mission to modernize your legacy business applications, there may seem like countless options to choose from. This assignment can be very intimidating, so take a deep breath and let’s explore your options.
Legacy Applications – Asset or Curse?
First, we must set the stage by placing a value on your legacy system. The questions below will help you decide if your legacy system is an Asset or a Curse. I’ve given you a hint on a couple of the questions!
Question 1: If your legacy system runs today’s business, then it’s an asset… assuming you like the business you’re in, of course!
Question 2: For reference, Leno took over the Tonight Show in 1991 when the AS/400 was a toddler. If your legacy applications are that old, they have stood the test of time and adapted to transitions in business. Then again, they may also now be limiting business or you wouldn’t be reading this blog!
Question 3: The Iron Lady was first elected in 1979, when the System 38 was new. Both earned a lot of respect, but I don’t think we want either of them running things at this point.
Question 4: Reliability is great, but it also often means that legacy applications can be taken for granted and forgotten, especially around the time of budget planning.
Question 5: Your legacy system grew along with your business. At this point, it is probably as unique as your own business offerings, which makes it an asset. However, question 5 also reminds me of a story involving one of our customers in the insurance industry. Let’s call them “Legacy Insurance.” Before our project started, we interviewed independent insurance brokers. When we asked one broker why he dealt with Legacy Insurance, he explained: “Well, some insurance companies offer brokers access to online quotes, access to view their clients and policies, to renew policies, or even the ability to log and review claims. Some of them even offer mobile services to us and our insured. And . . . if we don’t need any of that stuff, then Legacy Insurance is a really good fit.” I almost let out a laugh.
Question 6: One of the nice things about a well-written legacy system is that your data is well protected, but is it so well protected that business information and transactions are not readily available to internal resources, field agents, partners and customers? If so, that’s not data protection, that’s fear.
Question 7: Your system is RPG II and has internally described files? Curse!
Now that we’ve evaluated your current system, let’s explore three modernization options that I call the Big Bang Theory, Frankenstein and Darwinism.
Big Bang Theory
We’re not talking about the American television show featuring Sheldon, Leonard and ‘knock knock knock Penny’. I’m referring to a modernization approach where the entire legacy application is replaced all at once, in one great moment. The Big Bang approach can be achieved by implementing a package, re-writing or through a mass conversion project.
The table below considers Big Bang techniques as they relate to aspects of database, business logic, presentation layer, inherent risks and business agility.
If you’re only going to consider one factor in determining your approach, I suggest you focus on Business Agility. Ideal business agility is achieved when your system has the ability to adapt quickly and easily to any direction the business shifts. So how well do the three techniques of the Big Bang Theory achieve business agility?
- When you implement a package or subscribe to a Cloud solution, your business agility depends on how configurable the system is. Ultimately, you end up riding along with whatever new features are added to the solution.
- If you re-write your solution from scratch, the business agility achieved depends on the toolset you chose to write in. Is it repository based? Is it hardware-platform neutral? Can it deploy to all different types of user interface devices?
- If you decide to achieve the Big Bang through a conversion process, your business agility usually worsens, at least in the short term. Your system perhaps is now written in C++ or Java instead of Cobol or RPG, but is the new code any more maintainable that it used to be?
Frankenstein
This modernization approach sounds monstrous, but isn’t necessarily. The Frankenstein method involves starting with your core database and core functionality and then ‘bolting on’ parts to achieve new functionality. For example, the Hunter Douglas company, Carole Fabrics, had a MAPICS legacy system and rudimentary e-commerce ability. However, their customers needed a way to design custom window treatments and visualize the end result. Rather than replacing MAPICS altogether, Carole Fabrics bolted on an elegant web-based design interface that allowed users to browse fabrics and window treatments, ultimately feeding orders directly into MAPICS. This approach worked well for Carole Fabrics, increasing their market share and opening up doors across several new business channels.
The table below considers a few Frankenstein techniques as they relate to aspects of database, business logic, presentation layer, inherent risks and business agility.
How well does the Frankenstein approach effect business agility? It can be quite useful as a tool. In other words, if you have a solid core legacy system and can quickly bolt-on the added functionality you need, you have achieved business agility tactically, which can be a bring significant business value.
Darwinism
Finally, we’ll consider Darwinism as a modernization approach. Darwinism aims to achieve a superior system state through – you guessed it – evolution. With this approach, you embrace the legacy system but gradually reconstitute it so that it becomes more powerful, flexible and future ready.
As the table below shows, you can evolve the user interface framework to allow for modern navigation. You can also externalize the system’s business operations workflow so that it can easily adapt to changes in business volumes or new procedures. Additionally, you are able to expose core functionality as callable services that can be leveraged by other systems in your organization or that of your business partners.
Extending the Carole Fabrics example; the successful launch of their web-based Designer Workbench has created a buzz among not only their customers, but with their competitors as well. Several of these competitors have approached Carole Fabrics to negotiate a partnership whereby Carole’s designer functionality can be exposed as a service. This would allow Carole Fabrics’ partners to offer their customers the same design experience as Carole’s direct customers, and yet preserve the partner’s branding and sales channel. If your approach to Darwinism results in a modern and flexible user framework, externalized business workflow and the ability to expose services to partners, your system is truly evolved.
So, if you’ve got a legacy system, recognize how it is likely both an asset and a curse. Then, determine which modernization approach is best for you. Just make sure to keep your eyes on the ultimate prize – business agility!
