The Undercover IT Correspondent

IT cannot harm the business, or through inaction let the business come to harm 

In his famous science fiction epics, novelist Isaac Asimov handled the conflict between humans and robots by hard-wiring the three laws of robotics into the latter’s positronic brains. Clear, established rules governed all human/robot interactions, protecting humans from robots:

1. A robot cannot harm a human, or through inaction let a human come to harm.
2. A robot must obey the orders given to it by a human, except where such orders would conflict with the first law.
3. A robot must protect its own existence, except where this would conflict with the first two laws.

Given the sometimes conflicting relations between users and the IT department, we could also use some clear, established guidelines to govern all user/IT interactions. My suggestions for the three laws of IT follow:

Law No. 1: IT cannot harm the business, or through inaction let the business come to harm. This one would really get IT off its collective butt and into proactive mode. No more waiting around until Joe User decides it’s time to build a data warehouse a year after the competition has already been there and back. And when a new system is finally implemented, it had better work or the business might be harmed. IT would be expected to anticipate user requirements and be judged by the effect its systems have on the bottom line.

Law No. 2: IT must obey the orders given to it by a user, except where such orders conflict with the first law. Things get even better here. For users, no more battles with an uncooperative IT staff hiding behind technical excuses that can’t be proved or disproved. Straight questions must yield straight answers.

For IT, all user requests would be evaluated on purely business grounds, with the first law acting as a control for users who might inadvertently harm the company, as in the following example: Sales director to IT: ‘ I want the new SFA (Sales Force Automation) system in place within three months. ’ IT reply: ‘I’m sorry, Dave. That is unrealistic. A failed implementation could impact sales, and I cannot allow that. ‘

The second law would really reap benefits when IT can simply refuse to build certain applications until users revisit the underlying business processes to make them more effective.

Law No. 3: IT must always protect its own existence, except where this would conflict with the first and second laws. The ultimate sanity check. IT would counter any threats to its existence, unless it could be shown that the business stood to gain from its elimination. (Fat chance!)

IT would be guaranteed its rightful place within the organization, exempt from any hatchet jobs by know-it-all, MBMA (management-by-magazine-article) users or VPs with hidden agendas. Even outsourcing would be stopped dead in its tracks under the third law, because the CIO would have to be convinced that dismantling IT would benefit the business.

With the three laws of IT, everything would be under control. No more having to deal with cranky users who don’t know what they really want. No more building systems to support inefficient business processes. And no more coping with the enlightened user who seeks his 15 minutes of IT fame by trying to deploy a home-grown PC application on the network.

Now who would have thought that being a robot could be such fun?

Copyright 1995 by Computerworld Inc., One Speen Street, Framingham, Mass. 01701.  Reprinted by permission of Computerworld.  All rights reserved. 

MG

Remember when an apple was a fruit and a server worked in a restaurant? 

Any new field borrows words from standard English, and IT is no exception. However, it has reached such an extent that the norm for most words today is the IT one, and the original English meaning has been relegated to second place. For example, how many people can remember the days when an apple was a fruit, a server worked in a restaurant, access and scroll were nouns not verbs, and to default meant not meeting your loan payments? 

This can give rise to some interesting situations. Consider for example the following dialogue, in which the same words can actually describe two totally different situations.  

TOM (hanging up the phone): We’ve got another delivery problem 

MARTIN: Again? 

TOM: Missing packets, undelivered mail. 

MARTIN: What route is it this time? 

TOM: We ran a trace. It seems to be originating from the same neighborhood as the last time, the one we opened up a few months ago. 

MARTIN: Maybe it’s the new router?  

TOM: Surprisingly, no. And the hub doesn’t have anything to report either. However, we’ve got some new clients up there, and I think they’re causing problems. 

MARTIN: Maybe we should poll them more frequently? 

TOM: No, I think we’re at the right interval. 

MARTIN: Did we use the correct protocol? You know how sensitive they are. The slightest bit missing, and the phone starts ringing within 5 minutes. 

TOM: You know how careful we are on that score. Anyway, we suspect it’s one particular client, so we got the address and sent someone to take a look. Here, check this out (hands over a report). 

MARTIN(Reading the report): What a dump! Yeah, our man said he saw a lot of strange characters. He was really concerned. So, what do you make of it? 

TOM: Might have been a crash, but I’m fairly sure this is one helluva bad client.  

MARTIN: OK, that’s it! Cancel the contract! 

The above conversation today would most likely be about a network engineer and his boss trying to resolve a problem of undelivered email (as any internet junkie knows, email is broken down into electronic packets and routed along different routes by a router). While troubleshooting, they analyzed a dump which contained a strange combination of characters. They finally traced the problem to a defective client at a new branch office recently added to the network neighborhood. The clients were part of a batch of recently installed devices which are particularly sensitive to network protocol errors. 

The conversation could also however be a local courier or package delivery outfit that is experiencing recurring problems of missing mail and incomplete delivery in a difficult neighborhood where it recently set up shop. After ruling out the newly hired router (yes, they’re people who route deliveries!) at the dispatch hub, they finally suspect foul play from one of the clients. They send someone over to check out his location, which happens to be in a shady part of town. His report shows enough for them to decide to cancel the contract with this particular client.  MG.