For years it seemed as if “standard industry practices” had no place in the IT field.
What I saw happen in the 1970s, when development shops tried to standardize on the one correct way to develop systems, reinforced that.
A number of peculiar consequences flowed from those early efforts. In one shop, the minimum cost of a project soared to $25,000 – just barely enough to cover the cost of compliance with the standard way in which all systems were to be developed. The bureaucratic overhead – filling out the forms, attending all the meetings – was high. The standard became a very heavy hand that made small projects impossible and stifled development innovation. It’s unlikely that the recent introduction of such things as eXtreme Programming (www.extremeprogramming.org) would have been possible in a standard development shop.
But the world is changing. One of the more visible changes is the move towards IT outsourcing. It seems like everyone is either doing outsourcing, or thinking about doing it. There is a large and growing list of domestic and foreign vendors eager to take over a full range of IT tasks that are currently being performed in-house. The resulting outsourcing relationships can bring benefits. They also raise a number of concerns.
One of those concerns is exit procedures. It can be very uncomfortable for a client who doesn’t see any way out of an outsourcing relationship. In most cases, the service is still required. If, or when, the vendor exits, someone has to take over service delivery.
Wouldn’t the transition be much smoother if both vendors were committed to delivering their services using generally accepted IT service delivery practices?
A similar concern can arise when two organizations decide to cooperate. Effective cooperation usually requires collaborating on the delivery of IT services. Things like XML, for example, can simplify the flow of information between organizations, but real cooperation often requires that the organizations use similar procedures to manage and control their IT services.
But wouldn’t it be nice if both were committed to delivering their services using generally accepted IT service delivery practices?
It’s not as if there’s a shortage of standards – In the U.S., the IEEE has developed more than 50 that are IT-specific, and is adding five new ones each year. Our own Canadian Standards Association (CSA) has a 25-page list of IT standards for sale, with something like 25 items on each page.
You have so many different standards from which to choose that if you don’t like one, you can simply pick another.
But there is one emerging IT service delivery standard that is gaining considerable traction in the market place. The IT Infrastructure Library, or ITIL (www.itil-itsm-world.com), was developed by the U.K. government. Canada’s own Pink Elephant (www.pinkelephant.com) has made a thriving worldwide business providing advice on ITIL.
In my heart, I’m anti-standards, but in this case, my head sees the strong advantages of ITIL. It has already attracted the support of such firms as IBM, HP and Microsoft. Its framework also takes into account local conditions and, because it’s focused on the process of service delivery, it’s not based on any time limitations.
It may not yet be time for universal IT development standards (although SPICE – www.sei.cmu.edu/iso-15504 – is a promising candidate). But it is time to think seriously about ITIL. One of the indirect benefits of ITIL is that it may help us move towards an IT profession.
When we have generally accepted IT practices, we have a standard against which we can begin to measure the services of IT professionals. And that would take us an important step towards a real IT profession.
Fabian is a senior management and systems consultant in Toronto. He can be reached at [email protected].