Top Down or Bottom Up SOA?

This question has been plauquing me for a while. When attempting to deliver to an enterprise service-oriented strategy is it better to do bottom up governance or top down? Here's what I mean by this.

1. With bottom up design governance you work to have any line of business application deliver services at the time they deliver their application. Through the conceptual design and envisioning of this application discrete business functions are found and services can be delivered in front of those functions to provide enterprise re-use.

Problems: First of all when delivering services for your own line of business application you have very little visibility outside of your application silo. Finding the sweet spot for how fine-grained or how coarse-grained these services should be is almost impossible. Invariable an application will build exactly what it needs to deliver the functionality to the business in the most cohesive way for their users. This does not necessarily translate to modular loosley coupled 'building block' services. This lack of visibility also leads to other issues, as an architect you will start to struggle to foster adoption because the vision of what you are delivering is very cloudy.

2. With top down SOA governance you look for opportunities to deliver large enterprise functionality that may span multiple projects. For example an online retailer might want to build a workflow for processing orders. This workflow might plug into services in your accounting domain, it might call an external vendor to help procure product via services, it may use services in your warehouse to start the shipment process, the list goes on and on.

Problems: These opportunities are few and far between and often require revisiting deep rooted legacy components of an architecture. You will also often find yourself trying to help facilitate the mental leap from mainframe batch processing to online dynamic asynchronous workflows ....yikes! In the end though if you find these core business services you are likely going to find the functions that need to provide enterprise extensibility and availability but they are the most expensive and risky to re-architect.

In closing, I know the easy answer here is we need to do a little bit of both. That just seems very difficult to sell as an architect. Somewhere between the WS-Everywhere strategy (Joe McKendrick has an interesting take on thishttp://www.webservices.org/weblog/joe_mckendrick/the_rise_of_the_jbows_architecture_or_just_a_bunch_of_web_services) and the we'll be SOA enabled by the year 2020 strategy, there lies a happy place. My hope from this post is that I can hear what some of you are doing to dry and break through these very polarized approaches.

[3036 byte] By [Mr.SOAPitStop] at [2008-2-7]
# 1

As you said on an enterprise level you'd have to do both

I approach is try to go top-down first, to create a roadmap of where I see the whole organization going and then keeping the vision in mind be pragmatic and go bottom-up with techniques such as aggregation services, exposing existing LOBs as services etc. to try to evolve the enterprise in the right direction.

Arnon

ArnonRotemGalOz at 2007-9-8 > top of Msdn Tech,Architecture,Architecture General...