Why   IT   Doesn't   Work

Home
Up 
   

Venders-Schmenders 

There’s an old sort-of joke where the CTO finds he has tremendous problems getting his brand new application on his brand new servers working right—the response time is 120 seconds and the application crashes every few hours. The CTO calls the vender he bought all this stuff from and asks him to send out some technical staff (gratis) to get the kinks out. The sales manager says none of the top technical staff are available, but he can send out more sales guys… 

I’ve got news for you: the real joke is that the vender’s technical staff probably can’t fix the problem either at this point. When you go into the gift shop, the sign says, “You break it, you bought it.” In the IT business, the sign says, “You bought it, you integrate it.”  

Yes, you can rent staff from the vender’s consulting division to integrate the thing, but that raises a few little issues: (1) You probably didn’t budget for twelve consultants at $250/hour for six months since the sales guy forgot to talk about that, and (2) you only have about a 40% chance the consultants they send along will be sufficiently competent, in my experience. Oh, and the solution may be totally unfixable, no matter who works on it. More on that below. 

Before we go on, let’s clarify our domain of discourse, in case some of you weren’t paying attention when you read the earlier columns: In WITDW we’re talking about large-scale applications and enterprise infrastructure at Fortune 500-sized entities. We’re talking about the crucial systems that serve thousands of internal users and millions of customers via the web. We’re talking about the hard parts of IT, not getting MS Office running on everybody’s desktops. 

The Loading Dock 

Let me, as usual, relate a war story to connect my concerns to the real world. During a brief 28 year span of my life, I worked for a large hardware / software / services vender we’ll call Big Computer Company as, successively, a system developer, systems engineer, enterprise architect, and enterprise technology consultant. While I was wearing the hat of the enterprise architect, I would help the various sales teams design solutions to the problems of our largest customers and communicate those solutions to the clients. I would also work hands-on at the very earliest stages with clients to guide them towards the parts of the technology that would actually meet their long-term needs, i.e., help them avoid seeming solutions that had subtle limitations or were otherwise dead-ends (much more on this in later columns). I would do these tasks gratis for our large clients.  

What I seldom did was work miracles. This was about to become a problem. 

So I get a call that resembles this from a senior sales rep in a sleepy southern town one afternoon: “Mike, we just sold Big Southern University a whole lot of software and hardware and network products. They want to wire the whole campus and build a huge digital library and support distance learning. (N.B. This happened just before Internet technology arrived to make this commonplace.) A lot of the software is pre-release (i.e., doesn’t work) and the network cards are prototypes and no one’s ever tried to integrate these products.” 

“The brand new University IT Director is extremely excited about all this flashy stuff, but the staff here hasn’t really done anything in the last five years except keep the old mainframe systems running.” 

“The equipment and software will be on the loading dock here in two weeks. We really need an architect to come down and figure out how to get it all working.” 

If I’d had coffee in my mouth, I’d have performed a spit take à la Danny Thomas. 

Deep analysis will reveal just a couple problems here: 

·         The university IT Director didn’t understand the capabilities or culture of the existing IT organization, didn’t understand the complexity and risk inherent in the project, or didn’t bother to read the contract to see what BCC was obligated to do.

·         The sales rep was absurdly naïve, imagining that the sleepy university IT staff, with a little spare-time assistance from the various product developers at BCC (who were thousands of miles away from BSU, and from each other) and a few weeks of my time (between other projects) could possibly install, debug, customize, and integrate a complex set of products that were not even ready for customers.

·         And, of course, the sequence of events was similar to sending a Cub Scout den out to Lockheed Martin with a few billion dollars to spend and then trying to build a Space Shuttle Orbiter with whatever they returned with. It’s just a little better to architect a solution before buying a bunch of parts than after

Sounds like BSU has a big problem. Thank Gates this never happens at (your company’s name here), right?  

Baloney. I’ve seen case after case where IT selected hardware or software that was highly inappropriate for the problem and then spent years trying to get it to work: Intel servers when they needed Unix, and Unix servers when they needed mainframes, and two-tier client-server that would never scale, and niche infrastructure software from a six-person company when they needed an enterprise solution. They’ve tried to deploy networked applications that could only ever work if the speed of light were increased. And on and on. 

The venders will always try to sell you something. This is America. If you’ve got an unusual or large-scale problem, the sales staff probably has no idea whether the proposed solution will work. A few senior technologists at the vender may be able to design a solution that will actually work, but even they can’t make the wrong products solve the problem. 

In any case, it’s the responsibility of your CIO and CTO to ensure that you have a couple really superior systems engineers and architects in-house. This is quite hard, so they probably haven’t gotten around to it yet.  

If you have these guys (and listen to them), you control your IT destiny, and in the long run, you will succeed.

Your alternative is to ensure that your managers and staff can put just the right tragicomic spin on that immortal IT line, “Gee, the vender said it would work!”

 

 

     

 

Send this page to a friend:     

Copyright © 2005 Why IT Doesn't Work
Last modified: 11/21/2005
No Project Managers were harmed during construction of this site.