I took a long weekend, so this was my first chance to post even a re-run.

It’s a bit dated, (it ran in 2002) what with its references to web services, but substitute SOA for web services and it holds up pretty well.

At least, I think it does. But you’ll have to be the judge.

– Bob

# # #

Long before ManagementSpeak graced these pages, Mad Magazine had mastered the art of translation. My favorite:

What they say: It isn’t the money. It’s the principle of the thing.

What they mean: It’s the money.

To run IT, you need both money and principles, of course. Among the core principles for running a typical IT organization:

> Buy when you can, build when you have to.

> Minimize data redundancy.

> Maximize software re-use.

> Pick two.

If you buy when you can and build when you have to, you’ll use applications from more than one software vendor, your databases will be tied to your applications, and you’ll have redundant data. On the other hand, most vendors now write to an n-tier software architecture, which means you can get at the underlying logic, so you achieve software re-use.

Want to minimize data redundancy or maximize software re-use? Build everything yourself, or at least everything you can’t get from your primary ERP vendor. You’ll have full control over your code, too which gives you a fighting chance at re-use. Too bad you can’t afford either the budget or time to choose this option.

Web services promises to eliminate these trade-offs. The use of components instead of full-blown objects means logic is easily accessible while data is still defined separately, and the use of HTTP and XML means vendors can write general-purpose components and make money by renting them out. That means (blare of trumpets!) you’ll easily assemble enterprise applications out of commercially available components from all over the world.

It won’t happen — not because of technological obstacles, but because an enterprise application is more than a collection of general-purpose utility routines.

Software is an opinion about how a business should run. It’s expressed in code rather than English, but its an opinion nonetheless, so when you buy software from multiple vendors you’re buying differing opinions. Interfaces are where they clash. To state the obvious: Technology can’t resolve a difference of opinion.

Imagine you’re a retailer. Web services can solve some irritating problems for you, like managing the sales tax logic in multiple states, so as CTO you decide to adopt the architecture to run your whole business.

That’s when you discover: The different vendors from whom you’re going to rent components disagree on some very fundamental issues, such as how to define “customer.” One considers “customer” to be an individual. For a second it’s a household. A third, oriented toward hardware stores, perhaps, remembers that building contractors buy a lot of stuff and use a definition that includes companies and everyone in the company authorized to make a purchase.

Think you’ll just ship customer data into and out of components from all three vendors with impunity?

Think again.

The grand vision of Web services is that easy integration of independently engineered components will happen by just connecting them together like Tinkertoys. The reality: Integration is hard, even when designed into an application.

It won’t happen by accident, grand visions notwithstanding.

Bitcoin is the new Beanie Baby.

In case you’re too young to remember, in the early 1990s Beanie Babies were the new tulips. Which were, as documented in Charles MacKay’s Extraordinary Popular Delusions and the Madness of Crowds, (1972) an early example of something that only grows in value because people believe it will grow in value, and whose value vanishes as soon as skepticism sets in.

There are those who see no difference between Bitcoin as a currency and dollars as a currency in this respect. In both cases, the theory notion goes, the value of one currency unit is nothing more than a consensus among all who hold the currency as to its value when compared to other currencies.

Not that it has anything to do with keeping your joint running, and not that I’m a trained economist (perish the thought!); in this the Bitcoin enthusiasts are misguided. Because in the end, the value of a dollar is derived from the U.S. GDP, just as the value of a share of a company’s stock is, in the long run, tied to its profitability and balance sheet.

Put slightly differently dollars and other currencies have an entire national economy behind them. Bitcoin is backed by enthusiasts telling each other it has value. The name for this is the “Greater Fool Theory,” which states that Bitcoin, Beanie Babies, tulip bulbs, and the IPOs of companies that have utterly preposterous business models are all solid investments with excellent profit-making potential, so long as you can find a greater fool to take your investment off your hands before the bubble bursts.

In, just in case this isn’t obvious, my awesomely humble opinion.

Which has what to do with running IT?

In my awesomely humble opinion, it has a lot to do with enterprise technical architecture management, because every application, platform, and chunk of infrastructure you purchase or license is, in a very real sense, an investment in your company’s business. To the frequent regret of your technical experts, the best technology isn’t always the best investment.

The analogy is imperfect. In the case of Bitcoin the issue is that loss of belief will result in the collapse of Bitcoin’s exchange rate with other currencies. In the case of a technology you’ve invested in, you have no interest in reselling it. Your risk is loss of support.

This is especially true for new technologies developed by venture-funded startups. But it’s also true for established players, some of whom have been known to abandon customers when a product they thought was promising just didn’t quite pan out.

Here’s where Bitcoin and Beanie Babies come in. Belief … industry mindshare that translates to you and your peers being confident the provider will succeed … determines whether the product is an early-stage success, and is, as a result, supported.

And support isn’t merely the ability to call in technical expertise when needed to make the product do what you need it to do. Support also means distributing patches when someone finds a security hold; being able to install and run on updated operating systems; adding new features and functionality as the marketplace for the product and its competitors becomes increasingly sophisticated.

Even more important, support means you can hire top-notch talent to work with the technology.

Example: According to iDatalabs 167 businesses still rely on IMS, IBM’s ancient hierarchical DBMS. IMS still works. IBM still supports it enough that it will continue to work next year.

Try recruiting an IMS DBA and see what kind of talent shows up. And no, I’m not talking about the average applicant age. I’m talking about the average applicant’s level of sophistication and initiative. It’s doubtful someone who’s excited about working with IMS has even mastered relational data design. That puts them two conceptual generations behind what’s now possible, stuck in a hierarchical data design mindset in an era of post-relational NoSQL technologies.

So the Bitcoin analogy is imperfect: Those who develop and sell new IT products start out with Bitcoin value dynamics, where all that floats the product’s longevity is belief the product will have longevity.

But unlike Bitcoin and its advocates, IT startups have an intense focus on having the equivalent of an economy backing them, which in their case means either revenue and profits, or acquisition.

If I haven’t convinced you, a suggestion: Buy copies of The Moral Hazard of Lime Daiquiris (Bob Lewis and Dave Kaiser 2013).

The smart money predicts this will become a high-value collectible item. You’ll easily quintuple your investment.

Or at least get a few chuckles out of the deal.