All Posts by Bob Lewis

|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

|In: Metrics|Last Updated:

I’ve been reading up on technical debt. I’d thought the name was self-explanatory. Nope. Much to my surprise, I found the term’s formal definition excludes quite a lot of debts of a technical nature.

According to most authors, “technical debt” is really application development debt.

Just as paleontologists changed Brontosaurus’s name to Apatosaurus in 1903 when they discovered Othniel Charles Marsh had given the genus that name back in 1877, so I have to respect the going definition of technical debt: a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Yes, “technical debt” excludes a lot of what IT typically owes the future, illustrating an important principle of organizational dynamics: Someone Else’s Problems rarely matter.

And so, from now on, here in KJR-land we’ll refer to Chronodebt, defined as the accumulated cost of remediating all IT assets that aren’t what engineering standards say they should be.

Chronodebt is what your IT organization owes the god of time.

Chronodebt includes technical debt. It also includes the costs of: Converting an application whose supplier is out of business to something supported by a financially solvent vendor; upgrading server operating systems from out-of-support versions to something more current; and replacing hardware that’s out of warranty and aging beyond its projected lifespan.

Chronodebt also encompasses a frequent outcome of mergers and acquisitions: Acquiring a business and failing to integrate it into the enterprise.

A nicety here: Not all acquisitions should be integrated. It’s perfectly valid to run an enterprise as a holding company whose separate lines of business are left alone to win in their marketplaces.

If those running the business want a holding company then taking on an acquisition does add the acquired company’s Chronodebt to the total, but doesn’t add the cost of deferred integration.

If, on the other hand, the M&A plan does include some level of business integration or standardization, then failing to consolidate applications does add to the Chronodebt load.

Then there are boundary issues — issues like poorly engineered integration. Sure, we can blame an applications team for deploying a custom-programmed interface to keep two systems synchronized.

Is this really technical debt? Yes it is, if the IT architecture includes an enterprise service bus (ESB) or functionally similar integration platform and the applications team either ignores it or disguises a custom-programmed interface by hiding it inside the ESB.

But calling a custom point-to-point interface technical debt when it’s the best engineering possible given the IT organization’s existing set of approved standards just doesn’t seem accurate. After all, there’s no remediation path to improve the interface and won’t be, unless and until IT adds an integration platform to the mix.

In most situations, then, a classic integration tangle isn’t technical debt no matter how big a mess it is in the aggregate. It is, on the other hand, part of IT’s total Chronodebt because a time will come when untangling it becomes a priority, and when that time comes the time, expense, and complexity of the effort will be, shall we say, non-trivial.

All of which leads to a question: Should your average CIO calculate the company’s total Chronodebt?

The answer: Sorta.

The first question is jurisdiction. If the company has an enterprise architecture or enterprise technical architecture management function, then this is the group responsible for calculating Chronodebt, wherever and whoever it reports to in the enterprise.

The second question is whether to treat Chronodebt as a financial measure or as a non-financial metric. For most businesses, most of the time, keeping track of Chronodebt’s components, and grading each one with some sort of size and complexity indicator that associates with the cost of fixing it should be sufficient, and avoids errors of false precision.

On top of which there’s little point to developing a financial Chronodebt estimate.

One reason: Chronodebt measures remediation costs, not the business impact of the problems. Financial debt measurement works this way too: It notes the cost of repaying a loan, not what the loan shark’s leg breaker will do to you if you don’t.

The other reason is built into the Generally Accepted Accounting Principles (GAAP) — the official standard of accounting professionalism. As mentioned last week, unlike financial debt, Chronodebt and other forms of borrowing from the future don’t and probably can’t appear as a liabilities on the balance sheet.

In the KJR Manifesto, Metrics Fallacy #3 states that anything you don’t measure you don’t get.

Chronodebt’s absence from the balance sheet explains why IT has so much trouble getting funding to repay it.

Comments