Wonderland Of SOA Governance

Introduction - Down to the Rabbit Hole

One man, Harry W., once said "Alice does not fall down the hole. She sees the white rabbit, is intrigued, and willingly follows him down the deep rabbit hole." Yes, the secret of Wonderland is about the meaning of the words: Harry has insisted that Alice ‘willingly follow[s]’ into the Rabbit Hole while Alice has certainly “found herself falling down”. The same happens with SOA Governance – like in the Rabbit Hole, one thinks about governance but talks about management and another one does the exact opposite...

We used to think that management includes governance. This is correct understanding: Oxford and Merriam-Webster dictionaries as well as English Synonym Dictionary include 'governance' as a remote synonym to 'management'. However, the opposite is not true -governance is not management. Governance is about policies and controlling riles while management is about policy execution and controls. Management needs governance because without governance it does not know what and how to run, execute or preserve.

I am aware of at least 3 books written about SOA Governance and at least 8 articles published only in infoQ on this topic in the last two years. Nonetheless, I have found that in absolute majority of publications about SOA Governance it is directly associated with policy enforcement or with a straightforward management. To date, only OASIS SOA Reference Architecture (RA), Public Review Draft 1 recognises the effect of the 'rabbit hole' and clearly separates governance of service-oriented environment from its management.

You may ask why it is so important to separate Governance from Management. My answer is this: the separation allows us to better understand what is what, why something is needed, who has to do it and be responsible for the governance and for the delivery of results. Furthermore, this separation helps us to organise the governance control, compliance reporting and monitoring of the agility to the corporate strategic plans expressed via governing policies. Figure 1 illustrates the separation of power between Governance and Management that should be applied as in general cases as for SOA. Thus, the policies and rules may not be set by those who have to implement them later - this is the simple balance of power. In other words, Management itself must first adhere to the governing policies, and then it can enforce these policies onto the governed subjects.

Another question is why we need to govern SOA, and why we have not talked about governance of, for example, CORBA or object-oriented (OO) design? Well, the latter is not 100% correct – I remember some attempts to set up policies and best practices on the OO application development but this topic had never left the IT boarders. What is so special about service-oriented architecture that we have not dealt with before?

Figure 1.

In this article, I will elaborate on the consequences of governance and management separation and try to explain the specifics of service-orientation that have caused such high interest to the governance of service-oriented environment. Before digging into the details, I would like to let everybody know that SOA Governance is not about policing development and executions of services. On the contrary, SOA Governance is about formulating tactical and strategic business directions and goals in the terms of the best practices in a) relationship, b) architecture, c) design, d) implementation, e) testing, f) management, g) change control, h) product development-composition, I) agility to corporate business, j) agility to the market needs. All these are about creative spirit that targets crucial business goals of your company.

Surfing SOA Governance Definitions

At the time of writing this article, at least two Standards Bodies have announced their definitions of SOA Governance - OASIS and The Open Group. The latter has two definitions - one in the SOA Governance Framework standard and anther one in TOGAF 9. The OMG SOA SIG counted up to "18 SOA Governance definitions by industry analysts, members of the media and users". I think that the majority of definitions agree on SOA Governance purposes such as policies and compliance controls with objectives to minimise the risk of violating the concept of service orientation and compromising business objectives. Unfortunately, due to the mixing of Governance and Management realms, we are having such a mess in SOA Governance.

For instance, The Open Group's SOA Governance Framework  standard states: "In general, governance means establishing and enforcing how people and solutions work together to achieve organizational objectives. This focus on putting controls in place distinguishes governance from day-to-day management activities". It would be interesting to know how the authors consider governance enforcement when it is not in the "day-to-day management activities"; are they the activities for holidays?

The Open Group's TOGAF 9  says about Governance: "It is less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organization's strategic objectives". So, it seems that The Open Group has not made its mind yet - is Governance about "putting controls in place" or is it "less about overt control and strict adherence to rules"? What is the meaning of 'enforcement' in the context of "less... strict adherence to rules"?

The OASIS SOAR A defines: "The governance of SOA-based systems requires an ability for decision makers ... to set policies about participants, services, and their relationships. It requires an ability to ensure that policies are effectively described and enforced. It also requires an effective means of measuring the historical and current performances of services and participants." This statement requires the ability to ensure that the policies are enforced but does not attribute the enforcement itself to the SOA Governance.

