Growing Pains

It’s not hard to build an SOA. That is, technically. Once the domains are clear and the services defined, it’s kinda easy to implement. Sure, there’s lots of work to be done, but no rocket science. But, what happens after you’ve done your Proof of Concept and your first and maybe even your second real-life project?

By then you’re sitting on top of a lot of services, of different granularities and of different types, all mixed together. If you’re lucky, the semantics are still correct (no mismatches yet!). Maybe you even have an ESB running. Slowly but surely the need for additional tooling becomes evident. How are you going to manage this whole environment? How are you going to make sure the next project reuses the generic services that have been so painstakingly defined?

A logical first step would be to get a UDDI, where you can at least register your services. Usually this is not a tool that you would implement in your first project, as you do not yet have the need for location transparency or runtime service discovery. That may change, however. But the main reason for the introduction of a UDDI is the discovery of services: what are the reusable assets my organization has?
If you grow even bigger and you get more and more services, a UDDI will not be enough. You will also need to implement a Service Life Cycle Management environment.

Managing a handful of services (say up to 50) can be done manually, without the need for advanced tooling. As the people involved know about the upcoming changes and are involved in bringing the changes into effect, you can manage a whole lot of services. But .. up to a point. There will be a moment in time when you will have to formalize the procedures and support those with tooling. This is where a Service Repository comes in.

What will a Service Repository bring you? A lot! First of all it will give you a tool for implementing Service Life Cycle Management, as it will support discovery (through visibility), impact and depency analysis, monitor compliance (assets, policies & standards), collect metadata, automate lifecycle staging, etc, etc. What I really like about a repository is that it will become the central focus of development, test and deployment. In the repository you will find all the information you will need, from service contracts, SLA’s, documentation, dependencies, tests, policies, service usage (requires closed loop data gathering). Your repository will be the single point of truth in your SOA!

Unfortunately there’s not many repositories around. According to Forrester (The Forrester Wave: SOA Service Life-Cycle Management, Q1 2008) there are just 3 good repositories available at the moment: Oracle Enterprise Repository (rebranded from BEA AquaLogic Enterprise Repository), Software AG’s CentraSite Governance Edition and LogicLibrary’s Logidex.

Oracle Enterprise Repository, formerly known as BEA ALER, will be rebranded and integrated into the Oracle SOA Suite as well as certified against the Oracle BPA Suite. This is one of the reasons I’m very happy with the BEA acquisition by Oracle. OER is by far the most sophisticated repository around and will be making my life a lot easier!