SOA Governance Terminology and Positioning

Original publication date: Nov 01, 2007

I have been wrestling with this for a while but I think I have finally found an elegant solution to the SOA Governance terminology and positioning conundrum.

First, this is a short recap of the problem: we have approached solving the problem of SOA governance very methodically and developed a model that identified a number of well-defined entities that exist in the problem domain. Since most of the SOA terminology was coined by the analysts and other industry pundits, it is very imprecise and often downright ambiguous. As a result we decided to introduce our own terminology that has not been marred by multiple contradictory connotations in the context of SOA governance. That worked fine and allowed us to develop and successfully communicate the solution to technically apt listeners, however as soon as we widened the audience, those same analysts and pundits started picking on us for lack of support for the things like policies and service contracts broadly accepted as must-haves for any SOA governance solution. Ironically, when we did an about-face and renamed key artifacts of our solution to match the closest industry-standard monikers, we opened ourselves to criticism that our policies and contracts differ from those talked about in the analysts’ reports and vendor’s white papers.

I always felt that the solution should be to keep the buzzword-compliant nouns and prepend them with a distinguishing qualifier: akin turning democracy into functioning democracy. And in one late night revelation I found that qualifier: Governance. Now everything falls into place:

• Policies in general are mutable business-related aspects of service behavior, which developer has to externalize in order to allow analysts and other non-technical players to define and change them without changing the service implementation. Examples of policies include:
1. Service should authenticate users and should not accept UnerNameToken with unencrypted password or self-issued certificates.
2. Service should be available 99.9% of time during business hours and should be able to sustain 10 TPS during this time.
3. Service should accept requests for the previous, but not any of the earlier versions.
4. Service Leases should be tamper proof and should not exceed 30 calendar days.
5. Purchase order in excess of $50,000 should be routed to a VP for an approval.
6. In the absence of available rooms, reservation for a platinum level guest should bump an existing reservation of a lower level guest.
7. Orders from a client with more than 5 outstanding invoices should be routed through the collections department.

Policies in general are inherently application-specific and should be interpreted by the application itself. Thus they can be expressed in standardized format that lacks semantics and strong validation capabilities, such as described in WS-Policy. Generic policies (examples 5 through 7 above) are best represented as business rules and workflows and their enforcement (implementation) should be delegated to a Business Rule Engine and/or Workflow Solution as a part of the regular application architecture. There is usually little need to advertise these policies as a part of service contract, since the consumers will unlikely be able to understand and interpret them the same way as the service producer.

• Governance Policies (examples 1 through 4 above) represent common non-functional characteristics of SOA services, which should be declared, validated, interpreted and enforced in a centralized and uniform way outside of and independently from service implementations. Thus Governance Policies have to be expressed in a strongly typed semantically bound format ideally described by a Governance Information Model and need to be coupled with executable Enforcement Agents (aspect methods).
• Service Contract is an amorphous conglomeration of interface descriptions, invocation conventions (such as required SOAP headers), bindings and ports (WSDL), adorned with generic policies and other assorted metadata which has to be parsed and interpreted by service clients and implementers.
• Governance Contract is a complete set of non-functional characteristics of an enterprise service expressed in the form of Governance Policies, which is unambiguously interpreted and enforced by the Governance Solution. Governance Contract represents a business-centric view of a service and combined with a developer-centric Interface Description defines a holistic Service Offering.

Unfortunately this approach will not work for governance itself: we can not call our solution Governance Governance, in order to distinguish it from the amorphous offerings of the competition – it would be too … Nabokov. But we do need a differentiator here as well, and with my innate hubris I suggested True Governance, but for some reason it was not very popular L… Closed Loop Governance is already taken – not that liked it that much or even fully understood the term: it vaguely suggests automation, but governance should be a deliberate human oversight activity. Other possibilities might include Executable Governance, Model-driven Governance and Proactive Governance.

Armed with this terminology and message we should be able to successfully position and communicate our solution to a wide spectrum of audiences including our own leadership, analysts, technologists and executives.