Enterprise Tech Debt

You gotta pay the vig …

prof serious is a software engineer …

Given that digital systems and processes constitute the platform on which most enterprises operate, and on which they are increasingly dependent, it is not surprising that they occupy an increasing proportion of board and management time. Much of this is spent on issues arising from enterprise tech debt.

Enterprise tech debt (a term originally due to Ward Cunningham) is loosely defined as the liability incurred through prior underinvestment in software and systems. The debt arises from, amongst other things, outdated systems and frameworks, accumulated piecemeal changes, inadequately tested code, quick hacks and hasty compromises.

It manifests variously as operational risk through an increasing likelihood of system failure, as heightened vulnerability to security threats, user frustration, lack of agility and increasing cost of business change, lost opportunities, and a general diminution of business capability and capacity.

Enterprise tech debt can be categorised into 2 broad types. I will call them, imaginatively, Type A and Type B.

Type A. Given that, in software development, the greatest risks arise from inadequate requirements understanding and fit, it may make sense, with constrained resources, to do whatever is necessary to develop and deploy systems rapidly and get feedback quickly. The plan - on the part of the developers, at least - is to return, once the principal uncertainty has been addressed. But, of course, with a solution at hand, the users are reluctant to fund this, and do not themselves immediately bear the costs (the ‘interest’ on the debt) which are, in any event, slow to accrue. The next feature looks more tempting to all concerned, and so matters proceed until the project enters the enterprise baseline carrying with it the debt.

Type B. Failures in budgeting, bouts of costly organisational transformation, and shifting priorities, can lead to periods of underinvestment. Organisations with annual budgeting cycles and limited capacity for strategic planning (government comes to mind-) are, in my experience particularly prone to this. Periods of underinvestment are sometimes extended, but they do not have to be in order to seed serious problems. Once a ‘technology cycle’ has been missed, the problem of tech debt becomes rapidly more difficult to address. The pressing need to make immediate fixes arising from changes in the operating context (such as emerging requirements, data, systems integrations, all necessary to sustain operation and ‘keep the show on the road’) drives further complexity into a system that already carries substantial tech debt. The cost of the changes increases with each change, eating up any residual budget intended to pay down the debt, and skewing the portfolio away from innovation.

The problem is not simply running to stand still, but running to get further behind. And this is the ‘best case’, assuming that you maintain a knowledge of the system and do not lose the capacity to make changes at all!

Type A tech debt has been extensively considered by software developers. Essentially, the mitigation is to track the investment of effort very carefully - looking for the inflection point where the benefits of rapid progress flip into (are outweighed by) debt accrual. They can deploy a range of strategies to minimise the extent and effect of technical debt. These include: continuous refactoring (crudely, tidying-up and reorganisation), organising for change, scheduling ‘debt repayments’, maintaining a testing infrastructure, and so on. Best practice minimises the technical debt, it is never wholly eliminated. Best practice is, of course, rare, and Type A tech debt can fail-over to become Type B.

Type B tech debt has, I would argue, been neglected. I suspect most software developers see it as a ‘business problem’, and perhaps most enterprise managers see it as, in essence, a ‘technology problem’. It may fall between stools but we have, to recognise that, whatever kind of problem it is, it is an organisational reality. Most experts prefer to talk about how to avoid problems, rather than address this messy reality. My, informal, observations suggest that the most common management strategy is to simply ignore it and hope it will go away. Talking very loudly about AI and quantum computing sometimes does the trick.

Failing this, the more practical approach might appear to be to bet on rapid replacement, thereby driving functional enhancements and debt reduction at the same time. It is easy to write the business case, but the problems that this approach poses are obvious. First and foremost, with the best will in the world, it cannot be achieved, across a complex ‘digital estate’ in one jump. This leaves punitively costly and inherently risky integrations that amplify the tech debt in the residual systems. Second, the requirements have to be ‘reversed’ out of legacy systems mired in tech debt. The approach assumes that sufficient capital is available, which we know is not the case because of the ongoing maintenance costs. It demands high-levels of technical and programme management skill, rarely obtainable.

So there is an alternative, but it seems initially unattractive. Essentially, this approach entails architectural refactoring - breaking up systems, inserting interfaces, instrumenting the platforms, realising key interactions as exchange formats, surfacing as much data as possible in intermediating data repositories, building tests. Above all documenting.

There is no immediate functional benefit of doing this, it is costly and time consuming. In the first instance the primary sources of technical debt remain intact, the business sees very little immediate benefit. The benefit, is of course control, and ‘conditioning’ for change. Once this has concluded eventual replacement of ‘components’ can be orderly, incremental, and risk managed. Paying down tech debt can proceed hopefully at an increasing pace. Who said debt repayment would be easy?

prof serious is a software engineer.