Todd Biske: Outside the Box

With the upcoming publication of my SOA Governance book, which will be shamelessly plugged on this blog, you’ll be seeing more posts on SOA Governance, whether they are teasers to the book’s content or complementary material.

Many of the discussions I’ve had with colleagues on the topic of SOA governance is how to get started. Everybody’s heard from all of the analysts, bloggers, and other pundits on the importance of governance, but they don’t have a clear plan on how to put it in place at their organization. This isn’t a surprise, because organizations at this points are now facing the need to change head-on.

My definition of governance is the people, policies, and processes an organization uses to achieve a desired behavior. If you’re not achieving the desired behavior, than change is needed.

It is at this early stage where the first breakdown can occur. All too often, the steps of articulating the desired behavior and the policies that will lead to that behavior are not done, or done insufficiently. Rather, the focus immediately jumps to enforcement. Not surprisingly, the people involved with governance at organizations in this situation make statements like, “The developers are going to do whatever they want, and we can’t stop them.” Strong enforcement may catch things before they go live, but it doesn’t address the behavior that did things the wrong way to begin with. While it may result in some behavior change the next time around, it is unlikely, because it did nothing to change the understanding of the project managers, architects, and developers on what they should be evaluating themselves against as the right thing to do. If change is needed, but you’re not stating what you want to change into, the behaviors are unlikely to change. This truth applies whether we’re talking about pre-project governance, project (design-time) governance, or run-time governance, although it’s most easily understood in the world of project governance.

All too often, architects and developers lament the fact that the only concern of the stakeholders is that the project is delivered on time and on budget. If this is an impediment to success with SOA, then that mentality needs to change. If it does not, you’re always going to have this tension between the project manager and the technical leadership on the project. There’s a ripple effect to this, however. The resistance to such a change is that, in general, IT has not been able to demonstrate how adding technical concerns into the success criteria has an impact in IT’s ability to deliver solutions in a timely manner. If you are able to change the success criteria to where projects can be delayed in order to address architectural concerns, you’d better be collecting metrics to show that things are improving over time. This again comes back to establishing your desired behavior and policies first. If you have these in place, now you have something to measure against. If you’re not achieving the desired behavior, it doesn’t mean that you need to scream louder. A change in policy, people, or process may be what is needed.

So, if you’re looking for a place to start, my recommendation is not to focus on enforcement. My recommendation is to define the behavior you’d like to see out of your organization, the policies that will help guide that behavior, and then focus first on education of the organization on those items. If your staff is better educated on the outcomes the organization wants to achieve, they’re more likely to comply with the policies that will lead to that behavior, lessening the need for strong enforcement.

2 Responses to “Getting Started with SOA Governance”