ZapThink <http://www.zapthink.com/styles/Internet_Market/images/zapthinkheader.jpg>
The LegoR Model of SOA Document ID: ZAPFLASH-20061212 | Document Type: ZapFlash By Jason <mailto:[EMAIL PROTECTED]> Bloomberg Posted: Dec. 11, 2006 Any attempt to explain Service-Oriented Architecture (SOA) to a business audience typically elicits one of two standard responses: "this is techie stuff; you should talk to my IT people" or even worse, "I don't see the business value." The irony, of course, is that Service Orientation is a business approach for leveraging IT capabilities as business resources to meet the changing needs of the business in agile, cost-effective ways, and is thus critically relevant to today's business. But taking all the admittedly technical benefits of SOA, including loose coupling, composability, and reusability, and placing them in a sufficiently explanatory business context has always been a difficult challenge. To rise to this challenge, ZapThink likes to use the analogy of Lego blocks. We feel the Lego block metaphor for business Services is so powerful, in fact, that we put a picture of some on our home page. Whenever we introduce the concept of SOA, out comes the picture of the Lego blocks. We even recommend the Lego analogy to vendors who are looking for a way to explain SOA to businesspeople. 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 -- that serve to illustrate both the power as well as the drawbacks of SOA to any audience. The Four Advantages of Lego Blocks The four characteristics of Lego blocks that are most appropriate for illustrating the strengths of business Services in the context of SOA are the following: * Lego blocks are interoperable. Yes, it's all about the bumps. Because the blocks all have standard bumps, any Lego block will fit into any other Lego block. Standards-based interfaces are the secret to the blocks' interoperability -- or to be more precise, it's the Service contract that matters. After all, we've had decades of standards-based interfaces of various sorts and that hasn't gotten us that close to the Lego vision. * Lego blocks are unbreakable. When was the last time you saw half a Lego block? Even the most rambunctious three-year-old can't damage the things. Clearly, the business would appreciate it if IT could deliver capabilities that were as unbreakable as Lego blocks. Now, it's not that Lego blocks are truly unbreakable, but rather, that the Lego Group designed them with significant robustness in mind. And that's what we want from SOA -- a design for robustness. The key is that it's the architecture of the Lego block that makes it strong enough for a three-year-old, just as IT needs to function in a way that's robust enough for business. * Lego blocks are composable. One Lego block by itself is no fun at all. The whole point to the toy is taking many of them and assembling them to meet the need of the day, just as the business wishes to compose Services into applications that implement business processes in a flexible way. * Lego blocks are reusable. On the one hand, you can build one structure with your blocks, then disassemble it and reuse the blocks to build something else. Another way of looking at reusability is to consider the colors of the blocks. If you consider, say, all red blocks to represent customer information Services, for example, then you can easily use red blocks in many different structures, just as you can compose customer information Services into many business processes. There's little the business wants from IT that doesn't fall under the four characteristics above. The business cares little for how the blocks are constructed or why they do what they do. The business simply wants composable, reusable, interoperable, unbreakable components they can leverage in flexible ways to meet the changing needs of the business. The Downside of Lego Blocks As with any good analogy, the parallels extend beyond the positives, and also help highlight some of the limitations of SOA. Here are four examples: * Lego blocks' strengths pose business challenges for their manufacturer. It's no secret that the Lego Group who manufactures the blocks has had its ups and downs. Changing preferences for toys have impacted their business, to be sure, but the blocks' unbreakability, reusability, and composability have actually caused their own share of problems, as well. Once a family buys enough Lego blocks for their first kid, after all, they're usually set for life, regardless of how many children they subsequently add to their brood. As a result, sales of Lego blocks have waned over time, leading the company to roll out special kits with the intention of having children assemble a castle or a spaceship or what have you once, and set it on a shelf. In other words, the vendor talks about interoperability and reusability, but really wants to lock you in so that you have to keep buying products from them. Sound familiar? * Structures built from Lego blocks are only so strong. If you compare Lego blocks to, say, Erector Sets, the Erector Set was harder to work with and less flexible in its capabilities, but once you had that bridge or skyscraper constructed, it wasn't going anywhere, and you could virtually climb on the thing. The larger you build a structure with Lego blocks, however, the more fragile it gets. In other words, loose coupling comes at a price. While tightly coupled interfaces reduce flexibility and reusability, they also can increase efficiency. Loose coupling, on the other hand, can limit the efficiency of the implementation. * Lego blocks are interoperable with each other, but not with other kinds of toys. This characteristic of Lego blocks might provide a warning about the pros and cons of building on a single platform, but the more interesting story here is that loose coupling occurs on multiple levels. You can have loosely coupled interactions on the wire and message protocol levels, and still be tightly coupled on the semantic level. True loose coupling is far more complex and subtle than bumps on Lego blocks! * Lego blocks are for children, but children couldn't build Legoland. All parents think the structures their little ones build with their Lego blocks are the best in the world, of course, but to build the large structures you find in the Legoland theme park, you need architecture. Without architecture, a box of Lego blocks is nothing more than a box of toys, and without architecture, a bunch of Services is little more than, well, a bunch of Services. Only with a broad design and the discipline to follow it can companies expect to get the full value out of their Services over time. Lego Blocks and Service Granularity OK, all you Lego fans, what is the best size Lego block? Clearly, if all you had were a box of the tiniest, one-bump blocks, you wouldn't be able to build very much. Similarly, if you wanted to build, say, a model of the Taj Mahal, you could (in theory) commission the Lego Group to custom-make a single Lego block in precisely the shape of the Taj Mahal. As long as your requirements didn't change, that bespoke block would suffice, but any change in your needs, no matter how slight, would necessitate scrapping the entire thing and starting from scratch. The moral here is that fine-grained Services by themselves aren't particularly valuable to the business, but Services can also be so coarse-grained that they're too inflexible to meet the needs of the business either. The optimal granularity for Services generally falls somewhere in the middle. Furthermore, ask any child what size Lego block is the best, and they'll look at you funny and reply that they really want a box with blocks of a bunch of different sizes. Just so with business Services -- while the most flexible, reusable level of granularity is somewhere between fine and coarse-grained, in practice it makes sense for organizations to build a mix of Services at different levels of granularity. The ZapThink Take Technologists eschew oversimplifications as being unrepresentative of the true value of complex technologies, but business people appreciate straightforward analogies that both clarify complex topics while illustrating their salient characteristics. ZapThink has found that the Lego block metaphor actually goes over quite well with diverse audiences, and we even know a management consultant who brings actual samples to meetings with C-level executives. If you find yourself in such a situation, try this: place some red blocks on the table, and explain that these are customer Services. Next, place some blue blocks down, and identify them as operations Services. Likewise with the yellow ones, which are manufacturing and delivery Services. Next, single out a business process important to your audience, say, procure-to-pay. Assemble a mix of colors to represent that process. Now, what happens if there's a new regulation or competitor or logistical problem that requires a change to the process? Quickly add a block to your structure. What if you want to use the customer Services from that process in another process? Reassemble the red blocks from your structure with other blocks on the table. You'll be surprised how quickly even the most jaded of executives gets the power of Service Orientation -- and you don't even need to mention Services, architecture, or SOA. LEGOR is a trademark of the <http://www.lego.com> LEGO Group of companies which does not sponsor, authorize or endorse this content.
