Failure to implement and adhere to SOA Governance

Today we want to talk about a key reason that SOA does sometimes fail - lack of governance. I have asked Mervin Chiang from Leonardo Consulting to blog this for me. Mervin is one of Australia's leading BPM/Governance experts and has great insight into both the technical and business aspects of SOA/BPM projects. Over to you Mervin...

I have been a Business Process Management (BPM) practitioner for 5 years and in the last 2 have been working with companies to “Automate Business Processes” using Oracle Middleware technologies. You see, I try not to call it SOA, seeing that it has been getting a bad rep recently (see: SOA is dead). I see many similarities in both acronyms’ history…

The Birth – BPM, as a core concept, started very early and was not even called BPM. Someone smart (e.g. see: Scientific Management) realised that people work, and their work can be “chopped” up and studied and strung together... (A.k.a. “workflow”)

The Craze – Then we had Business Process Reengineering (BPR). “Let’s toss the organisation’s core processes in the air and see how it lands!”… “Ah, it landed well! Let’s spend money and lots of time to implement these process changes!” Meanwhile in the IT world the CIO goes… “Let’s toss our IT landscape in the air, screw on all web services in every hole and see how it lands! Then document it…” (A.k.a. “Enterprise” SOA)

The Epiphany – The statement: “Oh no! There are too many moving parts. How do we handle them?!” gave rise to BPM (keyword: Management).Much literature out there that talks about how SOA has failed or how we can save it, all point to the same realisation from the IT paradigm: SOA needs management… (A.k.a. SOA Governance)

Just as BPM, discusses the lifecycle of processes, we see the need to understand the service lifecycle. Also like processes, there are different “layers” of services (granularity). All These layers make up a service portfolio. So, how do we manage all these moving parts? In his article, Mike Kavis talks about design-time and run-time governance requirements. In addition to these two views I see the need for “management-time” or “continuous-improvement-time” governance.

At one of my recent customers, we’re using Oracle Fusion Middleware tools to achieve such an ecosystem. I call it an “ecosystem” or “platform” as this cannot be successful if only taken from a project level context (See Saul’s article on Viewing SOA as a project instead of an architecture).

Let’s start bottom-up shall we?

Oracle Service Registry (OSR) handles all the run-time knowledge of the services we have in the organisation’s landscape.

Oracle Enterprise Repository (OER) has knowledge at design-time of impact if one service, application system or business process were to change. It also talks to the OSR and has knowledge of usage to report on reusability of services.

Business Process Analysis (BPA) then uses information from the OER to build its catalogue or library of objects to aid during both design-time and continuous-improvement-time. We will use the BPA’s repository in various ways:

· To graphically represent the components of the Enterprise Architecture (EA)

· To launch process improvement, redesign and reengineering projects in alignment with the organisation’s strategic plan

· To do BPM itself

· To execute process automation projects (BPMN to BPEL, direct requirements implementation)

So, if we were to work top-down:

1. Identify/discover requirements to improve, redesign or reengineer using BPA and start a project. BPA gives you an enterprise or cross-project view of the organisation.
2. Analyse and (re)design your solution with the aid of BPA and OER. Run simulations in BPA, and undertand technical impacts with OER.
3. Build and deploy your solution into OSR. The service catalogue will be synced in OER and BPA for future projects.
4. Monitor performance to start round 2 of the lifecycle if needed (go back to point 1)

We’ve just talked about the tools that help us in this governance journey. There are also the challenges of people and process. The processes defined to do SOA governance are just as important as the people who will be carrying out these processes. In the customer example I mentioned earlier, we’ve used the publishing capabilities of BPA to communicate this to all roles involved in the business process and service lifecycle as an educational resource. We didn’t name it “governance” of course!

Ultimately, SOA governance as with anything; implementing software, BPM, building a house, getting married or having an operation, it’s the method of implementation itself and not the technology that determines success or failure. Just because I bought a shiny new scalpel doesn’t mean I am qualified to operate on you to take out your appendix!

Thanks Mervin for you valuable insights into how we should put Goverance at the core of SOA/BPM projects. However I will ensure that I don't end up at your surgery for my next operation! If you are interested in finding out more about the best practice of Governance and BPM technology you should check out Leonardo Consulting's Process Days Seminar in Sydney August 5-6.