Implementing SOA Governance
Many people have written that the hardest thing about a successful adoption of SOA is not the technology, but rather, the culture change. Whether it’s trying to encourage a culture of sharing that goes against the grain of developers that prefer complete control over their solutions, trying to change the way projects are proposed and funding to ensure strategic service creation, or trying to properly manage the new dependencies that are created at run-time, these changes require more than just technology. What is the key to ensuring that the culture change does happen? It is in managing the process of behavioral change, which is governance.
Governance is the combination of people, policies, and processes that an organization leverages to achieve desired behaviors. SOA governance is about achieving the desired behavior associated with, or attributed to, SOA adoption. These behaviors span the normal software development efforts, known as project governance, the interaction between service consumers and service providers in production environments, known as run-time governance, and the processes associated with the proposal, approval, and funding of projects, known as pre-project governance. During each of these efforts, people, policies, and processes must be established and leveraged to ensure that the changes to the culture are successful.
The very first step in SOA governance is to actually establish the desired behaviors. A successful adoption of SOA is not the desired behavior, because no one has defined what success means. There needs to be a measurable outcome that the organization hopes to achieve through the adoption of SOA, that is the desired behavior. The media consistently quotes vague benefits such as “increased IT and business alignment,” but this needs to be taken a step further to actually define a way to measure it. Does alignment mean that projects will be executed more quickly? If so, that is something that can be measured. What about agility? Agility can be viewed as the ability of an organization to respond to change. Does the organization know that it has redundant implementations of the same capability, which can impact its ability to quickly roll out changes to those capabilities? Once again, a reduction in the number of redundant implementations can be measured. These are your desired behaviors.
The role of establishing these behaviors normally falls to the leaders of the organization, who frequently are the sponsors or stakeholders of the effort. Their job is to establish this direction, but once established, the first process of governance must be executed, which is establishing the policies that will lead to those desired behaviors. This is where the governing body must be put in place. In some ways, this can be thought of as a similar separation that exists in many governments. In the United States, the president does not write laws, congress does. The president is responsible for enacting those laws, but more importantly, the president is the figurehead of the country, establishing the stated direction (i.e. desired behavior). It is then up to congress to enact legislation that they feel will lead to that desired behavior. A problem with this, however, is that party politics can lead to division between the legislative body and the president. There is certainly the same risk within a corporate enterprise, so it is vital that the people selected to establish the policies are all in line with the stated desired behaviors. Unlike the United States government where the president cannot fire members of congress, a CIO in a corporate enterprise can pick and choose the members of the SOA governance team.
The challenge of this step is in figuring out the right set of people to establish those policies. Clearly, a broad cross section is needed. An Enterprise Architecture team may be well positioned to establish the technical policies frequently associated with project governance, but may not be appropriate for the policies that guide service ownership decisions or the policies that impact the way projects are defined. A very common approach is the establishment of a Center of Excellence, or CoE, that has a cross section of leaders that can be accountable for policies within their domains. This includes IT managers, project managers, application architects, information architects, senior developers, business analysts, and operations managers. While the CoE has accountability for establishing policy, they may draw in others with deep expertise to be responsible for establishing the policy.
Policies must be established that guide the behavior within projects, but also with the run-time behavior of the systems and the pre-project processes that result in the project proposals within the organization. The goal of these policies should be to provide the connection between the goals of the organization and the desired behavior of the staff. For example, if a goal of the SOA effort is to reduce the time it takes to deliver IT solutions, one factor that can contribute to this goal is to reuse existing services within solutions. In order to do this, teams must be aware what services available through means other than tribal knowledge. This then leads to a policy that states that services must be published in a publicly searchable location, such as a Service Registry/Repository. While simple, this example demonstrates the connections between policy and behavior. The same holds true for run-time policies and for pre-project policies. A run-time example may be a desired goal to not allow any one consumer to jeopardize the availability of services to other consumers. A policy that would contribute to this goal is that all consumers must establish expected usage characteristics, including warning thresholds and throttling thresholds. A pre-project example comes back to the goal of reducing the time to deliver IT solutions. While we added a project-time policy of publishing services, a corresponding pre-project time policy is that all proposals must list existing services that will be leveraged in the solution. This policy itself can lead to a change in the behavior in the organization. Simply requiring that services be placed in a repository doesn’t deliver the value. Combining that policy with a policy that guides people to actually use the repository is what adds value.
Once policies are established, the next process of governance is not enforcement of policy, but rather education and communication. Often, the policies are known to the members of the governance effort, but poorly communicated to the people that are expected to follow them. Furthermore, the desired behavior itself may not be effectively communicated, which can lead to a situation of competing priorities. The most common scenario of this is the contention that can occur on a project where the team is driving toward an on-time, on-budget delivery without any concern for the architectural impact of those decisions. This is not to say that schedule and budget are not important, but they are not the only thing that is important. Only if those project teams understand the desired behaviors of the organization and the linkage between the policies and those behaviors can they be expected to follow them.
The CoE must develop a plan for communicating and educating the organization on the behaviors and policies. It is not a one-time presentation, but rather a formal plan that leverages all of the communication mechanisms available with targeted communications toward the multiple roles that will be impacted by the SOA effort. At this point, it may be wise to engage a communications professional (if your organization has a Corporate Communications department, it’s a good place to start), to establish this formal plan. Communications and education techniques include lunch and learn sessions, “road show” presentations given to individual teams within the organization, blogs and wikis, formal whitepapers, and more. These messages must be targeted toward the expected audience, whether it is a broad group in a lunch and learn session, or a very narrow group of developers from an individual team.
Just as with policy establishment, your communications efforts can involve people outside the Center of Excellence. A very common example is to have a member of the senior leadership team, such as the CIO, deliver the initial message of why SOA is important to the organization. As the SOA effort progresses, representatives from successful projects may be called forward to share their experiences and how the policies put in place contributed to the success of the effort. Finally, in addition to providing content, the CoE must also ensure that this communication is effective in educating the organization, and remains effective over the duration of the SOA effort. This can be done through surveys, interviews, or questionnaires at various times throughout the effort, since you must evaluate both the immediate effectiveness of the communication as well as the long term retention of the information.
Any governance effort, no matter how well specified and communication the policies are, will need to have some amount of enforcement. If nothing else, times will arise where there may be competing policies, and mediation will be required on which policies will be followed, and where exceptions will be granted. Preferably, the people making the decisions associated with the pre-project, project, and run-time efforts will desire to adhere to the policies and enforcement will simply happen on its own because it is naturally the path of least resistance and fits the corporate culture. This doesn’t mean it can be ignored, however. Just because a community has a low crime rate doesn’t mean they don’t have a police force. Auditing and compliance checks must be a part of the organization if for no other reason than to aid in the final process, which is measurement and feedback.
Measurement and feedback must be in place to ensure that adherence to the policies actually results in the desired behaviors and goals being achieved. Using our earlier example, if measurement indicates that projects are still being delivered at the same pace as always, then something needs to change. Are teams adhering to the policies that were intended to lead to this behavior? If not, then perhaps some adjustments need to be made to enforcement processes to ensure they are. If the teams are adhering to the policies, then a change in policy may be required. Some policies may actually be having the opposite effect. As was the case in the earlier example, it may simply be that additional policies must be needed. If we only had a policy that required publishing into the registry/repository, but no policy that required teams to actually look in the registry/repository, the desired behavior wouldn’t be achieved.
Hopefully, this brief introduction has made it clear that appropriate use of people, policies, and processes are a key to creating the behavioral change and goals of SOA adoption. These same techniques can be utilized as part of any governance effort, with the key difference being the domains of the policies. In the case of SOA adoption, these policies are all rooted around the definition of services and the interactions between service consumers and service providers. Proper articulation of the correct behavior between both the technical components of these services and their consumers and the human teams responsible for the definition, creation, and operation of them is what SOA governance is all about. A successful governance effort plays a tremendous role in determining the success of the SOA adoption effort itself.