A common problem facing any applications practice is dealing with technical debt. Technical debt, or tech debt for short, is the resulting back-end inadequacies of an application from either inadvertent error or prioritizing speed of delivery over quality. The former cause is somewhat inevitable and generally results from not having the proper checks and balances in place. The latter cause is the more frustrating scenario. Delivery teams, often outside of their control, opt for quick or cheap solutions and put off the more comprehensive or quality-assured option for a time when capacity allows, which often never comes. That gap represents deliberate technical debt. The reality is virtually all organizations are required to accept this deliberate tech debt to some degree, but it will eventually catch up with you and cause problems for both IT and the business.
Getting out of this problem is difficult. The natural instinct of many is to start with asking: How can I measure technical debt? What types of code analytics should I perform? What kind of metrics should I be after; lines of sub-optimal code, code duplication, rule violations, deferred features, or technical debt ratio?
I wouldn’t suggest that this approach is incorrect or that this information is irrelevant. Quite the opposite. Many development shops are in dire need of more of this type of analysis. However, it’s only painting half the picture when the real goal is to draw attention to the extent of the problem.
As mentioned, this scenario is caused by a balance of priorities that skew delivery efforts to speed over quality. That same sense of priority is likely to impact any efforts or buy-in for resolving tech debt as well. You need to change how you present the issue to the decision makers (DMs) of your application portfolio or ultimately who signs off on any refactoring or modernization efforts.
If there’s one point to get across, when that DM isn’t technically oriented, the measure of tech debt means very little if it isn’t both clearly linked to a business capability and articulated as risk to that capability. The case that needs to be made here is tech debt is technical risk, it’s business risk. Therefore, you shouldn’t express tech debt using solely technical or code-based metrics. It needs to be measured in terms of things like business continuity, production efficiency, or barriers to growth, for example. When selecting an APM tool, which is one of your best weapons in the fight against tech debt, you need to make sure you have a solution that paints the full picture.
Cast Highlight does this well. It collects business value information integral to any application rationalization effort, but specifically presents it in a comparison between application value and software complexity, production risk, and adaptability risk.
Figure 1: Risk map; courtesy of Cast Highlight
So, the argument to your DMs isn’t this high value application has poor technical health. The argument is this high value application won’t:
Think of application rationalization as a risk management function. A simple rationalization model compares technical health to business value. A simple risk management model compares the likelihood of a threat with the impact of that threat. With respect to technical debt, they are essentially the same variables in these analyses, and both are designed to prompt a call to action to when risk is present in a high-value area.
Green = DO SOMETHING
In both of these scenarios the business will understand the value and impact, where IT is more knowledgeable in suggesting the technical health of likelihood of the application or risk. It’s up to the role risk manager or application portfolio manager to compile this information and to push the DM in the right direction to act on that call to action.
Yes, measure technical debt. But, translate it into something that will resonate with the business.
Find out what will “resonate with the business!” So many application teams attempt rationalization or undergo some effort to address technical debt and don’t have an answer to that question. Technical debt is risk. Determine what risks will get your DMs moving.
Transfer risk, or at least create a sense of shared risk. This means blurring the line between the technology and the business capability. Don’t view tech debt as unhealthy applications – it’s unhealthy capabilities.
Be proactive as well. When determining the quick vs. comprehensive option, ensure you have an accurate sense of the business and technical priorities behind that decision; and that the eventual comprehensive option is properly injected into your backlog and not thrown to the curb.
These are the trends we predict will be most important is it relates to Enterprise Architecture in 2021.
Lean IX and Apptio have partnered to produce an integrated solution that better informs the strategic decision-making process with improved visibility into an application’s total cost of ownership and alignment to business capabilities.
From the business architecture perspective, agility is the ability to quickly change structurally and operationally to react to external changes or to create new business value. Enterprise architecture comprises business and service/application architecture – therefore, it needs to provide an environment for harmonized agility at each level.
This note outlines some of the fundamental KPIs that you should measure to show the success of the enterprise architecture team. It also discusses how you measure them and visualize the result.
The application portfolio management (APM) tool space can be a confusing one, as many software vendors offer their own take of what APM is. Enterprise architecture, application management and project portfolio management tools offer an APM use case, but these are often quite skewed the primary function of the tool.
Application rationalization fails when the chosen framework does not match your scenario or the goals for your application portfolio. This note looks at how to apply application rationalization during an M&A.
Many vendors suggest application rationalization is quick and easy. It isn’t. This claim does you a disservice and most importantly they’ve missed the point. Rationalization as part of a continuous application portfolio management function is about becoming a driver of the business.
Often people misidentify the purpose of application rationalization, leading to misuse and unsatisfactory results. We try to break application rationalization down to its simplest form to understand how to make the most of this critical IT function. tr
Many application rationalization tools and frameworks miss the true benefits of this practice, as they only assess the individual application without consideration for its redundancies. Infusing an enterprise architecture perspective, as seen with LeanIX, will generate the bigger savings you are looking for.