‘Technical debt,’ sometimes ‘technology debt’, is a common phrase used in enterprise architecture these days. But I am not sure we all understand it to mean the same thing at the same time.
This came to roost for me the other day talking to a senior technology leader in a ‘shadow IT’ organization supporting business operations. (I’m not trying to imply anything pejorative about shadow IT here – I’m actually a fan of citizen developers – but that is a rumination for another day.)
“I’m tired of hearing System Z referred to by the architects as ‘technology debt’ he said – I’m paraphrasing here – “it can’t be – it is working great for us!”
His working definition of ‘technology debt’ must be something like ‘technology that is suboptimal and should be replaced.’
From a limited horizon, he might be right – his System Z might be at or near a local maxima in the solution space.
And that definition is consistent with the earliest uses of the ‘technical debt’ metaphor in software development. It was coined by Ward Cunningham (first introduced the use of patterns in software development at OOPSLA 87, Agile Manifesto plank holder, inventor of the ‘wiki’ – that guy : ) to describe the cost of things left undone in early iterations of agile development.
The working definition in the local feature or component software development context is that there is a kind of debt that arises when you make design concessions for time-to-market reasons. The resulting gap between how the solution should have been done and how it was done results in not only significantly higher maintenance costs – concessions introduce problems – but makes it harder and more expensive to add new features later. Those additional costs, in the metaphor, are the interest you have to pay on the technical debt.
Grady Booch (another software luminary – one of the Gang of Three who invented UML among other things) points out some of the consequences. “Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.”
Martin Fowler has done some thoughtful analysis of technical debt, saying that “software systems are prone to the build-up of cruft – deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further.” He further classifies such debt in a quadrant whose axes are deliberation and caution:
The shadow IT leader I spoke to was clearly thinking about his System Z from this per-software-solution perspective: “We have not made significant design concessions. We can add features without significant rework of the overall code base. Therefore System Z is not technical debt.”
But if we zoom out from the business process and team using System Z to an enterprise scale perspective, there is another kind of technology debt that can emerge – one where the quality of System Z is not in and of itself a telling factor.
Here is an example from my own history.
During the Great Health Insurance Payer Aggregation of the 1990s and 2000s, many large payers were created by the merger and acquisition of regional health plans. Regence, as we were called back then, was formed over a period of years by the aggregation of a number of regional health plans.
Each of those had its own operational system for managing claims, members, groups, and providers.
The company decided to consolidate operations onto a common set of processes supported by a common technology platform – a common occurrence following M&As.
When that decision was made, each of those existing systems moved into the ‘technology debt’ column. Any money spent after that on improvements to those systems had a short window of return, as they were all destined to be retired after the migration to the new system.
One of them in particular, CPS, a mainframe-based system used in Washington State, was a wonderful piece of software engineering, not just for its day, but in sustainable way. But its quality was not the issue – from the enterprise perspective, it had become debt. We wanted to minimize spending money on it. Any investments we did make had a severely limited window of return which closed when the system was scheduled to be taken off line.
The resolution of this enterprise-scale technology debt is not just a matter of decommissioning solutions which have been strategically leap-frogged. There are frequently people and process issues as well. In the CPS mainframe case, as part of the overall enterprise solution equation IBM took over maintenance and care of the mainframe, and all of the employees who had been supporting it were re-badged with IBM.
So for our System Z we were discussing above, if the low-coding platform on which it has been developed, and the integration technology it uses, are not part of the larger strategic technology roadmap, System Z is technology debt, and the cost-effectiveness of any changes made to it must take into account the shrinking windows of time for realizing value from those changes.
Maybe we need another metaphor besides ‘technology debt’ for these cases.
The evolution of technology in an enterprise is never clean. We move in the awkward rhythms set by yearly budgets and regulatory deadlines.
The result is a ragged edge of evolution, with the onus on us – the back office architects and engineers – to bind the old and the new, the static and the in-progress, into a whole cohesive enough to provide continuity to the business we serve.
Stay tuned.
Health IT Architect 