> Archive > Issue XLVIII: March 2011 > Driving SOA Governance - Part I
Leo Shuster

Leo Shuster


Leo Shuster is responsible for SOA strategy and execution at National City Bank.

He has over 15 years of IT experience and throughout his career, has performed a variety of roles including group manager, team lead, project manager, architect, and developer.

His experience spans a number of industries but over the past 7 years, he has been focused on the financial services sector.

Mr. Shuster holds a Masters degree in Computer Science and Engineering from Case Western Reserve University and an MBA from Cleveland State University.

He has presented on SOA and related topics for groups of all sizes at such events as the Gartner summits and the Enterprise Architecture Executive Council.

He regularly blogs about advanced software architecture issues at and he can be reached at


rss  subscribe to this author


Driving SOA Governance - Part I

Published: March 09, 2011 • SOA Magazine Issue XLVIII PDF


As governance introduces new rules, processes, and precepts, people that must comply with them often do not accept the change easily. In general, people like status quo. Change is hard. It requires people to learn new things, follow new rules, and modify their behavior. This dislike for change leads to rebellion in many forms – outright rejection, quiet noncompliance, behind the scenes subversion, or complete disregard.

These patterns are even more evident in the case of SOA governance. Because it affects how almost everything is done in IT, people feel that many aspects of their jobs are being uprooted. Regardless of the role, SOA governance introduces many new rules and processes that should be followed. Almost everyone is affected and consequently dislikes it.

The true measure of any governance program success should be how seamlessly all the governance processes are integrated into existing everyday activities and how automated the execution is. If governed people do not consciously think about the governance processes they need to invoke but rather perform them automatically as part of their day-to-day work, governance is likely to be successful. This means that governance mechanisms are so deeply rooted into everything happening within IT that they are accepted as normal, thus quelling any potential noncompliance or disengagement.

This article will focus on running governance in the most efficient way and provide a recipe for effectively driving adoption across the enterprise. Many governance dimensions will need to be assembled to create a comprehensive mechanism of checks and balances that would not only establish a seamlessly integrated governance system but also ensure compliance throughout the organization.

The Governance Adoption Framework

Adoption of SOA governance program across the enterprise does not just happen by itself. It needs to be meticulously laid out, thoughtfully implemented, seamlessly integrated with existing processes, and thoroughly communicated. Universal adoption of the program should be considered a key milestone in SOA governance maturity. Therefore, facilitating and continually increasing adoption is critical.

The first step towards driving the adoption of the SOA governance program is establishing a comprehensive framework for doing so. It will help you understand what processes and technologies need to be put in place, how to integrate everything together, and what the final picture looks like. This framework will not only help you achieve a greater degree of SOA governance adoption but will also serve as a roadmap for integrating all the various governance elements together.


As discussed earlier, the primary goal of any governance program should be seamless integration with everyday activities the governed population is already performing. The SOA governance adoption framework aims to achieve just that. It strives to establish a fully integrated service-oriented environment with complete synergies between processes, people, and technology. Imagine an SOA ecosystem, in which governance processes are kicked off automatically upon initial identification of service or reuse candidates, all SOA platforms are seamlessly integrated among themselves along with the governance mechanisms, governance checkpoints are invoked automatically and no service deployments or changes can take place without proper authorization. Imagine an environment, in which people, processes, and technologies are so tightly integrated that neither can function efficiently on its own. A high level depiction of this model is presented in Figure 18.1.

Figure 1 - The integrated service-oriented enterprise achieves close coupling between people, processes, and technologies.

From a high level perspective, tight integration between many of the SOA governance elements can be achieved through technology. For example:

  • all of the service's metadata is stored in the service repository
  • service source code and related artifacts are placed into a source code repository
  • services are deployed to their execution environments from their respective source code repositories
  • service endpoints and contracts are registered in the service registry
  • services are exposed and invoked through the ESB
  • service policies are stored in the service repository and promoted to the service management platform for runtime execution

Not every enterprise has a complete suite of these technologies. The integrated view presented here should be considered the final state in the SOA platform evolution. Even if some technology elements are missing, they can be replaced by either manual operations or alternative solutions.


