The Prevalence of ITIL®
Although ITIL is far from perfect, it has become the generally accepted architecture for IT Service Management. While too few IT Service Providers are utilizing the full extent of ITIL’s architecture – the overall management of Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement – they are at least paying lip service to that architecture and are generally using ITIL descriptions as the basis of their Service Management processes.
Furthermore, IT people are increasingly becoming familiar with ITIL as the model for IT Service Management. Its vocabulary and approach to IT Service Management is generally accepted to be optimal best practice for an IT Service Management practice. Many organizations have put mechanisms in place to have their entire IT staff certified at least to the foundation level in ITIL. This ensures that everybody understands the basic model and its terminology.
Justify the exceptions, rather than the rule
As with any generally accepted body of best practice, the ‘adopt or explain’ principle applies. Under that principle, management need not be concerned with justifying why they use ITIL, but they will constantly have to explain and defend when they diverge from it. There may indeed be very good reasons why certain aspects of ITIL are not optimal for a certain situation, but the rationale has to be overwhelming to justify the ongoing defense of the deviation.
Auditors speaking the same language
Corporate and IT auditors are increasing aware of ITIL, and aware that it is the basis and vocabulary for IT Service Management in an increasing percentage of IT shops. Almost every ITIL Foundation course we conduct has, at least, one auditor in it. They realize that if they are going to communicate effectively with IT, they have to do so in ITIL terms.
Auditors realize that IT shops will be basing their Service Management mechanisms and processes on ITIL and will want IT to be able to demonstrate their satisfaction of enterprise requirements of IT in terms of what they know and what they use – i.e., ITIL.
The Specter of COBIT®
Alas, the enterprise does not speak or understand ITIL.
Almost all legal and regulatory obligations that the enterprise is bound by encompass some IT obligations and those obligations are usually expressed in terms of COBIT. COBIT is essentially a compendium of all the IT aspects of what a well-run, well-governed, transparent enterprise should look like.
COBIT encompasses far more of IT than ITIL and IT Service Management. It also spans overall enterprise information architecture, project and project portfolio management, application development as well as other aspects.
There is an overall architecture to COBIT and a defined set of processes within that architecture. This architecture is very different from ITIL’s and the process set (and to some extent, the vocabulary) are different.
Most IT organizations have enough on their plates getting their whole organization centered on one architecture, one set of process definitions and one vocabulary. They are loath to muddy the waters with another.
The Bridge too Far
The authors of COBIT never intended COBIT to be the source of how to do the various things that are required of IT, just what needs to be done and how it needs to be evidenced. So they have made references throughout COBIT to where disciplines like ITIL, ISO/IEC 20000®, PRINCE2®, TOGAF®, etc., can provide additional “how to” information.
This is the bridge can at allow IT organizations and their IT Service Management practice to understand what they have to do for the enterprise (as expressed in COBIT) in terms of what they already do (their ITIL-based IT Service Management practice).
But does that mean that they all have to know both COBIT and ITIL? How do they figure out how to accomplish this?
All well and good, but as part of the implementation of that process, how do you start demonstrating that you are doing those things in a way that will satisfy your auditors, and hence your enterprise.
The whole idea is that this should be done as a regular part of people’s duties rather than a flurry of activity before an audit.
We also realized that in addition to assigning these tasks to people, there needed to be mechanisms for assignees to confirm that the tasks have been done by producing or pointing to the relevant evidence, for allowing quality-controls checks to be done, and for various stakeholders to keep on top of it. These stakeholders might want to understand the state of things from a process viewpoint (like Incident Management), a phase viewpoint (like Service Operation) or a region (such as Asia-Pacific) and with the ability to drill down to individual activity.
Bridging the gap between ITIL and COBIT brings the best of both worlds to the IT organization. These are symbiotic practices. You do not adopt ITIL OR COBIT. In an ideal world, we would see a melding of the two worlds, giving outcomes that benefit the business as a whole.