Web Service Management

According to a recent commentary by my CBDI colleagues, web service management is stuck in the chasm (21st October 2004). In this piece, they discuss web service management from a tool perspective - what are the vendors up to. But we also need to think about the web service management process. Who is responsible for web service management within an SOA environment, what is it they do, what skills and techniques do they need?

When I spoke to IBM recently, the answer to the first question was unequivocal. An SOA environment needs a service architect. The service architect is the primary user for web service management tools, such as the service management dashboard.

For many organizations, service architecture is a fairly new role, and the architectural responsibilities of web service management are not widely understood. Although an increasing number of individuals and teams are becoming adept in the detailed mechanics of web services, large-scale applications of SOA principles remain comparatively rare, and so not everyone has yet had the opportunity to get first-hand experience in addressing large-scale architectural issues.

The service architect plays a key mediating role (“broker”) between development and operations, and is responsible for the negotiation of a manageable set of services with defined service profiles.

A service profile is a recognised pattern of service interactions (an orchestration scenario). A service profile distribution is a statistical pattern indicating the occurrence of service profiles. (For example, this might allow the system to generate an alert if a given exception condition is executed for more than x% of cases. More generally, it supports Statistical Process Control.) Deviation from accepted service profiles or profile distributions may generate an alert, demanding someone's attention. Alternatively, the alert may be passed as a signal to the web service platform, where it triggers some autonomic response.

If you only have a handful of web services, then the architecture role seems almost unnecessary. The developers can define the profiles, and pass them directly to the operator for monitoring and management. But if you have a large quantity of web services, composed in multiple and complex ways, then managing the complex interrelationships between services at different levels is beyond the scope of either the developer or the operator, and a separate service architecture role becomes inescapable.

A key job for the service architect is to create a service geometry - to organize the services into a composition hierarchy, identifying and stratifying meaningful and manageable clusters of composite services. Profiles can be defined and monitored at each level of the service composition hierarchy, with the architect responsible (sometimes) for dividing up the work of other people into coherent chunks, and responsible (always) for understanding how the chunks interoperate.

But this isn't something you can do on a white board. It calls for geometrical reasoning, of a kind that many IT architects will not have faced before.

The kind of problem faced by the service architect today is similar to the kind of problem faced ten years ago by the network architect. While the network architect was dealing with the topologies and performance characteristics of physical hardware and communication links, the service architect must deal with the topologies and performance characteristics of abstract services and B2B links. There are some techniques and experiences that can be transferred across from one domain to the other, but the job of the service architect is a new one, calling for new ways of coping with the challenge of complexity.

Our next task is to spell out the service management process, and to provide guidance to the service architect. Watch this space.