The World of SOA: Laundries, Legos, and Home Construction

As an architect explaining SOA concepts to developers of traditional enterprise applications, I encountered various analogies comparing the concepts of SOA to LegoTM blocks, which are actually considered by some experts as being misleading and superficial. Therefore, recent analogies by Antony Reynolds and Richard Veryard comparing services to a laundry, brought back memories of yet another analogy I used a couple of years ago - comparing business process driven SOA to home construction.

image

Let’s pretend you want to build a house from the ground up. You hire a general contractor, who is responsible for the overall execution of the project. The contractor locates a provider of concrete and makes a phone call to ask for estimates and the schedule for pouring the foundation slab. Next, the contractor will call and coordinate the lumber delivery, following which the framers can come out to do their job. In parallel, the contractor gets estimates from electricians and has to decide on the one that not only has the best rates, but also someone who is certified as per city code and who can meet the schedule. And finally, the roofers, plumbers and painters are arranged to complete the job.

Let’s put this in the perspective of SOA technologies. The general contractor is a BPEL Process, whose purpose is to orchestrate all the Services from disparate heterogeneous systems. The services in this example are the different actors – the concrete provider, foundation company, lumber company, framers, electricians, roofers, plumbers and painters. The contractor found the providers by searching the Yellow Pages (UDDI) and found the phone listing (WSDL); communicated by voice (XML) over the phone (standards based Web Service) in English (Standardized Semantics). He got quote and availability information, without having to really understand much about the inner workings of the concrete business (Service Abstraction), and as long as the provider abides by the contract, the contractor does not care who the actual electrician is (Service Virtualization).

I found that this metaphor helped many a legacy developer understand the complex SOA technologies better than the overly simplistic LegoTM blocks analogy. However, as recommended in the other blogs too, it is best to not push the metaphor too far. Once the SOA basics have been understood, its purpose is served; and no other simplistic metaphor can then explain every one of the prolific WS-<insert your favorite noun here> specifications.

UPDATE 07/30/2008: Richard points out a sequel to his laundry post: Services Not All Like Laundry. And just when we thought we had it all sorted out :)

Comments:

cool explaination for complex concept

Posted by Arun on July 29, 2008 at 05:51 PM PDT #

Your example is a good one, raising lots of issues about the way different types of service (delivering materials, working on the materials, certifying that the work satisfies building regulations) must be orchestrated. How do the electricians and the plumbers and the painters avoid getting in one another's way - do they talk directly to one another, or only via the general contractor? Thanks for mentioning my post Services Like Laundry. For the sake of completeness, you might also want to mention the sequel Services Not All Like Laundry.

Posted by Richard Veryard on July 29, 2008 at 06:05 PM PDT #

Great analogy, and a much better representation of reality than our friends the lego blocks. Though provoker: in the construction industry there are building and electrical inspectors tasked with ensuring the actual implementation meets regulatory requirements -- to protect the safety and welfare of those using the building. Is there an equivelant role in the SOA analogy? If so, where does that function lie?

Posted by Beth on July 30, 2008 at 02:19 AM PDT #

@Richard: Thanks for the tip on the sequel, I have updated the post for completeness. Regarding how the providers communicate, in real life, the plumbers and painters are being coordinated by the general contractor and they don't want to take the responsibility nor the liability of taking any decisions with respect to a peer service provider. Similarly in a best practice SOA environment we recommend that the service providers avoid these point-to-point integrations with each other and instead, are orchestrated via a business process flow (called Enterprise Business Flows or EBF in AIA terminology). @Beth: The closest equivalent role to the auditor of regulatory requirement that I can think of in the SOA world is the Enterprise Architect executing as part of the SOA Governance responsibilities. Similar to the city code requirements for electrical work, in software there are similar regulatory requirements e.g. SOX compliance; not to mention other organization-level best practices that need to be audited for compliance. A proper SOA Governance strategy needs to be in place to ensure that the roles of the architects are identified and that the results of the audits are tracked.

Posted by Rajesh Raheja on July 30, 2008 at 06:20 AM PDT #

Great metaphor, you have mentioned in one your replies the city code requirement for electrical work. This leads to another metaphor around the services with in an organization: the city planning metaphor I shared some of my thought around this in this article.

Posted by Gabriel Bechara on August 01, 2008 at 05:59 PM PDT #

Nicely explained... great post..... thank you...

Posted by Custom web application development on October 06, 2008 at 02:09 PM PDT #

The architect is the responsibility to explain about the construction. O your post I gathered a lot of information about it. it is very useful for the readers because it is informative and I really appreciated your blog. Thank you.
<a href="http://www.kbhome-quality.com/">KB Custom Homes</a>

Posted by Shirley Chisolm on August 13, 2011 at 05:55 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

News, views and implementation best practices from the Oracle Application Integration Architecture team.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today