Close Window

Print Story

SOA Web Services Cover Story: "SOA Governance - Gaining Flexibility and Retaining Control"

SOA offers significant advantages, but it puts additional demands on visibility, control, and overall governance. Although enterprise SOA initiatives are typically deployed incrementally, to gain long-term value and ensure quality and consistency, you must address governance issues early in the implementation process.

The goal of this article is to help you understand the role of, and the requirements for, SOA governance. After reading this, you'll be better prepared to ask the right questions and define and implement an SOA governance strategy.

What Is SOA Governance?
In any discussion of SOA, the term "SOA governance" will invariably come up. Ask what it means and you'll most likely get several different answers. The definition of governance and the requirements it dictates, like SOA itself, is an evolving concept.

In essence, SOA governance may be viewed as management architecture: a framework that blends the flexibility of SOA with the control and predictability of a traditional IT architecture.

Why SOA Governance Matters
SOA creates an inherently dynamic and heterogeneous environment. It introduces many independent and self-contained moving parts - components that are typically widely reused across the enterprise and are a vital part of mission-critical business processes. Governance is no longer optional - it's imperative. SOA has the potential to introduce risk and, without proper governance, can disrupt business processes and create significant inefficiencies.

How can you manage changes to business services to lessen the impact on consumers? How can the consumer be sure the service is of high quality? What happens if a subcomponent of a composite service is retired? How can you be sure a new service is compliant with IT, business, and regulatory policies? How can you insure predictable uptime of a service?

These are the kinds of questions that SOA should raise in an organization. SOA brings new challenges with respect to assurances for service quality, consistency, performance, and predictability. But the greatest challenge facing SOA is engendering trust between consumers and service providers.

The Fundamental Importance of Trust in an SOA
Trust has become a visible issue for SOA. But what exactly do we mean by "trust"? And why is it so important?

A working SOA functions like a marketplace. And trust is a key ingredient in a functioning market.

Consider an online consumer marketplace where anonymous buyers and sellers are expected to come together and conduct business despite their total anonymity. Buyers aren't willing to do business unless they understand what's being offered, the terms and conditions of the sale, and the reputation of the seller; likewise, sellers want to be assured of the buyer's ability and willingness to pay in a timely fashion. An element of trust must exist for a transaction to take place.

In this respect SOA is no different. Without trust SOA can't succeed: Consumers simply won't reuse services if they can't be assured of the quality, predictability, and transparency of the terms and conditions. In the same fashion, organizations can't realistically allow services to be used without solid processes for provisioning and controlling access, as well as for understanding the overall fitness of reusable services.

A significant challenge to widespread SOA adoption is that, while managing service quality is paramount, simply having quality service isn't enough. Quality is a key component in establishing consumer trust; it must be proven and demonstrated to consumers to gain their trust and create an effective shared-service environment.

Governance Is a First-Order Issue
An organization would be ill advised to start looking at governance down the road once the SOA implementation has reached a certain level of maturity. In the unique context of SOA, governance doesn't follow success; it's a prerequisite for success. It would be a mistake to discount governance as something that's optional, nice to have, or a later-phase consideration.

To be successful, you must consider an SOA governance strategy when you initially deploy an SOA. Your goal should be to establish a framework for assuring service quality and engendering trust between service providers and consumers as services progress through their lifecycles. Without governance strategies or infrastructure in place, organizations will hit roadblocks as they try to advance their SOA initiatives.

The Consequences of an Ungoverned SOA
As previously mentioned, an ungoverned SOA can become a liability for the enterprise, reversing the positive cycle, and adding costs and disrupting processes. In fact, the Gartner Group estimates that a lack of working governance mechanisms in mid- to large-size (greater than 50 services) SOA projects is the most common reason for project failure.

As with any management initiative, a key goal is to minimize risk - in this case, by defining an SOA strategy that builds governance into its core.

Potential consequences of an ungoverned SOA include:

The likelihood of these issues manifesting in an ungoverned SOA increases exponentially as the number of service offerings grows.

Key Components of SOA and the Role of Governance
To understand the increasing importance of governance in an SOA, let's look briefly at the road to SOA.

Initially, there were silos of monolithic applications. While silos offer the benefit of tightly controlled, application-specific functionality, a business doesn't operate in a silo. For example, customer information is often spread across multiple applications, and producing a single view of a customer's purchase, payment, and service history can be difficult. It involves creating fragile proprietary links between systems that don't handle change easily.

This was not sustainable so enterprises introduced an integration layer. Message Queue (MQ) and subsequently Enterprise Application Integration (EAI) reduced initial integration costs with adapters, but due to the tightly coupled nature of these applications, maintenance costs were enormous. Enterprises then implemented Enterprise Service Buses (ESBs) and Web Services to help address the problem. Web Services are standards-based and loosely coupled. ESBs also leverage standards and offer some loose coupling.

But the level of granularity with these technologies was too low, which led to misalignment with the business. This, in turn, led to business services.

