The world of SOA Governance according to Oracle – Introducing the Enterprise Repository

Without solid governance, a successful application of SOA seems out of the question. That much has become clear in recent months, perhaps years. And it struck me that most of what we are saying about SOA Governance and management of (the life cycle of) services and service related artefacts, really applies to all software components meant to last longer than say three months, especially those we aspire to reuse. So while the topic seems to gain center stage only now in the context of Service Oriented Architecture, it really deserves that place in the spotlight outside the SOA scope as well.

One of the more interesting sessions during the Oracle SOA Partner event last week was on SOA Governance. Various reports show that the main threat to success of SOA implementation is stated to be "lack of Governance". One of the reports says "SOA governance provides organizations with the processes,
policies and solutions/technologies that can help to manage
increasingly complex SOA deployments in an effective and efficient
manner." 

The success of SOA lies to a large extent in achieving service reuse.
(without reuse, SOA become nothing but an expensive, heavy handed, point to point integration approach). For services to be reused they need to be visible (findable) and trusted. One of the main objectives of governance should be to establish trust in the SOA assets – including service related artefacts such as WSDL, XSD, SLAs, policies etc.

Not too long ago, companies such as Oracle and BEA claimed that all you would need for effective Governance is a Service Registry, such as the one from Systinet, implementing UDDI 3.0, that both these vendors were offering. Then BEA bought Flashline and with its Enterprise Repository product changed its tune completely. Now Oracle purchased BEA and started integrating the mutual product portfolios, it changed its tune in turn. And Governance now is much more than making services discoverable through UDDI. And of course an Enterprise Repository is exactly the thing we all desperately need…

Falk Kukat – who presented this session in a very inspired way – pointed out many things. The success of SOA lies in both Design Time and Run Time. Design time: make services discoverable, establish trust, set up policies, help track dependencies and assess impact to manage change, support life cycle management etc. Run time: make services dynamically bindable/findable, apply and enforce policies, monitor service usage and report on SLA execution.

One of the first steps in getting the Enterprise Repository going according to Falk is building up a Taxonomy – a meta data structure of categories and topics that services will be related to. Such a taxonomy should make it easy to find services in a certain business area or domain. I was wondering whether something like a ‘tagsonomy’ building on the social networking concept of tagging things would be a useful addition to this more formal taxonomy. Falk concurred and mentioned this being planned for a future release.

Another important element in building up trust is providing insight in the (re)usage characteristics of services and providing some sort of a rating system where by current users indicate their satisfaction with a particular service.

Here an example of how a service is presented in the Enterprise Repository:

An interesting piece of information recorded with a service is the expected effort to make use of the service and the effort saved by reusing the service vs. implementing the functionality. All consumers of a certain service are expected to record this information, to provide useful insight for future users of the service.

At runtime, the ER will work with a or provide services to a number of other products, such as the Enterprise Manager SOA Management Pack,the Web Services Manager and the Service Registry. Service execution engines will use the combined stack to dynamically locate service end points.

An example of the impact analysis provided by the Enterprise Repository:

All SOA assets

One of the important messages of this presentation was that SOA Governance does not revolve around Services alone. There are many more artefacts in a SOA environment that could do with a little governance (life cycle management, dependency analysis, discoverability etc.), such as Policies, Schema Definitions, SLAs, business requirements, standards and best practices, etc. Also note that planned services should be documented as well – to avoid services being developed in multiple projects at the same time.

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… Well, just a thought for now. I need to know more about the ER before jumping to conclusions.

Note: the ER at this time does not seem to support the financial management side of things. For example: the cost of developing and maintaining a service nor the costs involved in calling a service are supported by the ER. Billing & invoicing based on SLAs and actual Service Usage and SLA violations is not (yet) part of the product. I do not know of any products that do provide automated support for this.

AIA Business Service Repository

It is interesting to see how the best elements of Enterprise Repository on the one hand and the Business Service Repository that Oracle provides as part of AIA on the other are going to be combined. BSR seemed to offer some built in facilities for dealing with the specific structure of the SOA services catalog according to AIA with a number of powerful search facilities (leveraging the EBOs – Enterprise Business Objects – and ABCS – the connector services) and supporting impact analysis and dependency tracing.  In the recent AIA release, the BSR was also linked to Business Process Models – the top three conceptual levels as defined in Oracle BPA. According to the Oracle representatives, this is currently "under investigation" – no plans or commitments yet.

Resources

BEA acquires Flashline

Oracle SOA Governance Blog (by Michael Stamback)

OTN Enterprise Repository Home Page