We have a few applications that are close to outliving their usefulness. Could you offer some best practices for end-of-lifing software?
Deciding that it is time for an app to be replaced used to be instinctive. Nowadays we have plenty of real-time telemetry coming from our systems that allows us to measure every aspect of our IT activities. How we use that telemetry, what data we choose to weight most heavily, what inputs we choose to ignore and the human factors in all this are what make this subject so interesting.
Of course the cost of keeping the system up and running is the only true determining factor in whether or not a system should live, limp or leave. But what are those costs? Here are four cost vectors to consider that indicate it's time for your system to go. They may be different from what you expect.
1: Maintenance: We know how much we spend every year on maintaining the system, or at least we should, by correlating the number of changes the app receives with the project time spent on those changes. It is estimated that 80% of a system's costs are in the maintenance that it receives after its original deployment. How much have you spent so far? How much did you spend this year compared to last year? What is the trend? Those questions are the easy ones.
2: Business cost: For the real cost, add these into the calculation. What is the lost productivity cost because the system is hard to use and difficult to learn? What is the expense (and risk) of keeping around old (unsupported?) technologies that the system is based upon? What is the cost of the reduced organizational flexibility of having a dedicated (and expensive?) team of specialists who only "know" this system? What is the cost of the lost confidence of the business because the system fails frequently, has poor performance, has long downtime periods when being updated, lacks a modern look and feel, cannot be accessed from mobile devices, is nonstandard, doesn't integrate well (or at all) with other systems or has the old branding?
3: Lost revenue: How many times do customers abandon their transaction because the system is hard to use, and how much lost revenue does that represent? What is the opportunity cost because the system takes too long to implement business changes and support IT activities? What is the impact on customer satisfaction when the system has "idiosyncrasies" that result in errors (the worst-case scenario) or misstated information (which is annoying)?
4: Staff morale: How many good people are you going to lose if you keep asking them to work on this system? How many people are you going to lose because they want to work on the bleeding edge and not on something that hasn't been bleeding edge for a decade (or much less than that)? How many people are you going to fire because they can't work on this system? How much money are you going to spend on training people to work on it, and how much is it going to cost you to hire specialists in this area?
All of this can be tracked and calculated if we have the automated processes infrastructure in place that orchestrates our IT activities. If you can measure it, you can calculate it in dollar terms. Let's find the true cost of systems.
Dig Deeper on Topics Archive
Related Q&A from Kevin Parker
Add controls to the business of delivering software, and teams will scream about delays. However, fast development is often the result. Continue Reading
Kevin Parker discusses the pros and cons of industry analyst reports and advises when it might be best to trust your own instincts. Continue Reading
Actually, application development veteran Kevin Parker says ALM is really a part of the APM process when you look at it from a distance. Continue Reading