SOA governance is crucial to building, managing, and maintaining a successful SOA implementation – indeed, without governance, well-intended SOA pilot projects spiral into chaos when they go operational. We have all seen it before – an organization spends a lot of money developing services, and they prematurely declare success when everything works well in the lab. Without a SOA governance plan, however, certain successful initial prototypes will cause constant pain at all levels of the organization when the project goes “live” and needs to be managed, maintained, and changed over a period of time. In cases where governance is largely ignored, the isolated technology benefits of SOA adoption are outweighed by the hassle of managing chaos. Managers, architects, and developers get burnt out as they make necessary massive “band-aid” solutions to real-time deployed systems.
Most seasoned SOA architects and developers have been there, they have felt this pain, and they realize how important SOA governance is. Many, however, do not exactly understand what a successful process is, how a SOA governance team should be established and managed, or how a process should be implemented. For this reason, I will briefly refer to the SOA governance process from the book Applied SOA: Service Oriented Architecture and Design Strategies that I recently co-authored with Mike Rosen, Boris Lublinsky, and Marc Balcer. In this book, we provide a comprehensive process for successful SOA governance, complete with examples, best practices, and organizational structure. This article will refer to some of the highlights of the SOA governance chapter.
The SOA Governance Process
First of all, let’s define what SOA governance is, and what SOA governance is not.
SOA governance is the creation, communication, enforcement, and adaptation of policies used to direct and control the creation and implementation of the lifecycle of services in an enterprise SOA.
In looking at that definition, it should be clear that SOA governance is NOT a product that you buy (although many vendors may try to convince you otherwise). It is important to know that SOA governance is not a “one-time thing”, where creation of policies happens at the beginning of a SOA project and where those policies are never revisited again. SOA governance activities may differ from organization to organization, but SOA governance is always a process (and typically an iterative process), operating over the service lifecycle – from the cradle to the grave of all services.
Policies defined in SOA governance typically drive the service lifecycle in the following phases, as shown in Figure 1:
- Design-time activities, where SOA governance policies govern service identification, design and specification.
- Deployment activities, where SOA governance policies govern checkpoint compliance testing and dictating run-time access policy standards.
- Run-time activities, where run-time service policies developed by your governance team dictate service utilization, availability, service level agreements, and access policies. This also includes service retirement, where services are deprecated and removed.
- Change-time activities, where SOA governance policies dictate the process for modifying, registering, and deploying new functionality. This is inherent in all phases of the SOA governance lifecycle.
Figure 1: SOA Governance Life Cycle 1 Click to view full image (PDF).The SOA Governance Team
SOA governance needs to establish chains of responsibilities, decision making rights, authority and communication, and this usually requires the creation of a SOA governance team. Such a team dictates the processes that occur throughout the service lifecycle, as well as the roles and responsibilities of the stakeholders. SOA governance activities will vary from organization to organization, and they will depend on many things, including the makeup and culture of your organization.
Your SOA governance team should position SOA as a critical element of IT toolset and align it with the business strategy, it will define business opportunities for SOA adoption and implementation, and it will create clear ownership and supervision of SOA-specific issues. The group should define SOA funding approaches (including reuse charge backs, etc.), enable SOA maturity tracking and its controlled evolution, align the SOA strategy with other enterprise strategies (including security, presentation, portfolio management, etc.), ensure adherence to services definition and implementation policies and processes, ensure infrastructure readiness for SOA, and maintain and advertise major SOA artifacts. Of course, this seems like a daunting list of responsibilities for an organization new to SOA governance or new to SOA. How then, does an organization get started?
Best Practices for Getting Started
SOA governance activities typically differ from organization to organization and project to project, and so will the stakeholders and the makeup of your SOA governance team. Applied SOA includes a comprehensive “whole nine yards” of SOA governance with an example team structure and mature process – you should certainly read this to get a feel for what such a process looks like, but it is equally important that any process should be tailored to the makeup of your organization and project(s). What are some tips that can apply to every organization? For this article, I am going to list five best practices:
- Get Buy-in from Management. First, it is important to convey the necessity of governance within your organization – starting at the top. Help management understand the necessity of governance, and the Return on Investment (ROI) it will achieve over the long run for you, your customers, and your business partners. Make certain that your governance team gets authority from upper management. The last thing you need is a powerless committee writing policies that no one will ever use, or policies that won’t be enforced when the rubber meets the road.
- Choose a Champion. Your SOA governance team needs a leader. This person is the one who guides the governance process, and who acts as the communicator within your organization. Choose your SOA champion wisely. Avoid the “ivory tower dictator” approach where one architect authors all the policies from on high, and shoves it in the designers’ and developers’ faces without their input. Such leaders are typically despised, and teammates will typically find ways around the policies or will rebel and try to sabotage the process. Instead, look for a team-playing consensus builder who gathers input from the subject-matter experts on the team, but who is clearly in charge of the process.
- Start Small, Then Evolve. If your organization is new to SOA, or if you are simply new to SOA governance, you will probably want to start small with governance, evolving over time. See what works for your organization. You may first want to start with developing service creation policies – such as dictating adherence to certain messaging and other technology standards, the use of security infrastructure, and conformance to enterprise vocabularies. You will then need to establish a process for enforcing these policies, typically when services are about to be deployed or changed. Soon after that, your organization will need policies revolving around versioning, discovery, and deployment. Over time, you will want to revisit and adapt your policies that you created. Learn from what works, and drop what does not.
- Avoid “Death by Governance.” If your SOA governance manual sits on your shelf gathering dust, has more pages that Tolstoy’s War and Peace, is so heavy that it can be used as a weapon in a dark alley, or is so confusing that no one ever reads it, then you might just be experiencing “death by governance”. Too many service policies and regulations sometimes backfire and translate into a barrier to productivity. Too much regulation is typically unnecessary and unhelpful, usually leading to confusion and the abandonment of governance altogether. If you find yourself in this situation, take time to refractor and simplify your policies. If your governance policies can be abbreviated into a two page check list (with references to a more detailed implementer’s guide), this is the way to go.
- Communicate that “Governance is There To Help.” Helpful communication is key. Designers and developers new to governance may see your process as another hurdle to jump through. Through education, it is important to communicate that these processes will help (and not hinder) your process in the long run, and the governance team is there to help the project.
Certainly, these best practices for getting started are just the tip of the iceberg, but they are often common sense practices that are not addressed. For a more comprehensive guide to SOA governance including example policies, organizational structure, strategies, and best practices, I refer you to the SOA Governance chapter in Applied SOA: Service Oriented Architecture and Design Strategies.
1 Image from Rosen, Lublinsky, Smith, Balcer, Applied SOA: Service-Oriented Architecture and Design Strategies, Wiley, 2008.
