Technological Debt is More Than Just Money

S. Schuchart

Summary Bullets:

• Managing technology change is more than just about the technology, it’s about business practices as well.

• Stagnation of technology leads to technological debt, which costs more than money to fix.

Far longer ago than I’m willing to admit, I worked for a now-defunct retail organization in IT. That organization prided itself on two things, its ability to fulfill business needs to a high standard without relying on external vendors or organizations, and its ability to extend the life of arguably ancient IT systems. Massive technological debt was accrued, all with the best of intentions.

Year after year IT extended the useful life of everything, from timeclock systems, to point of sale systems, hand scanners, radios, and even old, high volume dot matrix printers. There were extensive contacts with the gray market, where entire pallets of retired units like the ones being used were subjected to weeks-long projects to refurbish or part out those systems for use in stores. The company would even buy the entire IT physical inventory of dying chains that used similar equipment and bring that equipment into our vast fleet of spares.

This deep frugality also existed in software. Software no longer supported by the manufacturer was running. Deals with vendors were struck for licenses but no support. The operating systems this software ran on were relics themselves. Through a combination of clever coding, measured compromises, and sheer cussedness, IT kept running and delivered benefits to the business that were only seen at retail firms literally hundreds of times the size – all of it on the cheap. Now this is not to say that zero IT investment happened, because new systems and software did happen all the time. But the company saved literally millions of dollars and did it consistently. As a young administrator and IT gadfly I thought this was splendid as we were saving money and that was good. The reality was something different.

At the end of the day there was a price to pay. From a security standpoint, some of those systems were vulnerable, some of the operating systems so old that the companies that made them were not even in business anymore or had ended them long ago. We spend an inordinate amount of time adapting the new to the old, complicated by the fact that the old systems and software were not designed to interoperate. Long, late hours ensuring store uptime and a strict multi-person on-call schedule 24/7 was necessary. Worse yet, the elderly systems proved to be career development killers. If you became the expert in an old system, learned its idiosyncrasies, you could never leave it. Staff members became the default expert on call even when they were not officially on call, never really allowed to divorce themselves from the old system and denied training on anything new for fear of losing them for the old.

The company saved a lot of money over the years, a lot more than the cost of the people needed to keep the old systems running. When circumstances dictated that an old system needed replacement, when the systems had been stretched to their last and could no longer be jury-rigged to run, it was always an entire forklift upgrade. Even if the latest version of the system was purchased the existing systems were so old it was more work than a new install. Worse yet, because of the system stasis, business practices were also deeply entrenched and just as out of date. This made the new systems a huge operational problem for the organization as well. Many of these problems would not have existed had a measured approach of steady, slow change had been taken.

Vendors operate on a cycle and they are always pushing the latest product or feature as a reason to upgrade. Companies do not have to upgrade to the vendor’s beat. But they do need to keep in mind the human consequences, both on employee careers and on company operations overall that come from freezing in place. Small changes over time are easier to adapt the entire organization to than big earthquakes of change, to say nothing of the need to have realistic updates for security. This is a balancing act, but one worth learning to maximize the value of IT.


What do you think?

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.