A growing number of organizations are adopting a service-oriented architecture (SOA) approach to their IT infrastructure because they want to enhance their ability to change the enterprise application landscape cost effectively and rapidly, in support of changing business requirements. An SOA offers many potential benefits, but capturing the true value of an SOA is virtually impossible without the ability to manage the change inherent in Web service networks.
The Nature of an Enterprise Service Network: Big, Dynamic and Rife with Interdependencies
The result of an SOA approach is a rapidly expanding network of enterprise Web services. SOA breaks monolithic applications into a greater number of smaller, more focused application modules that are easily understood, modified, and linked to form and reform applications as the needs of the business change.
By nature, this network of Web services is highly dynamic. Since facilitating change is easier, change occurs more frequently. The applications of acquired companies are integrated more rapidly. Customers, suppliers, and partners are connected faster.
Moreover, enterprise service networks are characterized by complex interdependencies. In the past, monolithic applications had very clear boundaries. In a service network, "applications" have fluid boundaries - they overlap and they are often assembled by leveraging components and services provided by other organizations within the enterprise, or even across enterprise boundaries. Dependencies can be direct, indirect, and circular.
The Impact of Change in an SOA
What do you get when you combine change, big networks of application components linked together in complex chains, and interdependencies that are often unclear? You get exploding costs associated with keeping the network running and meeting performance expectations.
As a service network grows, the marginal cost of change in the network grows at an accelerating pace, fueled by both expected and unexpected changes.
Planned Change to a Service in the Network
In many cases, intentional IT actions may cause unintentional impact to the service network. These intentional actions can include introducing new applications, replacing and enhancing existing applications and Web services, upgrading and maintaining systems, and more.
An example of intended change with unintended consequences:
Change: An aircraft manufacturer creates a new portal that will display real-time manufacturing process status. This portal leverages a Web service that returns the current status of a given aircraft assembly project. The Web service is changed to accept a more detailed query and to return a more detailed response.
Impact: Systems bound to the old version of the service suddenly find their message formats invalid. Some systems that relied on the old version of the service were not even known to the Web service owner, putting those systems at risk as well.
Unexpected Change to a Service in the Network
In a growing network of connected applications, service changes can occur suddenly and unexpectedly. For example:
Change: A manufacturer faces a sudden increase in market demand for a product. Traffic increases to an e-commerce site as customers place orders. More calls come into the call center where customer service representatives take product orders. Both of these systems link to a customer management Web service being provided by a CRM system.
Impact: There is an unexpected decrease in the response time of the customer management Web service.
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:
Understand the makeup of the service network
Know when there is a service network problem
Identify the root cause of the problem
Insulate downstream applications from the root failure
Predict the impact of a change
Distribute policy, rules, and behaviors into the network of Web services to alleviate or avoid unintended consequences of change
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.
Author Bio
James Phillips is chief strategist and senior vice president of product marketing and management at Actional Corporation. Actional offers a Web services management platform that is uniquely architected to help organizations manage the impact of the constant change inherent in enterprise Web service networks. Actional's patented active-management technologies provide users with a complete view of the entire enterprise Web services environment.
jamesp@actional.com
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail:
info@sys-con.com
