We’ve been having a renewed debate online recently about the Lego block analogy for SOA. It’s amazing how energised people get about this analogy – but it’s important to remember what we are trying to achieve when we make it, and not take it too far or dismiss it out of hand. It seems fitting that on Lego's 55th Birthday (Lego was first patented on Jan 28th 1955) that we continue this debate.
The idea was first introduced in a Zapthink report way back in 2006. As one poster in the debate points out, that was “one year BI – before iPhone”, and things are moving on quickly in enterprise IT, but bear with me – context is all important. The context in which Zapthink’s Jason Bloomberg originally aired the analogy was as a way of explaining SOA to business people who either didn’t want to know about it, or didn’t see the business value of the small additional investment that was required for SOA.
ZapThink sought to use the Lego blocks image to explain how services, like the ever popular children’s toy, displayed certain characteristics that could make IT architecture more valuable to the business. Lego blocks, they pointed out, were interoperable, compose-able, unbreakable and most important of all, reusable. They themselves admitted there were some downsides to this analogy – including the challenges for the manufacturer in continuing Lego sales, the strength of the structures built and, most fundamentally, the fact that Lego is ultimately just a kit – it’s what you build with it that counts.
Others entering the debate continued to question the wisdom of the analogy, pointing out that Lego was actually a “proprietary” and “homogenous” system in that it wasn’t built to “interface” with other toy systems and the “interface” was always the same – those little bumps and grooves that connect together.....but when you look into it, the Lego inteface design in 2013 is actually surprisingly flexible these days. You have your standard little red blocks. But you also have all kinds of custom pieces, components and kits, from fighter plane propellers to camshafts. In addition, different toy manufacturers’ pieces will fit together perfectly well – pieces from KNEX, Mega Bloks and Kre-O to name but a few all work and are compatible with Lego.
In addition, the flexibility of the Lego system design comes not so much from the blocks themselves but from the “interface” that all these different toy makers “write” to. Of course Lego doesn’t manufacture all the little bumps and holes that ensure compatibility between the different toy systems, it’s the fact that the “interface design” is fundamentally the same, that is the key. Similarly in the world of SOA, the most important thing is the flexibility of the interface so that all the business components work together.
In all the commentary and to-and-fro, I think the most pertinent concern about the analogy was that it didn’t talk to the service-oriented nature of IT services and all that entailed, and as such building a Lego kingdom was more like building old-fashioned enterprise systems with all the complexity and development work that involved. I agree, and that’s why in a previous blog, I was talking about the SLAs of cloud services being suddenly out of the CIO’s control. The service-oriented world really is a completely different way of thinking about architecting systems, and that’s where the analogy breaks down.
So let’s go back to what we were trying to achieve with the Lego/Interoperable block analogy. We were trying to explain to the business why they should invest that little bit extra in SOA principals and a service-oriented architecture approach; and why they should even care about what that architecture looked like in the first place. The "Lego" system design goes some way to explaining what a robust, interoperable framework looks like and perhaps helps business users understand why it’s superior to the chaos of point-to-point integrations.
Should the business manager care about IT infrastructure? I agree, it is mostly a techie thing, but using another analogy raised in the online debate: one poster asked why a business manager should care what their factory is built of so long as it’s built at the lowest cost? My response was that they would care if they had to pay for special trucks to deliver building tools to the yard, something way more expensive than using standard trucks, but not necessarily impacting his cost of construction of the lumber plant?
The point here is to have a standardized way of delivering integration that delivers a better TCO over a period of time, following SOA principals with interoperable building blocks that can be assembled and built on over time. As I argued in a previous blog, most people look at point to point integration costs as a one off, but in fact it’s the cost of on-going support and maintenance that’s going to come back to bite them in the long term.
I don’t think anyone suggested trying to explain how SOA works to the business manager – in fact in our lively online debate, most acknowledge that even within the IT community, a Unified Business Service Model is still a distant dream, with several standards attempting to articulate it but as yet no overarching definition. The key is to articulate the value it delivers. In our business, for example, we don't mind how we onboard participants into our Cirrus (tm) cloud hosted integration service – but they do care how much it costs, and more importantly that we can build out additional services to the newly on-boarded customers. The Lego or Interoperable block analogy is an easy way to describe the value of SOA to people who aren’t interested in the how’s, why’s and wherefores.