In general, there are several major processes that are part of SOA governance.

  • Service Delivery Process - This process guides the actual delivery of a shared service asset. It covers the entire service lifecycle, which includes design-time and run-time governance and addresses issues such as service design, implementation, testing, deployment, versioning, retirement, and management.
  • SOA Vitality Process - This process maintains the applicability and currency of the SOA technology and reference architecture. This requires the architecture to be current, reflecting the business and IT direction and strategy, as well as anticipated changes in outsourced non-core processes.
  • SOA Exception and Appeals Process - This process allows projects to appeal the noncompliance of a solution design decision or an investment with the ARB or a similar group and be granted an exception.
  • SOA Communications Process - This process is aimed at educating and communicating the architecture across the organization. It also includes the steps to ensure that the process is acknowledged within the associated processes, as well as setting up environments and tools to allow easy access and use the architectural information.
  • Business / IT Executive Review Board Process - This process helps provide guidance for the SOA program as a whole, including reviewing business issues that are affecting the SOA journey.

For the purposes of the SOA governance adoption discussion, we will consider the service delivery process to be the primary governance mechanism and the other processes – secondary. While all the processes are important, service delivery directly addresses the principal goal of the SOA program – agility. By extension, it has the greatest impact on SOA governance adoption, either positively or negatively. All the other governance processes help support it and make it more efficient in the long run.

Integrated SOA Governance System

Once the goal of a fully integrated service-oriented enterprise is achieved, SOA governance processes can start to be automated as well. Technology can help with automating processes, but governance must help direct what those processes are. Closely coupling governance processes, people, and technologies establishes a comprehensive system of checks and balances that ensures nearly universal compliance. More importantly, it streamlines all of the governance activities while making it almost effortless to comply with them.

Recall that a service delivery lifecycle should be closely tied to the organization's software development lifecycle. On top of that, SOA governance should introduce its own private processes for dealing with SOA specific issues and concerns. Integrating the SDLC, SOA governance processes, and technology into a single, interconnected and cohesive system enables SOA governance to become transparent and virtually effortless to follow. Figure 18.2 depicts how this can be achieved.

Figure 2 - Integration between SDLC, SOA governance processes, and technology drives SOA governance adoption forward.

Let's examine all the elements and processes within the integrated SOA governance system and understand how they all fit together. We are assuming that all of the elements of a fully integrated service-oriented enterprise are already in place. If this is not the case, however, alternative solutions or manual approaches can be used.

Process Step
1. identify service opportunity

Once a service creation or reuse opportunity is identified, a new candidate service or consumer façade needs to be registered with the service registry. This informs the IT groups about the work in progress happening across the enterprise and serves as a launching mechanism for the subsequent SOA governance processes. Since typical Registry/Repository platforms include automated SOA governance capabilities, candidate registration and approval can be tied directly to the invocation of an automated SOA governance process.

Roles and responsibilities include:

  • Service Registry Custodian - create automated SOA governance processes
  • Service Architect - identify service creation or reuse opportunities; register candidate services

Note that the responsibility for registering candidates in the service registry is dependent on the specific organizational model being used.

2. approve candidate service

Once new candidate service or consumer façade has been registered, a notification should be sent to the SGPO to review and approve it. This is necessary to ensure compliance with the SOA standards, perform architectural review, eliminate potential duplication of efforts, and validate the opportunity. Roles and responsibilities include:

  • Service Custodian - validate the opportunity; take ownership of service stewardship
  • SOA Governance Body - approve service or façade candidates
3. design the service

Once new candidate service or consumer façade has been approved and registered, design efforts can begin. The automated SOA governance process should not allow the design work to proceed unless an approval has been granted. Any related service design artifacts should be stored in the service repository.

Roles and responsibilities include:

  • Business Analyst - supply related business requirements
  • Service Analyst - elicit service requirements, determine fit into service inventory and blueprint, model the service
  • Service Architect - design the new service or consumer façade; update service metadata in the repository
4. validate service design

The completion of service design should invoke the approval step. Once all the required design artifacts have been entered into the repository and request made to proceed into development, the SOA governance mechanism should suspend the process until an approval is granted.

Roles and responsibilities include:

  • Service Custodian - validate the service design
  • SOA Governance Body - approve service design
5. develop the service

Upon the service design approval, development efforts can begin. The automated SOA governance process should not allow the development work to proceed unless an approval has been granted. Any related service design artifacts should be stored in the service repository. Service source code and related packages should be stored in the appropriate source code repository. Ideally, the information of where the code is stored should be included with all other service metadata.

