May the Source Be With You

[Dave Farber <dave () farber net>]

http://www.pbs.org/cringely/pulpit/pulpit20030814.html

May the Source Be With You
IT Productivity Doesn't Have to Be an Oxymoron, but Outsourcing Isn't the 
Way to Achieve It

By Robert X. Cringely


India, outsourcing, and the concept of IT productivity were the topics here 
last week, and there is so much more to be said. But first there is that 
computer pathogen du jour, the pesky MSBlast worm to be dealt with. This 
was an old story before any of us even read it this week. That darned worm, 
which exploits the recently discovered RPC DCOM vulnerability in Windows, 
has been creating a lot of trouble for no good reason. It targets TCP port 
135. Why would any company have port 135 open to the Internet? It makes no 
sense. A competent network manager who is not using port 135 for something 
darned important ought to have that door locked tight. If your network was 
affected, you should be asking why.

Microsoft distributed a patch for this bug a month ago. If your network was 
affected, the patch wasn't installed. What took so long? But don't be too 
quick to blame your network administrator: In some companies, the data 
security guy has to approve a patch before the network guys can install 
anything. There is plenty of blame to pass around.

Microsoft is hardly blameless, either. A very good friend of mine (one of 
Microsoft's major customers at the time) recommended to Redmond precisely 
the e-mail safeguards that would have made this week's problem impossible. 
Since he was a big customer, they said they'd look into it, but did 
nothing. That was in 1991. Is 12 years too long to wait for vendor 
responsibility?

Yes.

Now back to India, outsourcing, and IT productivity.

First, a trick question: Why aren't Apple Macintosh computers more popular 
in large mainstream organizations? Whatever the gigahertz numbers say, 
Macintoshes are comparable in performance to Windows or Linux machines. 
Whatever the conventional wisdom or the Microsoft marketing message, Macs 
aren't dramatically more expensive to buy and on a Total Cost of Ownership 
basis they are probably cheaper. Nobody would argue that Macs are harder to 
use. Clearly, they are easier to use, especially on a network. So what's 
the problem? Why do Macs seem to exist only in media outfits?

Apple is clearly wondering the same thing because the company recently 
surveyed owners of their xServe 1U boxes asking what Apple could do to make 
them more attractive? For those who own xServes, they are darned attractive 
-- small, powerful, energy-efficient, easy to configure and manage, and 
offering dramatic savings for applications like streaming. Yet, Apple 
appears to be having a terrible time selling the things.

I used to think it came down to nerd ego. Macs were easy to use, so they 
didn't get the respect of nerds who measured their testosterone levels by 
how fluently they could navigate a command line interface.  Now, I think 
differently. Now, I think Macs threaten the livelihood of IT staffs. If you 
recommend purchasing a computer that requires only half the support of the 
machine it is replacing, aren't you putting your job in danger? Exactly.

Ideally, the IT department ought to recommend the best computer for the 
job, but more often than not, they recommend the best computer for the IT 
department's job.

Now another question: Why are Linux computers gaining in popularity with 
large organizations while Macs, which are based after all on BSD Unix, 
aren't? While there is certainly a lot to be said for Linux in competition 
with various flavors of Windows (Linux is faster, more memory-efficient, 
more secure, has more sources of supply, supports many more simultaneous 
users per box in a server environment, and is clearly cheaper to buy), the 
advantage over Macintosh computers is less clear.

Again, it comes down to the IT Department Full Employment Act. Adopting 
Linux allows organizations to increase their IT efficiency without 
requiring the IT department to increase ITS efficiency. It takes just as 
many nerds to support 100 Linux boxes as 100 Windows boxes, yet Linux boxes 
are cheaper and can support more users. The organization is better off 
while the IT department is unscathed and unchallenged.

I am not claiming that every organization should throw out its PCs and 
replace them with Macs, but the numbers are pretty clear, and the fact that 
more Macs don't make it into server racks has to be based on something, and 
I think that something is CIO self-interest.

Macs reduce IT head count while Linux probably increases IT head count, 
simple as that.

I didn't come up with this very smart idea, it came from a reader. That 
same reader made the point that every part of an organization ought to be 
concerned with improving the bottom line, which is to say with being more 
productive. Yet IT typically doesn't work that way. Since we can't 
effectively retrain IT, we outsource it, but that's no better. Costs may 
appear to go down, but overhead inevitably rises even when the real work is 
moving to India.

Some people dispute my claim that moving work to India increases overhead. 
Well, overhead rises whenever layers are added to the network stack. If you 
move IBM to India there is no increase in overhead. But if you move a big 
chunk of IBM to India, but keep the rest of IBM where it always was, you 
have to create an interface layer simply to decide what information goes to 
India, what information doesn't, and how does the information that does go 
to India (or comes back from India) get where it should go? That's extra 
overhead and it costs money -- U.S.-scale money because this bit of 
overhead takes place here, not in India.

And this leads us to why many development efforts of western companies in 
India don't work out. The problem with Indian software development is 
typically two-fold. In one sense, the Indian developers can't relate very 
well to the foreign end-users (us), and that can lead to problems. But far 
worse is a problem that is almost the opposite: The Indian coders are 
treated as just that -- coders -- with all architectural decisions being 
made 12,000 miles away. There is virtually no input to the architects from 
the coders because none is sought. That means problems that ought to be 
noticed early -- and probably are, but in India, not the U.S. -- are 
noticed too late.

One solution is to allow the Indians greater autonomy, but I think the best 
solution is to make the architects, whomever they are, live with the coders 
-- something that is literally NEVER done.

So outsourced IT is less efficient, but with those low Indian wages it 
certainly must be cheaper, right? Not necessarily. Let's look at the 
situation that brought us to this topic in the first place -- IBM's 
apparent decision to send IT jobs to India. These next few paragraphs are 
IBM-specific, but I am sure they could be applied equally well to many 
other large IT organizations. Are you paying attention, EDS?

Businesses are successful when they sell products and services people want. 
IBM's greatest problem is they have not placed any internal value or 
importance on the quality of their products and services, only costs. Look 
at how this focus on cost not only hurts products and services, but 
actually drives up the very costs it is supposed to be bringing down.

There are many people in IBM whose job it is to smooth things over. These 
folks don't contribute to any product or service, and if the products or 
services were better, these people wouldn't be needed at all. I call this 
the CYA Layer, and all it does is make outsourced IT that much more 
expensive for no good reason.

Part of the myth of IT outsourcing is that it saves money because you only 
pay for big brains when you need big brains, but that's not true, either. 
In the IBM example, you only get the brains if you're will to pay for 
consulting services. For every hour of brains, you will be charged three 
hours. The other two hours go to management and project management, which 
is to say they are wasted.

I even have doubts about the quality of those brains, too, not just at IBM, 
but at virtually any of its competitors. That's because the financial model 
for outsourcing doesn't pay to maintain education and certification. IBM 
cut most of that a couple years ago, and the rest of it went this year. In 
another year or two, most of IBM's MSCE's will have expired, for example. 
The ones that will remain will be those who paid for it out of their own 
pockets. Where are the brains in that?

The answer to IT productivity is to first decide who the customer is, and 
that isn't the CIO, it is the CEO and the janitor and anyone in between 
with a computer. Once we all agree on who is the customer (something most 
organizations never do), then purchasing decisions get easier. Truly useful 
products are bought when they are needed by customers. Now there's a 
brainstorm. And while you can outsource IT to Boston or Bangalore, today it 
is probably cheaper for a good-sized company to hire six to 12 smart 
people, empower them, keep their training current, and have them run the IT 
organization. A few smart leaders with a good pool of contractors can do a 
better job with open source support tools than IBM or any other outsourcing 
vendor can with its proprietary tools. That is because your IT department 
will better know your needs, and will have those needs at heart IF YOU MAKE 
THEM DO IT THAT WAY.

What's ironic in this IT outsourcing is that the end game has not the big 
U.S. companies winning, but their Indian subcontractors. This isn't rocket 
science, and the Indians are going to quickly see that they can cut out 
their U.S. employers and go directly to the customers. It won't happen 
immediately, but eventually every U.S. outsourcing vendor will try to bring 
the work back in-house for this very reason. And we'll be paying for it all.


-------------------------------------
You are subscribed as interesting-people () lists elistx com
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/