Innovation in the IT Legacy World

“Legacy” seems to be a “bad” word in the business world, and it tends to denote antiquated; methods, software, hardware, etc. Yes! I refer here to many IT Systems that drive businesses.

But many “legacy” applications that keep dominating the IT Business world—are Mainframe and Mid-range based. They still manage the bulk of the business transactions. Some popular applications are considered legacy—even though they are short years young.

Software Application Packages

Here, I will be concentrating in the mainframe and more specifically mid-range market; although this applies as well to Networked based systems, Unix/Linux and Windows based applications.

Many Applications Packages as “Canned” Software as they are commonly referred to since a third party develops them. Others called  “Home Grown” so referred to as they are developed in-house by resident developers and consultant. They both have, in most cases, designs, methods and source code 20 to 40 years old. Many are maintained with more new programming language’s code (intermixed with various more modern programming languages). Of course, the hardware is often top-of-the-line and state-of-the-art, as they are sometimes easier to migrate to since; they tend to be backward compatible with older hardware. Meaning that a site may be operating with the latest hardware, running antiquated Application software. And losing some of the advantages of more modern hardware architecture.

Yes, these applications are being maintained—many of them, even with great coding practices and tools, but mostly (sadly) without the structural changes need. Meaning here that they are not taking advantage of modern Relational Data Bases available and powerful new programming languages and tools.

These software maintenance practices which we call “patching”—a good method to solve immediate needs, but these changes & quick fixes, left that way—which is the norm that generates a long-term negative consequence.

These code changes applied could be for fixing old code, fast and localized; much by “Hard Coding”—where you supply data directly in the code, instead of by table or parameter input. Many changes are done with new code introduced by “Branching”—where you make a copy of a similar program and make some adjustments to it (leaving obsolete code untouched).

Some changes are implemented by attaching new tables and using unused data fields on old tables, using them for new purposes, even when the data type do not agree—like using a character/text field to store a number or a date, or using a larger than needed field.

And some applications still have remnants from the Y2K era modifications (the year 2000 problem—remember?), with mixed date fields and multiple fields to hold one date—like one for the century, and one for the year, etc. All these complicate maintenance by creating high or complex dependencies.

There is also the issue of missing or unidentified source code, bad coding practices—sometimes called “spaghetti code” because of the complex and tangled control structures.

Of course, there are challenges to “modernization” efforts, including outdated, obsolete documentation, or no documentation; but these challenges are not a good excuse—at least not always.

These short-cut solutions which are very innovative in a way; do solve the immediate problems fast, but sadly, failing to innovate for the long run. The equivalent of “kicking the can down the road,” putting off a more comprehensive solution for later that never materializes.

They (we—as I include myself at times) incur in what is called Technical Debt. In business terms, accumulation of Technical Debt; the more you do without correction or temp fixing, the bigger the cost down the line.

There is both Coding Debt and System Debt since architectural enhancements are a better solution and future proofing. We can add to the problems data quality issues; bad data and not taking advantage of the great features provided by all RDBS—Relational Data Base System available.

There are established methods and alternatives for proper application software modernization:

• Get a new Software Package — sometimes still legacy itself;
• Do “Screen Scrapping” — which amounts to a “facelift,” by wrapping or encapsulating some of the old code with nice looking Windows or Web-based designs which will make it “look good” and up-to-date. This is quite common;
• Do a full Re-design and code rewrite — To redo everything from scratch, which is very costly, and;
• Migration — move or convert the software and data to a more modern version of the same software or a different vendor’s package which is also costly.

And, there may be a better method for modernization; do an evolutionary re-engineering, by which we employ continuous improvements methods. Use modern coding techniques and practices; use the better programming language versions.

Under an agile plan, you take every opportunity to improve your design and coding. Little by little, use every opportunity you do maintenance, to advance ‘the cause.’ This minimizes the Technical Debts. And you can also implement specifics updates modernizing what you have.

It may be ok and wise, many times, to do the quick fixing and solve the immediate requirement/ problem; but then start paying your technical debt. Revisit the program (s), or modules and start to rework them, even documenting.

Many benefits are to be gained for sure: improving skills, increasing satisfaction — end users and developers. And facilitating your next maintenance/enhancements.

Apply innovation little by little. Some fixing may not be made in isolation and may require coordination, but much can surely be improved, facilitating future enhancements, reducing overall cost and avoiding the technical debt.

This not only increases the value of what you have but may help in the future migrations or the major improvement efforts. Lowering their likely Costs as Risks. All this thanks to Innovation in the IT Legacy World.