Cars Age Better Than Applications
Every Friday night in local towns there are displays of vintage cars, all immaculately maintained, engines clean, leather polished, windows and dashboards gleaming. Some were top of the line originally, some were more mass produced. Some date to the 1980s and some to the 1940s. But all can still serve the same purpose of transporting people in style.
Computers and their applications don’t age in the same way. Computer hardware components are more complex and subject to failure, there are components that cannot be replaced (hard disks) without huge loss of function, and when a vintage car doesn’t meet modern safety standards (e.g. absence of seatbelts) you can apply for an exception from the government – you don’t get an exception granted by hackers to your outdated operating system.
Keeping the 2008 Ford Taurus on the Road
A better analogy for an aging application is a 20 year old road vehicle. You may be keeping the vehicle running because you don’t want to shell out on a new car – you know the faults of the vehicle, you’ve long since paid off the loan and your trusted mechanic has kept it going so far. You are familiar with all of the dashboard functions (that still work) and you can get the spare tire out in less than three minutes from experience. You’ve got the seat covers you like and they don’t sell 6 CD carousels anymore. Sure the transmission is slipping but a small(ish) investment should patch that so why not another year or two?
Although there are advantages to the car it represents an increasing technical debt to you. Each year the amount you have to pair for repairs increases. Certain spare parts may be harder to locate. There is increased risk because components may catastrophically fail and the car lacks modern safety features.
Eventually reality has to be faced – whether from the simple cost of running the application or the fact you would never drive your kids in the vehicle the technical debt has become too great.
Time to Call the Garbagemen?
Aging applications have a similar consideration process – there are many advantages to retaining the old application but the technical debt is growing every year. The application is fully depreciated, all interfaces are running, most bugs have been long since worked out of the application, your users grumble incessantly but know every screen and table name and the vendor’s account manager has been taking you on golf outings for years. Why not a year or two more?
As discussed in the technical debt article there will be increasing cost and risk for sustaining the old application. As the application ages there will be multiple challenges:
- As the hardware ages the support contracts may not be available or will be at a premium.
- Fewer people will know or want to work with the technology (or be of lower skills) which will increase the cost.
- Operating system, database and application and patches may come at a premuim or even not be available.
- The risk of hardware failures will increase and availability of spare parts will diminish.
- Fewer or even no patches increases the risk of cybersecurity breaches.
The most common reason for not retiring the application is that there is still significant reporting required against the data and there is significant cost in actually retiring the application because of the cost to design, build and test the reporting. Once again this is an example of poor data governance but once data subject to records retention has been left in a legacy application the cost often cannot be avoided.
Ultimately the application has to be sustained until the records retention period has run out and the data is not subject to legal hold or the money has to be committed to archiving the data. Typically a tipping point between convenience and technical debt is reached and the application is retired, and you have to hope this happens before a catastrophic event leading to hardware loss or cybersecurity breach.
Zombie Application
Even worse than hanging on to the 2008 Ford Taurus as your main car for two years too long is buying a new car AND keeping the Ford Taurus. Here the analogy begins to break down but for applications many times the business wants to hang on to the old application even after the new one is up and running. Typically this is to support reporting needs when the data hasn’t been fully migrated (poor data governance) or because the business is too focused elsewhere to participate in the retirement (poor technical debt management).
And a zombie application is born.
Logically no-one wants to be in this position but too often through poor planning combined with poor data governance this occurs. Once this point is reached the business will not typically drive to eliminate the application except for cost so typically initiatives to remove the applications are driven by IT and it can be difficult to get full business engagement.
As far as the IT Garbagemen are concerned the zombie application is someone else’s problem, unless you are also directly responsible for eliminating technical debt. The zombie application:
- Runs on production hardware.
- Requires application licenses.
- Requires IT support.
- Needs patching for security vulnerabilities.
- Requires hardware maintenance and licenses.
It’s a production application and needs to be treated as such.
Conclusion
As an IT Garbageman you need to stand your ground when Product Owners are asking to archive an application and to retain access to the data. If the business needs routine access to data it should be in a production application – either the successor to the retired application, a read-only reporting application containing the data from the retired application or they can’t retire the old application.
And always figure out when it’s best to trade in your old Ford Taurus.
