Being a master of all these domains ensures that you have the capabilities and assets in place to effectively adopt and operate SOA. Conversely, understanding deficits in an organization’s domain model offers a good indication of where to devote resources that will drive successful SOA transformations.

The domain model was the basis for constructing a detailed online questionnaire designed to assess a respondent’s overall readiness for SOA in each of the eight areas. The high-level assessment identified the capabilities and assets that have to be developed or acquired, and the actions that need to be taken. The assessment tool can suggest where an organizations needs to concentrate efforts to start their SOA transformation, or point to deficits in an existing SOA strategy. The assessment tool acknowledges that SOA doesn’t happen overnight: SOA adoption is and should be incremental, and ideally should provide measurable and cumulative benefits at each stage of adoption.

The Governance Imperative
In the first six months after the online assessment tool was made available it attracted over 200 responses from different companies worldwide. Respondents varied widely in size, SOA maturity, and business. About 40% were based in North America, 25% in Europe, 20% in Asia/Japan, and 15% South America, Africa, or the Middle East. No industry sector accounted for more that 10% of respondents.

Despite the wide variety of respondents, one issue became clear: Governance is the single, most consistent area that needs to be significantly enhanced in most organizations. It was also cited by companies that have mature SOA implementations as the area that provided a foundation for SOA success, and the domain that had surprised them by being so fundamental and so underrepresented in their organization.

As mentioned earlier, SOA governance is typically much more important than governance in traditional IT environments because when organizations adopt SOA they are typically moving away from an architecture consisting of a relatively small number of large, static, and well-bounded applications and systems into an environment of myriad smaller, easily accessible business services. The very benefits of SOA, such as service reuse and enhanced business flexibility, means that the relationships between these smaller business services and their impact on the business are more complicated to grasp and control. Done wrong, SOA can quickly become chaotic.

SOA introduces many independent and self-contained moving parts — components that are widely reused across the enterprise and are a vital part of mission-critical business processes. What happens when a service is changed? How can you be sure the service you’re consuming 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 ensure a service’s predictable uptime? These questions illustrate the need for SOA governance. It’s about managing the quality, consistency, predictability, change, and interdependencies of services. It’s about blending the flexibility of service orientation with the control of traditional IT architectures.

A significant challenge to widespread SOA adoption is that while the management of service quality is paramount, information about the quality must also be effectively communicated and measured. For the first time, quality must be proven and demonstrable to consumers to gain their trust and create an effective shared-service environment.

A useful way to think about the importance of trust in SOA is to consider the example of a consumer marketplace such as eBay, where anonymous buyers and sellers are expected to come together and quickly establish some degree of trust, despite their total anonymity. According to basic economics, a market requires information to function efficiently. Information is the lifeblood of any market, largely because it enables buyers and sellers to make informed decisions, and provides the basis for establishing trust. Buyers and sellers on eBay trade on the basis of information. Buyers won’t 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 some assurance of the buyer’s ability and willingness to pay in a timely fashion. In this respect, SOA is no different. SOA can’t be successful without trust – consumers will simply fail to reuse services if they can’t be assured of the quality, predictability, and transparency of the terms and conditions. In the same fashion, organizations shouldn’t encourage the use of services without understanding and controlling access, provisioning, and the overall fitness of reusable services.

Tightly coupled systems define governance and control in the context of the application. SOA is different in the sense that the application context is varied and ever changing. This means that governance must be managed at a different level of abstraction – on the services themselves. Policies need to be taken out of the code and externalized as metadata associated with them. Complicating matters is the fact that, in a loosely coupled world, change is a constant and increasing. Loosely coupled architectures potentially involve hundreds of services that evolve and change based on their own unique lifecycles. With all of this change happening at once, how can an IT organization identify and manage the potential impact and interdependencies of change? This is a key domain of SOA governance.

The challenge facing enterprise architects tasked with developing SOA governance processes is creating an open marketplace for services that’s regulated enough to protect the business, but not so much that over-regulation causes adoption failure. Services need to be easily accessible and demonstrably trustworthy, but how and when services are reused or changed needs to be carefully controlled.