Friday, January 27, 2006

ITIL: Normal Service Will Be Resumed Just As Soon As We Know What Normal Is

I have just attended a briefing on ITIL, the IT Infrastructure library. This was very interesting, despite not answering my burning question: pronunciation. Apparently we can pronounce it "EYE-tul" or "itt-ILL" or indeed any way we choose, including spelling out the initials1. Whichever way we pronounce it, ITIL is a framework for best practices for the delivery of IT services assembled by CCTA, the folks who've also given us SSADM and PRINCE. We tend to think about IT services as being application support, networks, etc but it should cover everything, including system development. Certainly anybody who is a production DBA is in the business of delivering an IT service.

I had come across ITIL once before, when working as a consultant for a government agency. This was a long running gig, in which we were responsible for the whole IT provision. After a couple of years the word "ITIL" got bandied around but it seemed to make no difference to our delivery of services. This briefing explained why: it takes three to five years to successfully implement ITIL. Which is quite astonishing given that these days it is rare for an IT project to last more twelve months. ITIL requires such a lot of time to implement because it is a framework for thinking about service delivery rather than a set of procedures. ITIL covers the what and to a certain extent the why; of course, the real work is in the how. Identifying discrete processes and documenting them is what takes the time, particularly as each will probably take several iterations to get them right. One useful tip I learnt is that anybody who mentions "ITIL compliance" is talking through their hat. Being a set of suggestions ITIL has nothing to comply with2.

The reason why ITIL can specify such a long time scale is that it is actually targeted at internal IT departments delivering services to their company's users. This assumption reveals itself it a number of ways. For instance, ITIL has SLAs - Service Level Agreements (the definition of Normal Service and permitted deviations) - because an agreement suffices when we have an IT department dealing with their business colleagues. This is a very bad fit with the prevalent model of IT today - outsourcing and consultancy - which is wholly driven by contracts and contractual negotiation. The next revision of ITIL (due 2007) apparently will address this aspect of service delivery.

By codifying and standardising terms ITIL provides a useful way of thinking about things. For instance it distinguishes Incident Management from Problem Management. Incident Management is when our users cannot connect to the system because the listener is down; restart the listener and the incident is closed. Normal service has been resumed. Problem Management on the other hand is when the listener has crashed three times in the last month and we need to find out why; is it because we don't have a separate listener for the extproc?

Another useful distinction is User and Customer. Both are consumers of our service. The user is the person who actually, um, uses the service whereas the customer is the one who pays for it. This means that the user and the customer have different priorities. The user needs the service to carry out their job, so they tend to be interested in quality, especially reliability. The customer has a set of targets for their business which our service helps them meet. Therefore they are interested in value for money. This matters because it is the customer who specifies the service. ITIL assumes the customer talks to the user, but this is not always the case. Another difference is that the IT Department mostly deals with the user. When it all goes horribly wrong it is the user who phones the Help Desk not the customer.

I find distinction between user and customer helpful because it illuminates several of my previous development projects. As a consultant I am exhorted to regard all the staff who work for my clients as customers. This is a good thing. But it is useful to distinguish between the people who use the system and the people who will fund its development. Given free rein in the Requirement Gathering stage users will tend to ask for the moon on a stick. We need the customer to remind them of the harsh financial realities. Alternatively it is not unknown for customers to seek to use a development project to drive through business change, riding roughshod over their own users' requirements. This is a harder one to handle: they are paying for it. All the IT team can do is assert the need for the users to be trained in the new way of working as well the new system. I think now I could look at any requirement and determine whether it is a user's requirement or a customer's requirement.

These are political rather than technical issues and ITIL is not going to solve them. However, by identifying the issues and defining responsibilities for both technical and business roles it seems to provide a useful start. I'm sufficiently enthused to consider doing the ITIL foundation course.




1. Apperently "EYEtul" sounds like something rude in Manadarin or Cantonese but then doesn't everything?
2. Although there are now the BS15000 and ISO20000 standards, which mandate certain ITIL practices.

Thursday, January 26, 2006

Oracle Patching Malarky

The last few months have really taken the shine off Oracle's reputation for building secure products. The latest spat between Duncan Harris (Oracle) and David Litchfield (Next-Generation Security Software) looks like shaping up into a fine old row.

Yesterday Pete Finnegan advised everybody using iAS to apply David Litchfield's workaround immediately. However,Robert Lemos owver at Security Focus reports Oracle's Harris as saying something along the lines that Litchfield's workaround is inadequate and "the configuration changes have at least five technical problems that could cause problems for some applications" (paraphrase by Security Focus not Harris's actual words). Harris recommends testing it before deploying to a production server. This is obviously sensible advice.

Whether Oracle going toe-to-toe with security researchers is a sensible strategy is slightly less obvious.

Tuesday, January 24, 2006

Doom! Misery!! Despair!!!

Why is everybody in London so miserable? It's because of the constant bombardment of doomladen headlines from the Evening Standard.

Friday, January 13, 2006

Get your output in real time

Roger Cunha has posted a neat alternative to DBMS_OUTPUT on the OTN PL/SQL forum. It uses UTL_FILE to write to stdout, which means you can get output from your PL/SQL procedures whilst they are still running. Obviously it's only for *nix platforms and you can only see the file from a SQL*Plus session on the database server. Still, it's a cute trick to keep in the toolbox.

Of course, screen output remains the Devil's Debugger.

Wednesday, January 11, 2006

Buy Sun, Get 10.2 Free!

Sarcastic IT site El Reg has a report on the latest Sun and Oracle pricing move: buy an UltraSPARC server and get Oracle Enterprise Edition free. Well, we have to buy a year's worth of Oracle support but we'd all do that anyway, eh? The key thing about this is that the price is free regardless of how many processors the server has. Now that's the sort of licensing model everybody can understand.