Business services are expressly designed to align with the business needs. They may be Web Services or non-Web Services deriving from legacy systems. An example of a transformation to business services might be turning 2,000 fine-grained API-level services into a reusable set of 200 coarse-grained business services. With the advent of business services, enterprises could orchestrate these services into composite applications and implement Business Process Management and workflow.

While this new set of technologies solved the original problems of proprietary, tightly coupled, fine-grained systems, it introduced a new challenge for the enterprise: a lack of control over change. Since services were now decoupled from applications and technology, changes in these services could have a severe impact on the consumer of these services. Hence the need for governance.

The elements that help create an SOA fall into three areas: SOA infrastructure, SOA management and security, and SOA governance.

SOA infrastructure services often include components such as:

We often group SOA management and security together because they usually have overlapping functionality. That is, an SOA management and security component typically enforces policies such as authentication and authorization on services at runtime.

Finally, SOA governance usually include:

Looking at the breadth of management concerns, it's apparent that there's no one single solution for SOA governance; instead, you need a suite of integrated tools. Vendors such as Oracle and Systinet are leading the way in developing such integrated tools by introducing solutions such as the Oracle SOA Suite. For example, the Oracle Service Registry, the OEM version of the UDDI v3-compliant Systinet Registry, integrates with other components in the Oracle SOA suite to provide a platform for managing several aspects of SOA management, such as lifecycle management.

Now, let's take a deeper look at the various components of SOA governance.

Lifecycle Management
As you've gathered by now, SOA's success and viability is directly related to quality and predictability, which ultimately engenders trust. System developers or architects are unlikely to start building an application against a service unless they can guarantee that the service is fully certified for quality, predictability, interoperability, and performance.

As such, managing the SOA lifecycle is an intrinsic part of SOA governance. In general, SOA lifecycle management revolves around:

Although it's a common mistake to treat the requirements of providers and consumers similarly, their needs are quite unique. Because of the loosely coupled nature of providers and consumers in an SOA, there are actually two parallel yet distinctly different lifecycles at work in an SOA.

Service providers focus on the lifecycle of individual services as they are designed, built, and deployed. In general the provider lifecycle is centered on:

The consumer lifecycle is quite different. It involves: Proper SOA governance depends on a strategy that addresses the needs and concerns of both provider and consumer lifecycles. Such a strategy offers the structure, control, and discipline necessary to encourage good and discourage bad behaviors.

Policy Management
An SOA policy defines configurable rules and conditions that affect services during design time and at runtime. The nature of SOA - highly distributed, heterogeneous, and very dynamic - means that it's critical for SOA artifacts to be governed by such specific business, technical, and regulatory policies.

An initial step in policy definition is to turn existing service rules - which often exist as soft-copy documents - into a set of standard, reusable policy files that can be associated with services. Linking service and policy lets you automatically validate services and enforce specific policies.

Once they're defined, policies are used throughout the service lifecycle. For example, they're used to validate services at design-time, well before they're released to consumers, and they're used to enforce specific standards and behaviors at runtime.

The goal, of course, is to first ensure that quality issues and non-conformance are detected before services are put into production. Once in production, organizations should ideally implement runtime policy management capabilities for monitoring and automatically enforcing policies during service use.

The key aspects of SOA policy management include:

Contract Management
Contracts are critical for communicating and enforcing policies, as well as other requirements in a heterogeneous and distributed IT environment. Just as a business contract ensures a healthy commercial relationship, a service contract ensures a healthy provider/consumer relationship.

Contracts are typically unique to a specific provider/consumer relationship and serve as the container for both formal policies, as well as agreements that are unique to the parties.

To put this in context, consider the example of renting a car. The rental agency is the provider, the renter is the consumer, and the car is the service. The contract defines information about the provider (the rental agency) and the consumer (the renter). It also specifies the service (the car), the terms and conditions (the policies), and any other provisions or agreements that are unique to the provider and consumer (for example, pre-paying for fuel). This contract is the basis for an agreement to bind the deal. A service contract is no different in complexity or purpose.

SOA Metadata Management
Effective SOA governance is ultimately the result of combining policy, process, and metadata. Metadata, or data about data, is the set of policies and descriptions of business services that let you discover and appropriately use those services. In the context of our discussion, metadata is all the information that would be centrally published to a UDDI registry.

There are three kinds of metadata generally associated with SOA:

In the world of tightly coupled implementations, metadata is usually defined in the code of systems and applications. SOA requires this metadata to be externalized - that is, decoupled from the native system - so that these independent services can be classified and governed.

The promise of SOA is powerful and appealing. But what's apparent as organizations peel back the layers of SOA is that it radically changes traditional IT architectures. While SOA promises untold opportunities, it also introduces new challenges and risks that you must manage and mitigate.

The concept of SOA governance, while still somewhat nascent, is already a prerequisite for a successful SOA implementation. As with any sound management practice, SOA must be seen as a first-order concern with requirements that you must factor into your organization's SOA strategy at the very earliest stages of implementation because, simply put, without an effective governance strategy, SOA can lead to chaos.


© 2008 SYS-CON Media Inc.