Executive Overview

This is Part 2 of our Legacy Applications Series, visit Part 1 here, and stay tuned for the next one.

All of us in our Careers as Executives have encountered Software Applications and systems that over time have degraded in their capabilities, can no longer support the business in its current state, becomes too slow and costly to maintain, or worse is mission critical but very few people know how to support it.

The question that always comes up is, do we:

• Fix It?
• Replace It?
• Re-Architect It?
• Or “Pray” that nothing Bad happens… and that we can hold out just one more year.
  

Of course, any of the above Options may work and they all have some costs and risks associated with them, especially if the system suddenly stops working at an inopportune time. In this Blog Article series, we will discuss the primary Business Drivers, Technical Considerations, Decision Criteria, as well as several real world Examples.

Fix, Replace or Re-Architect

Every IT Executive when faced with these decisions has several potential Tactical Approaches to take:

‍

Fix the System

This is normally the fastest and lowest costs approach, as you are only focusing on those individual components of the System that are prone to failure, deprecated and need to be replaced, or Technical Debt that is critical to fix. Considerations to take into account.

• Quickest Option
• Normally the Lowest Cost Option
• Only Minor changes (if any) to the User Interface, Functionality & Features
• May be Just Putting a Bandaid on the System that will need to be addressed later

‍

Replace the System Entirely

This option should not be considered lightly, regardless of whether you are migrating from one Custom Application to another, or from or to a Commercial Off The Shelf (COTS) Application.

There is often significant costs in terms of:

• Custom Development and/or Implementation Costs
• Data Migration & Testing Costs
• Training & Documentation Costs
• Process Changes within the Organization - as things will be different

• BE VERY CAREFUL OF WHAT YOU HAVE CAPITALIZED:‍
• Whatever your reasoning for Replacing the System Entirely, you absolutely need to find out how much you still have on “Your Books” in terms of Capitalization.
• Otherwise, by simply taking an Asset Out of Service, you will have to immediately Depreciate whatever is left on your Books.
• And I guarantee you that your CFO is NOT going to be Happy about taking a large write-off.
• Most Enterprise scale applications may be Capitalized over 3, 5, or even 7 years. Find this out.
  

Managing “Change” and ensuring that there is adequate communications to everyone affected by this Change is critical. Too many Technology Replacement Initiatives have failed due to a lack of adoption and/or resistance from the various User Populations.  

You can have the greatest new widget in the world, but if no one wants to use it for whatever reason, it doesn’t matter.

However, there are times when this really is the only option:

• You’ve outgrown the Application and can’t scale it any further
• The Application Vendor no longer Supports it
• The Technology / System / Database / Programming Language, etc. is so OLD you can’t find anyone - Direct Hires or Contractors to Support it, without paying a Lot of Money
• The System has significant problems (Security, Compliance, Data Loss, etc.) that simply cannot be fixed or mitigated in any way
  

‍

Re-Architect the System

This is an option when you own the Intellectual Property (IP) of the Application or System. In this case you are making fundamental changes to the Core of the System, potentially affecting one or all 3 major Tiers:

1. Front-End User Interface
2. Middle Tier - Business Services / Micro-Services Layer
3. Back-End Database & Data Storage
   

Since this isn’t a “Replacement” of an existing System, this is akin to Swapping Out Parts of the Airplane, WHILE IT IS FLYING!

So, if you are going to do this and fundamentally upgrade your Custom Application, the absolute best way (IF - BIG IF, it is possible) is do this one Module or Component at a Time. This way the overall impact to the entire System can be minimized, and it will be significantly easier to fix and resolve any Defects or Bugs that do occur.

Remember that the greater the amount of Change that you create in a System, the greater the chance of it Failing (Law of Entropy).

However, there are times when this really is the only option:

• You’ve outgrown the Application as designed and can’t scale it any further
• The Database Structure needs to be completely redesigned to support new Business Features and Functionality
• We are experiencing Data Loss or Loss of Transactions
• It is getting too Expensive to Support and Maintain the System Internally
• Technical Components need to be replaced, i.e. no longer Supported by the Vendor
• The System has significant problems (Security, Compliance, etc.) that simply cannot be mitigated in any other way
  

‍

Just Let it Die - Turn It Off

There are times when a particular System or Application is no longer useful, other than for maybe a small handful of users. But the reality is that it provides very little or no overall business value, and the costs of trying to maintain it is higher than the value.

So, sometimes you just need to “Turn It Off” and put the Application or System “Out to Pasture.”

• Do you have a Telegraph Office in your buildings?  Nope
• Do you have a Telephone Switchboard Office in your buildings?  Nope
• How about an Executive in charge of Electrification?  Nope
• Manual or Electric Typewriters?
• Carbon Copy (cc) Paper?  And for those who don’t know that is where the term “cc” comes from used in emails even today.

‍

Conclusion

In this Blog Article we’ve covered the main Business Drivers, Technology Considerations, and Options that you might take as an Executive or Organization.

In Part 2, we covered which approach you take in either Fixing, Replacing, or Re-Architecting your System / Application, will depend greatly upon your individual situation and business needs. In Part 3, we will provide you with several real world examples, including the challenges and considerations which we took into account. We hope that this Blog Article has been valuable to you.

Thank you, David Annis.