Within the world of SOA the term service management usually refers to the control and orchestration of the invoked service (web. Business, composite, etc.), usually called SOA governance.
However, in the wider IT world, particularly for infrastructure or data center environments, service management has a different meaning and relates to the processes covering the way in which Service Levels are achieved for metrics such as capacity, availability, incident, problem, configuration, change and release management. These services, normally termed IT Service Management (ITSM) are themselves governed by various frameworks, the most common of which is ITIL (IT Infrastructure Library). ITIL was developed in the UK in the Eighties to help define and manage the provision of IT services to the business customers of all IT services, including PCs, networking, storage, servers, and applications.
I would not expect you to have come across much confusion between the two types of service mentioned above, as they tend to be encountered in different contexts. SOA services are predominantly in the domain of application or web development. They are usually code artefacts or wrappers around discrete business services, such as a credit check. ITSM services cover the delivery of all IT to the user within acceptable limits (service levels).
However, as SOA and ITSM grow in influence within organizations, their domains have started to overlap and we are now seeing a convergence of ideas leading to a confusion of terminology.
For instance, in SOA information about services is now typically stored in a service registry or repository. These contain attributes about the services (version, location, usage, access rights, etc.). For ITSM information about IT services in stored in a Configuration Management Database (CMDB) and/or a Service Catalogue. These contain attributes about the services (version, location, usage, access rights, etc.)…
Actually, the information stored in each type of database does have some significant differences, but the point here is that there is definite convergence between SOA and ITSM particularly around the concept of encapsulating the provision of some functionality within defined boundaries of performance.
This convergence is relatively recent. In the early days of web service development, when creating a callable applet or portlet little thought was give to mundane considerations such as capacity or availability of the service. Similarly, error or problem management tended to only arise during testing, and was not considered to be a core requirement by the programmers. As SOA environments grow larger and more complicated, the performance and supportability of the services has become of paramount importance. No organization will use SOA for a business-critical situation unless they are convinced that the service is delivered with no surprises. To do this requires a rigorous adherence to ITSM principles of meeting the non-functional business requirements, such as availability, capacity, service continuity, change & release management and reporting.
SOA development has produced some interesting challenges for ITSM in that the definition of service levels becomes more complicated as significantly more components (i.e. services) need tracking than for traditionally developed applications. This has increased the need for more granular monitoring and reporting capability across a more distributed production environment. There is also a significant challenge to maintain integrity for the complete transaction that I covered in a previous article, ‘Monitoring SOA End to End’.
From the ITSM perspective, some of the lessons learnt from SOA have started to appear in the way in which service management is now delivered. There is considerable interest in applying a service catalogue concept to the provision of all IT services to the business, typically with three layers of abstraction (sound familiar?). At the bottom of this structure are IT component level service catalogues defining the atomic elements of the IT components. For the data center this would be the Infrastructure Services Catalogue, covering servers, databases, software instances, network devices, environments, etc. The infrastructure services are defined by technical patterns which are the design of the technology components.
For applications, including SOA & BPM developments, there would be Application Service Catalogues, defining the process and service functionality delivered by the application services. In many cases this information is available from the Service Registry or Repository.
Above these component catalogues is an IT Services Catalogue that defines the way in which all IT services can be ordered and consumed, along with service levels and costs. The IT services are defined by the application of the service attributes to the Technical Pattern to ensure that service levels are met, and constitute the Service Design. It would include all necessary components to provide a complete service to a business consumer – application services, security, processor & storage allocation, service levels, charging model, etc. An example of an IT service could be a hosting service for a FX trading system, providing guaranteed availability and performance for all the hardware, software and network components required to meet the required service levels.
Finally, at the top level is a Business Services Catalogue which contains the Business functions or services that individual business units or clients could order or consume to meet business requirements. An example of a Business Service could be a Customer Portal, providing access to all customer information from legacy systems. This will be made up of a number of IT Services (such as hosting, internet bandwidth, Portal application, Experian Credit Check, etc) that provide the total needs of the business unit.
So from an ITSM perspective, we now have a service oriented architecture for the provision of IT to the business. And from the SOA perspective, we have a well managed and predictable delivery of functionality to the users. For many organisations, this is very much still a future state, but there is considerable merit in working towards this common goal.
