Modernize your Cat? Sure.

I came across a white paper from Software AG that attempted to make a case for not modernizing legacy systems, but rather to attempt to extend their life by exposing existing functionality to other systems. Although I can see the benefits of this approach in certain tactical situations, I disagreed with this being a sustainable long term solution to the business drivers that are behind today’s modernization projects.

There were many good points cited that anyone facing a modernization project needs to consider. The point is made that your legacy system contains critical, unique functionality that has evolved through the years and that differentiates the business from its competition. Yet this functionality does not exist in one place, but rather in many places: manual processes performed by users, work around processes, business logic in the application and the system data and structure. Since there is typically little understanding and documentation of all of these system layers, any kind of replacement effort is full of risk. There is the risk of missed requirements, the risk to schedule and the risk to budget, just to name a few.

Where my real life experience started to part from this white paper was when the argument was made that modernization, the replacement of legacy technology with modern technology, is unnecessary and even detrimental to the business. There was even a comparison made between computer modernization and replacing the family cat, suggesting the two were equally ridiculous. These arguments were supported with statistics from a 2007 survey that found 50% say it is too risky to migrate off of the mainframe and 28% have tried and failed to migrate off of the mainframe. Scary statistics indeed.

With all this doom and gloom around modernization why not (so the logic goes) consider extending the life of your existing application(s) by exposing functionality with web services, commonly known as SOA wrapping, thus allowing the development of additional functionality in other systems as well preserving the years of business logic that already exists in the legacy application. Surely this must be a lower risk, lower cost approach, no?

Actually this is not a new idea at all. Back in 2000 when I was working at one of Canada’s largest telecom companies this approach was embraced under the guise of Enterprise Application Integration (EAI). Around this time a project was initiated to identify a limited number of functions within the customer information and order entry systems that could be exposed for other systems to use. After 3 very experienced contractors had spent about 18 months writing wrapper code, a handful of interfaces were ready for use within the enterprise. Concurrently, I started a large project to build a web based qualification, ordering and provisioning system for IP-based products. Two of the eleven systems we needed to interface with were the customer information and order entry systems. I was happy to hear about this EAI project that had exposed key functions I would need for my project.

Unfortunately, things are not always what they first appear to be. First, we ran across significant issues when testing against real life situations, and as such we needed to put in extra time for bug fixing. Next, we found that there were a number of new data elements required for our new application that had to exist in the legacy system – this was almost a show stopper for us as the challenge of adding these elements to the mainframe and the wrapper code was not an easy task. In the end we got it to work, but at a significant cost. In total, our new application was about 148,000 lines of new Java code, including about 31,000 lines of wrapper code dedicated to a small handful of interfaces to two of the mainframe applications. One full time equivalent was required to maintain the wrapper code that we developed, in addition to the one FTE that was required to maintain all the rest of the application code. Just under ¼ of the software development project budget was used in bug fixing and enhancing this wrapper code. Not only is the legacy system still embedded in the heart of the IT infrastructure, now it is cemented even further with wrapper code that adds to the overall complexity rather than reduces it.

- Grant DeCecco