Service-Oriented Architecture

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:

• A lack of trust in service offerings, causing consumers not to reuse services because of unpredictable quality and performance issues;
• A disruption in processes by publishing services that don't fully conform to service-level requirements or by failing to assess the impact of change;
• Escalations in support costs through an onslaught of help desk and field service calls due to service issues and outages;
• A lack of interoperability, creating silos of business services and perpetuating the same challenges of a traditional, tightly coupled architecture;
• Non-compliance with regulations by failing to associate key policies with services;
• Security breaches by allowing arbitrary access to data and services; and
• An overall SOA failure by letting chaos reign and perpetuating a "garbage in, garbage out" environment.

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:

• An ESB to integrate applications;
• A BPEL-based service orchestration engine to tie services into business processes;
• A business rules engine to capture and automate business policies; and
• A business activity monitoring solution to optimize services.

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:

• Lifecycle management;
• Policy management;
• Contract management; and
• SOA metadata management.

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.