PA enterprise architecture expert, Peter Nørregaard, has had a byline published in Version2 discussing how to avoid the pitfalls of the term ‘technical debt’. The purpose of using technical debt as a concept is to make the consequences of making short-term decisions, and the costs involved, more visible. However, a major pitfall is being unclear about the differences to monetary debt when communicating technical debt to business stakeholders.
For instance, a financial system poorly maintained with quick fixes and temporary solutions may have a huge technical debt, whereas replacing the old system with an entirely new and more efficient system will eliminate the technical debt in one stroke. This is quite different to the dynamics of monetary debt. Thus the concept should be used carefully not to undermine its validity.
So how does the CIO then use the technical debt and communicate it to the business? According to Peter, technical debt – which can also be called ‘deferred maintenance’ – should be used primarily to assess systems with long residual lifetime, adding the debt to the expected total cost of ownership.
Peter adds a further cautionary suggestion: “Rather than factoring in potential issues with the quality of the IT in the debt, the CIO should supplement the information with a risk log to clarify the risks that are embedded in an older IT system. An honest risk log will be more helpful compared to a loose assessment of the technical debt.”
Peter Nørregaard is an enterprise architecture expert at PA Consulting Group