ITIL & Service Oriented Architecture
We hear a lot of buzz these days in software circles about Service Oriented Architecture (SOA). Software architects certainly place prime emphasis on it. But, beyond sharing the 'SOA' acronym with ITIL's 'Service Outage Analysis,' how closely does Service Oriented Architecture really align with ITIL? Read on . . . the answer may surprise you.

The IT Infrastructure Library (ITIL®) as we all know provides us with a descriptive framework of best practices for the delivery of the components of the IT infrastructure as a set of services to the enterprise; better known as IT Service management (ITSM). The IT Infrastructure Library provides a source of guidance on what an IT organization needs to think about in order to provide an IT organization to deliver and directly support IT services.

IT Service Management is more than just the processes described within the IT Infrastructure Library. Effective IT Service Management requires the integration of several well-accepted frameworks, methods and standards. ITSM itself plays a major role in an overall Continuous Service Improvement Program (CSIP), which represents fundamental changes to the business and IT organizations, and how they approach IT and the utilization of IT services in enabling business processes.

Service-oriented Architecture (SOA), in its most common definition deals with an architectural approach to the design of a software architecture that uses loosely coupled software “services” to support the requirements of (enables) the enterprise’s processes. In a properly architected SOA environment services are made available, independent of other services and can be accessed without the user (enterprise user) knowing about (or caring for that matter) the details of their underlying platform implementation.

Think of it as architecting a software utility. The logical extension of the concept is architecting the entire IT infrastructure as a utility service that incorporates both the application software and its hardware delivery platform.

The intent is to support both the integration as well as the consolidation of complex enterprise activities. Unfortunately, SOA currently does not specify any framework or methodology to actually implement a “service-oriented architecture.” Unlike ITIL, which is owned by the Office of Government Commerce in the UK, SOA currently has well over 50 organizations trying to move it along its evolutionary path.

Neckties & SOA

The old saying about never throwing away a necktie, just hold on to it and it will come back into style is applicable to SOA and ITIL too. Many of the concepts underlying the development of “loosely coupled” applications can be traced back to the COBOL days. For those of you that have not been around the galactic core once, COBOL is a 3rd generation programming language and stands for Common Business-Oriented Language.

Back “in the day” the mantra was “reuse,” which lead to structured programming, which lead to “object-oriented design” which lead to “object-oriented” languages which required “object-oriented analysis” … and the cycle went on until the “next big thing” came around (client server). The idea behind “object-orientation” was that we could build “objects” that could be used to assemble various applications. These objects could be plugged in and used without the need to understand how they worked. All you needed to know was what the “object” expected as input was and the form of the expected output from the “object.”

It was a very powerful concept, and when properly implemented was very successful in providing robust and flexible software applications to the enterprise. The difficulty was the commitment required by both the business and IT management in its adoption and the discipline and structure within IT necessary for its success; thus its demise.

Object-oriented Design (OOD) seems to have morphed over the years into the Object Management Group’s (OMG) Module-driven Architecture (MDA, which OMG has trademarked. MDA is viewed as a way to provide a platform independent service model for SOA. Okay!!! I’m confused; what does this have to do with ITIL? Hang in there...

One more trip in the “Way Back Machine” to the first version of IT Infrastructure Library (all 41 books); one book in the library, Understanding and Improving IT, was written from the business customer’s perspective and laid out what the business customer’s responsibilities were to become an efficient and effective consumer of IT services. It was probably the best book of the first version of the library because in effect it says (I’m paraphrasing),

“If the business and IT don’t get their goals aligned then none of this other stuff matters. And, oh-by-the-way, it’s the responsibility of both the business and IT to make sure that happens.”

That book has a lot of text and diagrams that read and look very similar to many of the text and diagrams in many SOA documents that are available today. It should not come as a big surprise, since the book was written about the same time object-orientation was reaching the top of the “hype-curve.”

Where There is Hype There is Fire

Over the years a number of frameworks (ITIL and CobiT) along with various methodologies (PMI, Prince2, Lean, Six Sigma, Lean Six Sigma, and Deming etc.) and standards (ISO17799, ISO9001:2000 and ISO20000) have come into being to address many of the issues facing the modern IT organization.

Why are there so many frameworks, methods and models? Good question, and about the only answer I can come up with is that each was created to address a particular set of problems from the viewpoint of its creator. In other words, each of these is a nail to someone’s hammer.

When examined carefully one discovers that there is some significant level of overlap and some gaps when compared to the others. So, while created from a particular viewpoint, they all end up addressing a similar set of problems and often deal with them in a similar fashion (similar to “parallel evolution” explaining why most alien species on Star Trek only differed in skin color and the shape of their forehead).

There is also an evolutionary flavor to some of the frameworks, methods and models as the industry has matured and as IT has evolved from the “automator” of clerks to enabler of business process. The current evolutionary stage of IT has IT Services becoming part of the overall enterprise value chain, or the “new” term “value net.” IT organizations are being challenged to become “service providers” within their own enterprise.

The result is a mish-mash of frameworks, methodologies and models that are all “serviceable” in their own context, but in one way or another fall short of providing a complete “solution” to what an IT organization must do in order to achieve continuous service improvement and all that goes along with it.


Probably the easiest way to think about ITIL (actually ITSM) and SOA is that IT Service Management provides the necessary guidance for an IT organization to plan, design, develop, deploy and support business aligned IT Services. These services include the hardware, software and other IT assets necessary as well as the overall guidance for the IT organization in the provision of these services. Therefore, ITSM provides the necessary underpinning processes required to realize an infrastructure delivery platform that would support a Service-oriented Architecture.

Related programs