Managing Business Services, Page 2
Auditing Business Service Utilization
A service provider offers a service not only out of the goodness of its heart, but for some type of remuneration. Usually, this remuneration will be based upon the number of service requests processed and the service levels delivered. This means that all service requests must be audited by the service management platform. The audit records should be stored in a permanent data store. Billing reports are run for various clients based upon how the actual utilization mapped to their contractual arrangement.
The auditing use case is shown as an extension of the monitoring use case because it is a special case of monitoring. It is primarily concerned with data that is captured at run time and analyzed later via standard reports. The data used for these reports may need to be retained longer than that of standard monitoring reports.
Modifying a Business Service Interface or Implementation
Due to the extensibility of XML, it is often possible to extend an existing request and response schema in a way that adds new capability, but is entirely backward compatible. Because this is not always possible, the service management platform should allow for multiple versions of a service to be utilized at a single point in time. It's not practical to expect all clients to migrate to the new service API in step. In this case, the service request must be inspected and routed to the appropriate version of the service. Over time, the older version of the service may be deprecated, but not until all clients are being routed to the new service.
A service management platform should have mechanisms to adapt the payload and protocol of a service request. If the published API of a service request changes, the older requests can be mapped to the new payload format of the service by way of a transformation. The service management platform can also adapt the incoming protocol to the protocol of the service. This provides the ability to make a service available to additional client types without changing the service itself. It also might be used to adapt the client protocol if the implementation of the service changes to another protocol.
A business service passes through a typical birth through death lifecycle as is common with other software. During its utilization phase, there are several use cases related to managing the operational aspects of a service by the service provider. A service management platform is responsible for implementing these use cases. We discussed some representative use cases that a service management platform would be expected to support: access control, monitoring, auditing, and service modification.
Business service management is not something to consider after services are proliferated. It should be thought of early on. A full-blown service management capability may not need to be in place on day one in order to meet client commitments. However, a framework should be in place that can be extended over time or easily replaced.
We began this series with a famous quote from the voice in the movie Field of Dreams: "If you build it, [they] will come." Kevin Costner's character, Ray Kinsella, responded to the voice, built a baseball field in the middle of an Iowa cornfield, and relied completely on divine Providence to work things out. He built it, and they came.
It's almost too easy to build and publish a "service" today—much easier than it was for Ray to build his baseball field. If you build a business service, they will come, too. It's very desirable from a service client perspective to use your service rather than build and maintain it. But, unless like Ray you heard a voice, don't count on divine Providence to work out the rest for you. Planning and organization are needed prior to being "open for business" as a service provider—or utilizing a partner's service, for that matter. A service management platform can help manage the operational aspects of business services.
Will you manage your business services or will they manage you? The rest is up to you!
About the Author
|Jeff Ryan is an architect for Hartford Financial Services. He has twenty years experience designing, developing and delivering automated solutions to business problems. His current focus is on Java, XML and Service Oriented Architecture. He may be reached at email@example.com.|
Page 2 of 2