One of the challenges in assessing and comparing products, solutions and technologies, is determining what matters and distinguishing it from incidental features and design-related artifacts. In order to do so one needs to clearly demarcate the scope of the comparison and the first step is to define the problem which the solutions are trying to address.

Let’s try to do this SOA Governance, because although, as will be shown later, such definitions are in abundance, all of the ones I have come across have some shortcomings. Some are biased to justify a product or class of products in which the author has vested interest, others are too general or academic to serve as a foundation for meaningful analysis and comparison of products and technologies in this area.

I will take the following approach to ensure that the definition in question product neutral and relevant in today’s marketplace: we will start with the opinions of the leading analysts and industry pundits, validate them against actual customer requirements and at the end compare them against the vision that my team has developed over the last 3 years.

Analyst’s View

There is a broad range of definitions for SOA Governance in the industry that are ranging from very abstract, that are hard to argue with, yet give very little for the goal above, like the following based on Miko Matsumura’s view on Governance in general and the OASIS SOA Reference Model:

On the other end of spectrum is very concrete and limiting definition from Sun’s own Mark Hapner, who sees SOA governance as:

However most of the analysts actually seem to be in accord, with definitions similar to one from Jason Bloomberg of ZapThink:

The biggest variable in these visions of SOA Governance is the meaning of the policies, which in most writings remain, perhaps deliberately, vague. For example L. Frank Kenney of Gartner defines policy, in the context of SOA, as:

He follows this definition with a set of examples which include:

• security policies, such as access and authentication;
• management policies, such as performance, monitoring and availability;
• development policies, such as development-language requirements;
• routing policies, such as content-based routing;
• transformation policies, based on document types or partner profiles;
• correct use policies, such as sequencing resources.

Client’s View

As Service Oriented Architecture (SOA) is rapidly becoming the mainstream of business computing and more companies are moving into post-pilot implementations, SOA Governance is turning from a “cool feature” into a “must-have” requirement for those projects. This is trend is clearly visible in the increasing number of RFIs and RFPs being issued by businesses that are dedicated solely or in a large part to SOA Governance requirements. This section contains overview of several such requests to which Sun SOA/BI practice has responded in the last year.

A national Bank

Date: 2007

Focus: SOA Governance

A very strong RFI focused specifically on SOA Governance and showing deep understanding of the problem domain and strong organizational focus and commitment. Key areas:

1. Design-time Governance, focusing on Governance Information Model, its richness and extensibility. This section also focuses on general Registry-Repository capabilities, including secure access, notifications. This section contains 25% of all functional requirements.
2. Operational Governance, focusing on Life-cycle Management and Analysis-time Governance, specifically service versioning, ability to support environment-aware service governance across multiple environments, ability to expose the same services with different sets of policies and classes of related services with the same sets of policies. This section contains 6% of all functional requirements.
3. Service Consumption Support, focusing on consumer APIs and interfaces, Client Proxies and support for Service Debugging and Testing. This section contains 12% of all functional requirements.
4. Service Execution, focusing on Run-time Governance, and specifically security, throttling, QoS/prioritization, request timeouts and cancellations and logging. The noteworthy requirements include: session management, support for asynchronous services and “events” or ability of the governance engine to initiate autonomous service requests based on some conditions. This section contains 25% of all functional requirements.
5. Service Monitoring & Management, focusing on service availability, performance, fault management, queuing, retries, compensation and archival. This section contains 32% of all functional requirements.

A global Consulting Company

Date: 2007

Focus: Service Delivery platform and SOA Governance (~80%)

A broad use case- centric RFI focused covering many areas from managing service proposals to service implementation, deployment and governance. SOA Governance-specific areas include:

