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!

Oracle Service Bus Explained

There's a lot of confusion towards the positioning of the Oracle Service Bus. In this post I'll try to clear up the issue as best as I can.

First of all, Oracle has already shown a convergence of BEA and Oracle FMW. This will continue even stronger in the upcoming releases, 11g in particular. The strategic platform as it will be introduced with 11g will consist of two main components: Mediator and Oracle Service Bus.

The mediator is an intra-composite mediation component within an application. It is responsible for brokering communications between components that make up a composite (conform Service Component Architecture - SCA). It will enable transformation, routing, event delivery and payload validation. The mediator is almost exclusively based on Oracle ESB (yes, the old Oracle Enterprise Service Bus).

The Oracle Service Bus (OSB) provides service bus capabilities for the entire company, again including standard functionality as transformation, routing, event delivery and payload validation. It's main function is to decouple intra-application communication from inter-application. Endpoint changes will not affect the internals of composite applications. The OSB is based on the Aqualogic Service Bus, augmented with key features from the Oracle ESB, especially JCA adapters, DVM, X-ref and JDev based design-time.

In the long run, I expect the distinction between these implementations to disappear, but I do like the current setup, as it differs between development of application and integration. I wouldn't be surprised to see this pattern appear more.