Managing Business Services

Introduction

In the previous article, "Producing and Consuming Business Services," we discussed the roles and responsibilities of the service provider and service consumer and their relationship with one another. A service provider enters into a contractual arrangement with service clients, specifying the services, service levels, and interfaces to be provided. Becoming a service provider is a big responsibility. Prior to publishing a service, a service provider should understand the use cases involved in the operational aspect of offering services to clients. Putting a platform in place to help automate these use cases could be the difference in meeting or breaking its commitments.

We'll begin by reviewing the lifecycle of a business service. This will provide a context for discussing the high-level use cases related to managing services. Each use case will highlight the features of a service management platform that automates the operational aspect of business services. We won't discuss any particular third-party products for managing services per se, but focus on the features such platforms would be expected to support. We'll end with a summary of the major points covered.

The Lifecycle of a Business Service

The lifecycle of a service is a typical birth-through-death cycle. (I suppose it's possible that some services may also be resurrected over time.) The first phase in the lifecycle of a service is its development or incubation phase. During this phase, the service request contracts are modeled and implemented. Once the service and its APIs have passed functional and technical quality assurance, the service is ready to enter into the published phase. During this phase, the service endpoint, service levels, and contracts will be stored in a public or private registry where it may be discovered by clients. Once clients begin using the service, it enters its utilization phase. Over time, there will be changes to either the implementation of a service, its interface, or both the interface and the implementation. When the service provider no longer has any contractual responsibilities to provide the service, a service may be deprecated and ultimately retired. These phases are depicted graphically in Figure 1.

Business Service Management Use Cases

Since we're discussing the operational aspects of managing business services, we'll be concentrating on services that are in the utilization phase. We will survey some of the high-level use cases that occur during this phase:

Access Control

Service Monitoring

Service Auditing

Modify Service Interface/Implementation

These use cases represent some of the many responsibilities of the service provider. They would typically be implemented by a service management platform. A high-level use case diagram is depicted in Figure 2. Note that this is a representative, but not comprehensive, set of use cases.

Let's provide a definition for each of these use cases and discuss the features of a service management platform that implements them.

One of the preconditions for utilizing a service is being authorized to do so. In some cases, the service or service request may be made available to all internal clients or even the general public. It's more likely that clients will need to be authenticated by the system and authorized to access a particular service request, especially if remuneration is involved, or if sensitive information is being accessed. In this case, security profiles need to be established and maintained for service clients.

A patchwork services management platform will require each service to implement the authentication and authorization functions. A much better solution will have a common security framework to encapsulate this feature. In many shops, existing security mechanisms are already in place. Ideally, the service management platform security framework should leverage existing security mechanisms in use for business-to-business, intranet, extranet, or Internet Web applications.

When sensitive information is being transmitted, service requests and responses may be encrypted either at the transport or payload level. Transport encryption will always encrypt an entire message. Payload encryption may be entire or partial, where only sensitive pieces of information in the message are encrypted. As with the authentication and authorization features, the encryption feature should be implemented by the service management platform in a common way for all services.

Monitoring a Business Service

In order to manage the operational aspect of business services, the service provider needs a variety of data about service activity. This data will be used to monitor system reliability, availability, scalability, performance, and security. Some of the data might be real time and reflect the current state of the service platform. Other data will be captured at run time and analyzed later to spot trends and identify areas of improvement.

A real-time view of the service platform might be represented in a service management dashboard that highlights current service activity. The dashboard would show current service request volumes, faults, and response times, among other things. The dashboard is used by the service manager, architects, and developers to monitor service activity and diagnose problems.

Real-time service management alerts notify support personnel when certain thresholds are exceeded. Since it's the service provider's responsibility to meet a certain quality of service measures, it is important to pro-actively respond to any degradation in these measures. It's quite possible that the popularity of a service will lead to a large, unanticipated volume of requests. Alerts will kick in before clients are adversely affected and trigger corrective action to be taken.

Most Web servers provide access logs showing the time a resource on the server was accessed by a given user. These logs can be used to monitor server activity and generate information helpful in managing the site. This information might include user profiles, usage patterns, and the access frequency of site resources. A service management platform is no different in this regard. It should also create access logs showing which users accessed a particular service request. The capability to generate both standard and ad hoc utilization statistics from the logs would be expected as well. In today's service oriented architectures, messages are often passed in XML, which is a self-describing, payload format. It is possible and very desirable to have the ability to mine request and response messages for data in the payload to capture at run time and analyze later.

Service management traceability provides the ability to diagnose faults. Because a service request may involve multiple network hops and span multiple tiers and layers in the architecture, it's important to be able to isolate exactly where a fault occurred in order to be able to diagnose the problem and implement a solution. A service management platform should provide the ability to trace service execution and aid in root cause analysis of faults.