Todd Biske: Outside the Box

Sorry, I need to rant, although, not as much as I originally thought. I just read the interview with Gartner’s Paolo Malinverno on SOA Governance at SearchWebServices.com. I read his answer to the question “How do you define SOA governance” and decided I needed to blog on this, although he made up for it a bit in his answer discussing “phases.”

Anyway, in his definition of SOA governance, he split it into two halves. The first half is about making sure that important decisions go through to appropriate people and that these people have appropriate input to make those decisions. The second half is making sure those decisions are followed. I wanted to scream out, “Where are the policies???” But, he did mention in his answer to the next question that there is a “phase which defines what the policy is.”

Unfortunately, I really didn’t feel like this article made the whole picture crystal clear, so let me do that here.

1. People.
2. Policies.
3. Process.

Step one is to figure out who your governors are. Before you can have governance, you need to have someone responsible for creating the policies to be governed. Paolo made the statement, “This set of decisions, I wanted them covered.” I think it’s more vague than that. I doubt any organization already knows all of the decisions that need to be made. It’s more likely that they know the desired outcome, and now need someone to work backwards to figure out what policies will enable that behave. For example, there’s the holy grail of IT, reuse. If the desired outcome is reuse of services, you need someone to work backward and figure out where policies are needed to make that outcome a reality.

Step two, therefore is about establishing the policies. The key to this is making sure the policies exist is some form other than the memories of the governors. Put them on paper in the form of patterns or reference architectures. Codify them and rely on tools to automate it. If the only place the policies exist are in the brains of your governors, all you’ve created is a bottleneck. This results in a situation like this:

On the one side up in the ivory tower sits the governors, pontificating away. On the other side are their constituents (the developers) busily working away in the trenches. Only on a rare occurrence are the constituents able to gain audience with the governors in an exercise known as a review. At such review, the constituents demonstrate their mind-reading abilities in predicting what things the governors care about, and praying that they don’t reach the dreading situation of disagreeing governors who hadn’t even talked to each other about their own opinions.

Clearly, we need some documented policies here.

Well, that helped a bit, as the mind reading isn’t necessary anymore, but as is most often the case, the constituents either disagree with the policy, or don’t bother to look at it until it’s time for their review, only then to find out that they are out of compliance. Now it’s time for the filibuster! At this point, the best course of action from the constituent’s standpoint is to simply put it off until the cost of making it compliant is far more expensive than the perceived cost of leaving it non-compliant. It usually entails telling the business sponsor that the project can be released in two weeks or it can made compliant and released in 3-6 months. Thus ensues the debate between the business leaders and the elected officials, yada, yada, yada. And this doesn’t even touch on the subject of policies which the constituents don’t like, and claims that the governors are being overly influenced by lobbyists and out of touch with the people.

To conquer this one, and get the right process in place, I recommend the following model:

In this model, we introduce a third party that bridges the gap and is the key to successful policy enforcement. Keeping policies up to date can easily be a full time job, as is building solutions. What we need is a third role that does a bit of both. I’ll call it the solution architect. These individuals are able to participate in the policy setting process, but they also are the key enforcer on projects. They may have the role of technical lead, but at a minimum, they have the authority to set direction on a project. In this way, they help projects apply policy at the right time, and they help the governors define relevant policy. Formal reviews may still take place, but hopefully, they’re much faster and focused on increasing communication and collaboration instead of being a potentially belittling exercise and demonstration of authority, which isn’t good for the health of the organization.

Most importantly, people must know their role. The governors should be judged on their ability to produce relevant policy in a timely manner. Constituents should be judged on their ability to produce solutions in a timely manner. Solution architects should be judged on a combination of the two.

2 Responses to “People! Policies! Process!”