All Posts in Technology

|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

|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