Have you ever tried to build a new solution on top of a legacy system?  An “undocumented, patched a thousand times, two people in the world know how to keep it running, backed up with reel to reel tape, and interfaced to other systems with baling wire” kind of legacy system?  If you haven’t, then count your lucky stars, knock on wood, and pray to the IT gods that you won’t ever have to.  If you have, then you may still be having nightmares about it all.  Or bald patches from where you pulled your hair out?  There, there.  It’s going to be okay.

Why do legacy systems get to stay in operation, despite the availability of more modern, streamlined systems and products?

1. They work.

Maybe not efficiently, but at least reliably.  As the saying goes…if it ain’t broke, don’t fix it.

2. Zero investment.

Like your dad’s old Buick, the investment paid off a long time ago.  Why replace something that you’ve already purchased as long as it is still running more or less like you expect it to?

3. Easier to fix than replace.

So, you get a flat tire. Do you buy a new tire, or just patch it? You patch it, right?

4. It is the backbone to multiple other systems that are also working, more or less, as needed.

Ever heard of a backbone transplant?  No, me either.  If you try removing the spine, how will the other systems keep functioning? That sounds really hard. That sounds like down time.  That sounds like…a risk!

So, yes.  These are all relatively decent reasons for legacy systems to stay in operation.  Many government organizations keep legacy systems for the additional reasons of budget limitations, running support programs that the public depends on (and legislation mandates), and making any past investments in systems/software/resources worth the cost.

The negatives of legacy systems can be numerous and complex, many of which I hinted at in the opening  paragraph.

1. They are often poorly or partially documented.

Trying to understand how (or why) a legacy system is operating can be a guessing game, if you look at the documentation.  Try fixing dad’s Buick without some kind of owner’s manual.  There may even be original documentation, but it may be lacking or simply not contain the level of detail required to be truly informative.  This is in large part due to the…

2. Numerous patches (several a year for x years of legacy system life) changes the original system.old buick

Over the course of so many years of minor to medium changes and adjustments, nothing is as it was when the system was “born.” Temporary workarounds that became permanent, a patch that made a certain process faster, or the other patch that added a whistle instead of a bell–they all changed the system into something different.  After awhile, it’s a complete rebuild and a complete departure from that “factory original” you started with.

3. Few resources truly know how to manage them well.

As legacy systems age, so do their caretakers.  Sometimes it’s not so much about age, but that the system is too complex to keep track of all the moving parts.  It is difficult for one person to know it all, but sometimes there is one expert who does.  However, many people change jobs in the course of a legacy system’s life.  You can’t MAKE a system expert stay, so what happens when they decide to leave?  Oy, the system is often more jumbled by the new caretakers who do what they can to keep it running when it’s handed down to them.  What do you do with dad’s Buick when he gives it to you to take to college?

4. Back-ups are not modernized.

Here we are in the age of the cloud, but legacy systems are still operating with whatever antiquated back-up systems they were made to work with.  They are probably more up to date than the tapes I joked about earlier, but probably not very modern or efficient.  Does your dad’s Buick have a cassette tape deck?  Yeah, I thought so.

NOW, though…it’s time to modernize, and BPM product solutions are likely the best bet for making a less painful transition.

Business Process Management software is able to fast-forward the development process while streamlining existing business processes and leveraging out-of-the-box features.  It’s a good place to start when considering the first steps to phasing out legacy systems.   There are several options to begin with, when considering the switch over…

1. Update user interfaces (UIs) to provide a new look and feel to existing systems.  BPM products can “wrap” the legacy systems with more intuitive UIs that are easy to navigate and can improve the user’s experience, while still leveraging the legacy system’s backbone.  Such an update is a good initiation to modernization efforts and how BPM products work.

2. According to an article by Joe Gentry, VP at Software AG, another “option is to integrate the legacy system with 25 or 30, or even 100 other applications running on the mainframe or on smaller servers. This is the most sophisticated approach and provides the highest degree of flexibility. To do this you will need to move toward a Service-Oriented Architecture (SOA), by extending legacy and other applications as Web services.” This isn’t news in the IT industry, and some legacy systems are already leaning toward this approach.  BPM products can further capitalize on the reusability focus of SOA and significantly speed up production of new applications with standard frameworks to build upon.

3. Focus on outward facing applications that interact with the legacy system as a “system of record.” Outward facing applications to support mobile functionality and/or social media can provide more “bang for the buck,” at least for clients who have grown accustomed to having service at their fingertips.  The legacy system can provide the muscle behind the new service, while BPM solutions provide the agility of modern functionality.

4. It’s generally not advised IF the legacy system is functioning well, but there may be cause to perform the dreaded “rip and replace.” It’s a scary undertaking, and several past attempts have resulted in dreadful failures, but sometimes, it just has to be done.  Planning is obviously key for success, and assuming the phase-out of the legacy is something that can happen over time, decision makers have the ability to weigh all options.  BPM products that have been proven with measurable success offer robust frameworks and support services to begin anew.  Investment in any additional or new hardware is something that must be carefully planned, as well.  But we already know that.  The real test of “rip and replace” is when there is no time and it’s mission critical.  In this case, too, BPM solutions are your friend because of the out-of-the-box functionality that significantly decreases development time.  A recent Capgemini study found that it is 6.4 times faster to develop applications with Pegasystems’ Pega 7.1 product than with Java.

If your company or organization is facing the challenge of updating your legacy system, please contact ATS by e-mail at orangebpm@architechsolutions.com or by phone at 703-972-9155.  We can provide the analysis and manpower needed to add a BPM solution to your enterprise system, making the transition to modernization easier than driving your dad’s old Buick.