I wrote at length in 2008 on applying ITIL (v2) to SOA, and it is interesting to see how much of that still applies to ITIL v3, and in fact even more so, given the focus on service.
To recap:
"Service-oriented architecture (SOA) proposes a model of software as a distributed network of cooperating services, in contrast to the traditional, more monolithic application model. Operationally managing such applications requires a sophisticated management organisation and operating framework that are capable of defining and sustaining service levels to customers across the enterprise.
ITIL is the widely adopted framework for service management, defined as the management of an IT infrastructure of hardware, software, communications equipment and facilities, documentation, and skills used to provide the required service at the required level of quality."
Though the ITIL definition of service is much broader than that of SOA, the ITIL provides a useful framework for thinking about how to build and manage your SOA.
Service Strategy
A well defined and clearly articulated service business strategy is crucial to the ongoing success of a Service-oriented Architecture. It needs to be "defined" so that the architecture evolves in the desired direction. It needs to be "clearly articulated" so that during the long journey people remember why the process was started. Your strategy will answer questions like:
- Why are you building software as services?
- What is the business case?
- What is the goal (in bothe business and technical terms)?
Service Design
The ITIL concept of service design expands the traditional software service analysis design activity to include the consideration of the following:
Supplier Management : "No man is an island", and this applies especially to SOA, where the number of "suppliers" that services rely upon to fulfil their function increases dramatically over traditional, monolothic software architectures. Supplier management is about understanding which services your services rely upon, who owns those services, and defining contracts and SLAs with those service providers.
Service Level Management : Having defined contracts with service consumers and suppliers, service level management is about monitoring and enforcing that SLA, dealing with exceptions, and communicating effectively with both.
Service Catalog Management : Your service catalog or repository or registry or whatever you want to call it is that place where questions like the following are answered: What are your services? Where are they? What different versions are there? Who uses them? What SLAs are defined? Where can people find out about services?
Availability Management : Availability management addresses questions around ensuring that your services can meet their SLAs, considering the availability of services during planned or unplanned service outages, unexpected increases in volumes, etc
Service Transition
The initial build of your services will only form a tiny part of the overally lifetime of the service. Managing the potentially frequent changes to your services forms the focus of the ITIL service transition discipline.
Change Management : Change management is about being able to introduce change with minimal disruption to service consumers. A versioning policy will form a key part of this process, that is the ability to introduce new service versions without disrupting existing clients, as well as defining processes to enforce managed migration to the newer versions.
Knowledge Management: Effective decision making and service support requires information such as who is using your services, how are they being used, etc
Release and Deployment Management : SOA requires continuous deployment methodologies in order to satisfy the SLAs that govern the linkages between services. Consideration needs to be given to how multiple service versions may be run concurrently, and the how deprecated services will be managed and phased out.
Service Testing and Validation: SOA requires automated testing to allow rapid regression testing
Configuration Management System: SOA requires that services are versioned, and readily visible to the client community.
Service Operation
Operating a complex network of interoperating services is more complicated than monolithic architectures and needs
Event Management: monitoring services, alerting and triggering responses
Incident/Problem Management : service incident logging and classification, knowing what steps to take, who should do what, SLAs for completion, escalation procedures, client notification procedures, evidence capture, reviews,
Request Management : providing channels for clients to request an receive services, information to customers about service availability and procedures for obtaining them, sourcing and delivering services, assist with general information, complains and comments
Access Management : managing access to service to authorised users and nobody else, monitoring