Defining and especially agreeing on what the term “architecture” means and represents, within organisations that do not produce brick-and-mortar structures, seems to be a never ending struggle. The saying “Truth is in the eye of beholder” cannot be more true than in this context. To make things worse, additional words get prefixed to the word architecture like business, enterprise, solution, technical, applications, security, network, system, software, information, data, integration, etc., which does not really help as we now have more terms and definitions (that we cannot agree on) to deal with.
Over recent years I’ve had a pleasure of learning from Samuel Holcman, from Enterprise Architecture Centre of Excellence (http://www.eacoa.org), who provides simple examples that help demystify some of these terms. So, here is one of them.
Looking at a structure made of Lego®, like the one below, how many and which architectures do you see?
There are actually many architectures that describe and define this structure. I would like to focus on two architectures that seem to be creating challenges to many organisations.
One of the architectures, that is quite obvious and usually the one people refer to when talking about “an architecture”, is the one that describes and defines “which Lego® block types to use, how and where to connect them to achieve the desired end structure”. This is Solution Architecture for this structure, as each structure/solution is unique, based on what the “structure requester wanted at a point in time”. The value of this Solution Architecture is in providing structure and guidelines on how to create/manufacture that specific structure you see in the picture. If your organisation is only in the business of producing this structure then great, but if your organisation would like to build slightly or radically different structure, from Lego® blocks, then you would have to define and specify another Solution Architecture addressing this new structure. A standard question is usually posed: “How much reuse/savings did my organisation get from the previous work we’ve done?” I’ll leave that answer to you.
However, an architecture, which is not an obvious one and which people usually do not see or place value on, is the one that relates to Lego® block’s intrinsic ability to connect in various numbers of ways (their capability).
So, someone in Lego® land has, without prejudice on what the end structures would be, gone about defining and specifying various Lego® block shapes, their “interface” characteristics (e.g. the humps and bumps), that enable blocks to be assembled in a multitude of ways, thus enabling relationships to be created just-in-time and for a given context (e.g. I would like a house/car etc.). This approach has obviously contributed Lego®’s enormous success.
This is actually “Lego® structures’ Enterprise Architecture”, representation of their enterprise capability. If your organisation is in the business of building structures out of Lego® blocks, then “Lego® structures’ Enterprise Architecture”, basically represents “Your product structure’s Enterprise Architecture”. So, as you go about building many structures and specifying their Solution Architectures, using the same Lego® block types , how many times do you have to define and specify “Your product structures’ Enterprise Architecture“? How much reuse did your organisation get? Is it clear, to everyone in your organisation, on what underlying capabilities underpin all of your product structures ? When you decide to buy a big software package, that you “just” configure and “slightly” extend, what have you actually bought? I’ll leave those answers to you as well.
We at Fronde believe that just by formally understanding and recognising the difference between Enterprise Architecture and Solution Architecture and the value that activities around each bring to your organisation would provide significant benefits. It would result in significant shift in organisational thinking and put you on the path of organisational engineering.