1. Design-time Governance, focusing on Governance Information Model, service publication and discovery, management of contracts, policies and metadata. This section contains 42% of all governance use cases.
2. Run-time Governance, focusing on service versioning, security, monitoring, SLAs and arbitrary constraint enforcement. The client emphasizes the need to support any type of service implementation technologies including messaging (JMS/MQ), web (SOAP, REST, POX), J2EE (EJB, POJO), .NET (WCS) etc. This section contains 21% of all governance use cases.
3. Operational Governance, focusing on subscriber management, ability to support environment-aware service governance and governance-related activities and workflows. This section contains 32% of all governance use cases.
4. Analysis-time Governance, focusing on management and application of universal reusable contracts and policies. This section contains 5% of all governance use cases.

A national Insurer

Date: 2006

Focus: SOA Governance (~75%) with elements of ESB

This was supposed to be a governance-centric RFP but the requirements were to a large degree based on a pre-conceived vision of a solution strongly influenced by an ESB vendor. The requirements were focused on the following key areas:

1. Design-time Governance, focusing on service registry capabilities, specifically: service publication, validation, development and run-time discovery, version and change management, access control of contracts, management, extensibility and access to metadata. This section contains 31% of all governance use cases.
2. Run-time Governance, focusing on dynamic contract assembly and provisioning, security, SLA monitoring, and chargebacks. The client emphasizes the need to support delegated governance. Having been influenced by ESB approach, the client required dynamic content-, contract-, and context-based routing to be a part of the Governance Solution. This section contains 52% of all governance use cases.
3. Operational Governance, focusing on root cause analysis, ability to support environment-aware service governance and governance-related activities and workflows. It also includes testing and simulation support. This section contains 17% of all governance use cases.

A global Pharmaceutical Manufacturer

Date: 2006

Focus: SOA Governance

A broad governance-centric RFP but, similarly to the previous case the requirements were to a large degree based on a pre-conceived vision of a solution strongly influenced by an ESB vendor. The requirements were focused on the following key areas:

1. Design-time Governance, focusing on service registry capabilities, specifically: information security, taxonomies, standard compliance, validation and transformations, notifications and workflows. This section contains 57% of all governance use cases.
2. Run-time Governance, focusing on security, reliable messaging, WS-Addressing, SLA and monitoring, management and failover. The client emphasizes the need to support multiple types of service implementation technologies including: messaging (JMS and SMTP), web (SOAP, REST, POX over HTTP(s)), J2EE (RMI, IIOP) etc. The client emphasizes the need to support delegated governance and provides a long list of legacy governance solutions they would need to integrate with. This section contains 43% of all governance use cases.

A global Communications company

Date: 2007

Focus: SOA Governance

This client did not issue any RFI or RFP, but was the first actual client for our SOA Governance solution. Instead of RFP, we have analyzed the actual technical and business requirements and client feedback on the execution. The requirements were focused on the following key areas:

1. Design-time Governance, focusing on service versioning and ability to register and services and generate client-side WSDLs at the earliest stages in development environment. This section contains 20% of all requirements.
2. Run-time Governance, focusing on monitoring, throttling and fault analysis. The client emphasizes the need to support delegated governance (required integration with Sun’s in-house Common Services Framework). This section contains 40% of all requirements.
3. Operational Governance, focusing on ability to support environment-aware service governance, federation across multiple development, testing, integration and production environments, and support for Service- and SDLC-related activities and workflows. This section contains 40% of all requirements.

Vendor view

To complete the picture this section contains definitions of and views on SOA Governance that are coming from the solution vendors:

Oracle defines SOA governance as:

One of the follow Sun bloggers Sasikanth Tenneti recently come up with:

And our partners Layer 7 has recently published a whitepaper on SOA Governance that amongst other things attempts to define the problem domain. It does not contain a single unified view of Governance but provides the following “partial” definitions:

They see Design-time SOA governance primarily as control over service WSDLs and other related artifacts, but also include virtualization functions and SLA based routing. The paper views policy description, control and lifecycle management as well as the entire service contract as run- rather then design-time issues.

In lieu of a verbal definition of SOA Governance, to following diagram illustrates Layer 7’s overall vision of what it is:

This post turned out to be so long that I will have to leave our own point of view to a separate one.