Unless you've been living under a rock or in a similar media black hole the last few years, you know that the U.S. debt ceiling debate has created a global financial panic. In all likelihood, your debt ceiling isn’t getting the same press as the national debt, but maybe it should.
We all know that the cost to maintain legacy applications prevents you from investing in new projects and as systems age their cost only increases. What you may not be paying attention to is the growth of your portfolio's technical debt and how it may be adding to this funding gap.
What is YOUR technical debt ceiling? In other words, how much technical debt can you stomach?
The best way to start this discussion is to acknowledge that you have technical debt.
Step 1: “Hello, my name is Peter and I have technical debt.”
All legacy and new systems have it. Every time we fix a bug or add new functionality we are adding technical debt. According to Capers Jones, “Roughly 7 percent of all defect repairs will contain a new defect that was not there before. For very complex and poorly structured applications, these bad fix injections have topped 20%.” So accept it and move forward.
Step 2: Determine how much technical debt you currently have
You need to understand your portfolio in context to the business, cost, value and risk in each application. You may already be ahead of the pack and have a repeatable, objective application portfolio management process in place. Or if you are like most organizations, you have never been able to find the time or funding for it. APM solutions can be extremely effective when funded and implemented properly. However, expensive enterprise APM solutions are not necessary to get started. Your company is already collecting key information about the applications within the portfolio and there are sources to help determine technical debt. There are also light-weight APM tools that are designed to be fast and affordable, while providing the APM data you need.
You may also realize that APM solutions don’t calculate technical debt. Most provide some application analytics such as size measures and quality assessments. These are typically rolled up into a pseudo-quantitative index that attempts to express technical risk. Wouldn’t it be much more impactful to monetize that risk? Expressing in financial terms how much risk is present in an application and/or a portfolio may be the only way to get some people’s attention.
So, to determine how much technical debt you have, you need an objective, repeatable, affordable, light-weight solution that quantifies technical risk.
Step 3: Determine your technical debt ceiling
It’s not realistic to think that you can eliminate all technical debt. But now that you have an idea of what debt you have and where it exists at least you can hold the discussion about how much debt you can handle.
Armed with a better understanding of your portfolio’s existing state in financial terms, you are now able to determine if you are near an uncomfortable level of risk. The appropriate level of risk varies by business; I can’t help you with that. What you do have is a quantification of the risk in the systems you currently manage coupled with the capability and value those systems provide.
You are now able to look for redundancy, high cost/low value, legacy technology and situations that cost you precious time and money – in other words, applications with high technical debt.
Now that you have an idea of how much technical debt you have and better yet where it is, you can actually have a rational portfolio rationalization discussion. Application Portfolio Rationalization quantitatively measures each project along four dimensions, business value, cost, risk and technology. Effective rationalization enables you to select the initiatives with high business and technology value, and low cost and risk. By selecting the best transformation projects, you can consolidate applications and modernize infrastructure, ultimately freeing up resources to be re-invested in the organization, rather than keeping-the-lights-on work.
Step 4: Rinse and repeat
As with most processes worth doing, this is never a one-shot deal. As I mentioned at the start of this post, we are constantly adding technical debt to our systems and hopefully, we are also removing some. So it’s a moving target that requires ongoing assessment and monitoring to insure you are moving in the right direction. What you need to support this process is to find ways to educate your organization about technical debt, find automated ways to identify and track it, and then modify your existing funding processes to incorporate this data into its decision-making process.