Explanation of technical debt for CIOs of non-software product companies
Digital product companies, primarily those companies that were built with the internet as the primary customer interaction, have the best grasp of technology debt. In our article about Technical Debt, we explain debt as a liability that has principal and interest. The principal is what you had to defer to get to market with an MVP, and the interest will continue to grow the longer you defer it.
If you are the CIO of a company that is not digitally native (organizations or companies that don’t produce technology products for revenue generation), think of your enterprise software as assets that need continual care and feeding. When you defer maintenance on these assets, you will incur debt and the principal will grow over time.
For CIOs, these types of assets typically need 12%-25% of the initial investment set aside for continued maintenance. Maintenance for enterprise software is primarily modifications that help it keep up with the needs of the business. If this maintenance is avoided, the deferred maintenance is technical debt that can quickly accumulate in just a few years. In the example below, we show the ideal scenario (maintaining your assets) and the non-ideal scenario (deferring maintenance).
Large enterprise software implementations should be viewed similar to large expensive pieces of machinery or commercial buildings. These are assets that can depreciate in a non-linear fashion without proper maintenance. In the image below, the yellow (low-cost maintenance) and red (high-cost maintenance) show how the cost to fix the debt accumulates over time.
When organizations fail to invest in the annual maintenance in hardware, software, and labor, technical debt accumulates. Then the tech debt shows up as wasted business opportunities, wasted employee time, and the risk that unplanned events will have a larger impact than they would for a more resilient organization.
Let’s focus on an example of the purchase and implementation of enterprise software. Let’s further assume that:
- a solid business case was established for the investment based on key metrics
- that requirements were actually mapped to improved metrics such as faster cycle times and fewer errors
- the project was iterative in the sense business users got early feedback via prototypes or an Agile delivery
- users were initially trained with a focus on the improved metrics
- the project was actually on time and on budget
To expand upon our analogy of software as an expensive asset similar to machinery, let’s use the example of a task or job of “digging a hole”. This example is inspired by the concept of Humalogy ® from FPOV. The task of “digging a hole” can be done entirely by hand or with increasingly more capable tools. In the example below, we’re showing a scale of increasing autonomy or tool leverage.
Because enterprise software is difficult to physically see, most organizations struggle to account for or track how to maintain it. Considering that enterprise software is an expensive tool, we recommend a range of 12-25% in annual maintenance including the initial labor it took to implement the tool.
When the owners of the enterprise software fail to maintain the asset, employees can no longer rely on this expensive tool to help them efficiently do their job. The workforce will find various ways to get the job done, and often employees fill the gaps with less powerful tools.
With Enterprise Software, when we fail to pay our maintenance, we incur technical debt. In particular, when we fail to invest the required labor, users rely on cheaper and less powerful platforms. In turn, this will likely lead to longer cycle times and more errors. When this occurs, the entire enterprise has now incurred Organizational Debt. This typically shows up where users spend a significant portion of their time using multiple platforms and tools for the same job or collection of related processes. In the example below, an ERP implementation is launched but not properly maintained. Work shifts to cheaper platforms.
This is not to say that there is no place for augmenting functionality of large enterprise systems with cheaper platforms, but these lower cost platforms should not be too heavily relied upon long term as they will not appreciably pay down the principal on the debt. In many situations, they cannot keep up with the growing interest on the debt.
To learn more about how AKF Partners can help you optimize your products and services for scalability and availability, contact us at AFK Partners.