Roles and responsibilities include:

  • Business Analyst - ensure related business requirements are met
  • Service Analyst - ensure service requirements are met
  • Service Architect - ensure adherence to service design and SOA standards
  • Service Developer - build the service and implement any related policies; update service metadata
  • Service Tester - ensure all functional and non-functional requirements of a service are met
  • Schema Custodian - ensure compliance with schema standards
  • Policy Custodian - ensure compliance with policy standards; assist with implementing service policies
6. validate service deployment

Once the development is complete and all the necessary artifacts are updated in the repository, the deployment approval step is initiated. No deployment can occur unless approval is granted. One way to streamline this process is to integrate code deployment and/or release management tools with the SOA governance automation platform and validate the approval for specific deployments prior to performing them. Note that this step may need to be performed several times, one for each deployment environment depending on the organizational policies in place.

Roles and responsibilities include:

  • Service Custodian - validate the service code does not impact existing consumers or changes initial purpose or intended functionality of the service
  • Schema Custodian - ensure compliance with schema standards
  • SOA Governance Body - approve service deployment
7. deploy the service

Once the approval to deploy the service is received, the deployment process can be started. Ideally, the deployment tools should be integrated with the SOA governance platform to ensure that specific deployment can, in fact, proceed. Source code repository should serve as the definitive source for deployable packages. Alternatively, a separate repository could be established where all the deployable packages are stored for deployment purposes. Any related service configuration information should be stored in the service repository. New service contracts as well as any changes to the existing service contracts or interfaces should be exposed through the registry. Note that this step may need to be performed several times, one for each deployment environment depending on the organizational policies in place.

Roles and responsibilities include:

  • Support Organization - perform deployment
  • Service Registry Custodian - provide assistance in registering service contracts
8. prepare service for use

Once the service has been deployed and fully registered, final preparations for its use should be made. All of the service policies should be published to the service management platform. The actual service endpoint that should be utilized by its consumers should be exposed through the ESB. The ESB should, in turn, be configured in such a way that the endpoints exposed through it cannot be invoked unless the underlying service has been fully approved and registered in the service registry. The service management platform should provide yet another checkpoint by ensuring that only ESB exposed endpoints can be called.

Roles and responsibilities include:

  • Support Organization - expose service endpoint through the ESB
  • Policy Custodian - assist in promoting service policies; ensure integration with the ESB
  • Service Registry Custodian - ensure integration between the ESB and the registry and the SOA governance platforms

Table 1:Detailed examination of all the integrated SOA governance system components and their relationships with each other.

As you can see, the integrated SOA governance system provides a structure of checks and balances in many important ways.

  • The automated SOA governance process is invoked automatically upon identification of a service creation or reuse opportunity.
  • The SOA governance process cannot be subverted or disregarded because it tightly integrates with the technology supporting the entire SOA efforts.
  • The usage of the delivered service is predicated on compliance with and successful completion of all the SOA governance steps.
  • The entire SOA platform is aware of the service state and guarantees proper compliance with SOA governance decisions.
  • All of the processes are automated and do not need to be explicitly executed.

If you can successfully implement this SOA governance adoption framework, SOA governance will cease to be a burden and will almost completely dissolve in the existing software development lifecycle. It will essentially become a background process that is executed automatically and is triggered through a series of external events. The governed population may not even recognize how their actions impact the governance processes and will not consciously realize when they are going through governance mechanisms. The entire service-oriented platform will become a fully integrated system of checks and balances that is completely synchronized with the SOA governance mechanisms and relies on them as definitive sources of truth about service state and metadata. As a result, SOA governance adoption will become nearly universal as anyone utilizing any or all SOA platforms will have to comply with it.

Keep in mind that reliance on all the tools, platforms, and technologies mentioned in Table 18.1 is not a necessity for success. Following the concepts outlined in the SOA governance adoption framework is, however. The technology is helpful and valuable. However, the processes can be implemented using a wide variety of tools such as wikis, spreadsheets, simple workflow products, open source platforms, etc. The solution you choose should provide the best fit with your organizational realities and SOA program roadmap.


An integrated service-oriented enterprise can help achieve nearly universal SOA governance adoption. The integrated SOA governance system provides a seamless integration of SOA governance mechanisms with many SOA platforms and service delivery lifecycle and, as a result, can achieve a nearly universal SOA governance adoption. The next article Driving SOA Governance - Part II: Operational Considerations will focus on governance operations.