Talking about the relationship between SOA Governance and Management, OASIS SOAR A outlines:

There is often confusion centered on the relationship between governance and management. ... governance is concerned with decision making. Management, on the other hand, is concerned with execution. Put another way, governance describes the world as leadership wants it to be; management executes activities that intend to make the leadership's desired world a reality [MP - via enforcing compliance to the governing policies]. Where governance determines who has the authority and responsibility for making decisions and the establishment of guidelines for how those decisions should be made, management is the actual process of making, implementing, and measuring the impact of those decisions.

The responsibility of SOA Governance is to establish the policies and rules under which duties and responsibilities of governed subjects (including Management) are defined. This contains "transparency in aspects where transparency is mandated, trust in the impartial and consistent application of governance, and assurance of reliable and robust behaviour throughout the SOA ecosystem" [OASIS SOAR A].

Governance is helpless without Management (unless governed people are extremely law-abiding); Management without Governance is uncontrolled and undirected. As Figure 1 shows, Governance provides for policies of different kinds and defines procedures of enforcement and controls while Management realises policies (implements and enforces policies) and provides for policy compliance monitoring means. Policies are applied to different subjects including: services, service development, people, processes and procedures. Governance is based on the local laws, industry regulations and feedback from the corporate management and governed subjects.

Position of SOA Governance in the Enterprise Architecture

I have to explain what I mean by SOA and by Enterprise Architecture before positioning SOA Governance. I understand SOA as a service-oriented architecture, which is agnostic to the technical or business implementation; I will follow the OASIS SO RM standard and OASIS SOAR A when talking about SOA. By Enterprise Architecture, I mean enterprise wide architectural organisation that crosses business-IT boundaries and includes both Enterprise Business and Enterprise Technical architectures. This organisation belongs to the cross-functional cross-departmental management rather than to IT. If your company does not have such structure while you are expecting to get the maximum return from SOA, I would recommend to create it.

SOA does not substitute Enterprise Architecture, though it may be a significant part of it. At the same time, not everything is or should be service-oriented (SO) in the organisation. SOA models real business world where a business service is the most important entity but not the only one. SOA is an architectural methodology and, as such, affects business and technology means, though it does not prescribe them. SOA expands in the Enterprise Architecture during the transition from a process-oriented organisation (typical to Value Chain model) into a service-oriented organisation (typical to Value Networks model). The parts of the organisation – products, functions, services, etc. – that have been transformed into or created under SOA, must be service-oriented end-to-end, from the user interfaces down to the data store access layers. This is the pre-condition to the successful SOA realisation.

SOA Governance does not exist in isolation, it is a part of the Enterprise Governance. While we build SOA-based solutions incrementally, addressing one business task after another (as recommended by the SOA Best Practice), SOA Governance cannot be treated in the same way, from a project to project; it simply will not work. Particularly, if we implement services via projects in a Business Unit (BU), the SOA Governance must be at the level of BU, not at the level of projects. If several BU implement SOA, the SOA Governance must be at the level of Line of Business (LOB), Department or cross-BU Programme; this will make governing policies available and equally applicable to all projects and all services.

