In a previous blog article, I discussed how the judicious adoption and management of technical debt was a potential competitive differentiator and a key strategic business imperative for financial services firms. In contrast, with technical debt consuming 41% of enterprise IT budgets, for some firms an ignorance of technical debt may pose an existential threat. In this article, I wanted to incorporate some additional perspectives that industry professionals may find of practical benefit when considering how to manage technical debt within their firm.

Distinguish between technical debt and self-harm

Technical debt is the accumulation of consequences that follow from the commission or omission of decisions within an organisation. This yields different kinds of technical debt which can be modelled as a quadrant with prudent/reckless and deliberate/inadvertent axes. Clearly, firms should focus activities on prudent technical debt which has been deliberately adopted to tactically address commercial imperatives or inadvertently adopted due to the inherent learning process of doing something new (“if we knew then what we know now, we’d have done it differently”). This form of technical debt is arguably inevitable and unavoidable.

Deliberate omission or being ignorant of vital processes such as adequate testing or sound solution design is reckless and avoidable. Life is hard enough for firms dealing with prudent technical debt, without committing these unnecessary acts of self-harm.

The impact on people 

Firms must recognise the impact of technical debt not just on the business, but on its people. For teams with a significant psychological disposition toward creative development and solution building, regressive excursions from development activities to address technical debt can impose a huge toll on the dynamics of these teams and the contentment of the individuals within. To ensure technical challenges do not morph into significant talent challenges, firms should carefully schedule regressive activity, and where possible align this activity with team members more psychologically oriented to it. 

If you can’t measure it, you can’t manage it

One of the biggest issues with technical debt is its lack of visibility across the enterprise. Project managers are acutely aware of its magnitude and location but often, this is not communicated to the business. It’s often easier to trumpet a project for being delivered on time and on budget, without providing the small print detailing how much the project has borrowed against the future to achieve it. And whilst communication is one thing, measurement is another. Most of the established metrics for technical debt are highly aligned with the software development process (e.g., number of open issues, code churn etc) and are significantly detached from their overall business impact. Metrics such as technical debt ratio or absolute debt (effort required to repay it) are arguably more relevant to the business. Regardless of the metrics adopted, an open culture which encourages their communication is foundational to an effective management strategy.

Extend the analysis to process debt

Technical debt invariably refers to the handbrake on a firm’s progress caused by inadequacies of technical systems. However, an equivalent concept is applicable to a firms’ process landscape which is invariably being served by these technical systems. Tactical prerogatives and the passage of time are equally damaging to processes within firms’ operating models. Process Mining technologies are effective at identifying and quantifying the degradation of process performance in terms of performance and conformance metrics, to which estimates of rectification effort can be attributed. This provides a coherent view of overall technical debt in the context of a firm’s overall business design.

Don’t just measure it, use it

Quantifying debt is pointless unless firms can use this information to guide strategic decisions regarding its management. Incorporating these metrics into the low-level artefacts such as APIs and applications that reside in Enterprise Architecture (EA) tools creates an additional dimension of context that can drive strategic decisions. First, it helps map out the technical debt minefield within the organisation, enabling new initiatives to avoid building solutions on shaky, indebted foundations. Secondly, using EA tooling, it is possible to understand where and how technical debt accumulates in strategic organisational capabilities. This creates an evidence-based approach to enable firms to prioritise technical debt mitigation and focus investment where it delivers maximum impact in the context of a firm’s business plan.

It isn’t a debt if you don’t have to repay it

Another benefit of incorporating metrics into EA tooling is in understanding the where technical debt resides in the context of overall IT portfolio planning and decisions relating to retaining, retiring, re-hosting or re-architecting of a firm’s systems. With technical debt being tightly coupled to system development, firms can take more effective decisions regarding what development they undertake, and the development that they delegate. Specifically, how they can retire indebted systems and use the capital which would have been used to mitigate the technical debt, and instead invest it in low code solutions and managed services such as SaaS (Software as a Service), PaaS (Platform as a Service) and iPaaS (Integration Platform as a Service).

Putting it into action

With technical debt consuming the most significant proportion of enterprise IT budgets, and being the biggest single impediment to innovation, technical debt management is a perennial business challenge which firms must address. Significant competitive advantage is a realistic outcome for firms who can incorporate a variety of cultural and technological approaches to excel at technical debt management.