SOA Governance@work

Writing in his ebizQ SOA in Action blog, Joe McKendrick quotes Forrester's Larry Fulton in making an important point about SOA Governance:

Successful SOA projects seems to have one thing in common -- they were developed on an incremental basis. The same principal extends to SOA governance itself, says Larry Fulton, senior analyst at Forrester Research. "You can really go too far too fast and end up with processes that are very overweight considering what you're really doing with them. An incremental approach is probably a good way to go. The big pitfall to avoid is building out a lot more governance than you need given where you are in your SOA journey."

In taking that incremental approach to avoiding "overweight" SOA governance, it's important to apply the right governance model. One of the posts I migrated from my old BEA blog addresses that issue:

The right SOA governance model for any organization depends entirely on the specific goals and the specific environment: available tools; skill levels; general level of SOA education, maturity, and commitment; and a plethora of other factors affecting the people, processes, and technologies involved in the SOA.

Read Joe's entire post: ebizQ Presents Service Oriented Architecture (SOA) in Action Virtual Conference Blog

A posting in Joe McKendrick's SOA in Action blog, and subsequently covered by my colleague Bob Rhubart, quotes Forrester's Larry Fulton about taking an iterative approach to SOA Governance, much the same way SOA projects have been approached.  Specifically, the blog quotes Larry as saying

The big pitfall to avoid is building out a lot more governance than you need given where you are in your SOA journey.

One of the most common challenges to SOA Governance success is adoption of the governance process.  Taking a big bang approach will undoubtedly lead to low adoption, as you tend to put too many control mechanisms on a culture not quite ready to accept them. 

Larry is correct, an iterative approach to governance is the right way to go.  Start with your most immediate concern and grow from there.  As your SOA expands, new challenges and circumstances will present themselves, so your governance program needs to evolve as your SOA evolves.  As one customer I recently spoke to put it, a key to governance success is knowing ahead of time that you're going to have to reinvent your governance program as your understanding and maturity of SOA progresses.  Don't let one evolve without the other.

One word of caution about this though.  Don't be too tactical.  You want to address your immediate concerns, but not without an understanding of the longer term goals and objectives.  Doing so will help ensure your governance program can evolve with your SOA. 

Read Joe's entire post: ebizQ Presents Service Oriented Architecture (SOA) in Action Virtual Conference Blog

A recent posting by Lucas Jellema in his AMIS Technology blog covers some of the value that the Oracle Enterprise Repository (OER) brings to SOA Governance solutions and how vendors like BEA and Oracle have evolved their governance positioning.  Toward the end of his blog, Lucas points out that OER could very well be used for managing assets that may not fall under the SOA domain. 

It struck me that most of what applies in terms of Governance to SOA assets, also applies to other assets in any software engineering process. Trying to manage reusable components for example or even implementing a good maintenance approach for a non-SOA application is a tremendous challenge, that has many parallels with SOA Governance. And to some extent could benefit from applying a tooling infrastructure such as provided by the Enterprise Repository…

One of the big challenges that SOA has tried to overcome for years is equating SOA to web services.  In the past, governing SOA assets has been about gaining visibility and control over reusable assets to establish the notion of trust amongst consuming applications. As Lucas points out, reuse cannot occur without trust that the service you are reusing won't negatively impact your application. 

Oracle believes that if you want to properly govern your SOA, you need visibility and control over the end-to-end spectrum of assets your SOA is interacting with.  Afterall, SOA Governance is an extension to existing IT governance and enterprise architecture governance, so why shouldn't the same apply to the assets?

OER provides the capability to gain visibility into and track relationships of all the assets that effect your SOA.  Services must interface with something on the backend, so you need visibility into what those underlying components are, whether they be legacy mainframe artifacts, underlying applications, custom code, etc.  You also need visibility going up the stack, including the consumers that are utilizing those services, what policies apply, etc.  Having this end-to-end visibility gives you greater ability to manage change more accurately.  Afterall, change doesn't just happen at the service level.  If an underlying application component changes, you need to know how it will impact everything all the way up to the consuming process of a service interfacing that application component. 

Lucas is correct.  As a side effect of providing this capability, you can expand the role of OER beyond just SOA Governance related issues. The same capabilities and benefits that are provided for SOA related projects can also be applied on non-SOA related projects.  That is one way in which Oracle provides support for you to truly treat SOA Governance as an extension to your existing IT and EA governance programs. 

Read Lucas's entire post: http://technology.amis.nl/blog/?p=3369

In addition to the invitation-only SOA Customer Advisory Board (CAB) event next week (Thursday, 9/25/08) at Oracle OpenWorld, the Oracle SOA Governance product team has announced that it will host a special SOA Governance Break-out session. This breakout is open only to end-user customers of Oracle's SOA and SOA governance products, and will be of particular interest to those using products formerly under the BEA brand.

Customers interested in participating in this breakout should contact Cathy Lippert (email) , Director Product Management for SOA Governance.