BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The Top-Down vs Bottom-Up SOA Debate Revisited

The Top-Down vs Bottom-Up SOA Debate Revisited

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
Style

Hello stranger!

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

Get the most out of the InfoQ experience.

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

Community comments

  • RESTful web services and resources as bottom up building blocks

    by Juergen Brendel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

BT