Lego has been used many times as a metaphor for SOA. I first came across it during a vendor presentation and was not particularly impressed by it as I immediately saw some shortcomings in the metaphor.
After thinking about how I would explain some of the benefits of SOA like agility and loose coupling I decided Lego might be fairly descriptive after all. I ended up doing my own presentation on SOA at a planning session complete with blocks from my kids' Lego set. I felt this was one of my more entertaining presentations and it helped get across some good messages. I plan to post a transcription of the presentation on this blog. As it was a "show and tell" presentation I need to get my digital camera fixed first.
When I did this talk I did not realise the Lego metaphor for SOA was so common. Google brings up many hits that relate the two. It is sometimes handy in IT to show something tangible to explain our concepts. What we build is never clearly visible and how we build it is often very abstract.
Gian Trotta does a good job of looking at this metaphor.
These components are loosely coupled code components that represent well-defined and self-contained business services. “This is important. Loose coupling is a design criterion that enables agility. It can't depend on the context or state of other services,” she noted.The business services become part the overall service oriented architecture (SOA). “Service-oriented architectures require well-defined interfaces and this is the evolving role of Web services. Finally, we have a standard interface that everyone's agreed on, enabling service-oriented architectures to take off,” Gold-Bernstein added.
I do not think much of the Swiss army knife metaphor though. For me SOA is not a grab bag of utilities that can be applied to any problem.
Jason Bloomberg was the source of the above illustration (which is not actually Lego, see footnote) but covers the whole Lego issue pretty well.
As with any analogy, the parallels only go so far, but with Lego blocks, we've found four positive salient characteristics -- and four negative ones
Some of Jason's points identify problems with Lego rather than problems with Lego as a metaphor for SOA. He raises the issue that Lego blocks are so unbreakable that they get passed down the generations so new generations do not buy enough new blocks. This is why the new Lego has so many different parts and looks more realistic. The Lego company is trying to get kids to build it and put it on display rather than reuse it. I see this as a strength of the Lego metaphor (or 'analogy' as Jason refers to it). This is excellent reuse but it also shows the importance of overall architecture. The architecture has adapted to meet the purposes of the business.
The physical nature of Lego means that structures are easier to break as they get bigger, composed of more building blocks. It is interesting to speculate on whether this is true for SOA. Will a big SOA implementation become more fragile? My feeling is that with good design and testing it could be fairly robust but in practice any system with more components and connections will have more points of failure.
Jason states "Lego blocks are interoperable with each other, but not with other kinds of toys." He has a very good point here. Adapters can be built for Lego. I used some sticky tape and a bit of wire attached to Lego blocks when I was demonstrating legacy adapters for an SOA. It is not common practice though to interface Lego with other toys.
Jason's last negative characteristic is "Lego blocks are for children, but children couldn't build Legoland". All metaphors have to break down at some time. SOA is not for children. Services are not made of plastic or cannot fit in an ice cream container either. The metaphorical point is that services can be composed together in an ad hoc fashion without much forethought, but to build large systems with many services that meet the needs of the business requires good SOA and discipline.
One failure of the metaphor I do think has merit is from Jack van Hoof who observes
First start building a nice fortress with LEGO blocks. Then after you finished it, just change one little LEGO block somewhere in the middle of the wall. You won't be very happy, I suppose. Not to mention creating a new window or a door. ... LEGO constructs are easy to be build, but a nightmare to be changed ...
The concern I originally had with the Lego metaphor is aptly covered by a quote from an article by Joe McKendrick who in turn is quoting a vendor white paper
But unlike a single LEGO block, which can only be used in one design at a time, a 'service' can be used by several applications at once (much like a letter in a crossword puzzle).
It is an advantage of software that it can used to process many business processes and it does not get consumed in the process. I sometimes like to consider the service is the block design rather than the actual block but I would not want to try to explain this to an audience as the metaphor starts to lose its simplicity.
The Lego metaphor has been used before in IT and will probably be used for other engineering disciplines. It is a popular model for describing why one might want to build things in parts, why we use standards and how we make big, complex systems out of simple building blocks. For me, Lego continues to be descriptive for SOA. Any discussion about its strengths or weaknesses as a metaphor just seem to help explain more concepts about SOA.
Footnote:
The image above has been presented in a number of articles by Jason Bloomberg of Zapthink. Please note that the blocks illustrated here are not standard Lego blocks. This is a photo of some other interconnecting toy. Standard Lego blocks have the Lego trademark on each of the bumps. Standard Lego blocks also have a gap between the bumps which is larger than the radius of the bumps.
References
- Totta, Gian, The Lego/Swiss Army Knife Approach to SOAs http://www.ebizq.net/topics/soa/features/4040.html
- Bloomberg, Jason, The Lego® Model of SOA, http://www.zapthink.com/report.html?id=zapflash-20061212
- Van Hoof, Jack, SOA and LEGO, do you dare to compare?, http://soa-eda.blogspot.com/2006/12/soa-and-lego-do-you-dare-to-compare.html
- Taylor, James, If SOA is Lego then decision services are Mindstorms http://www.ebizq.net/blogs/decision_management/2006/12/if_soa_is_lego_then_decision_s.php
- McKendrick, Joe, Why are we building ‘enterprise’ SOAs with ‘LEGO blocks’?http://blogs.zdnet.com/service-oriented/?p=777
LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this content.
No comments:
Post a Comment