SOA Policy Police

SOA Policy Police

Last week, IBM announced their service oriented architecture SOA Governance portfolio of software and professional services designed to help organizations ensure they are achieving their goals and objectives for service oriented architecture SOA adoption.

On one hand service oriented architecture SOA governance can be considered just part of IT governance. Ensuring that business requirements are met, delivering ROI, and meeting SLA is the same for service oriented architecture SOA as any other IT activity. Organizations should not be worrying about putting service oriented architecture SOA governance in place if they don’t already have effective IT governance processes.

SOA service oriented architecture does bring new challenges though. The multi track delivery model requires SLA and contracts are established between providing and consuming organizations, not just between IT and the business. Whilst the federated model requires governance that crosses organizational boundaries. One example of this is that governance is required to ensure that black box services behave exactly as required and deliver their SLA. Another, is that it requires policies to be described as precisely as the Service Specifications themselves so that they too can be shared between participants, so that activities can be governed in the same way regardless of who the participant is.

SOA service oriented architecture also delivers opportunities. Most organizations for example have expectations of shared and standardized Services improving the consistency of business processes and information, and maximising ROI. But this does not happen by accident. It is a consequence of governance ensuring that the appropriate policies are in place and enforced to deliver those shared Services where they are required. For example, what is the RAEW for a Shared Service?

It is no surprise therefore that as the service oriented architecture SOA maturity of organizations gradually rises, then so does the requirement for SOA governance. Organizations now report having legacy Web Services in place. Service Oriented Anarchy is not going to endear service oriented architecture SOA to the business.

Part of the IBM portfolio is the SOA Governance Lifecycle. This is fairly generic lifecycle that might apply to any process or asset, but it is apparent IBM has good insight as to the sort of activities specific to SOA service oriented architecture that should take place within it.

Another part of the portfolio is the IBM WebSphere Service Registry and Repository. Or will be, as this is not available to 2H 2006. IBM intend for this to be Business Services Registry that goes beyond UDDI to provide support for the Service Lifecycle and governance of it.

However, from the information made available so far, the registry seems to have a fairly limited view of the Service Lifecycle in comparison say to CBDI Forum’s own Service Lifecycle. The IBM Service lifecycle appears to be centred around the publish/discover and operational aspects. The Service Lifecycle enables policies and governance activity to be related to specific lifecycle states. For example

CBDI Service Lifecycle State
Key Policies

Planned
Architecture; Standardization

Specified
Design; Specification Standards

Being Provisioned
Sourcing

Provisioned
Design; Quality

Certified
Security; Standards

Published
Publishing; Commercial

Operational
Security; Usage; SLA

Retired
Consumer Notification

Archive
Deletion and Retention

One current challenge for service oriented architecture SOA Governance is there doesn’t seem to be many policy languages around that provide for precise specification of policies. Particularly those that would enable them to be machine automatable. The lack of automation is not too dissimilar to other IT and non-IT governance activities in many organizations of course. Some policies will not easily lend themselves to automation.

Consequently the governance process largely consists of recording governance activity. That is, a governance system records who performed the compliance check, but cannot perform the check itself. The organization has to trust the assessment of the compliance tester.

Whilst some might imagine a dedicated service oriented architecture SOA Governance System, this may become a key role of the Service Registry. That is it becomes the “system of record” for Services, not just a place where they can be discovered.

The key challenge however is that organizations need to strike a balance with service oriented architecture SOA governance. Governance and policies must be flexible. If many policies must be checked by hand they should not over burden the organization with bureaucracy. Organizations must be sure therefore as to when to enforce, and when to allow optionality.

Few developers are going to welcome the service oriented architecture SOA Policy Police knocking on their cubical!