Is it smart to start SOA at the top?

Think 'business services,' not 'Web services,' says one industry expert.
Written by Joe McKendrick, Contributing Writer

Here's some more grist for the start-small/start-big debate that I covered in this Weblog last week. In a report in ComputerWorld, Bobby Soni, chief strategy officer at Webify Solutions Inc., says people should be thinking of SOA from the top-down, not from the bottom-up. "IBM, Oracle, BEA, SAP and others are going at the SOA problem from the bottom up," he says. "You need to go from the top down." According to the write-up, Soni says these vendors "are too focused on stringing together lots of interrelated components, which is good technology, but not necessarily good for your business."

Think 'business services,' not 'Web services.'

Others say, however, it's better to think bottom-up, at least initially -- then move to top-down as the business grasps the potential of SOA. David Chappell (the SOA consultant, not the Sonic Software David Chappell or the comedian Dave Chappelle) said that for many organizations, a bottom-first, then top-down approach is more palatable.

Brent Carlson also weighed in on this question in my previous post with this perspective: "The key is to pick complementary projects with enough 'interesting' overlap to drive the definition of a set of common services. Neither the 'boil-the-ocean' approach of 'transforming the enterprise' (otherwise known as the Enterprise Navel-Gazing Open for Business Analysts) nor the project-centric 'put-your-blinders-on-and-just-deliver' mindset are effective ways to build out an SOA in a real-life enterprise. Looking for shared opportunities and building momentum upon successes with those shared opportunities is the only way that most (if not all) organizations of any size will be able to make SOA work."

Brent provided his perspectives on the top-down vesus bottom-up approach in a post last year. "Some enterprises see the need for governance and some level of top-down structure earlier in this progression than others; other organizations have to reach the point where they are 'victims of their own success' with many overlapping services and no clear guidance as to how to control future service development before they determine that some level of architectural oversight is needed."

Chappell also observed that making applications service-oriented from the get-go initially makes life easier for IT developers and architects, but as the practice catches on, "the advantages of the top-down approach will become clear. You'll hunger for a broader view of your organization and its business processes. Given this, organizations start bottom-up, then attempt to take some kind of broader view once they've gotten part way down this path."

Editorial standards