Everyone into ITSM may use the Service Level Management process to maintain and improve IT Service quality through a constant cycle of agreeing, monitoring and reporting to meet the customer’s business objectives.
Service Level Management is the name given to the processes of planning, coordinating, drafting, agreeing, monitoring and reporting on SLAs, and on the on-going review of service achievements to ensure that the required and cost-justifiable service quality is maintained and gradually improved.
One of the activities related to that process, is the creation of a Service Catalogue which was subject to another post: “Service Catalog, what do you exactly mean?” where I tried to distinguish the different types of catalogues when we refer to either an ITSM or an SOA environment.
Most of the time companies which have implemented a service desk have a SLM module which allows defining different kinds of level agreements:
- Service Level Agreement (SLA): Which are written agreement between an IT service provider and the IT customer. SLAs are normally used for internal customers
- Operational Level Agreement (OLA): Which are agreement between two internal IT areas/departments e.g. Network Management and Operations
- Underpinning contract: Which are contract between an external supplier providing services to an IT department
Many vendors have dedicated modules which manage the SLM lifecycle with requirements collections, monitoring, escalation, and various dashboards. These modules are obviously linked to other ITIL processes and information is kept in the CMDB. Among various solutions we have different SLM modules from HP-Mercury, HP-Peregrine ServiceCenter, CA Unicenter Service Assure, BMC Service Level Management, Assyst for Service Level management, Expertdesk.
These solutions allow managing the end to end SLM process in an efficient manner through an ITSM view and sometimes the content is routed to a Business Service Management solution or specific modules managing SLAs in dedicated dashboards such as Tivoli Service Level Advisor among other system management solutions.
Service Level management in a SOA context
In a previous post I was referring to one of the intersection between ITSM and SOA. “Amberpoint proposes a module to manage web services, their performance and availability. It can monitor failures, send alerts, display useful information related to problematic web services, automate performance and so on.
HP Mercury Systinet 2 has a module title Contract/Consumer Management which promotes trust between consumers and providers by facilitating service-level agreements and other terms and conditions that bind these two key stakeholders.
Progress Actional Looking Glass provides dashboard and reports which define, sort and prioritize by business or IT metrics (customer, transaction or service type). SLAs are also monitored, managed, measured and alerts are generated. We can also easily monitor and report on SLA's for a specific customer or class of customer such as gold, silver, etc.
For some consistency we should differentiates SLAs in an ITSM framework from SLAs in a SOA. For these reasons a good thing would be to create a new acronym: WSLA for Web Service Level Agreement!!
A WSLA could either be attached to a specific service or to a composite service. WSLAs should then be linked to SLAs. An end user does not have to know what the underlying architecture of his applications is. The Service Level Manager (if such a position exists…) has to negotiate with the customer SLAs. If an IT service is based on various technologies including SOA, he should take into considerations OLAs, Underpinning contracts and WSLAs!!!
WSLAs could also be attached to Underpinning Contracts is web services are either 2rd party services or hosted externally.
Most of the SLM activities remain the same however some of them may differ:
The Service Level Requirement activity will have to be taken into consideration the definition of the WSLAs. It will not be necessary to specify to the customer the underlying technology.
The building of the Web Service Catalogue is different from the Service Catalogue and probably the responsibility should be shared between the SLM manager and the SOA experts.
The SLAs creation and review taking into consideration OLAs and UCs should also consider WSLAs. If possible a hierarchy should be built.
Monitoring should be done at two levels:
- At the SOA level (eventually in SOA center of excellence or an operation dedicated team
- At the ITSM Level (the Service Manager should have a global view on all IT services)
Coming back to Service Level Management and solutions available in the Service Desk arena, companies should be able to only deliver one and only one SLA per service and monitor it. IT and business dashboards should aggregate all underlying categories of SLAs. In other words SOA Governance vendors should be able to provides APIs to upload data related to WSLAs into any IT Service Desk/System Management solution covering the SLM process.
2 comments:
I like the way Serge has tied together SLA's and WSLA's. The hierarchical structure of SLA/WSLA is natural and makes sense and makes clear the relationship (in this case) between IT governance and SOA governance.
Very informative, thanks Serge. A "lighter" that I found to be interesting was: Service Level Management
Post a Comment