All Posts in Technology

|In: Strategy and Tactics|Last Updated:

Is Chronodebt ever a good idea?

Chronodebt is the accumulated cost of remediating all IT assets that aren’t what engineering standards say they should be.

It’s what most of us have been calling “technical debt,” and I would too except that Ward Cunningham and his fellows at the Agile Aliance have already claimed it to mean “the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”

Anyway, the short answer is yes. Taking on Chronodebt is, in many circumstances, exactly the right choice. The conundrum preceded the advent of business computing by at least a century, when, during construction of the transcontinental railroad, the Southern Pacific Railroad, was faced with a shortage of hardwood railroad ties.

And so, instead of waiting for enough hardwood ties to continue construction, it took on massive Chronodebt in the form of ties made of cheaper and plentiful cottonwood (“Cottonwood now or hardwood too late?“, KJR, 4/28/2003).

The cottonwood ties would only last a few years, but with them the company could generate enough revenue to replace them. Without them it would never have completed enough track to sell a single ticket.

The significant difference between this and most modern companies’ Chronodebt is that the Southern Pacific Railroad paid its Chronodebt off.

Chronodebt, like most other forms of debt, is neither good nor bad as an absolute. As with most other decisions, context matters. In the case of Chronodebt it all depend on what stage of concept development you’re in.

Imagine your “concept” barely deserves the term — it’s really more of a notion. You think it has promise, but you don’t have much in the way of supporting evidence to support it.

It’s time to bet the farm!

And it is, but only if you’re betting someone else’s farm, “someone else” is someone whose friendship you don’t value very much, and you’ve checked with your lawyers to confirm you aren’t at risk when someone else finds themselves farmless.

If it’s your kids’ college fund it’s time to launch Excel, or maybe Access, or an ISP’s generic eCommerce development kit.

If it isn’t all about you … if we’re talking about a corporate setting and it’s a proposal to try something new and different for which there isn’t and can’t be much data to bring to bear on the decision … then it’s still time for Excel, or maybe Access. Or, because it’s a corporation, perhaps SharePoint, or some SaaS product whose licensing terms aren’t too expensive and onerous.

It’s time, that is, for Chronodebt, because doing things the so-called “right way” probably means missing the opportunity altogether. And in fact we might not be talking about Chronodebt at all. Chronodebt in this situation comes from the danger of success, because it only has to be paid off if the idea pans out. Success is, to push the metaphor to the breaking point, the usurious interest rate charged for underinvestment, which wasn’t underinvestment until success happened.

Chronodebt is a good idea during the exploratory phase of innovation management. It’s a bad idea when innovations start to prove out. That’s when it’s time to replace the kludges and prototypes you built the new concept on with more robust and scalable alternatives … time, that is, to pay down the debt, which means investing in sustainability.

That isn’t the whole story, though.

There are times when a company’s whole business model starts to approach its use-by date. Imagine, for example, you’re CEO of a metropolitan daily newspaper and your presses are a major source of corporate Chronodebt. Time to pay it off by replacing them with something more modern?

Probably not. Like it or not (I don’t), newspaper print circulation has been steadily declining for decades and the more important metric — advertising revenue — is in even sharper decline. The best and most advanced presses money can buy won’t sell a single additional newspaper, or, more importantly, attract more advertisers.

As CEO, you tell the god Chronos to take a hike.

If, on the other hand, your on-line news site or mobile app are Chronodebt-bound, that’s another story entirely.

None of this is particularly complicated. And yet, especially in IT circles, we do have a tendency to consider engineering excellence to be an unalloyed and immutable good.

Sometimes, prototypes and kludges are exactly what the situation calls for.

And sometimes the right answer, although painful, is limping along on your ancient legacy systems until they crumble into dust.

Comments

|In: Architecture|Last Updated:

Funny thing about Chronodebt: It stands IT governance conversations on their heads.

Chronodebt, you might recall if your memory extends beyond 4/29 (otherwise click on the link), is the money IT owes to the god of time.

It’s the accumulated cost of remediating all IT assets that aren’t what engineering standards say they should be. It includes the costs of: Updating out-of-support software versions to current ones; replacing hardware that’s approaching its expected lifespan; exchanging applications whose vendors aren’t financially viable for something more mainstream; and consolidating redundant applications added to the portfolio during mergers and acquisitions.

The reason Chronodebt stands most IT governance conversations on their heads is that most IT governance conversations are about business benefit. They’re about return on investment: If we spend $1 million today on the Internet of Things we can expect to generate an additional $500 thousand in profits next year, the year after that, and the year after that.

Chronodebt conversations are only like that to the extent you count not being evicted as a benefit of paying the mortgage.

There are those in business who figure everything is negotiable. When they can’t or don’t want to pay what’s due they cheerfully tell their creditors what they’re willing to pay — an amount just barely better than the net of full payment minus the cost of collecting it.

This sort of business executive, faced with a Chronodebt conversation with the CIO, will try to negotiate it.

But negotiating Chronodebt is trickier than negotiating financial debt because Chronos doesn’t negotiate. Try for an extension on replacing your car’s bald tires and Chronos collects by way of a blowout at highway speeds.

Do the same for aging server hardware and Chronos collects by way of an outage that cripples business operations. Refuse to migrate from a CRM package whose vendor is in decline and Sales and Marketing will suffer the death from a thousand cuts as their frozen-in-time application increasingly limits them from selling and marketing as well as their competitors can.

While you can phrase Chronodebt conversations in terms of benefit, Chronodebt isn’t fundamentally about benefit. It’s about inevitability. It drives pay-it-now or pay-it-later conversations where paying it later costs a great deal more than paying it now, even taking discounted cash flow into account.

(In case you aren’t familiar with cash flow discounting, it’s why a dollar tomorrow is worth less than a dollar today: You can earn interest on a dollar you have today. That is, a dollar today is worth, say, $1.05 a year from now; reversing the calculation, the expectation of a dollar you receive one year from now is only worth ninety-five cents right now.)

Chronodebt has a lot in common with preventive maintenance: The company will spend what it needs to spend to keep a conveyor belt running. It can either spend it now preventively or spend it later to fix the belt when it breaks.

The big difference between preventive maintenance in the factory and Chronodebt in IT is that everyone involved in these decisions can easily get their minds wrapped around the idea of a conveyor belt and the consequences of one failing.

That’s compared to the IT logic of updating, say, its Windows 2003 servers. Yes, they run right now. Yes they’ll still run tomorrow. But when the hardware they’re running on fails there’s no guarantee Windows 2003 will install on new server hardware.

“But don’t we virtualize our servers?” a tech-savvy CEO might ask. Yes, but that just means there’s no guarantee Windows 2003 will install and run on VMWare virtual machines.

Oh, and by the way, everything that needs to run to satisfy the company’s information security requirements isn’t guaranteed to run on out-of-support operating systems either.

Not only that, but the application development tools IT programmers use to develop applications only run on supported Windows versions, which wouldn’t matter except that the business is growing and needs to add more developers. So yes, the developers you have can continue to use out-of-date tools. But the next ones you hire will need their own licenses, and the old versions aren’t for sale anymore.

By now, while the CIO is delivering the clincher, the CEO’s eyes have glazed over.

Which is one reason so much of IT’s success depends on the CIO’s working relationship with everyone in the executive suite. A bad relationship means the CIO is on the defensive, and nobody cares about the evidence and logic of the situation.

With a positive relationship the CIO can explain, with serene confidence, “You have two choices. You can trust me, or I can explain it to you.” It’s Hobson’s Choice with the CIO playing Hobson.

Comments