Monday, 11 May 2009

My Take on Governance: People, Process and Tools

I was reading Dave Berry's blog on how to achieve the ROI on SOA by implementing Oracle SOA Governance tooling. Dave starts with a simple example of how customers - using Oracle BPEL PM - have no clue as on how to achieve reuse. In his blog he states that 'one of the main values of SOA Governance is to deliver savings by enabling this reuse of existing services'. From there on he moves towards governance tooling, enabling visibility, control and monitoring of all SOA artifacts.

My first response was to point out that tooling for reuse is nice, but there's also something about culture. What about the 'not invented here' syndrome? After that, i started thinking (well done, Dave, you got me thinking!) about the elements of SOA Governance. To me governance is about people, process and tools. People, because it's all about the professionals on the job and the need to govern their actions to make sure the right things happen at the right time. To do that, you need a governance process in place that ensures that all artifacts are reviewed and judged to be either confirming to the architecture, or rightly not so. But, that should be done, before anything get's built! Finally it will really enable to process and the people to have good governance tooling available. For to be sure: we do need visibility, control and monitoring to enable reuse. And we do need reuse to reap the major profits of SOA.

For instance, I know of a customer case where the people involved were SOA adepts. However, they decided not to use an existing service, even though it was accepted by the Architecture Board. The main reasons being, that the service was developed by a different department, it's quality and availability could (maybe) not be guaranteed and they could probably do a better job. Unfortunately, this happened not just once, but four times for the same artifact. The company ended up having 4 almost equal services doing almost the same thing. Being able to govern this process would have saved them 3 times building the same component! Tooling in itself would probably have made this problem more visible, but would not have prevented it.

So what are the typical governance processes you see being advocated either internally or by vendors? Let me know!


  1. Hey Mike,

    Polling some colleagues and memory of customer engagements, I came up with the list below. I’ll have to think about it some more though to sort out.

    -Establishing a Governance control board identifying key decision makers, how to engage them and the process to measure and report success or failures.

    -Asset lifecycle management processes for approval and promotion of assets

    -Developing an asset consumption process, i.e. who gets access to what assets, in which environment and how?

    -This isn't necessarily a process but it is important to have a plan in place to automate any or all of the above whenever possible


  2. I might add that building trust between departments is critical for building a culture of reuse. One of the ways to build this trust is to publish the recent quality of service metrics for the services or components you want reused. This is where tooling can definitely help.