Comprehensive software reviews to make better IT decisions
Stop Measuring Technical Debt, Start Measuring Risk & Value
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:
- Meet your production targets
- Meet your availability requirements
- Guarantee data privacy and security
- Allow for you to accomplish the goals you’ve set to grow the business
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.
Want to Know More?
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.
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.
MEGA International announced the launch of its HOPEX Information Architecture solution, enabling various stakeholders to share the same level of information to make collaborative, informed decisions about the governance of data.
Enterprise architects want to collaborate with businesses in real-time to design and create models, but due to geographical constraints, this is not often possible. Many enterprise architecture (EA) tools simply don’t allow the parties/teams to view changes in real-time.
iServer: Enterprise Architecture and Strategic Portfolio Management Tightly Aligned to Your Microsoft Suite
Orbus’s iServer provides quick and easy architecture and strategic portfolio analysis features for those embedded in the Microsoft environment.
Over 1,000 IT leaders and professions gathered for a diverse slate of technology and professional practice sessions this week at BA World Toronto, May 27-30, 2019. There has been broad representation from key vendors in the Product, Requirements, and Design Management category. Tom O’Reilly, the COO of Sparx Systems ran a session to explore how requirements management tools are a key part of a modern business analysis practice.