Recently, I’ve noticed a theme among a couple of new clients as well as some people that I met at a conference. Governance? Oh sure, we’ll fold that in at some point. I’ve seen this expressed in two ways:

1. Governance is fine, but should only be implemented once some services, a registry, and a few other pieces are in place
2. Governance is a part of the project management life cycle but only once the services have been deployed

I believe that both of these perspectives on governance are flawed. I’ll address each one in turn.

Flawed perspective #1: Governance isn’t needed until after our SOA is up and running

At first glance, this thought process is rather logical. You really need some services (15+) and infrastructure before governance becomes an issue, right? The trouble is that ungoverned services require refactoring once governance is put in place. Additionally, personnel tend to be frustrated when structure is introduced later. They resist the idea that governance is needed today when it wasn’t needed yesterday. The counter to this line of thinking is that instituting governance too early will crush a fledgling service orientation initiative before it gains any traction. The flaw in this line of reasoning is to assume that governance has to be fully-mature at its inception. Governance does not, and in fact should not, be implemented all at once any more than your SOA infrastructure should be deployed in one fell swoop. Experience shows that change should be rolled out incrementally, delivering more mature capabilities gradually within the enterprise.

Flawed perspective #2: Governance isn’t needed until services are deployed
Although I’ve seen this expressed in a variety of ways, no one presented it more clearly than one client I worked with in August when they showed me their SDLC: Design > Build > Deploy > Govern They had successfully avoided the first flawed perspective by recognizing the importance of including governance from the very start. At the same time, however, they fell into another trap in relegating governance to more of an administrative function at the end of the project life cycle. Governance should be a consistent thread throughout the entire project life cycle. Enforcing policies, applying best practices, and ensuring that services and their related artifacts are properly documented begins with the service design phase and continues until service retirement.

Alternative perspective: Lean Governance
Lean governance represents a mindset in which governance is applied as needed. Implement only as much governance as is needed and constantly monitor the environment in order to tweak the degree of guidance and oversight. Governance shouldn’t be implemented as one or more powerless committees, nor as heavyweight bureaucracy. Governance should be focused, lean, and ever-present. Early in the adoption of SOA, governance should be minimal. It could be as simple as a requirement to be WS-I compliant and maintain service contracts for each service. Over time, the governance policies, processes, and procedures, as well as the corresponding infrastructure can be grown incrementally along-side the maturing of the service oriented enterprise. Finally, this governance should be applied throughout the project life cycle. Best practices identify three governance gates - design-time, change-time, and run-time. These three gates serve as check points to ensure that service design, development, and run-time behavior are consistent with enterprise goals and stated best practices.

In my experience, governance is crucial to any significant organizational change and service orientation is no different. I don’t believe that governance has to be at the extremes (powerless committees vs heavyweight bureaucracy), but instead can and should be focused, lean, and ever-present. Initially you don’t need very much governance, but it is much easier to start with an expectation that governance will be present and grow it incrementally than it is to add later down the line. Governance should be planned from the start and it should provide context for the entire project and program life cycle.