Hidden SOA Challenges
Architects must both enable and control the business need for interconnection.
by Paul S. Clarke

December 13, 2004

In the past, many enterprises integrated their businesses through data integration via shared data and document repositories. These efforts will certainly continue. Considerable effort has also gone into integrating software applications directly. Recently, focus is shifting to the notion of a fully integrated enterprise based on a service-oriented architecture (SOA).

The many compelling benefits of an SOA based on Web services have been discussed by various sources. However, as great as the benefits might be, there are also challenges involved in pursuing the SOA dream. Beyond the well-known performance penalty from using XML, there are numerous lesser-known challenges in using a Web services-oriented architecture (WSOA). This article focuses on several of the most significant.

Seduction of the Loosely Coupled Mantra
Loose coupling has been heralded as one of the major advantages of WSOA over other technologies such as distributed objects. In fact, WSOA truly is less coupled than distributed objects because it uses programming language-less, data-oriented interfaces. In contrast, a distributed object's interface must be compiled into source code, equally for the object's implementation and for all of its clients. Reduced coupling is a tangible benefit of WSOA.

Nonetheless, belief in the loosely coupled WSOA mantra might lead you to believe that coupling is not an issue in WSOA. On the contrary, coupling remains an issue, and the real role of coupling in WSOA has been downplayed. Coupling comes from the quantities and types of connections in a system. Here are some coupling issues in WSOA:

• Coupling occurs through the data passed among various services. The syntax and meaning of the data must be defined consistently across services; any change to the definition can affect any service that handles the data.
• Data can be modified by the services it passes through; these modifications tie the services together into a business process, effectively coupling those services through the business process and the data.
• The syntax and meaning of a service interface creates coupling because the service must be understood by the services that invoke it.
• The number of different consumers of a service affects coupling. It is harder to change the interface of a service with a large number of consumers.
• Long-distance coupling between a service's providers and consumers can negatively affect the provided quality of service (QoS).

I discuss several of these challenges in more detail later.

Hazards of the Highly Integrated Enterprise
The quest for a more integrated enterprise drives enterprise IT to be more interconnected. A more interconnected system is more difficult to understand, build, test, maintain, change, adapt, or improve. This greater coupling can dramatically increase complexity. An agile, integrated IT is more complex than independent IT processes. In contrast, segregating software functionality into independent pieces is primarily how reliable, maintainable systems are created. This is one reason why many enterprises have application silos in the first place.

WSOA assists in building highly interconnected systems because connections are easier to make. Ironically, loosely coupled WSOA enables more connections, producing an even more coupled and complex IT. Enterprise-wide coupling can easily become unmanageable if it proceeds ad hoc without an overall architectural view to guide it. As the number of services grows over time, the management and maintenance burden increases and improvements become harder to track. Repeated changes can compound the problem by producing more coupling and confusion, with consequent deterioration in reliability and flexibility.

For large-scale SOA, it is imperative to invest in an architecture process (architects, planning, reviews) to manage coupling. Somehow, architects must both enable the business need for interconnection and control the degree and nature of interconnectedness. This is one of the biggest challenges of any system architecture. There is no easy solution. Nevertheless, you can apply certain architectural techniques. I briefly summarize a few techniques here; a detailed discussion is beyond this article's scope.

Managing coupling first entails documenting it and then tracking its changes. In SOA, this involves creating a dependency map that shows the services and the users of each service, and tracks the characteristics of each communication (message, message format, message type). By showing which users or services might be affected by a change to a service, the dependency map allows architects to manage change.

One effective approach to structure a large quantity of interconnected services is to divide services into hierarchical layers, in which a service can only access services in the same layer or in lower layers. One way to approach this is to create a series of business-level layers, infrastructure services layers (e.g., security), and lower-level utility services layers. A simple example is a three-layer structure that places business process orchestration services in the top layer, specific business services in the middle layer, and infrastructure and utility services in the bottom layer. The layers help manage coupling by constraining it.

Another way to manage coupling is to use indirect communication between services, such as through a publish/subscribe communication model. Services do not interact directly. Instead, they send messages to a distributed routing mechanism that forwards them to subscribing services. Messages are classified into topics that can be structured hierarchically for flexible subscription (see Resources). Publish/subscribe is an indirect data flow model that must be managed by architects to coordinate service interdependencies via common data. As the SOA grows and evolves so will the complexity of data dependencies unless they are carefully managed.

The Imprecise Meaning of a Service
A service represents an interface that must be understood clearly and consistently by the service's providers and consumers alike. Unclear or ambiguous meaning will likely cause some consumers to use the wrong services or to use them incorrectly.

Precise meaning in interfaces is always needed, and WSOA is no exception. Although Web services greatly improve interoperability through syntax, they do little to improve the meaning of services (with the possible exception that business-oriented services generally have clearer business meanings). It is notoriously difficult to be precise about meaning in software systems. Meaning must be specified for both the behavior of the service and the data being passed. The meaning of behavior is usually described using imprecise human-language description. Preconditions and postconditions certainly help and should be included in the interface contract whenever possible.

