NEWS AT SEI
This article was originally published in News at SEI on: June 1, 2006
A service-oriented architecture (SOA) is an architecture built around a collection of services with well-defined interfaces. A service is a coarse-grained, discoverable, and self-contained software entity that interacts with applications and other services through a loosely coupled, synchronous or asynchronous, message-based communication model. A system or application is designed and implemented using functionality from these services as part of its mission. SOA connotes a style or approach for developing a system. Thus SOA is not an alias for system, but rather describes a particular way in which systems might be constructed.
SOA systems have become more common because of the capability of accessing capabilities that are distributed across the Internet, and growing acceptance of approaches and technologies that support this system environment.
An example of a system built around an SOA is the Global Combat Support System–Air Force (GCSS-AF). The purpose of GCSS-AF is to provide timely, accurate, and trusted agile combat support (ACS) information to ACS personnel at all ranks to execute the Air Force mission throughout the spectrum of military operations. GCSS-AF includes an enterprise infrastructure for AF operations support with a common set of services, common software and hardware, a corporate data warehouse, and enterprise security.
The use of an SOA has implications for a number of aspects of traditional acquisition, development, and sustainment. This article focuses on how governance, one of those aspects, is affected. Insights for these observations have come from our experience with several SOAs, including GCSS-AF.
Range of SOA Systems
There is a wide spectrum of possible ways for systems to incorporate the principles of SOAs. One extreme of that spectrum would be a collection of services and applications—all running over a single, large infrastructure; existing unambiguously under a single authority; following consistent business rules; and executing defined processes known to all. In such a case, the boundary of ownership would be clear and encompassing. At the other extreme, we could imagine a collection of diverse, heterogeneous services, used in ad hoc fashion by a set of diverse applications, facilitated by various infrastructure capabilities, and governed by business rules known only to the applications themselves. The boundaries of ownership there would likely be at best complex and at worst highly ambiguous. The one extreme is one of absolute authority; the other is one of near-anarchy. The reality of large systems based on an SOA approach lies somewhere in the middle.
Given this reality, it is important to consider how services and applications relate to the boundaries of ownership domains. GCSS-AF is certainly an SOA that is entirely within the domain of the U.S. Air Force as a whole. But multiple participating organizations, separate divisions of the AF, and separate domains of interest (e.g., logistics, human resources, and finance) mean that for GCSS-AF, there are indeed different owners and diverse system boundaries.
Role of Governance
The word governance describes many facets of management and policy for SOA-based systems. Depending on context, governance can refer to
- overseeing and enforcing policy (business design, technical design, application security) that directs the organization
- creating policy that directs the organization
- coordinating the people, policies, and processes that provide the framework for management decision-making
- taking action to optimize outcomes related to an individual’s responsibility
- promoting efficiency in the organization
- determining the integrity of services
Good governance exemplifies such characteristics as accountability, freedom of association and participation, a sound judicial system, freedom of information and expression, capacity building, and similar things.
The concept of governance is not entirely new. What is new is that development and acquisition, are, in an SOA context, very different, and management and policy apply to more than simply construction. However, like most aspects of management, traditional or otherwise, governance will be reflected in one or more processes.
Characteristics of Good SOA Governance
In the context of SOA, governance should encourage active and efficient use of available services by application builders. While a number of characteristics of governance apply within the SOA context, we will focus in this column on just the following:
- a flexible authority structure
- management incentives
- full operational life cycle
We describe these characteristics in terms of traditional system life-cycle development and discuss some of the differences that arise with SOAs. We then consider how the changed context of SOA affects the concept of governance, with examples drawn from the GCSS-AF experience as well as other examples.
A Flexible Authority Structure
In traditional systems development, the authority for a software system strongly resides in the development process. Ownership is primarily centered on the agency that acquires and develops a system, and most concepts of software management are related to the traditional aspects of the software life cycle (e.g., requirements, design, testing, and maintenance).
By contrast, SOAs demand governance across all of the communities involved—operation, development, and acquisition. Ownership cannot rest solely in the development phase. Lines of authority are at once far broader and less well-defined, especially for large systems for which ownership is shared across multiple domains. Thus the context of SOAs involves multiple, overlapping networks of nodes–service providers, service consumers, and nodes that both provide and consume services. Because many service providers will participate in multiple systems and multiple processes simultaneously, the boundary lines of a system become blurred. Any successful SOA governance process will, by definition, be governance of only some part of the whole. Such a governance process will embrace rather than contest the notion of flexible authority and control.
Correspondingly, an SOA governance policy must be defined based on the realization that influence will be as valuable as control. The policy will necessarily take a distributed and cooperative view. Governance will depend on varying spheres of influence. Governance of a given sub-network of nodes (e.g., a particular system or SOA) may be well-defined, but in the aggregate, governance of the whole cannot be well-defined.
A number of incentives are related to traditional software development; the primary focus of the interested parties is on the system being developed. Thus, the contractor bids on and receives a contract to build the system. The acquirer lets that contract and is rewarded when the system is successfully built and deployed. This paradigm is equally true for the vendor who builds and sells commercial off-the-shelf (COTS) products. The product for sale is the system, regardless of any internal complexity, number of modules, and so forth; the incentive is to sell the system for a profit. In all of these cases, the primary focus is on the system, and the incentives flow from that focus.
The operational concepts required by an SOA demand that we rethink incentives for individuals and organizations. First, the system is far more diffuse; it may be difficult to establish where the boundaries of the system actually are. The contractor may be creating a system made up of a collection of applications that may depend on external services over which the contractor has ceded authority, design, performance characteristics, and evolution. In place of the familiar incentives of contractual obligations, the contractor now deals with service providers who offer service-level agreements (SLAs), which seldom are specified as requirements once were.
In addition, service providers, especially of Web services, have a changed concept of profit, because their services exist in a far more volatile marketplace than a COTS vendor’s products. While service providers want to keep providing the service, they also have an incentive to attract more customers by constantly adding improvements. Yet, they gain little knowledge of how customers use the services; they may know only that customers pay a fee. As a result, they do not know whether their improvements will benefit existing clients.
There is also a different concept of success for acquirers. With SOAs, system deployment is likely to occur iteratively, and fielding a system is now fielding a collection of capabilities. The time frame for such ongoing deployment will likely span several years, making it difficult to clearly define when a program comes to an end and what its level of success has been.
In such an environment, governance has a vital relationship to managing incentives. An obvious incentive for an enterprise to use the services in an SOA environment is the promise of reduced development costs or delays. In other words, why should the enterprise underwrite the expense of creating some functionality when it is available at a lower cost through such mechanisms as SLAs?
Incentives are also needed across industry boundaries. For instance, the government may desire that company A make use of various services in creating an application for a government contract. But if using many of those services provides a favorable revenue stream for company B (a competitor with company A), there is a strong disincentive for A to use those services.
In addition, there is a tension between local and global optimization; this is an instance where SOA differs from other system-of-system contexts. For example, it is often the case, for some system-of-system contexts, that local optimization defeats the global goals and that to optimize for the global means accepting suboptimal behavior at the local level. In such cases, it is conceivable that an owner might act for the greater good and accept suboptimal behavior in its system.
However, in an SOA context, service providers usually cannot optimize for global goals: they cannot know who is using the service, and any optimization that favors one user might be detrimental for others. Thus, governance for an SOA can consider incentives only at the global level, where the application developer operates.
Full Operational Life Cycle
As with many other aspects, governance of software systems has generally focused on system development, and sometimes on deployment. Once a system has been deployed, most of the familiar management controls (especially those related to government acquisition) are at best replaced by another set of management policies or at worst simply removed. In traditional systems development, management control tends to be vested in a single person or agency. Thus, for a given system, there is a single acquisition authority during development and deployment, and after deployment, there is typically a single person or agency that owns the operation of the system.
In the context of SOA, the notion of a system becomes distributed widely among infrastructure providers, service providers, and application developers. Governance, too, becomes distributed, with shared responsibilities among several different agencies. As a result,
- The governance process will not be focused purely on the integration of services; it will cover things such as changes to a service beneath the interface, changes to the interface itself, and retirement of a service.
- The governance process will probably not describe how to migrate legacy applications to a service basis.
- The governance process will focus more on service providers regardless of whether they are providing infrastructure services or application-level services.
There is an important distinction for an SOA between governance of design-time issues and governance of runtime issues. In addition, there are also distinctions throughout the various parts of the overall life cycle in how governance is divided among the infrastructure provider, the service provider, and the application developer.
Thus, at design time, a governance process must constrain the construction of services, at least to enforce infrastructure requirements (whether they are stringent or flexible). In addition, a governance process will consider how services are registered and discovered. The parties affected by governance at design time are the infrastructure provider and the various service providers. At least some of the constraints will originate with the infrastructure provider, though the more likely condition is that constraints will be the result of negotiated agreements between infrastructure and service providers. Another set of negotiations, probably with still weaker binding force, will occur between different infrastructure providers, toward the goal of making services available on different infrastructures and through different registries.
However, at runtime, governance would deal with the definition of how a service behaves when called, how various policies (e.g., security) are enforced, how behavior is validated, and how services are replaced and retired.
SOAs have implications for a number of aspects of the traditional software acquisition, development, and sustainment cycle. As we gain additional experience with the use of SOAs, we will continue to refine these preliminary ideas on governance.
About the Authors
Dennis Smith is the lead for the SEI Integration of Software Intensive Systems (ISIS) Initiative. This initiative focuses on addressing issues of interoperability and integration in large-scale systems and systems of systems. Earlier, he was the technical lead in the effort for migrating legacy systems to product lines. In this role he developed the method Options Analysis for Reengineering (OARS) to support reuse decision-making. Smith has also been the project leader for the CASE environments project. This project examined the underlying issues of CASE integration, process support for environments and the adoption of technology. Smith has published a wide variety of articles and technical reports, and has given talks and keynotes at a number of conferences and workshops. He has an MA and PhD from Princeton University and a BA from Columbia University.
Pat Place is a senior member of the technical staff in the Integration of Software Intensive Systems (ISIS) initiative at the Software Engineering Institute (SEI). Recently he has been working on the theory and practice of interoperability in systems of systems. Prior work at the SEI has included the development of CURE and investigations into COTS-based development processes, communications in distributed real-time systems, architectures for flight simulators, and system specification using formal techniques. He also holds a position as adjunct professor at Carnegie Mellon University and teaches in the Carnegie Mellon Master of Software Engineering program. Before joining the SEI, he worked at various companies either creating software development tools or formal specifications, sometimes both.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.