BT

The Top-Down vs Bottom-Up SOA Debate Revisited

by William Martinez Pomares on Jul 19, 2010 |

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

RESTful web services and resources as bottom up building blocks by Juergen Brendel

The advantage with a bottom-up approach is that you can use the exposed end-points as building blocks for functionality and integration tasks that you didn't even think of when you started out.

This is one of the core aspects of the RESTx project, which makes it really easy to create RESTful resources and web services out of data access, processing and integration code.

To see how those RESTful web services can then act as building blocks for integration code (which in turn can also become such a building block), take a look at this example here.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT