X

Avoiding the cost of entanglement

All the TCO and ROI calculations in the world won't save you from the massive gremlin of IT economics: Our entanglement with the vendors, products, and approaches we choose.

Jonathan Eunice Co-founder, Illuminata
Jonathan Eunice, co-founder and principal IT adviser at Illuminata, focuses on system architectures, operating environments, infrastructure software, development tools, and management strategies in networked IT. He has written hundreds of research publications and several books.
Jonathan Eunice
5 min read

Modern IT is very focused on economics. We talk endlessly about cost. We debate capital costs vs. operational costs--CAPEX vs. OPEX, in the lingo. We look at Total Cost of Operations (TCO) and we try to calculate our projects' Return On Investment (ROI). But even with all of these economic metrics, we miss an enormous source of costs: Our long-term entanglement with the products, technologies, and approaches we choose.

Image of man entangled
Licensed from VectorStock
Long ago, we had a bright idea. "We could represent the year portion of dates with just two digits--that would save space!" We happily did that for a few decades, saving two characters across billions of records. Then, 25 years later, we had to spend a few hundred billion dollars to fix the Y2K problem.

We choose this platform or database engine or application suite, only to find out a few years later it was overkill, or too expensive, or not as good a fit as we first thought, or not right for changing times and requirements. Perhaps we'd like to change, but here's the rub--often, we can't. Our data, our processes, our SLAs--everything's entangled with choices previously made. And we've already spent so much time, money, and energy--who wants to admit "failure"? So "the train has left the station."

We'll go on paying the bills for a legacy choice--even increasing our investments. This often goes on for decades. Whether it's Oracle or IBM, Salesforce or SAP, Microsoft or CA, it's all the same. Open source, open standards, and plug-compatible products are often presented as a solution. They help, but there's no miracle cure. Regardless of the technology or vendor, we're locked into the choices we make for a very, very long time.

If things go well, it's a good marriage. There'll be tensions and frustrations, sure--but overall, we're satisfied. If things go badly, it's a bad marriage. We're left bemoaning our plight, thinking "How could we have possibly thought this was a good idea?!" Divorce is often so difficult, wrenching, and disruptive as to be unthinkable.

It's important to realize this isn't just about choices made 30 years ago. It applies equally to choices we've made recently--or are making today. Consider Microsoft's Internet Explorer 6. Enterprises are struggling to move away from it now, but when it was new in 2001-2004, targeting IE6 first and foremost "was a no-brainer." "It's ubiquitous! It's up-to-date! Let's focus on the one browser 90 percent of everyone will have!" In its heyday, IE6 was both popular and modern. Moreover, there were no good alternatives. Fixating on IE6 wasn't a newbie mistake or a dumb decision--we just got entangled with it. Then, things changed.

It is absolutely normal to have a natural, rational, appropriate decision that, 10 years later, everyone bemoans. Today seemingly everyone hates IE6. Even Microsoft. It's painfully out of date, doesn't support interactive Web apps, and has all manner of ugly security exposures. Yet it's still required for many enterprise Web apps. Our continuing need for it interferes with our Web, thin desktop, and application modernization projects. We spend time, money, and attention trying to virtualize it, or update/replace the apps that depend on it.

There are common factors at work in unfortunate entanglements. Before making a decision, everyone does some analysis and predicts how the various options are likely to turn out. But the analyses are almost always short term. We calculate the 3- or 5-year TCO--for systems that may last 10 or 15 years. We look for ever-more-immediate ROIs, trying to keep our near-term costs down, and near-term benefits up. When the benefits or drawbacks are diffuse or longer term, we ignore them, punting potential problems into the future. The future arrives a lot sooner than we expect it to. Expect to do something for a few years and you'll wake up a decade later, still doing the same thing, the same way. And, as Yoda tells us, "Impossible to see, the future is." Some of our assumptions simply don't pan out. Finally, we often don't do much work along the way to adjust to changing conditions.

How do we break this cycle?

Plan for change. Expect and plan for change. Expect that your requirements, situation, and desires will all change over time. The risk of long-term entanglement is difficult to model as a part of conventional TCO and ROI calculations, but the dangers of becoming entangled should be a part of every major evaluation. Ask: "What if we're stuck with this for the next decade? What if I have to live with this for the rest of my career? What if this vendor is acquired? What if this product is mothballed?"

Invest in flexibility. In all sorts of purchases--airline seats and database engines alike--you get the best immediate deal by making a long-term commitment up front. It's enticing, but often a matter of "pay me now or pay me later!" Consider paying a little more, if that gives you better options to change later. More proactively, invest in things like virtualization, open standards, open source, and agile development that fundamentally increase your agility. It's interesting that many shops get into such approaches primarily to save money--only to then discover that flexibility is even more valuable than the initial cost savings.

Make continuous improvements. We've moved much of software development from the old, simplistic, static waterfall model toward more agile, incremental models. We should apply the lessons learned to IT's logistics, system management, security, and other processes. The idea of continuous improvement runs counter to IT's traditional "if it ain't broke, don't fix it" operational philosophy. But the old "update infrequently, and only when really necessary" mantra led to fragile, static infrastructure. It's time to give more regular, continuous improvements a try. If we regularly evaluate and improve our situation, we can sense much earlier when our entanglements no longer meet our needs, and move toward something better.

Whenever we make a choice, we're constrained by it. We're locked into it, often for far longer than we expect, with far greater implications. Entanglements are inevitable--but falling into them unawares is not. So look for them, and choose with open eyes. Changing conditions--either in the world, or what we want and need from it--are equally inevitable. Changes are what turn entanglements into unhappy situations. So invest in flexible, future-proofed approaches so that when you realize you no longer want to be locked into a given product, vendor, or strategy, you have the ability to change, and the agility to do so easily.