With carefully considered IT investment and governance, organisations with complex systems can ensure continued efficient and equitable operations.
Many IT leaders in large organisations with complex systems often find themselves saddled with technical debt. Technical debt is a metaphor which defines the gap between the things we know are wrong, incomplete or not-fit-for-purpose and the minimal optimal operating state.
This is not restricted to things like software code or features but all elements of people, process, and technology. Technical debt is creeping and insidious by nature, and its contributors exist both within and outside the organisation.
In any large complex IT organisation, systems (infrastructure, people and software for example) must be maintained; that is, fixed, enhanced, trained and adapted. In essence, they require constant modification and change in order to maintain relevance and deliver on expectation.
Feeling impatient about the pace of change is not uncommon, but the challenge remains that the sheer size and complexity of the task of overcoming technical debt isn’t something that can be achieved overnight.
As an analogy, I see it as the IT equivalent of The Great Leap Forward – China’s ill-fated mid-century attempt to transform from an agrarian economy into an industrial powerhouse seemingly overnight.
While this is an extreme example from human history, it’s a timely reminder for what we sometimes see happen cyclically in complex IT environments.
Large-scale change cannot be hurried – and this is paramount when it comes to dealing with technical debt.
In any enterprise, decisions are constantly made that contribute to the debt, although these decisions may not be recognised in that context. For example, deferring a code change or patch in a critical application to future release cycles because they are complex or expensive is, in reality, kicking the risk tin-can down the road and adding technical debt to the ledger. It is also important to consider that technical debt also, just like financial debt, has a very high interest rate.
In the case of technical debt, this interest accumulates in the form of:
- The delta between the cost of change now and the cost of change later
- Productivity losses
- Loss of market share through lack of agility
- Stakeholder confidence in organisational capability
- Staff morale – working in an organisation with high technical debt is no fun
That said though, just like with finance, not all debt is bad. The concept of Minimum Viable Product in Agile Development is an example of a technical debt-by-design to start gaining benefits as soon as possible. But make no mistake, the outstanding requirements all go on the ledger.
So, at what point are we required to repay the debt? Simply put, when we reach technical negative equity. This means that the cost of the changes required to pay down the technical debt exceed the benefit gained.
A good example in the news last year was when the Department of Immigration (now Home Affairs) announced a massive ten-year overhaul to arrive at a future state where they have “…self-contained, adaptable systems, supported by common reusable services and cloud-based infrastructure.”
This can be interpreted as they’ve looked at the technical debt ledger they have now and realised that the negative technical equity is of such a scale that it’s not worth further investment, and by abstracting the business logic from the systems they can avoid a large deficit in the future. Which, by a strange coincidence, was pretty much what they said ten years ago when this cycle last occurred (Systems For People, etc).
Large-scale investment programs to solve systemic enterprise technical debt is symptomatic of a boom/bust saw-tooth IT investment cycle where periods of chronic underfunding must then be alleviated with a Chairman Mao-style Great Leap Forward. This happens because IT investment is very vulnerable and the concept of technical debt is not really understood by CFOs, Boards or Governments at all layers. In fact, Public Sector organisations are structured in such a way to make tech debt unavoidable particularly under CAPEX / OPEX models, election cycles and broad-brush so-called ‘productivity dividends’ which have reached such a point of diminishing returns as to be nothing short of political dogmatism rather than financial pragmatism.
This all begs the question of course of: how do we avoid or minimise technical debt? The Department of Immigration was right in betting on abstraction and adaptability but there are no secrets here.
The basic principles of enterprise IT governance and solid discipline were true before and they are true now.
We also need to move away from the legacy of believing that IT and technology is an adjunct to the true core business, when in fact it is the business. There is also a place for a conversation on how we manage IT investments and sustainment including making enterprise IT technical debt an audit requirement for governance committees.
About the author
Business Development Manager