LEGO Blocks, Software, Design Mentality, and Random Thoughts

UPDATE: It turns out that it wasn’t quite “5 minutes” but the better part of 1 day… ZapThink Research published a piece called “The Lego Model of SOA” shortly after I wrote this post…

Thomas wrote a good post about the “LEGO Block Syndrome” in software and Hasso Plattner’s continued efforts to shake the industry loose from the grip that engineers have had on the software design process.

McKendrick over at ZDNet wrote the originating post on the LEGO block analogy and it’s worth reading first. You really can’t spend 5 minutes in this business without someone saying “it’s like LEGO blocks, you just plug them together!” and for the most part nobody ever objects because the truth is that we all WANT it to be that easy. Getting there is another issue…

Here’s why it’s never going to be that easy: LEGO blocks don’t have to pass information between each other and there is no requirement that they be sequenced in any particular order. In other words, the beauty of LEGO blocks is that they are fully compartmentalized and you can click two 2×2 blocks to a 2×4 and it works the same way was two 2x4s, and if you want to use a pair of blue vs. 1 green and 1 red, well that’s cool.

At this point the LEGO-philes out there will say “hey, the Mindstorm LEGOs are capable of building complex systems” and you would be right. But even here there are some distinct differences from Old Skool Lego, like the fact that there is no LEGO version 4.6 legacy customer base, and insists on an non-disruptive upgrade path, hanging around the neck of new LEGO. The other point about Mindstorm is that it’s a $250 LEGO package… so maybe it’s looking more like enterprise software after all?

Thomas also mentioned Hasso Plattner’s continued efforts to achieve real design innovation in software. This is no bullshit, Hasso has always cared about usability but even as the CEO of SAP he was unable to decouple software design from software engineering and it continues to be a problem not just for SAP but the entire industry.

One of his later initiatives is the at Stanford in partnership with IDEO, a design firm without equal. This is a very innovative initiative because it attempts to bring together disciplines outside of technology for the purpose of designing better technology products, although one could also argue that this is further evidence of the pervasiveness of technology across a broad spectrum of industries and research areas as well. I expect we’ll see some amazing things from, and Hasso’s other projects in this area, but it’s overstating the case to suggest that this is going to be a watershed moment for enterprise software because the problem our industry has is that we want complexity and just don’t want to admit it – it’s the Culture of Complexity thing I wrote about last week. New companies will embrace these advances in usability and design because it’s a way to be disruptive but the incumbents will not, at least not in the core, because they have too much to lose.

Hasso often uses automotive industry analogies to the software business, for example he’ll point to companies like Bosch that are successful and dominant in their segment of the industry but have no end user brand, which is a valid point but I don’t think we’re broadly moving to a business model where there are 6-8 global brands and hundreds of tier 1, 2, and 3 suppliers who feed up the technology and if this were to be the case then you would have to consider Open Source which pretty much blows the analogy up.

I think he’s wrong to continue to use the automobile industry as a model, but it’s best summed up with the comment I left on Thomas’ post:

Yes, cars today are more complicated but they are more safe, higher performance, cleaner, comfortable, and more reliable than their 1950’s counterparts… and the user never has to deal with the complexity (unless you have a BMW with iDrive!). [ED: I wrote “reliable” twice in the original comment so I edited it out here]

Can the same be said of enterprise software? Have all the gains of the last decade resulted in software applications that hide their complexity from users? If so, why is SAP itself not running Duet instead of CATS? [ED: original comment has a double negative, I corrected it here]

BTW, and you know how much I respect Hasso, but he is flat out wrong to continue to use automobile analogies as applied to software. Put another way, if the automotive industry was like enterprise software your new car would come to you in boxes of parts and because many of them wouldn’t be compatible you would hire a machine shop, engineer, and a mechanic to put it all together.

Technorati Tags: , , , , ,

4 thoughts on LEGO Blocks, Software, Design Mentality, and Random Thoughts

  1. Thanks for the trip down memory lane. I can add two cents to this string, one being a little probably meaningless historical background on the lego analogy and the second being my opinion on the root of the discussion/complaints in your various posts and links.

    First, I’ve been researching and trying to make analogies between information technology (IT) and more mundane things for over 35 years. One of the strings you link to is correct in saying that the lego analogy has been around since 1991. In fact, I first heard this lego analogy when Chris Stone was splitting off the Object Management Group into a separate organization from DG circa 1988/1989. If I was on Final Jeopardy, I’d guess the comparison came from some HP NewWave folks with their stub diagrams around that time or a little earlier. However. with a little research I also think we might discover that OO’s and Lego’s mutual Scandanavian ancestries are probably more than coincidence and the analogy probably goes back even further.

    Second, and more important, although “when” is just a good geek trivia question, “why” is the interesting one. The fact that legos are such a good and long-time analogy for objects is exactly why they are not a good one for services. Services to SAP are sets of business processes, IT functions, event interactions (e.g., RFID), and so forth that are “a level of abstraction above” (to use another great overused analyst phrase–guilty!). The services can be “automated” using a variety of different technologies including OO.

    And of course, that taxonomy raises a bigger issue: do others agree with that SAP definition of “services.” I suspect the real reason a post such as yours and the others you reference can raise such a long interesting string of comments and rebuttals is that there is no agreement on the meaning of the key terms themselves (open source, service oriented architecture, enterprise service bus, component, object… even the term ‘legacy”). The vendors have a vested interest in keeping the definitions loose so as to always claim they have the lastest, greatest whizbang. And those of us who analyze the IT industry make our reps inventing new terms. That makes it pretty hard to draw analogies.

    Thanks again.

  2. Hi Jeff,
    Maybe Lego has a subversive viral marketing campaign going. If we all talk about it in a work context then perhaps we will pop into the toyshop on the way home. Next there will be a gapingvoid drawing.

  3. Pingback » LEGO blocks and SOA: is the singularity near? | Service-Oriented Architecture |
  4. Hey

    I was surfing the web and i saw this site, pretty cool.
    Currently im running and adult site:Reachton
    k, just want to say hi :)
    Can i link you from my site? im looking for quality content like yours. If no let me know if i can add u in exchange for a montly fee or something.

Comments are closed