The other side of IT vision

“Having worked at [Microsoft] for some time now, it’s no clearer from the inside, trust me. I think that the visions proffered by [Microsoft], IBM, et al may actually prove Heisenberg’s Uncertainty Principle on a macroscopic scale.”– A reader who shall remain nameless lest the same fate should befall him as befell Michael Hanscom (read more)

Last week’s column regarding the product “visions” of the major vendors generated quite a bit of comment. It appears that readers agree that vendors’ product vision has, to a significant extent, replaced the solid architecture advancements and developments that IT requires.

For example, Lance, who prefers we only use his first name, wrote: “The problem with both IBM and Microsoft is they’ve both become so used to spreading manure, smelling it and telling us that we should believe them when they tell us it smells good, that they actually now believe it smells good themselves and keep spreading it. Conversely, the marketplace is now finally not reacting like sheep and realizing that their stuff actually stinks, rather than simply believing their PR machines’ respective word for it. It makes for great comedy sometimes, as in the case you pointed out in the article.”

I love being agreed with but I might have understated the vision problem. Not only has vendor vision been part of the problem but so has buyer vision. We’ve conjured up views of how things should be that have led us into product choices that now are costing us on the strategic front.

For example, our vision of a “standard” platform for users and servers is something that has had an obvious appeal to network executives since PCs started becoming a corporate IT foundation. But that standard came about not as a truly strategic choice but as a choice driven by expediency.

The result was that most organizations adopted the Wintel architecture as the desktop standard. If you doubt that this wasn’t a completely rational choice, just consider that Intel’s processor architecture doesn’t implement a continuous memory model. The added complexity for programming is non-trivial, yet we all bought into it!

And Windows: Where do I start with the heinous architectural issues that Windows has delivered? Even if you overlook the obvious kludges, you are left with the undocumented APIs and self-serving system elements that are not insignificant issues when it comes to building networks and applications.

Nope, it wasn’t that these were the best architectural choices, but they were cheap and, in the course of time and marketing, became imbued with the “nobody gets fired for buying . . .” spin.

And while you might cite all sorts of justifications for what we wound up building our networks out of, the truth is that our choices were simply driven by little more than expediency.

It seems that years ago we forgot that strategy matters, and we selected tactical choices based on our flawed short-term visions. Now those choices are costing us because we’ve created a worldwide network monoculture based on the lowest common denominators.

This kind of uniformity exposes us to problems that are enormous in terms of the risk involved and the cost to try to fix them. The risks are easily highlighted, for example, by the effects of the MS-SQL Slammer worm, while the costs are illustrated by the downtime caused by Slammer and now endless streams of Microsoft operating system patches.

It is time to start asking some serious questions about how we deliver processing power to our organizations and whether we’re leading ourselves into a vision that we didn’t create but rather bought from vendors that is, in reality, unsustainable.

Is your vision 20/20? Eyesight test results to backspin@gibbs.com.