SOA Approach .. Top Down or Bottom Up..

In his blog, Grady Booch (of UML and Rational Fame) talks about 'how Bottom Up approach for SOA can be a disaster'.

"Going back to the A part of SOA, the issue then is one of abstraction, separation of concerns, and all the usual fundamentals of architecture. I've seen some folks suggest creating an SOA from the bottom up: look at a silo, identify the potential services, and publish them, then weave a system together from them. This is in essence technology first. In my experience, this is a recipe for disaster and/or serious over-engineering. You've got to start with the scenarios/business needs, play those out against the existing/new systems, zero in on the points of tangency, and there plan a flag for harvesting a meaningful service. These styles, and their resulting costs/benefits, are rarely discussed. "

Following things should be kept in mind while deciding on the approach for SOA

1. It is business first and technology afterwards.
2. Do not think SOA as the panacea of all Business and IT alignment issues.
3. Keep it simple... Do not over-engineer.
4. Understand your business, existing IT assets/systems before going for something like SOA

Taxonomy and Ontology..

Recently I attended a session on "Architectural Knowledge Management " in a TOGAF conference, where I learnt about the KM concepts like topic maps, concept maps, ontology et al. Of course I was aware of mind mapping as a technique...But, I was quite impressed by the amount of research that is going on in this space...

And here it is again.....while doing some research on Service Registries/Repositories I bumped into Ontology once more...

Do you want to store the relationship between your services and their meta data, store some of the service properties like certain service qualities, say, minimum and maximum service delivery times; may require certain payment obligations, say, advance credit card payment, rather than only classifying them only into categories and sub categories??

Of course, that would be of great help for the consumers in finding services based on what they exactly want. They would also know the service dependencies (how the services are related).

If the service registry is expected to be the management backbone of an Enterprise SOA, then the they should support these features.. Does any of the Service Registries in the market or the open source space have support for this..May be...?? I could only find one of them clearly talking about it..

http://ebxmlrr.sourceforge.net/tmp/Registry_Capability_Matrix.html#ebrr_ontology