Q

The trick to SOA governance enforcement

How can an enterprise architect enforce SOA governance without becoming the bad guy? The fear is that one can be seen as uncooperative and counterproductive if one says "no" too often. The answer may surprise you. It's not so much about enforcement as it is about the other aspects of governance - policy definition, education, and measurement and feed back.

How can an enterprise architect enforce SOA governance without becoming the bad guy? The fear is that one can be seen as uncooperative and counterproductive if one says "no" too often.
It is definitely true that governance is a four-letter word in many organizations. If that's the case for you, it's probably best to just avoid calling it governance altogether, but that doesn't mean you can't have effective governance.

There are four key processes to governance, and only one of them has the potential to be counterproductive, and that's usually because enough attention was not given to the other three processes. These processes are:
  1. Policy Definition
  2. Education
  3. Enforcement
  4. Measurement and Feedback
When people think of governance, they only think of process number 3, enforcement. Architecture reviews can be a very painful experience if the reviewer doesn't know what they're being reviewed against. I've experienced reviews like this, and I'm sure many others have too.

The review consists of the project architect going before one or more people the organization has deemed as "smart" and the review becomes more about them demonstrating their knowledge than actually reviewing the project against any kind of standards or guidelines.

To be fair, often times the review board is not given any more guidance, either. They're asked to judge based on their experience, not on any documented standards or guidelines. The way to fix this is through the other processes.

It begins with policy definition. In order to have any hope of a successful governance program, you have to establish the expectations against which projects will be reviewed. These are the principles, standards, and guidelines. They must be rooted in the business goals and operational model of the company, otherwise they are at risk of being perceived as arbitrary.

For example, it's one thing to enforce that the approach to services use RESTful practices. It's another thing to require that a very specific development framework be used to implement it. If your company is concerned about developer portability across projects, and you have a centralized support organization, then the latter may make perfect sense.

If developers are allocated to particular business lines and provide their own third level support, then the use of REST may be important, but standardization of the development framework may not be important, and will probably be resisted. Once you have the principles, standards, and guidelines established, you now have a clear set of policies to which projects are expected to adhere.

The next step is to make sure your development teams are aware of these policies. While having documented policies is better than no policies, it doesn't do much good if the reviewers are the only people who know what they are. The development teams that will be governed must be made aware of the expectations through an effective education program.

Throughout the process, the message must not be about passing a review, but rather, making their job easier so they can focus on the important part of the project, implementing the business logic. Simply put, you've given the teams everything they need to be successful. Too many projects start out without proper positioning for success. Do everything you can so the project can be successful from the very beginning.

If you do these processes right, enforcement can become very efficient. The teams can perform a self-assessment against the policies, allowing them to focus on areas where an exception will be needed, or areas of concern that may not be addressed by current policies. This keeps the focus on creating the best solution possible and avoids wasting time on unnecessary areas.

Finally, like any good process, the system must continually improve. If exceptions are consistently being asked for certain policies, perhaps there's a problem with the policy. If business needs change, such as a need to shift from maximizing growth to reducing costs, the policies will need to change.

New approaches and new technologies will come along, and new policies may be needed in those areas. The team defining the policies must listen to the teams being reviewed and incorporate their experiences into the policy decisions they make.

If you effectively implement all four of these processes, rather than just focusing on enforcement, your odds will be much better that the governance program is effective rather than dreaded.
This was first published in November 2010

Dig deeper on Data governance and management for SOA

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close