That is, the SOA Governance must be one level above those who construct SOA and its implementation. This requirement has very simple explanation – the SOA Governance authority has to supersede the authority of governed subjects. The matter here is not only in the enforcement authority (which is the management's attribute) but also in the notion of service composition or aggregation. The SOA Governance sets the rules that regulate service compositions and related service collaborations. For example, a SOA Policy may define the maximum level of business rule complexity that may be implemented by the composition itself while the more complex rules must be externalised into dedicated 'rules engines'. Based on given explanation, we can draw a hierarchy of the SOA Governance structure as shown on the Figure 2.

Figure 2.

Special attention should be paid to correlation between the level of SOA policy authority and the policy scope. Let's assume we have four policies:

Policy 1:

'All technical business services must be deployed on the IBM WebSphere Application Server of the versions defined in the Technology Roadmap for 2009 (for example, versions 6.1 and higher). This policy is not applied to the composite services utilising dynamic service invocation'.

Policy 2:

'All technical business services that utilise dynamic service invocation must be deployed on the IBM WebSphere Business Service Fabric of the versions defined in the Technology Roadmap for 2009.'

Policy 3:

'The release testing of all technical services must be performed as an end-to-end testing including all services the tested service depends on.'

Policy 4:

'The release testing of all technical services must be performed under all technical and business execution policies that will be applied to these services in the production environment.'

Depending on the level of SOA adoption in the organisation (sometimes called SOA Maturity Model), the governing policies such as Policy 1 and Policy 2 might be applied at the level of BU, or LOB, or Enterprise level. However, if different LOB/BU of the company used different technologies for SOA implementation, aforementioned Policy 1 and Policy 2 should not be applied at the Enterprise or LOB levels because some BU might use another technical means than IBM WebSphere family of products. At the same time, Policy 3 and Policy 4 are agnostic to implementation technologies, i.e. these policies may be applied at the Enterprise level, once and for all.

SOA Governance impacts corporate architecture potentially on all levels. As we mentioned before, depending on the SOA adoption in the company, some upper levels may be temporary not affected until SOA gets to the enterprise level. However, it is highly recommended starting SOA Governance in the top-down manner, from the Enterprise Architecture down to the project design. In this case, SOA Governance may initially occupy a small portion of the Business or IT Governance but end-to-end – from the business function and its user interfaces to the business meta-models of data and data store access layer. When SOA adoption extends onto more business and technical areas, the basic SOA Governance policies, created for the first builds, may be extended incorporating specifics for newly covered business domains.

I hope I am talking about relatively comprehensive things, and I have expected similar straightforward approach from TOGAF 9 when it talked about Governance and SOA. However, I found something quite different.

TOGAF 9 has very good words about Governance:

Governance is the ability to engage the involvement and support of all parties with an interest in or responsibility to the endeavor with the objective of ensuring that the corporate interests are served and the objectives achieved.” In another place it says: “Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It includes the following: Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization...

Every statement is correct and I can sign up for it with pleasure. But what happened with SOA and Governance in the TOGAF Architecture Development Model (ADM), which "describes a method for developing an enterprise architecture, and forms the core of TOGAF"? Have they made "a curious appearance in the air" and "vanished" as the Cheshire-Cat used to do in the Rabbit Hole?

If TOGAF 9's ADM has only Implementation Governance phase, then who and how is supposed to govern the rest of the Enterprise Architecture. Where does the SOA Governance hide after all?

Figure 3.

I have taken an initiative and re-defined the ADM from SOA perspective as shown in Figure 3. I believe that Architecture Vision, Architecture Governance and enterprise level of Analysis and Opportunities supersede all other phases of the architecture development. These three functions are direct providers of the service orientation paradigm to all other architectural activities. An Architecture Governance, carrying the concept of service orientation, must be above all other architecture building functions; otherwise, they might be realised in violation of a prescribed direction.

The Architecture Vision must be in line with the Business Strategy of the organisation. This means that no business changes in the Business Architecture may appear 'from out of the blue'; they have to be considered in the Architecture Vision first. Also, after the change passed the Business, Information and Technology architectures in the ADM circle, isn't it a bit late for architectural opportunities to take place? Architectural solution must be ready by this time and only refined via Migration Planning after that.

The Architecture Vision and Analysis-and-Opportunities not necessary have to be built or changed in every ADM cycle. This allows me to position them above other phases but together with the Architecture Governance. Service orientation paradigm affects all three of them; then it may be cascaded down to other architecture development phases. You can notice that the Implementation Governance positions in the same phase G of the ADM as before, but now it is under the Architecture Governance control; this structure matches the SOA Governance hierarchy.

Governance Accountability and Ownership

Several publications have discussed the details of SOA Governance implementation from a variety of different perspectives. While these publications contain very useful information, they do not address some specifics of SOA Governance. For instance, SOA Governance has to be distributable across the ownership boundaries covering:

• resources
• people and systems interacting with each other security
• and management aspects.

Even in the contexts of a single organisation, "the reality is that different groups and departments often behave as though they had ownership boundaries between them. This reflects organizational practice; as well as reflecting the real motivations and desires of the people running those organizations"[OASIS SOAR A]. To better understand how ownership boundaries affect SOA, we need to look closer at the social structure in the social context of an enterprise.

The social context defines the meaning of all actions happening in it, including interactions between participants via services. Formalisation of the social context is the social structure. A social structure represents some of the cultural aspects that characterise the relationships between the participants. "A social structure may have any number of participants, and a given participant can be a member of multiple social structures. Thus, there is a frequent interaction among social structures, sometimes resulting in disagreements when the goals of the social structures do not align" [OASIS SOAR A].

Every social structure has a purpose and, sometimes, a goal. For example, a social structure of an enterprise that implements the business model of Value Chain facilitates the increase of business values of individual business activities. If any relationship in this social structure constitutes potential risks to the business value of given activity, this relationship tends to be shut down.

The social structure defines the rules that may be not explicitly written but the participants follow them. An attempt of setting a rule that does not fit with the 'spirit' of the social structure leads to active resistance to the rule or to its ignorance. This is why it is so important to associate a not-fitting rule with the right level of authority. If an Enterprise Architecture has established the authority to review all IT projects to verify compliance with the corporate technical policies and has the right to stop any project if it is not compliant, then the not-fitting rule can lead to a change in the social structure.

The practice shows that in the presence of the appropriate authority it is not necessary to enforce a policy. For people to follow the policy it is usually enough to know that an incompliance with the policy may have undesirable consequences. However, the practice of non-enforcement should not become the reason for revoking such authority either.

Particular social structure influences the rights an owner has over a resource or capability. This relates not to the rights only but also to the responsibilities of the owner. In other words, the ownership implies responsibilities and contains rights; the latter is used to set the policies, which, together with responsibilities, apply to the resource or capability. If the resource or capability is not owned, this requires that the rights to use the capability have to be eventually returned to the owner. For the social structure based on the Value Chain model, the effect of not having an ownership over any used resource constitutes the risk to the delivery of the business value produced using this resource. This is why the Value Chain model tends to set the governing policies tight enough to guarantee the ownership or, at least, direct control over all related resources and capabilities. For IT, this results in the creation of silos and maximally isolated applications under the single ownership.

As we know, SOA does not fit with monolithic applications or with their integration that does not change the ownership model but rather preserves it. Since the ownership is always associated with the ownership boundaries, the participants within the ownership boundaries are limited in their rights to use different resource and capabilities that belong to different ownership. This explains why organisations based on the Value Chain model usually have significant problems with SOA adoption. It is not only about reuses of services constrained by the ownership boundaries, it is about management restrictions on creation of services that might be used by other ownerships. This also results in using technologies for service implementations without considering potential consumers from other ownerships. These silos and isolation are the things that the SOA solutions struggle against.

I would like to note that the business model of Value Networks is almost free from the described problems associated with the Value Chain model. I've said 'almost' because no model can guarantee the change of the human nature and attractiveness of an ownership. However, Value Networks model sets different content for the ownership and accountability for the business owners and related management.

As I mentioned before, effective Governance assumes top-down authority, which may be viewed as a delegation of specific authority and responsibility to the lower levels to accomplish a purposeful portion of the original level's consent. For instance, there may be several BU in the LOB each of which governs its own sphere of dealings in a manner that is coherent with the BU own tasks as well as with the goals of the LOB. Another LOB may have its own portion of governing authority delegated to it by the corporate level. Together, this creates a structure of chains of governance that goes along with the corporate organisation. If an enterprise realises the Value Networks, it benefits from additional business value coming from the relationships between activities of different participants, from their collaboration. This value, as practice confirms, exceeds the summary of individual business values that would be gained in the Value Chain model in similar cases. In the contrast, if an enterprise realises the Value Chain, there is a constant risk of the conflicts between the interests of different chains of governance. The corporate executives spend the time on aligning the chains with the strategic plans, instead of improving the position of the company in the market.

That is, delegation of SOA Governance in the Value Networks model is aiming the success of collective efforts of separate units of work (if it does not, it should). This fact matches the SOA notion of service composition, which provides the most of the SOA business value. The requirement of collaborative work is implemented via delegation of SOA Governance functions to the cross-divisional and cross-functional business organisation in the enterprise first, and only then - to the separate functional units. The governing power of the cross-functional business organisation has (or has to have) an authoritative jurisdiction over the multiple governance domains and helps to avoid or resolve ownership conflicts.

Re-distribution of SOA Governance in the Value Networks model leads to the changes in the accountability and responsibility of individual business teams and their managers. The governing policies, in this case, require team’s accountability to all consumers of the business service while the team's ownership and responsibilities are narrowed to the activities that performed only by the team/service itself. According to such SOA Governance, the business team enters into multiple relationships with other business teams on the contractual basis, not on the direct subordination basis. The cross-functional business organisation utilizes SOA Governance to compose outcomes of different business teams, i.e. services, into the composite or aggregate services and, finally, into the business products.

If somebody thinks this governance magic exists only in the Rabbit Hole, they would be advised to learn how the most successful businesses govern their internal divisions. The examples of these businesses may be found among telecommunication companies, financial institutions and retail companies.

Specifics of SOA Governance

The specifics of SOA Governance are not in some special governing methods but in the governed subjects that situate throughout the enterprise, from Business to Technology. Such distribution demands particular attention to the integrity of the governing policies. For example, if somebody sets the policy for User Acceptance Tests (UAT) and does not set a policy for the test environment that must contain all supportive/engaged services, there is a risk of inconsistent UAT results, which may cost a lot in the future.

SOA Governance applies to the following list of major aspects of service-oriented environment:

• Service structure - the minimal set of elements that constitute a service with its relationships in the service interaction realm. Related policies ought to address development, integration and deployment.
• SOA infrastructure - "the plumbing that provides utility functions that enable and support the use of the service" [OASIS SOAR A]. Here we deal with deployment and run-time policies.
• Service inventory - "the requirements on a service to permit it to be accessed within the infrastructure" [OASIS SOAR A] via public interfaces, manually and/or automatically. This aspect relates to the management policies.
• Participant interaction - "the consistent expectations with which all
  participants are expected to comply " [OASIS SOAR A]. Policies about reachability and run-time behaviour work in this area.

Also, here is a list of the areas where SOA Governance is frequently omitted by mistake:

• Service design - where policies must require to define service scope and boundaries as well as identify the set of mandatory and optional elements of
  the Service Description and Service Contract
• Service development - where policies provide the definition of the service
  development process, Best Practice rules, recommended tools, specifics of the project management practice for service creation, directions for service testing and release.
• Service composition - where policies define of the rules of collaboration for the aggregate or composite services and rules for the composition
  modifications (process, procedure, ownership relationships, etc.)
• Service resource access - where policies state what internal and shared resources such as data stores and legacy systems may be used and how.
• Service life-cycle management policies including service versioning mechanism and procedures
• Service monitoring and audit
• Service stewardship roles and Service Contract negotiation procedures at all organisational levels
• Communication channel constraints including automatic and manual (UI) interfaces.

This list does not mean that other areas may not or should not be covered by SOA Governance.

While it seems that described lists regulate all aspects of the service-oriented environment and do not leave room for development creativity, it is not necessary true. SOA policies are needed to direct SOA and its implementation rather than dictate how it may be done. Also, some policies are expected to be only temporary because when the practice of efficient SOA is settled, these policies should retire.

Here is an example from my experience. Several years ago I was working for the company that had special Centres of Excellence (CoS) in IT and one Centre was responsible for SOA while another one - for the use of open source software. There was a case where the open source CoS allowed usage of Apex Web Services v.1.1. While another CoS had to issue a temporary policy restricting the use of these Web Services with the WebSphere 5.1 Web Services toolkit. Later on, the Apex v.1.1 Web Services were fully permitted for use with another version of WebSphere and related restrictive policy was removed.

The outstanding SOA Governance specific is in that it may be applied not only to the technical realisation of services but also to their business parts. This means that the word 'service' in the aforementioned lists stands for the automated service and for the semi-automated or even manual ones. Description of such services may be found in the book 'Ladder to SOE’.

SOA Governance is accountable for the definition of controls across different ownership areas as well as for the rules of interactions across ownership boundaries. This would be possible if all service interaction participants were agreed with the single governing authority. This is not the most likely scenario for multi-ownership cases and instead the Governance Bodies of all participants have to set mutual agreements and policy mapping mechanism. This is similar to the organisation of security controls across multiple independent entities - there may be a minimal centralised set of security policies-standards and the crosscutting agreements and mapping for the specialised security policies. Setting such structure requires certain Governance Processes with appropriate jurisdiction. Thus, "the major difference for SOA governance is an appreciation for the cooperative nature of the enterprise and its reliance on furthering common goals if productive participation is to continue." [OASIS SOAR A]

SOA Governance Instruments

SOA Governance is still considered as an exotic sphere of activities in Technology while in Business it is a blur plank between governance and management. When practitioners enter this area, many ask "How can we do this?" and "What technology and tools can we use?" In response, vendors offer a spectrum of tools that are supposed to answer the question of HOW 'to do governance'. There are many such tools with a marketing buzz about the magic of service recording, which has very little to do with governance. This is similar to what Alice witnessed in Wonderland during the croquet game and commented "they all quarrel so dreadfully one can't hear oneself speak—and they don't seem to have any rules in particular." Indeed, what the rules should the SOA Governance tools adhere to?

The first rule, in my opinion, is to understand what problems we have or anticipate to have when dealing with services that SOA Governance can ease or fix. This will show us what we should govern. Dave Linthicum has mentioned with this regard: "focus on SOA governance as an approach and practice, not as technology. Create a SOA governance strategy first, and make sure it's considered during each step."

The second rule says - after you know what kind of things you have to govern, you need to identify exact points in your services and service compositions where the policies should be enforced. The enforcement per se is not the Governance's responsibility. However; it is the duty of implementation management.

Rule three encourages the definition of the policy compliance criteria and mechanisms for their verification.

Rule four asks you to think first, understand why, and what you are doing because governance is a double-edged 'sword'. It can significantly help the organisation in delivering business values as well as it can hurt the organisation.

Only now is the time to deal with the governance instruments. Dave Linthicum explained: "only purchase SOA governance technology, if it's indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before." Following mentioned rules, you will be able to define the requirements to the governance tool. Proper SOA Governance starts with what you need rather than with what you have.

In reality, unfortunately, the things happen in reversed order, as it is used to be in Wonderland - we buy a tool that promises 'to do' SOA Governance but governance does not happen. It is our job to do SOA Governance with or without the particular tools. Tools can help if we know what we are doing or just confuse us if we do not.

Before, we talked about Governance Processes that comprise a set of manual and automated activities starting with policy creation and registration, and continuing with policy application, compliance verification and reporting. According to IBM's Muhammed Yaseen Muriankara, the governance realisation or framework must be automated to provide for capabilities of the Governance Processes.

He says :

Some of the minimum required automation capabilities for a startup project include:

• A centralized registry and repository to find and publish the service related
  artifacts and metadata. This is necessary to:
  • Find the right authorized service
  • Avoid duplication of effort
  • Encourage reuse
  • Identify the current state of service in the SOA life cycle
  • Provide visibility to subscribers of the services
  • Find related services and the impact of changing a service
  • Communicate changes done to the service
• The registry should ideally be SOA run time optimized so that the metadata
  stored in the registry can be used to provide enrichment via dynamic routing
  during the run time..."

Yes, centralised service registry is important but not earlier then all stakeholders agree to use it for their current and future services. For example, it is unclear why a registry is necessary to "Avoid duplication of effort"; it is the governing policy that can request that special procurement to be applied to avoid duplication. All this means that the first Governance instrument should be a Repository of Governing Policies, and only then – a Registry of Services.

Service policy meta-data is another under-water stone. To be useful, it requires all potential participants to share the same policy ontology and semantics. We talked about this already; it is not easy to reach such a sharing.

The leaders in service registry/repository tools are HP Systinet / S2, SAG Centrasite, SOA Software, TIBCO, ActiveMatrix and Oracle-BEA. Nonetheless, the service registry can be started with regular Excel spreadsheet. Where this is appropriate depends on the individual corporate situation and needs. These tools help "collection and cataloging of metadata about services" but I do not accept the vendor's claim that cataloguing tools should be used to "organize the interdependencies, they [services] have with each other, along with the documentation of SOA Policies to define how combined services should meet business requirements. " I think that those vendors have crossed the competence line here - what services need from each other and "how combined services should meet business requirements" is the prerogative of the business needs and their realisation. At the same time, cataloguing tools for Policies significantly help in keeping the SOA governing policies in one place for better observation, maintenance and management.

SOA has one very special aspect to be reflected in the SOA Governance - policies that services follow during the execution must be externalised rather than inserted into the service implementation. The consequence of this specific is in that several legacy systems, which have their execution policies embedded, unsuitable to play a role of 'service' despite any interfaces. Actually, such systems should be wrapped by real services -applications - and used only as service resources. This line of logic leads to the requirement of having policy plug-in interfaces (per policy type). SOA Governance has to take care of defining such interfaces and prescribe technical tools that can provide such policy implementation technique. The plug-in policy interfaces allow new or modified policies to be enforced on the service without service modifications.

Finally, I would like to comment on populist movement called 'Pragmatic SOA Governance’. As the name of this movement states, it is not about SOA Governance; it is about how to attach a title 'SOA Governance' to what people already do. For example, if IT developers build domain objects first and then think how these objects might be converted into business services, the ‘Pragmatic SOA Governance’ has to 'bless' this approach in spite of all potential troubles caused by the objects that across 'service' boundaries, which is one of the major sins of SOA implementation. In support of such ‘pragmatism’, Ross Mason, CTO and Co-Founder of MuleSource, said: "In today's world, it's clear that the traditional top-down philosophy for SOA is outmoded and outdated – a new paradigm is needed for today's organizations to see the real value." It is another Wonderland quiz to me because the “SOA navigation agreement”, signed by OMG, The Open Source and OASIS clearly states that SO 'philosophy' is top-down while the realisation of SOA may and should go in all directions.

Mason has questioned effectiveness of top-down SOA, including SOA Governance, deriving it from the fact that only about 20 per cent of organisations benefit from SOA. To me this sounds like pulling The Rabbit by its "ears and whiskers" to make a gentleman out of him; this number means only one simple thing that only 20 per cent of organisations got SOA and SOA Governance right.

According to Mason, pragmatic SOA Governance is needed to avoid "significant behavioral change" required from the people in order to use these SOA Governance tools. Furthermore, "introducing any kind of change has to be done in a way that respects the roles and routines of those affected. In the case of SOA governance policies, an enterprise architect's lengthy requirements document will likely be ignored by most developers. Instead, those requirements can and should be implemented as automated policies... only when the everyday IT professional sees the benefits of a new approach to development will the enterprise see value overall".

On one hand, it is a bright idea to place non-welcomed changes into automated policies; on another hand, hiding non-welcomed changes does not change people behaviour - they will always find the way to work around then if changes are not appropriately enforced. For instance, Parasoft's JTest tool for writing Java code had several hundreds of writing style policies. If the code violated the style policy the code compilation failed, i.e. the developer was not able to deliver the result. I witnessed how developers turned off these policy controls because different stages of code development required different style policies while the tool was not 'smart' enough to accommodate the real development process.

The problem for "the everyday IT professional" is in that proper SOA and SOA Governance do require significant changes in the understanding of the development process cycle. It is, however, not a news or a show stopper – a shift from client-server into the multi-tier model also required different understanding from the developers and the adoption took some time before the multi-tier model was widely accepted. I can only add that SOA Governance policies will not alter required changes for the sake of convenience of those who do not grasp the sense of service orientation. This means that if a developer tries to build services having, e.g., object orientation as the guideline, there are only two exits - this person changes his/her mind toward service orientation and leads his/her company to the success or this person breaks SOA initiative, with appropriate consequences.

I am so confident in this SOA Governance position because service orientation is about implementing real business products and procedures. This puts additional and very strong control on how things may be done. Everything, which does not fit with preserving the business value of SOA, will retreat sooner or later. Thus, real pragmatic SOA Governance is the one that guards and promotes business objectives across Business and Technology.

Conclusion

Despite multiple efforts in SOA Governance standardisation, there are still some conceptual areas for improvement. With this regard, I am making a few statements in the article that I offer to your attention and discussion.

The first fundamental statement discussed is the separation of concerns between SOA Governance and the governance enforcement attributed to Management function.

The second statement argues that SOA Governance must guide all SOA related activities in the enterprise and, thus, must be positioned ‘above’ all of them. This leads to the revision of the TOGAF ADM and repositioning the architecture development phases accordingly.

The third theme talks about a vital necessity for SOA Governance to be able to cross the departmental ownership boundaries as well as an artificial boarder between Business and Technology. SOA Governance, if realised correctly, influences the social structure of the enterprise including people, resources and operational relationships.

The final fourth statement recommends to start SOA Governance with the understanding of why it is needed, what it is, in which areas and who will be providing it, and only then to talk about supporting tools and instruments. Expensive Registry/Repository systems or even free open source products with these functions will not help until people feel the need for them. SOA Governance is much more complex than registering Web Service interfaces in one place; as a minimal SOA Governance needs a Repository of a SOA Policies and related mechanisms for their maintenance and management.

Lastly, I encourage you to expand your view on SOA Governance from the Technology 'box'; try to think and apply it gradually and accurately to the low-level business processes and related business activities. This is the direction where SOA Governance is moving to.