Unexpected Change to a Service in the Network
In a growing network of connected applications, service changes can occur suddenly and unexpectedly. For example:

This is just the beginning of a ripple effect of change throughout the service network, which will eventually impact systems that are several times removed from the initial problematic service. Specifically, any application that depends on the customer management Web service will now also begin to experience performance degradation.

Any upstream service that depends on the (now performance-degraded) customer management service may now itself display performance degradation in response time. Ripple effects continue until there are no more upstream systems acting as service providers - much like a rolling brownout effect in a power grid. The result is an overall decrease in service levels for all dependent Web services within the network.

While this series of events paints an ugly picture, what IT experiences is even uglier. There are no lines painted on the floor of the data center highlighting the interdependencies among the loosely coupled systems in a service network. There are no performance gauges and no alarm bells that sound when service performance moves outside normal bounds. There is no means of tracing failures back to the root of a service network problem.

Instead, those responsible for keeping the service network up and running face a bewildering set of seemingly coincidental system failures. These failures are expensive as orders are lost, customers turn to competitors, and valuable IT personnel are frantically troubleshooting problems.

In order to truly reap the benefits of the service-oriented approach to application architecture, organizations must have a way to manage the impact of change in their enterprise service network.

Web Services Management Platform Requirements
A Web services management platform is critical to the continued profitable growth of a service network and must address both planned and unexpected change in an enterprise service network, providing a facility to:

Figure 1 provides an architectural overview of a solution that meets the requirements highlighted above.

 

This architecture combines the power of centralized visibility and policy management with distributed monitoring and policy enforcement. In this approach, active "in-network" components reside within the enterprise service network, logically positioned between the providers and consumers of Web services. A centralized management and policy server, working in concert with service registries and identity management solutions, communicates with these in-network components, both receiving and sending information. Information received from in-network components includes service performance statistics, alerts, and service interdependency information. Policy, in the form of rule sets, is sent to the in-network components to define in-network component behavior - when to raise alerts, how to process transiting message traffic, where to route messages, how to enforce security policy.

Successive deployment of in-network capabilities for each new Web service project results in a fabric of control woven into the enterprise service network. The central policy and management server taps into this in-network fabric of control (see Figure 2).

 

This solution provides a complete answer to the challenges faced in dealing with change in an enterprise service network - both unexpected and planned.

Those enterprises that deploy a Web services management platform in support of their adoption of a service-oriented enterprise software architecture will get what they expect - movement toward operation as a real-time enterprise and an IT organization able to rapidly respond to, and even enable, changes in the operation of the business.