All Posts in Technology

|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

|In: App Dev Methodologies|Last Updated:

And now some admiring words about Mitt Romney.

No, no, no, no, no. I’m not referring to any recent votes he might have made in the Senate. I’m referring to his recent, well-publicized 72nd birthday and the parallels he and his staff established for achieving business and IT agility. The standard they set for business and IT thought leadership rivals anything Romney achieved during his years at Bain Capital.

Start with his staff’s innovative multi-Twinkie cake architecture.

Most birthday cakes are layer cakes and result from waterfall design and production techniques. The baker starts with a recipe — a complete specification for the cake itself, coupled with a detailed work breakdown structure for creating it.

Many cake makers achieve excellent levels of success using these waterfall techniques, and I’d be unlikely to reject their work products.

But … personally, I’d be likely to concentrate my gustatory efforts on the icing. It isn’t that I dislike the cake component of the finished product. It’s that the cake component dilutes the flavor of the frosting, which I enjoy quite a lot more.

In business/technical terms, layer cakes aren’t modular, and deliver unnecessary features and functionality. Twinkie cakes are, in contrast, modular. Each component Twinkie is a complete, integrated whole.

Also: A layer cake is an all-or-none proposition. The baker decides how big a cake to make and that’s that. If unexpected guests show up, well that’s just too bad. Either everyone gets less dessert, or the new guests do without.

Traditional cake-baking doesn’t scale. Because Twinkie cakes are modular they scale easily: Just add more Twinkies, frost them, and everyone’s happy.

Another aspect of the Twinkie cake deserves mention: It evokes the value of an important technical architecture design principle: buy when you can, build when you have to.

Layer-cake bakers start with raw ingredients and baking infrastructure (the oven and other paraphernalia) and engage in actions equivalent to application development.

Twinkie-cake-makers start with a pile of commercially manufactured Twinkies. They do then make and apply their own frosting, but that step is more analogous to application configuration and integration than to application development.

Our final step in beating the metaphor to death (as opposed to beating the eggs that go into many layer cakes) is testing.

Bake a layer cake and the only way to test it is to mar the cake by cutting a slice out of it. Sure, you can reserve some of the cake mix to bake a mini-cake instead, but small cakes bake more quickly than full-size ones so the baker can never be sure the test cake tastes the same as the production version.

Compare that to a Twinkie cake. Want to test it? Eat a Twinkie. Not sure? Eat another one.

No problem.

The Twinkie cake architecture was innovative and interesting. But just as there’s no such thing as an IT project — it’s always about doing business differently and better or what’s the point? — so Romney himself deserves credit for the “business innovation” of using Agile techniques to blow out his cake’s candles.

Traditionally, candle blowing has been just as waterfall-oriented as cake baking: The birthday celebrator attempts to blow out all of the candles in one great whoof.

As is the case with waterfall project management, this is rarely successful, due to another waterfall parallel: Just as the risk of failure rises in direct proportion to the size of a project, the older the candle-blower, and therefore the more candles there are to extinguish, the less likely it is that anyone could nail all the candles in one breath.

Not to mention the unpleasant thought that unavoidably, in an attempt to blow out all those candles, some of the blower’s saliva must inevitably end up on the cake.

I’ll leave it to you to figure out parallels to application development or business change. And please do feel free to share your analogies in the Comments.

In any event, Romney used an Agile technique — iteration — to dodge the challenges of traditional candle out-blowing: He removed each candle from the cake and blew it out separately.

Especially, kudos for explaining that this way each candle was another wish.

The candles, that is, were his birthday backlog. And he dealt with them as all Agile teams deal with items in the backlog: One at a time, with little stress, and a very high level of success.

And, in the end, a spit-free cake.

Comments