Does the LEGO analogy for SOA have legs, or is the theory blockheaded? There's been a lot of interesting reactions to my recent post on the "LEGO-block" analogy used so often for SOA-based deployments.
Coincidentally, ZapThink's Jason Bloomberg made a very good case for the LEGO analogy at the same time of my original post. (Do great minds run in the same rut, or what?)
Kiran Garimella of WebMethods, noting that "folks with LEGO kits shouldn’t be the only ones having all the fun," posted these thoughts around the LEGO theory:
"In the LEGO world, there are several copies of each kind of block that an be used in many places in the model. In the services-world, there is only one service (ignoring load-balancing forks). In the LEGO-world, each block has exactly one interface (or way to interconnect with other blocks). In SOA, a service may have multiple interfaces and beconnected in multiple ways."
To make the LEGO analogy more meaningful, Kiran posits that LEGO-like blocks of capabilities "may occur at various levels of abstraction." There would be smaller LEGO blocks for finer-grained services, and larger blocks for higher-level abstractions such as business processes. "A well-defined setof process steps could be composed into little processes, which in turn could be packaged into a bigger process."
Hmmm. I did have different-size LEGO blocks myself, some with just two snap-parts, others with four, and others with six. But I always ran out of the sizes I needed for my endless and off-balance skyscraper construction projects. They would be still standing today if my mother's vacuum cleaner showed some mercy.
Jason Kolb also weighed in on the discussion, observing that "Joe has hit the nail on the head here, although I don't know if he quite realizes it." (Probably not, Jason…)
Difficulties arise when "the SOAs you're using to build your spaceship with aren't built with the same kind of blocks. When you try to plug marketing's LEGOs into Finance's Erector Set, the pieces don't fit together and you need to start building the nuts and bolts adaptors. The real underlying issue here is that SOA is so new that every vendorcan run off and build a proprietary API and claim to support SOA. The business users grin and drool with anticipation of creating fantastic new mashups. Yes, you can use the SOA to create new applications, but only if the other applications you're using support the SAME SOA. If one supports REST and the other supports SOAP, or the two applications don't support the same schema , you need to use duct tape to stick the two SOAs together."
Personally, I found Scotch tape and Elmer's Glue to be effective customized temporary solutions.
Thomas Otter posted this observation in his blogsite: None other than SAP's Hasso Plattner made it very clear at a recent lecture at Pottsdam University that the LEGO analogy lacked a solid foundation: (What do you expect from lightweight plastic?)
"The LEGO bricks are not the model for corporate or enterprise software. Lego bricks are not the model for architectural models. No architect in the world uses LEGO for models, and they are a few magnitudes simpler than enterprise software.And later he said. The ones that are running around and saying this is bricks and we just put them together are misleading you, regardless of how prominent they are I’ll take a bet, I put money on it… that I’m right."
Hmmm. I've also heard that LEGO itself reported that it was unable to keep up with demand for the blocks to replenish inventories for the Christmas season. A company official said its difficulties were the result of a corporate and operational restructuring. Perhaps they need to implement SOA to provide more flexibility, standardization, and visibility into its supply chains? It should be easy for them to snap such an architecture together, right?
