All Posts in Architecture

Enterprise Technical Architecture Management

|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: Architecture|Last Updated:

“I like TCO — Total Cost of Ownership. I feel like it’s a much more accurate economic model of price. Granted, it’s just price, not usefulness, but as long as you know that, then it’s a highly useful metric, much better than manufacturer’s suggested retail price.”

So said Mike M in a comment he posted to a recent KJR, which took some courage given how often I ridicule … uh … critique TCO in this space.

Credit where it’s due, he’s quite correct. TCO is a more accurate measure of spending than MSRP. That doesn’t fix any of TCO’s intrinsic flaws. Quite the opposite, it puts a spotlight on a flaw I ignored in my last missive on the subject: From a 7 C’s perspective, neither MSRP nor TCO are Connected to any important goal.

Wait, wait, wait, wait, wait! I can hear you shouting at your screen. Yes, reducing costs can be painful. It’s still an important goal in most or all businesses, isn’t it?

Well … no, or at least it shouldn’t be.

Increasing value is an important goal. Cost-cutting can be a useful way to increase value, but, as I’ve pointed out enough times to make your eyeballs roll, only when the organization can cut costs without a commensurate reduction in benefits.

As I haven’t pointed out enough times (yet) to make your eyeballs roll, reducing TCO can drive a short-term perspective that can, over time, prove calamitous.

For example …

I have, over the years, run into a handful of companies that (I’m not making this up) wrote their own development languages, transaction processing handlers, and file management software. In some cases these companies used their proprietary platforms to write proprietary applications that underpinned their go-to-market services.

No question — they reduced TCO quite a lot compared to competitors that had to license COBOL, CICS, and VSAM from IBM, not to mention licensing applications instead of relying on their home-grown ones. They passed this reduction along to their clients in the form of lower prices that helped them win and retain business.

What’s not to like?

Let’s start with staffing. Someone has to maintain these proprietary platforms. The folks who wrote them decades ago either have retired or will retire soon. Recruiting programmers qualified to and interested in taking on this sort of work is, in this day and age, pretty close to impossible.

But if you can’t recruit, why not just freeze the platforms in place? They all work, after all.

But that assumes the next IBM mainframe they buy, with any operating system that’s available and maintained by IBM, will run proprietary platforms written before IBM re-named MVS to Z/OS.

So … never mind all that. Nothing lasts forever. It’s time to convert the application to a more modern platform.

A fine idea, made even better by the only other alternative that would work being shuttering the business.

One problem with the conversion strategy is that decades of enhancements made to applications that are directly visible to customers either mean a lot of time and effort adapting a commercial package to service contractual obligations; or else committing the very large investment of capital and effort that would be needed to rewrite the application on a modern platform.

One more challenge: As mentioned, companies like these won and retained business by offering more attractive pricing than their competitors, made possible by avoiding the costs of licensing COTS applications and commercially available development and operating platforms.

No matter what these companies convert the applications to, they’ll be paying non-trivial license fees they’ll have to pass along to their customers in the form of higher prices.

They are, to turn a phrase, borrowing from the future.

Businesses borrow all the time. When it’s money, your average banker will work with companies to restructure debt to improve the odds of being repaid. The future isn’t like that. When the time comes, it demands repayment, often at usurious interest rates, and with mafia-like collection practices.

No argument — this week’s example of TCO reduction gone wild is extreme, and by now increasingly uncommon.

But while your IT shop probably doesn’t rely on proprietary platforms, other forms of technical debt — the term we use in IT for borrowing from the future — are distressingly common just as funding to repay them is distressingly uncommon.

Even TCO’s strongest advocates will agree that accurately calculating it ranges from difficult to Full Employment for Accountants.

But compared to the challenge of accurately measuring and reporting technical debt, TCO calculations look easy. Perhaps that’s why you never see technical debt and other forms of future-debt on company balance sheets.

Or maybe it’s just because reporting future-debt isn’t required, and would make the books look worse than ignoring it.

Comments