Debt in IT Architecture is just as unavoidable as financial debt for any company. Managing it carefully is at least equally important.
It’s amazing how common sense is repeatedly ignored in digital domains. Debt is a perfect example - in your booking sheets there would be all sorts of reasons to accept debt or even welcome it for the better of the company overall. What you would however never do is simply ignore debt.
How come ignoring architectural debt is so common in the IT space, then? Even worse, in many organizations there is no doubt about the IT debt itself but zero grasp about its magnitude. The attempt to put the debt in numbers was never made.
That appears strangely indifferent. It still just adds up if you consider that IT is still considered only as cost center in way too many organizations. In that light, why not stick to something that “works” and focus on the profit centers, right?
The epiphany that these profit centers are directly tied to your IT cost center in almost any case today* comes only much later, might take years to shape out.
That is certainly the case for organizations that struggle with (the idea of) improved online or combined online and offline sales channels, hence do not realize that the baseline IT is not only a matter of cost but an enable for new business models altogether.
However it is the case as well for organizations that are only “operationally” driven, meaning ones that will only focus on customer projects and sacrifice innovation to that end. Such organizations include even high-tech startups.
So architectural debt is all around and not only a concern for traditional companies and their legacy IT infrastructure.
Truth is, architectural debt has the annoying tendency to exponentially increase complexity and cost while decreasing reliability and security.
Ignoring it while you still have time to breathe is only asking for a hasty rescue mission with uncertain ending.
The only way to break a vicious cycle of “no time to improve” -> “the mess is slowing us down” -> “no time to improve” is to get back to square one. What is the reason you are running your IT systems? What is your long-term plan? Deliberately slow down to turn things around - and take it as an investment. Unless you get to the conclusion that running your systems was a bad idea in the first place. Then don’t waste capacity on a lost mission - do the hard and the right thing and get rid of them ASAP.
Losing speed comes unwanted when plenty of project work is knocking at the door, that’s clear.
Yet, losing speed in order to do the right thing is certainly better than ending up agile but fragile.
*) Unless your business vision does not involve complete or new and in either case actionable data, processes nor flawless process and system integrations.