SOA Governance - it's not just a question of services

Submitted by Ivo Totev. Business Analysts

The main objective of SOA is to bring business and IT closer together. SOA governance helps achieve this aim by organising the right processes for a company. The present debate on governance, however, seems to be centred exclusively on services. Of course we have nothing against services - after all, they in fact form the modular building blocks of any SOA set-up. The problem is, if you only bear services and their implementation in mind, you tend to lose sight of the "big picture" and the essential business overview. So why not think on a grander scale? Let's take for instance something really big - a business domain; for example: payment transactions, logistics or a call centre.

Let's focus on the latter: In a call centre, we find automated processes that are (perhaps) based on standards, such as BPMN, as well as composite applications. Individual steps within a process activate business services, which in turn based on technical services. These technical services are often geared to standards like BPEL and can be combined into larger units. In a business domain we are also dealing with various levels and technologies that are connected and interdependent.

Systems like this can only function, and function well, if there are policies. These policies define demands such as availability, security precautions and reply times. Defining policies using standards is a good idea - in this way individual departments are encouraged to define their demands according to certain patterns. We are somewhat familiar with this concept from the field of aviation in which the communication between tower and cockpit is strictly standardised. A concept like this helps to avoid misunderstandings - surely an important issue when it comes to cooperation between business and IT.

The question is - how can we ensure that policies harmonise with each other beyond the various levels and that they are adhered to? Let us assume that the business domain of a call centre requires an availability of 24/7. A CRM system involved in the undertaking is, however, only available from 6 a.m. until 10 p.m. How can such conflicts be identified and how can we make sure that the total subsidiary policies (those on the technical-service level) are in line with main policies on the top level, the business domain?

This example makes it clear that there is much more to a SOA than just services. Processes and policies are equally vital elements. Effective SOA governance has to embrace efficient life-cycle mechanisms for services, policies and processes, so that the plans of a particular business domain can be integrated into an SOA. Only then will business and IT really move closer.