Dealing with technical debt and the kludge
McKinsey refers to technical debt as a “tax a company pays on any development” and according to their research it accounts for as much as 40 percent of most organisations IT balance sheets.
How did we get here?
To understand technical debt its important to understand an often borrowed German word the “kludge”. The Oxford defines kludge as “an ill-assorted collection of parts assembled to fulfil a particular purpose”. Why is this word so important to understanding technical debt? Because in IT, engineers are particularly likely to have created more than a few “kludges” to meet a demand (fulfil a particular purpose) when under pressure from business and management to deliver faster and/or cheaper solutions.
This is a particular issue in IT because unlike other areas of engineering, there is a perception that kludging something together has no downside. If it was physical infrastructure such as a building or a road there would be a physical safety concern and a kludge would never be tolerated. Because we do not see IT that way (even when today it might be a physical danger), its acceptable to “just make it work”.
This starts off a vicious cycle where pressure to keep up means complex solutions (aka kluges), leading to installed complexity which only adds to the pressure to keep up.
What is important to understand is that the vendor narrative that technical debt is due to “old technology” is not the whole truth. Vendors want you to believe that simply keeping all your technology “current” that it will be easier to manage. Certainly old technology can eat up time from your IT team maintaining and patching it. However, consider the reality in the service provider world, where never have they rolled a van to replace something in the network, in a street cabinet, simply because it was “old”.
KPMG’s 2022 study into technical debt said: “ About three-quarters of respondents (73%) to the survey said the long-term maintenance costs attached to deploying systems have little to no impact on their IT ambitions.”
That paints a very different picture from the one the vendors are promoting. The reality is somewhere in between. Long-term maintenance costs are a serious concern, and customers should be factoring it in when making IT decisions. However age is not a reason to replace something that is perfectly functional.
So where does technical debt come from?
One word.
COMPLEXITY
Remember what we said about those kluges? That is where the real issue comes from and what is actually creating technical debt. By taking shortcuts or generally doing things without proper architectural design means that IT systems become increasingly complex over time. An old system that is simple, sits there, does its job… it might require a bit of patching, or ring-fencing to protect it from more evolved threat actors, but if its simple it will be easy and cost-efficient to maintain, why replace it! It works! On the other hand a brand new system which is implemented with haste, high complexity and without proper design or forethought into long-term maintenance will rapidly become a millstone around the neck of your IT teams.
KPMG summed it up as such: “To avoid creating fragmentations that could harm customer interactions, blueprints for emerging technologies should not overlook the importance of minimising tech-debt responsibilities,”
“Fragmentations”…. Kluges by another name. Complexity.
What is the solution?
Sorry, sales pitch incoming… that’s right. Sound architectural design.
Simple and elegant is unfortunately not automatic. Technology is increasingly complex. Virtual, software-defined, DevOps, all brilliant advancements that have only made design more flexible. This added flexibility is great, for an Architect. It’s the same as the move from building with stones to concrete. The fluid nature of modern man-made materials has meant that architects can design wild and imaginative buildings… or absolute monstrosities. Because design is not automatically elegant, it takes work and concreted effort.
By working with an Architect, someone who is not mired with the “this is how we’ve always done it” and can bring a fresh perspective. By working together with your internal teams and suppliers, key issues around long-term maintenance and complexity can be explored and properly understood. Roadmaps will be created and implemented that will guide future IT initiatives.
Over time complexity will come down, and with it, technical debt. Guidelines can be put in place to make this managing down process part of the organisation’s “evergreen” strategy so that no more than 20% of any project budget is spent towards managing technical debt.
By utilizing the Infratech Method and our 5States, organisations will be able to form a much clearer picture of their estate and its current life-cycle stage. This insight is invaluable in determining which technical debt to manage, and which to eliminate, and more importantly when these activities should take place within the wider IT workplan.