Arc debt

As part of the work assessing and improving Data Capability for the HE sector, we talk about the importance of understanding architectural debt.   I’ve summarised my definition of it here.

Architectural debt is the concept that adding complexity to an already complex system will generate debts (technical, commercial, process, data, etc) which will need to be ‘unwound’ at some future date.

Integration complexity (or ‘coupling’) increases as architectural integrity decreases. Simply put when issues are fixed tactically – without rigorous impact analysis – the ‘string gets longer and harder to unravel’. These types of changes tend not to update business processes, data models or similar documentation so making the understanding of that change very hard to determine in the future. It essentially obfuscates the ‘as-is’ state.

This situation increases the speed at which architectural debt is accumulated, because it is extremely difficult to consider any solution other than a fix building on previous tactical changes. The understanding of the original solution – both it terms of what was being solved and how it was being solved has been lost.

Eventually this becomes unsustainable. Either the debt has to be unwound through an expensive and time consuming experience of reverse-engineering back to the starting point, or – as is more likely – the solution is replaced by an entirely new approach starting from scratch. This is illustrated as ‘the point of no return’ in the schematic

There has been some work to quantify levels of architectural debt in any coupled system, but this is hampered by the sheer number of variables. However,  do not be fooled – it is prevalent and pervasive in many of the issues we’re struggling with on a daily basis.

The symptoms include a lack of flexibility in use and the high cost of change when attempting to align a capability to business cycles and events.  It is also self perpetuating because there is an understanding unwillingness to back out of many complex and poorly implemented change before actually embarking on the change originally planned!

Architectural debt is generated within IT systems, data models and lifecycle, business processes and organisational design. It is mitigated by having strong governance and architecture functions within an organisation and senior management buy in to properly understanding the impact of change, before embarking on it.

It’s a little discussed topic. We should however  consider it as part of any planning exercise – failing to do so will unleash a hidden killer of everything from small change to wide ranging transformation.

Architectural debt

Leave a Reply

Your email address will not be published. Required fields are marked *