As per a sort of unspoken understanding with my eldest son, his good behavior whilst running errands on Saturday earned him a new Bionicle from Target.  And of course when he got home he quickly put it together, again amazing me with his skill in following architectural blueprints.  But it really got me thinking about the metaphor for building blocks and connection points.  Being a fan of these fun toys helped me form this up and it's still taking shape, but I think that it's important to note the metaphor which I don't think trivial from an application design standpoint.  I know that folks like TowerGroup have used similar metaphors before, but of course I would have questions about their understanding of application architectural needs or concepts.

Many people use the LEGO as a metaphor for the building blocks of software.  But think about the rigidity of that model.  Typical LEGO configuration are blocks of various length/width with all the same connector design (little nubs...what are those things called?).  And out of those blocks you can make anything and when put together you can't distinguish the blocks from each other in the end result (colors aside).  But think about applications and application parts....they're not like that are they?  Not all application parts fit in all areas of an application, and each set of application blocks produces something very unique.  And in addition, the connectors (integration, interop and messaging) for applications are not often all the same.  Some connectors require security, reliable messages, fire and forget, point to point, forwarding, etc.  And so each connector looks differently and behaves differently.  Each connector does not universally connect to every other.  That is one fallacy with the vanilla LEGO as a software building block metaphor.

I prefer the Bionicle as a better metaphor.  To understand this you should visit http://www.bionicle.com to see the various creatures that you can create and the parts.  Let me explain somewhat how I construct this metaphor so that you understand how it helps describe true IT and software design.

• Core Bionicle parts are uniquely suited for a purpose.  They are arms, bodies, legs, feet, heads, etc. - Application blocks have a purpose in an application.  They perform business logic for underwriting rules, risk management, claims workflow and they are uniquely suited for that application space.  They MAY be used elsewhere, but the final product may not function entirely correctly, or may appear very strange looking.
• Bionicle connectors vary in form and function, pivoting, ball joint, gears, etc. - Application connectors also vary widely by need and application.  They may provide a broad range of movement and have a number of connection points, or they may be fairly constrained and lightweight.  This is the difference between a lightweight event message and a more complex reliable message conversation.
• Each Bionicle part does not have a connection point for every Bionicle connector - Application blocks are not automatically suited to connect to every other application block with any kind of connection type.  It depends largely on business function, workflow and other requirements that may exist or need to exist (like security, correlation, RM)
• Standing alone, Bionicle parts can often be identified for what they are - Application blocks, since they have discreet form and function, should be able to be identified independant from the finished product.  This doesn't mean they can function entirely alone, but they do have form and can be identified in a standalone way if need be.

In completing the application, and when using proper design principles and "best fit" architecture you arrive at something functional AND specifically suited for what it was designed to do with the parts working in harmony. 

- Josh