COBOL Architecture Astronauts: Mountain MOVErs?

This is another entry in my ‘Legacy development paradigms are the greatest source of legacy problems’  series.

Architecture Astronauts are developers who create a complicated solution to a simple problem in order solve a bunch of other potential, and probably imaginary, future problems. Every day developers all over the world fight their inner Architecture Astronaut, and every day, thousands of them lose that fight.

Over the last couple of years I have seen a lot of legacy systems built in COBOL, NATURAL, RPG and PL/1.* Expecting overly designed hyper-abstract “frameworks”, I am always surprised at the incredible pragmatism and restraint shown by the developers of those systems. At worst you’ll find a dynamic call, where the name of the program being called is passed in as a variable, or a common error routine. 

Legacy mainframe code usually is incredibly verbose, not necessarily because the language requires you to write a lot, but because legacy developers did not reuse business logic or at the very least they try to avoid doing it. Or: 20 years ago code reuse was the stuff Architecture Astronauts came up with while mainstream mainframe developers avoided it.

Programmer A: So, I need to validate this postal code. Didn’t you already write code that does that?

Programmer B: Oh yeah, here: copy & paste the bugger!

Programmer A: Eh: can’t we move that in a common function?

Programmer B: ARCHITECTURE ASTRONAUT! ARCHITECTURE ASTRONAUT!

As usual I am exaggerating, but there is a core of truth there: reuse was not harder to implement than in modern languages, but developers just did not do it on a regular basis. I’d like to say that that was caused by unsophisticated specification and design phases and a less mature software engineering practice, but that is not true: most, not all, reuse in modernized development is done by developers, while implementing, after the designs were created.

Developers communicate business needs in code, and computer restrictions into conversations with users. But the whole practice of software development itself is also guided by a higher level of fads: assumptions about what can, should and may be done in code and how it should be implemented. The more I think about it, the more important these ‘paradigms’ seem to be compared to the individual choices of each developer or team. The quality and business alignment of your system is heavily influenced by the paradigm that was used to develop it.

Next in this series: ‘SOA: where Architecture Astronauts mate’.

- Mik Lernout

* Note that I always refer to legacy languages in uppercase but I do not line break after 80 characters. Inconsistent, I know.

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