11/20/06

SOA Governance Granularity

Are you excited yet? I'm sure the title of this post has you chomping at the bit... Seriously, now that the industry seems to have figured out that there is a difference between design-time and runtime governance, we now need to start looking at the different levels of governance (or governance granularity) within the design-time perspective. As I have been discussing this topic with our customers and prospects, I have come to the conculsion that three levels of design-time governance should be taken into account by organizations pushing forward with SOA:

• portfolio governance: what initiatives, projects, and deliverables (both services and applications consuming those services) get funded and the tracking of those projects' progress against funding and timeline objectives
• architectural governance: ensuring that the services and applications developed under SOA initiatives conform to the organization's business and technical architectures and best practices
• SDLC governance: the day-in day-out application of SDLC best practices (e.g., unit test before code promotion, peer review of code changes, establish an SCM system with code promotion levels) when developing services

Most people don't think of SDLC best practices as governance but in fact it is a great example of fine-grained governance within IT. When defined properly, SDLC governance serves as a natural feeder to the "mid-level" architecture governance that is typically established at key SDLC checkpoints (e.g., requirements complete, design complete, preproduction). This architectural governance in turn ensures that IT projects stay connected to the objectives of their stakeholders as established by the portfolio governance activities of initiative and project prioritization (which presumably connect back to core business needs).

Portfolio and SDLC governance have been around for quite some time, and a number of tools (APM and PPM tools at the portfolio governance level, and the traditional SCM, requirements management, defect tracking, etc. tools at the SDLC governance level) exist to support these governance activities. What SOA brings to the table because of its loosely coupled nature is the increased importance of architecture governance -- it's back to service spaghetti if organizations don't effectively apply architectural governance over their service production and consumption activities.

SOA also should force behavioral change at the portfolio governance level -- breaking away at least partially from application-centric initiatives and recognizing the need to support and fund service production projects that span across applications. This hurdle can be a significant challenge for IT organizations used to funding and optimizing at the application level, but if those organizations don't make the leap to fairly evaluate and prioritize cross-application activities, they will never truly build out an SOA but rather they will build old siloed applications using new Web services technology.

Jeff Schneider's November 11th post makes some similar points on this topic. He breaks up the governance world into portfolio governance, process governance and asset governance. I see process governance and asset governance as different facets of the architectural governance level, with asset governance activities also leaking down into SDLC governance. However you decide to slice it, though, you need to recognize that an SOA will not just build itself. Without governance SOA simply turns into ABOS -- A Bunch Of Services...