Lego® and ABBs - does the analogy really work? Yes, but...

Like so many analogies, my comparison – so far – between a box of LEGO® and an architectural catalogue of parts (I mean an ABB Framework) has several shortcomings… at least five that I know of.

I think I can cover three of them by refining the analogy (making it a more grown up Lego box!), but two will have to wait…

Shortcoming #1: not Physical, but  Logical

Firstly, I’ve described the the Lego box as being full of “real” things – Lego bricks, wheels and other stuff.  Things you can touch, take out and play with.  Let’s more formally call them “physical” things.  But ABBs are not “physical”: they are specifications of what things can do, describing their capabilities and limitations – they are “logical”.  And they also have (or should have!) selection criteria, allowing the solution designer to decide which physical implementation of the ABB they would be best advised to choose.

So we need to put a lid on each of our Lego box’s compartments, describing the capabilities and limitations of the things inside: each compartment now “contains” things that satisfy a specific type of ABB (such as “authorisation” or “2*4 tall brick”), with the things inside being ABB Implementations (such as “IBM Product X” or “Red brick”).

(It’s probably wise at this point to note that ABB Implementations are, in some methods, called System Building Blocks (SBBs).  But for me, this name does not properly capture the essence of what they are – to my mind ABBs and ABB Implementations are equally capable of being a system’s building block, it just depends on whether you chose to look at the system logically or physically. Ho Hum.)

But of course there are other sorts of brick/Implementations in the same compartment/ABB satisfying different selection criteria:  there are blue ones and green ones – each with their own distinct selection criterion, helping the modeller decide which one to take out.

Or are these Lego compartments actually full of physical blocks?  Of course they are in a normal, everyday box of Lego, but that’s the second shortcoming of the analogy…

Shortcoming #2:  not Inventory, but a Catalogue

An ABB “compartment”, does not contain “real” things – it’s much more like a catalogue entry, with lists of ABB Implementations that are themselves (physical) specifications of the various product’s actual capabilities, limitations, costs, sourcing models and so on: it’s a fulsome description in a catalogue.  In other words, the ABB compartment contains a collection of “documents”, describing what the modeller can use.  In formal terms, the “ABB type” provides selection criteria for each “ABB Implementation Type”.

It’s a bit like a magic Lego box, in which each compartment contains one red block, one green block and one white block – and each time the Lego modeller takes the red block out, another magically appears to take its place…

(In fact, this is a critical and often confused difference between Enterprise Architecture – documenting what and how IT might be used to solve business problems, and Inventory Management - focused on managing and enhancing the existing IT estate of an enterprise:  this would be the "physical collection" in the Lego compartment - all the individual instances of the thing described on the lid.)

Shortcoming #3:  where’s the “2*4 flattie?”  

Are we there yet?  No, not quite… So far, it’s been pretty comfortable seeing each ABB and ABB implementation sorted into one place - I hope I wrote earlier, somewhere, that an ABB is a unique specification – each type of ABB appears exactly once in one ABB Category within the ABB framework:  in the analogy there is only one ABB specification of a “2*4 flattie” Lego brick, even if it comes in many colours.  

But what if an implementation of the “2*4 flattie” was attached to two others?  Would it satisfy the specification of quite a different ABB, one that is specified to be “2*4 tall”?  It might…  so could you find an ABB Implementation in the “2*4 tall” ABB, describing how three of three flatties can be used instead?

If you were a vendor of flatties and you did not make talls, then I suspect you would be very keen to see your product in that “tall” ABB selection criteria, as well as the “2*4 flattie” ABB!!!  (In case you are wondering, outside of the analogy I suspect the the “tall” ABB is a Z series mainframe, and the “flattie” is something like a mid-range UNIX© server, and therefore three are needed to do the work of one!)

In other words, it is quite reasonable to find an ABB implementation is a valid implementation of more than one ABB – which really starts to stretch the physically focused Lego box analogy because now I might find “anything” under those ABB lids – various wheels implementations, varying in size, colour, tyre type and so on in the “wheels” ABB, but maybe the bigger/wider ones will also be valid options in the “turntable” ABB too… not sure I could have coped with that as a child with my Lego box! 

Maybe it’s time to leave the analogy – but sadly it’s not taken us far enough; we’ll have to deal with two more shortcomings, later.