Over at HDS, the always thoughtful Hu Yoshida, discusses a recent CIO roundtable he attended. I’ve spent years of close listening to customers to understand the nature of their communication. Despite the “high-tech” aura of their work, I’ve found that IT people are very much like manufacturing people rather than engineers, and you have to listen to them with that in mind.

IT is a Factory
Let me explain. IT gets measured, like any manufacturing operation, on timely execution against well-defined metrics. If a plant commits to shipping 2000 widgets on Friday, everyone is going to know if they did. And if the quality stinks everyone is going to know that too, when the returns start pouring in. So manufacturing folks are big believers in process, in figuring out a good way to do something and then working all the bugs out so the process is highly repeatable. Same with IT. If employees don’t get their paychecks, it gets noticed, fast. If the network is down, ditto.

Now one thing you notice about manufacturing people if you hang with them a while is that their process becomes almost sacred. Once they get something that works they HATE to give it up, and who can blame them? Gettin’ freaky on the floor doesn’t get widgets out the door.

It isn’t so different in IT land. The air conditioning is better, but the pressure to deliver no less intense. Like their plant floor counterparts, IT managers worship process and order, good vendor support, predictable workloads and stability. Which is exactly what puts them at odds with the business units they support.

The Difference Between Listening And Hearing
So when I listen to IT folks, I understand that some of what they say is what they always say: “Too much change” — zero is about right; “Vendors need to work with us” — even though the business units (BUs) have the problems and write the checks; “We don’t worry about vendor lock in” — potential vendors go away; “We are aligning with the BUs” — but we never seem to get there. It is all very reasonable from within the hushed confines of the glass house. Which is why every few years the BUs dump their ad hoc business solutions back on a groaning IT organization. Then they can go off and do it again. Minicomputers in the ’80s, PC LANs in the ’90s.

So there really wasn’t much new in Hu’s recounting of the CIO’s comments. Except one new thing I hadn’t heard before. It’s important because CIOs aren’t much interested in new things except in self-defense. Yet this comment was unique: an area where the BUs and IT agree:

. . . this meant more focus on the consumer space. [One CIO] said that applications must be more intuitive. “You don’t need a manual to use Yahoo, but you do need a manual to use SAP.”

Somehow I doubt the CIO understood the implications of what he said, because if he had he wouldn’t have said it. Put bluntly, he sees the consumer web app software model taking hold in the Enterprise. Now don’t sell Oracle short: this is one canary in a coal mine. It is the implications for IT infrastructures that interest me. To understand that you need to understand the dynamics between the BUs and IT.

The BU folks typically have a “some love, mostly hate” relationship with IT. Wherever they go they see what the competition’s IT does that they can’t. They discount the good in what their IT delivers and exaggerate the bad. They look at every online experience they have and compare it to what their IT group delivers. When the gap gets too great, they start buying their own technology to close it.

Web apps in the 00s? Oh-Oh.
So what gaps are BU execs seeing today? How about the speed with with which numerous small companies are rolling out web-based applications that come out of nowhere and scoop up millions of users in months, sometimes even days. Eventually the light bulb goes off and the thought balloon over their head reads like this:

Hey, I pay $6m a year to my IT group, and yet these kids put together this cool app that millions of people are using for just a tiny% of that. Dammit, every time I want something it is two years and another mill. I’m going to give the CIO one more chance to show he can do what these kids can, and if he can’t we’ll find someone who can!

At that meeting, the CIO carefully explains:

  • Our primary vendor has it on the roadmap
  • The server cycles and storage are too expensive
  • We’d have to hire it done and who’d maintain it
  • That thing you saw isn’t a real enterprise level app anyway
  • Check back in a year . . . .

The BU guy sits there fuming “kids . . . six months . . . he can’t? He’s toast!” And the light on the big “CIO Wanted” sign out front of corporate goes on again.

This is the risk to CIOs and installed vendors of big iron products. Not today, but within two years the aggressive financial services firms will start rolling out pilots based on the web app model. Big iron won’t go away, but its growth will.

The key to these massive web apps isn’t just AJAX or Ruby on Rails or whatever the latest Web 2.0 code fad is. It is an infrastructure whose hardware is so cheap and redundant that huge amounts of processor cycles can be profitably “wasted” tweaking the user experience.

It’s all open source software, so if they need 2000 databases, they install ’em. The servers are $600 each, not $3,000. The storage is $800/TB, not $15,000. Throwing hardware at problems is cheaper than taking months to optimize the code. Which is the kind of responsiveness BUs want. And are learning to expect, from the consumer side of the world. There is nothing here that can’t be predicted. Timing uncertain, but the economics and organization dynamics are inexorable.

Listen hard enough and you can hear the future.