Beyond the immediate behavior of a service, it is also important to document the externally visible side effects of the service because they are part of its behavior. Side effects can involve the other services it invokes. Managing or eliminating side effects is an architectural challenge. Another challenge is to ensure that the development team remains cognizant of the side effects over the life of the enterprise architecture, especially with staff turnover. It is essential to document completely the external behavior of every service.

When interconnecting the entire enterprise, another challenge is to establish strict common definitions for the meaning and precedence of data items like customer or account across all services (see the Delta case study in Resources). Legacy applications, when wrapped as services, can still use their own internal definitions, but they must translate to the common syntax and meaning when providing or accessing services. To handle conflicting data, there should also be prior agreement on which data takes precedence. A big part of this challenge is to obtain agreement from all interested parties across the enterprise that the definitions and priorities meet their needs.

Scoping a Service
Several issues relate to the challenge of scoping a service:

• Most services should have a business meaning, not a software meaning. Some utility services, used internally by other services, might have a software-oriented meaning. These utility services should be clearly separated from business-oriented services.
• As for any software function accessed remotely across a network, services should be coarse-grained. In contrast, fine-grained services are usually too costly in network loading and response times.
• Inevitably, there is common software shared by services internally in their implementations. The common software must be portable across the different platforms of the services it supports.
• Applications tend to be larger-grained than services. It might be necessary to restructure a monolithic application to make its functionality available as a set of services. This restructuring raises the cost of implementing the services.

Shifting From Data Orientation to Service Orientation
In the past, IT has focused on data: getting, moving, processing, manipulating, and storing data. In SOA, the role of data in the architecture must be reassessed. One SOA challenge is sharing data across the enterprise while still addressing QoS (see "Data Considerations for SOAs"). This involves the usual IT tradeoffs of increased complexity due to replicated data (or services) versus slower response time (lower QoS). SOA does not specifically address this challenge. Some typical approaches are: Share data in a common repository; encapsulate data and associated business logic within a service; and pass the data and context along to each service. The last approach's benefit is that it can be more easily tailored to match enterprise business processes (an example is the sequence of services an insurance application might pass through on its way to approval).

This challenge calls for architectural attention to enterprise data and process flows. Services are process oriented. SOA entails looking at processes and workflows and seeing how the data flows through them. Tracking data as it flows, backing it up, maintaining multiple copies of data that each might change, being able to undo changes and roll back transactions, and handling long-timeline transactions are all issues in a service-oriented, process-oriented IT. The issues are not new, but the challenge has greater scope because transaction and data management can now span the entire enterprise in potentially new ways.

A Still-Emerging WSOA Infrastructure
An infrastructure for WSOA is essential. It might appear from what you read that the WSOA infrastructure is already here, but it's not that simple. The standard Web services technologies (XML, SOAP, WSDL, and HTTP) are sufficient to look up a well-understood service in a registry and invoke it. Nevertheless, in numerous areas the standards are still in progress or not yet addressed. Examples of service infrastructure capabilities yet to be fully standardized include aspects of security, event-based messaging, service scalability and load balancing, usage policies and enforcement, service management, transactions, workflow, QoS, and service-level agreements. Without standards, the market will produce incompatible solutions from multiple vendors, and the Web services infrastructure will be less interoperable.

Service Governance
One focus of SOA is to share IT services across the enterprise. To establish a shared service, you need teamwork and consensus building across the enterprise. This challenge involves how IT operates across the enterprise, and how you can merge local control with centralized coordination. Related issues include how you manage and coordinate the architecture; how you select and define services in terms of specific interfaces, QoS, service-level agreements, policies of use, and security policies; and how you fund services for development and maintenance.

One useful approach is to create a governance hierarchy based on reusability of services. The hierarchy defines who in the enterprise has responsibility for a service's definition, architecture, development, and funding. An example hierarchy has three layers (see the BEA Systems article in Resources):

1. Utilities and infrastructure used everywhere.
2. Business services shared by more than one business unit.
3. Local business services.

Some of the local business services might someday be deemed worth sharing across business units; the governance model should include a mechanism for moving local services into the shared business layer.

It should now be apparent that many of the challenges described in this article must be addressed through a systematic architecture process. There is critical need for coordination across the enterprise to deal with enterprise-wide SOA coupling, governance, service design and management, and data management issues. Moreover, setting up and carrying out this architecture process could be considered another SOA challenge.

About the Author
Paul S. Clarke, a member of the Worldwide Institute of Software Architects, is applying his more than 15 years experience in large-scale systems and software architecture to a book he is writing on that subject. Beyond architecture, he is also an entrepreneur and consultant with a diverse technical background in software, signal processing, telecommunications, security, artificial intelligence, and other technologies.