A long standing debate in the SOA community about top down vs. bottom up approaches to SOA resurfaced recently, after open source ESB maker MuleSoft announced the release of a management console said to support their bottom-up approach to SOA management philosophy.
Rob Barry from SearchSOA gathered some opinions about bottom-up vs top-down approaches:
When building out a SOA, a bottom-up governance approach focuses on integrating services around individual ESBs that can be quickly assembled. The approach has been criticized for requiring excessive updates and rework later on. Meanwhile, an opposing "top-down" governance approach involves extensive planning and strict policy enforcement. This approach has been faulted for taking much more time to produce results.
The opinions gathered on the post agree: the bottom-up is a good approach to start, basically when the main objective is to integrate. They also agree the top-down approach requires much more business involvement. They conclude that deciding which strategy to use will depend on the business-IT relations.
Barry’s post fired a question in ebizQ with few but interesting responses. In a response to ebizQ's question, Avi Rosenthal distinguishes both approaches based on what you are building:
SOA is architectural style. Building architecture is Top-Down and not Bottom-Up. Web Service, sometimes wrongly defined as SOA, are technical. Web Services are build Bottom-Up. Building SOA Bottom-UP is a wrong approach some times called ABOS (A Bunch Of Services). If you build SOA Bottom-Up probably you will end with a lot of redundancy and no architecture at all. However, the result of building SOA only Top-Down could be perceptual Architecture building with no run time artifacts, so some SOA efforts should be Bottom-Up efforts. To sum up: Initially SOA is a Top-Down approach but pragmatic approach requires mixing Top-Down approach with Bottom-Up approach.
In another response to the question, Michael Poulin says consumer-centric nature of SOA forces the top-down approach:
If you start constructing service from what you have - bottom-up - you have a very high risk to end up with what you have, not with what your consumers need. SOA is the consumer-centric business-oriented architecture. Starting with the consumer needs you do not have a chance to avoide the top-down. This is the start point, always. However, in the next step, you better assess your capabilities, i.e. look at the consumer needs from your bottom laying recources.
This debate is not new. Back in 2005, John Crupi posted that SOA was a Business-Driven Architectural Style and as such, it must be top-down to be successful:
And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure.
Back then, other voices like Bill de hÓra’s reaction post went against the idea of a "top-down or fail principle":
The difficulty with a solely top-down approach is that there is no top. SOA systems in reality tend to be decentralised - there's no one point of architectural leverage or governance, no one person who's going to be able to say and then enforce "a decision in ten minutes or the next one is free".
This debate has been going on for years. At the end of the day, it seems that some tool vendors have chosen the bottom-up strategy.