This week Todd Biske, an Enterprise Architect in a F500 company, (re)started a discussion around the relationship between ITIL and SOA. The starting point of his discussion is the observation that:
there are strong parallels between SOA and ITIL Service Management.... SOA can shift the thinking from a traditional linear lifecycle that ends when a project goes live to a circular lifecycle that begins with identification of the service and ends with the decommissioning of the service.
For Todd, this means that:
we should be thinking about application and “web” service delivery in the same way that we are thinking about ITIL service delivery...Many people think ITIL is only about IT operations and the infrastructure, but that’s not the case. If you’re a developer, it equally applies to the applications that you are building and delivering.
Jack van Hoof, an Enterprise Integration Architect, agrees with Todd. He wrote last year:
- There is the service strategy, where - among others - the market and the market value of the service is determined. The service portfolio and ownership must be managed and there must be a financial model to deliver and maintain the service.
- Then there is the service design, where solutions are developed in terms of architecture, technology, people and processes. Processes are developed with regard to service catalog management, continuity, security, service levels and more.
- The service transition includes processes like change management, configuration management, releases, planning en testing.
- Finally service operation has to be governed with focus on keeping services running. This includes for instance incident management, problem management and access management.
All of the above are aspects of SOA governance, aren't they? And this is exactly the scope of ITIL v3!
Jack adds:
there are more huge benefits to pulling ITIL in a SOA-context. These are the ITIL oriented tools.
This is actually easier said than done. A couple of years ago, Jeff Kaplan had already noted that:
Despite the common goals and guiding principles of ITIL and SOA, there is a chasm in many organizations between these two efforts.
The most significant obstacle is the psychological distance and structural barriers between the IT operations and software-development teams. [which have a] long history of working apart and often at odds [that]... make it difficult to put aside their differences to achieve a common objective.
Many organizations have permitted the same structural barriers that got in the way of properly coordinated IT operations and software development in the past to continue even as they have initiated their ITIL and SOA adoption efforts. Rather than use these initiatives to break through organizational silos, many companies are conducting separate ITIL and SOA efforts in a vacuum.
On a follow up post, Todd responded to James McGovern, who challenged him on this very question:
James: it would be highly valuable to outline what types of feedback do operations types observe that could benefit the software development side of the house.
Todd: if ops has drunk the ITIL cool-aid, then they should be measuring their service performance, the goals for it should be reflected in the individual goals of the operations team, and it should be something that allows for improvement over time. If the measurement falls into the “one-time” measurement category, like delivering on-time and on-budget, that should be a dead giveaway that you may be measuring the wrong thing, or not taking a service-based view on your efforts.
In a private communication, Richard Webb, Enterprise Architect in a large financial institution in Seattle, went a step further commenting on Todd's post:
Measurement is so over-used...knowing the "run state" includes measures and metrics (by this I mean instrumentation) but more so root cause and the "how" things really are (as-builts) and how things really work (models) - [i.e.] know the development and engineering aspects
Todd concluded by restating one of the key (but often overlooked) foundations of Service Oriented Architectures:
Adopt a culture of continuous improvement, rather than simply focus on meeting the schedule and the budget and then waiting for the next project assignment.