Got Legacy?

Share on Facebook

10 years ago I was tasked with estimating the development effort for a small enhancement for a production application. The enhancement work was to be divided between a colleague of mine (Gilberto) and myself. Gilberto’s part was so simple at the surface that I estimated only 2 weeks for it (including contingency!). When the poor chap started to work on the piece however, he discovered that his enhancement touched on a hidden complex piece of code (called KCC – Key Code Component in MAKE’s TLM Methodology) which contains logic that was developed and maintained by many developers over many years.

I still remember at the end of the two week period, both he and I had a meeting with the project manager to give status on our progress. My piece was complete, but Gilberto’s delivery was this statement: “With friends like Sinan, who needs enemies?”.

That was an excellent lesson learned in life about being cautious when approaching the unknown. It applies not only to programming code but to any task a person is undertaking for the very first time.

This problem is very prominent when it comes to modernizing legacy code that took years to build, where at the beginning, no one really knows when a certain piece of Key Code Component is called and what it does precisely. The Modernization Sales Team and Project Management will always be faced with the challenge: “How to estimate the unknown?”

To visualize the challenge, let’s assume that we are modernizing a product made of a closed box with Input Control Buttons and Output Lights (see figure 1).

We don’t know exactly what the logic behind the buttons (inside the box) is, but we can go through the analysis phase:

- discuss the purpose of the box with the business

- document what is known of how the box currently behaves (PCA – Present Case Analysis)

- document how the Business wants to enhance the box’s logic to behave (FCA – Future Case Analysis)

When it comes to the Development Phase however, the Developer in charge of modernizing the Key Code Component will start to read the code behind the buttons (hence, opens the box). The Developer may face a simple logic (figure 2) or a more complex one (figure 3).

The more complex the logic in the code is, the more effort it will take for the Developer, Business Analyst, and the Business to accommodate the enhanced logic and make it co-exist with the current logic without breaking one another. It is this effort that can not be estimated.

So how do we estimate the unknown? During the analysis phase it usually becomes apparent for the Business Analyst that there is more inside the box than the eye can see (if they encountered scenarios that the Business can not explain for example). It is important then to mark the logic behind the box as a Key Code Component. A legacy modernization project that succeeds in highlighting its KCCs in the Analysis phase allows the System Analysts (Developers analyzing the legacy code complexity) to parse the KCCs and provide closer estimates for the effort that will be required in the development phase.

Any unidentified pieces of KCC, or lack of proper analysis for the impact of enhancements on KCCs will cause the estimate to quickly go outside of the ballpark.

- Sinan Ali

Share on Facebook

Over the last couple of months we, with the help of our great partners Barrington Consulting and Service Nova Scotia, have deployed a new system for both the Vital Statistics and the Department of Motor Vehicles of the province of Nova Scotia, into production. Hundreds of people all over the province of Nova Scotia lined up to get copies of their birth certificate and register their new truck. And it worked. Some of the regulars told us it was one of the smoothest go-lives they had ever experienced in the province.

So: We went in, aligned and analyzed their existing, expensive, mainframe application and replaced 2,393,000 lines of Natuaral/ADABAS code with 483K lines of Java and 195K lines of XHTML, and then successfully deployed the sucker.

You could also rephrase that as: we went in, took out a barely beating heart, and put in a brand new one; patient got up, thanked us and walked away. The enterprise software equivalent to jumping over a car.

- Mik Lernout

Share on Facebook

Introduction: One of the common challenges faced when attempting to modernize an old legacy application that is heavily rooted in the business is to envision how the disparate parts of the new system will interact together to provide a similar business solution to the one the legacy provided.

Examples: Let’s review a couple examples of pitfalls that could become major obstacles in the way of successful delivery:

Challenge 1: Hey, where did my extract go?

Some legacy Batches (programs that are scheduled to run unattended by users) extract newly entered records according to certain criteria to a flat-file. This process is followed by another batch that reads the extracted records, updates them according to certain logic, then populates some other table in the system with them (see figure 1).

A Modernization Specialist (a Developer in the role of System Analyst) modernizing such a set of Batches can reasonably design a modernized System-Event (a program that may have no interface and is usually scheduled to run unattended) that simply skips the extract part and runs a script to insert the records into the destination table with the required updates (see figure 2). Meanwhile, the System Architect (in charge of making core, high-level system design decisions) might have reached an agreement with a 3rd-party that expects to be fed with the flat-file extract to keep sending them the file as is (not being aware of the history behind the file generation).

Once the modernized System-Event is built, there will be no flat-file generated which means that the 3rd-party would not be receiving their file. This kind of problem is actually hard to detect, because all parties have assumed no changes to the existing extract and hence minimal follow-ups.

Prevention: Clear communication between System Analysts during the design phase minimizes the chance for such pitfalls to happen. The System Architect can lead the System Analyst group in one or more sessions to secure against missing pieces.

Challenge 2: Report numbers look all funny!

While most legacy reports are produced by the programming language code as part of the program, the reporting technology to be used in a modernized application is very likely to incorporate a reporting server (Cognos, Crystal Reports, etc.). This presents the challenge of synchronizing modernized application programs calls to related modernized reports.

Consider the situation where a legacy Batch made of 5 legacy programs, each producing 1 legacy report being modernized into only 2 modernized programs. If we don’t keep track of which legacy report is executed when, and ensure that we are calling the modernized reports from the equivalent stages of modernized System-Event processing, the report numbers will not match.

Prevention: We have to start by proper documentation of legacy reports and where they are called from. This is to be followed by documenting the modernized reports and their parameters (we may combine a few reports together, ignore some reports and generate new ones) and finally properly linking the modernized reports definitions to the legacy ones in order to empower the developers modernizing the Batch code with enough information to make the right report calls at the right time.

Conclusion: A legacy modernization project can be a huge undertaking. Paying attention to details and making the right modernization decisions is not enough to ensure successful delivery. You may modernize every part of an application, but the new pieces may still not work together to deliver the same solution the legacy application delivered, hence delivery failure!

The modernization methodology should be comprehensive enough to ensure that the big picture is not blurred by all the details.

- Sinan Ali

Share on Facebook

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

Share on Facebook