IT service management: Getting the view

Abstract

The dictate of customer orientation has become ubiquitous with today's providers of connectivity and value-added services in the IT domain. Customers subscribe to services and are billed for service usage or the provisioning of customized services. Thus, customers' view on a provider's products is from a service perspective. To approach customer orientation, the providers must in consequence adopt a service-oriented view of their operations. However practical the service concept may be to customers, services are not atomic entities. They are provided through collaboration of multiple resources managed by the provider. Such resources include hardware (computing, storage and network elements) as well as software components necessary to deliver the service. Conversely, the same resources are used to provide multiple kinds of services. The management of IT resources, as well as systems and networks built from them, has been an important area of research in the past years. The concepts that have been developed in these disciplines (Hegering et al. 1999) have been implemented and allow a reasonably comfortable level of management for today's IT infrastructures. Service management, however, poses new challenges that are being addressed in current research efforts. Three important issues raised by the transition to service management are discussed in this work. An important aspect that has to be considered in the context of service management as opposed to resource management is the interaction with customers. Fig. 1 shows a simplified version of the MNM Service Model (Garschhammer et al. 2001), which was developed in order to allow a consistent, formal representation of services. In its lower part the figure shows the provider side being responsible for provisioning the service and operating the infrastructure that supports it. The service itself can be understood as a point of access for users, divided into a usage interface and a management interface for the User and Customer roles' use. Although we will focus on provider-side issues, messages from the customer side regarding the perceived status (e.g. malfunction, degradation) of a service play an important role. When a customer experiences problems with the service, the provider may be hard pressed to react quickly in order to honor the Service Level Agreements (SLA) in effect between customer and provider. A customer's report results in a service event for use in the provider side (see Section 3.1). It will not include the cause of the problem experienced or even the infrastructural components causing it. Remember, the customer only has knowledge of the service's interface she is agnostic regarding its implementation. Hence, service events will only describe the effects of a (possible) problem in the provider's domain. From multiple descriptions of effects, the provider must infer the actual cause of the problem, identify malfunctioning or misconfigured resources and devise a problem solution. This process is by no means trivial. In large scale systems, its execution is impossible without appropriate tool support. The event correlation based approach discussed in Section 3.1 addresses the deduction of problem causes by means of user/customer feedback from a service management vantage point. IT service management requires the assessment of dependencies of a service on specific resources, resource interdependencies as well as the mapping of resources on the services provided. Most information models and protocols currently employed to manage resources lack the means to express interdependencies among the managed entities in an explicit manner (e.g. McCloghrie et al. 1999; Case et al. 1996). Many state-of-the-art component-oriented management facilities are built upon this service agnostic foundation. In consequence, the rudimentary support they provide regarding the needs of the management of IT services relies on manual configuration and expert knowledge. Section 3.2 presents an approach to extending existing information models to represent services. The introduced concepts take into account (the issues of) interdependencies. Still, they allow continued use of the same, or similar, protocols and tools for the management of services as the ones currently employed in component and resource management. Automation support for service management requires the acquisition of management data from the infrastructure (monitoring data) as well as other data related to a service and its customers. The concepts developed in the domain of resource monitoring allow the surveillance of the systems em ployed to provide a service, but without taking into account the requirements of service management as outlined above. However, attributes of services can be assembled from resource and network properties. Therefore, it makes sense to maintain the large, expensive base of deployed monitoring tools and provide a means to aggregate the disparate, resourceoriented data into service information. An architecture allowing the aggregation of resource monitoring data while reusing existing management tools as data sources is presented in Section 3.3. In the next section, we describe a management scenario that highlights the issues mentioned above in an operational environment. © 2006 Springer Berlin · Heidelberg.