Reflection: why the confusion? (2) Reality

In almost every client I worked with, I detected an instinctive feeling amongst my fellow designers (or where we architects!?) that the operational viewpoint is more physical than the functional.  But I also detected that they meant it was more "real", that the functional viewpoint provides them with a more abstract way of thinking about the IT system, because it actively chooses to ignore more of the "real world's" issues.

Only when we discussed the difference between "physical" and "real" did the light dawn, that thinking functionally was no less "physical" than thinking operationally - both consider the implementations of technology to be used - whether that be a CRM package from vendor X, or a Linux platform from vendor Y.

And, just as equally, both viewpoints reason about the specification of their parts - what each part has to do and how well it has to do it - how else could decisions on implementations be made? (Oh, I forgot... "the answer's OS/2, what's the problem?" :-) )

So thinking "logically" and "physically" is ANOTHER powerful consideration - pair of viewpoints - to thinking "functional and operational", and "application and infrastructure".  That's three orthogonal ways (three separate pairs of viewpoints), from which to conceive, reason about and communicate the design of an IT system.  

I think I need another "thinking model" to help me position these three dimensions...

Reflection: why the confusion? (1) People!

Why did I postulate a confusion between the "operational" and "infrastructure" viewpoints?

Where to start...

At the beginning!  In the old days, before software engineering was called software engineering, those who "wrote code" simply, we may now say maybe naively handed it over to operations, who independently, maybe instinctively decided how to deploy it.

(And, human nature being what it is, this "over the wall" approach is still the case today in many places.  That'll be politics, people and power... and process!)

So we had (and still have!) functional-application stuff, and infrastructural-operational stuff.  Two power bases for separate "tribes", each largely blissfully unaware of the other's world.  And as a consequence a whole host of decisions automajically made to fill the gap between the two worlds, hopefully largely based on custom-and-practice; or better still an IT inspired standard template ("put it in the cloud!"), but never "joined-up" between the two viewpoints.

But thinking of "application" and "infrastructure" as distinctly different things from "functional" and "operational" gives us the chance to help each tribe see, and therefore more cleanly and obviously first separate and then properly join, the concerns of "how will we make the application work technically?" and "where will it all go?"

Can we help the functional developers consider the infrastructural implications of there code and data designs; and the operations professionals to understand the deployment needs of the applications and databases for which they are designing/configuring an operational environment?

Yes!  We can... and I'll explain in a moment... but first I think there's another, equally powerful explanation for mistakenly making "operational" and "infrastructural" synonymous... in my next entry!

Operational viewpoint - isn't that "Infrastructure"?

No!!!!

Yes, OK, I agree that, just like "operational" has a formal meaning (a viewpoint looking at the placement and distribution of the IT System), so can "infrastructure", but I think it's a different, equally powerful idea.

Infrastructure - the stuff you can't (or maybe choose not to) see. 

• From my favourite search engine: "the basic physical and organizational structures and facilities (e.g. buildings, roads, power supplies) needed for the operation of a society or enterprise."

Electricity cables underground,  sewerage pipework. And even if you can see it - roads, telephone exchanges and so on, it's all the physical things we need behind the scenes to live our daily lives more comfortably.

So it is with IT systems - the infrastructural viewpoint focuses on the underlying software and hardware needed... maybe I should say we system designers decide is needed to keep the (business) applications and data going, working in conjunction with users and support professionals, day in, day out.

And, critically ( but oft forgotten) there is therefore every bit as much a need to think about infrastructure from the functional viewpoint as there is when looking from the operational viewpoint.

In other words, software engineers concern themselves just as much as systems engineers about "transaction management" and "Backup-and-recovery", whether in the form of middleware or hardware.  Unsurprisingly, they have a different emphasis, for example developers are more likely to focus on how their application exploits the SQL functionality of an RDBMS, rather than the RDBMS's distributed data management capabilities - in which the systems engineer is far more interested.

Put otherwise, it is insightful - I'd say vital - to recognize how infrastructural concerns are orthogonal to those of the functional and operational viewpoints; that when thought of as a wholly separate notion they provide a powerful means of "joining" the functional and operational worlds.

Aspects, perspectives... viewpoints!

My first role in IBM was as a "Systems Engineer", responsible for designing, well in those days we called it configuring IBM's standard hardware and systems software to provide the performance, capacity needed by my clients' applications, while also ensuring their systems were secure and available when  needed; and not forgetting batch and backup and loads of other "systems management" stuff!

And of course all this 'kit" filled a machine room, with separate cabinets for disks, tapes, controllers and of course the "mainframe", all connected together at a "noticeable" (quick, byt not rhat quick) speed.

These concerns were so different from those of my previous role as an aerodynamisist, "simply" writing programs (we call them applications now) to do stuff, running on my self contained minicomputer in the corner of a lab.  Ah, my PDP/11, I remember it well...

These two perspectives of computer systems could not be more different!  As a systems engineer it was all about two things - "deciding on how much hardware was needed", and equally importantly "deciding WHERE to store stuff" - by which I mean which disks and tapes to use for storing software and data (oh the effort it took to ensure databases were spread out over the right disks to minimise data retrieval times, and to store "log files" away from "lock files"!).  But as a programmer, all I'd ever worried about was writing clean code that did what I wanted.

These are two wholely different but equally valid perspectives onto a computer based IT system - each from the viewpoint (ah ha!) of a different stakeholder:

•  The software engineer's perspective; focused on what things the system is doing - that from now on I'll call the Functional Viewpoint
• The system engineer's perspective; concentrating on how and where it's doing its thing - that I'll call the Operational Viewpoint.

I'll discuss the merits and objectives of these (and other) viewpoints onto the one system model later, but for the moment I simply want to say each is a perfectly valid stand point from which to view a model. While the functional viewpoint is clearly more abstract (it chooses to " hide" a lot stuff about where and how), it can be quite sufficient.  But the moment a sense of place enters into your thinking, the more concrete world of the operational aspect is vital.

Reflection: Who am "I"? What's "my" model?

So I just said:

What's in a system model?  Everything!  Everything "I" am interested in modelling.

And of course the big question there is "who am 'I'?" 

In general terms, I am choosing to interpret "I" as being the "system modeller", the person or people who is/are interested in all aspects of the system's design, all perspectives that may help them understand, design and communicate what the system will be, what it will look like, how it will fit in with the wider world, how it will be used (or use) other systems... and not forgetting how it works with it's human users.

But that's an enormous undertaking; certainly without the ideas of "something of everything" and "views and viewpoints" (coming next...) it would be.  Even with these aids though, it's almost inevitable that the system modeller will decide to focus, from time to time on some specific aspect of the design - they may even delegate some part of the work to a designer who specialises in one of those aspects.

What is it that that specialist works with?  A partial model?  No, not from their point of view - they are working on a "complete model" too, it's just that their complete model "only" covers part of the bigger whole; whether it be one particular viewpoint of the whole system, or maybe on particular part of the system.

So, while I talk about "the" system model, and indeed it's that which I am most interested in - the complete system design model, please bear in mind that "model" can address any scope or area of interest, so long as everyone understands its purpose - by which I mean the viewpoint(s) it's authors and observers are interested in.

Maybe I need to talk about "viewpoints"...

So what's in my system model?

(Have you noticed a change from solution model?  Solution design creates system models.)

What's in a system model?  Everything!  Everything "I" am interested in modelling.  That may sound so obvious... but it wasn't always; and in fact is still not the case in many methods today in which there are many  different models for different aspects of the system; several for requirements modelling, more for software design, and even more for deployment considerations, almost everyone of which is called the "XYZ Model Work Product". And that's just one perspective - carve things up in other ways and you'll find security models, infrastructure models, and risk models... All of the same system.

So what? To repeat an earlier phrase - so what a lot!

First of all, imagine making a change to the name of something... How many models will you need to edit? Will you make those changes?

Or "So how does this model relate to that one? Not just at this moment, but after I've made this change?" Any idea?

Or "We've had a budget cut, and need to descope all of this" Gulp.

Far, far easier if there is one and only one system model embracing all aspects and perspectives of all that "I" am interested in... and since I am a Solution Designer, I know "all" for me covers a well understood spectrum of stuff.

Oh boy, that's a lot of stuff... All those aspects and dimensions! I couldn't possibly... Oh yes you can, if you adopt the right approach: "Views and Viewpoints" and Something of Everything".

Structure and behaviour

My LEGO(r) models, and definitely my Airfix(r) models were (largely) "static" - yes, they had wheels and propellers that turned, but otherwise they were constructions of parts that you looked at - hanging them on black cotton from the ceiling, pretending they were flying (Airfix planes I mean!).

And so, sadly it is with so many system models... Drawings of parts connected together... boxes and lines - "static views".  Just like my childhood Airfix model, imagination is needed to try and work out what the parts of the construction might do, together and individually, and whether that was the right response to some requirement or other.  How nieve, and how common - because it's easy...

...or at least easier than the alternative - accurately describing how the system reacts to an external event; its behaviour, drawn as "dynamic views". It's not as if we do not know how to create these views: all our methods provide notations for dynamic views, and some even state clearly how a dynamic view (or more often a set of dynamic views) relate to a corresponding static view.

Put otherwise, a system model described through a set of static views leaves a lot to chance, but is easy (and cheap).  Only when the modeller invests in dynamic views can you be sure.

And what's Solution Design modelling?

Well, it's Solution Modelling! Based on the previous post, the word "design" is superfluous!  Design is modelling!!  So I could equally say "it's Solution Design"!

So what's "Solution"?  In some contexts (language is all about context!) it labels the work done to create a plan to profitably realise, you might say implement an answer to a problem: "if we do this and this to understand the challenge, then decide which package fits best and how to implement it in a phased way while keeping the existing system running... all signed of by our sponsors and users by next Christmas and within budget.. then we have a solution!!!"

Yes, that's a perfectly OK use of the word, and is in fact one I find attractive.  A solution design may therefore include many models, including a system model, financial model and project model (plus loads of other things like stakeholder management and contracts) that taken together should deliver profitably a working solution.

But in the context of my "tribe", that's more likely to be called programme design, at the heart of which (for us!) is the design... sorry, model of the business/IT that shows how we expect to solve the business (or IT) problem with a combination of human and IT components - in other words, our solution model is more narrowly defined to show the structure of the system's parts (some based on silicon, some on carbon) and how they work together, how they behave to safely and profitably satisfy the requirements.

We're getting there: to solve is to design, to design is to model, and to model is to think about structure and behaviour... What do solution designers think about when they think about their system's structure and behaviour?

Yes, I know I should have said "their solution's structure and behaviour"!  But I did say I liked that other tribe's terminology!

Enough of ABBs, let's go modelling.. what's modelling?

Right back at the beginning of this blog I offered a basic distinction between architecture and design - Architecture focused on identifying and championing the use of standard (exemplar) building blocks and standard structures of those ABBs, while Design solves specific business problems using IT systems - hopefully based on these standard parts and structures.

But since then almost all of this blog has been about architecture, its ABB catalogues and frameworks - maybe now is the time to go Solution Design modelling!

First and foremost - why do I now say "modelling"?  And very specifically "Solution Design modelling?  We probably agree, in general terms that at it's most general anything that "represents reality" is a model of that reality - whether it be a financial spreadsheet or an Airfix(r) kit.  And, I hope without fear of contradition, our ABB Framework is a model of the buildoing blocks the enterprise wants to use in its business and IT systems.

But the difference is that ABBs and their Framework is an organised collection (or catalogue) of parts' descriptions - as distinct from a construction made from those parts - the difference between the box of LEGO(R) bricks, and a Lego model made from those bricks.

So, from now on (and actually up to now too but I never said), whenever I'm discussing a construction of something, I am modelling and I'm working on a model.  When I'm discussing a collection of somethings (that's plural), I am organising and cataloging, working on a framework.

Architecture also drives change

So far, everything I've said about architecture has been in the context of design, with ABBs and reference architectures providing guidance (hopefully best practice guidance!) to teams of solution designers.

And, if we're thinking about an enterprise's architecture, the fact that these designers are using a common set of ABBs and RAs should then give everyone greater confidence that their enterprise's Infomation Systems (IS) will work together, using a well engineered underlying technology infrastructure.

But how did the enterprise know what systems needed to be designed?  What new applications are needed? Infrastructure replacing? Old systems switching off?  The trite answer was in an earlier post - Business Architecture!

But in and of itself, BA is not "the requirement" to which ISA is "the solution". Architecture (ABBs and RAs, whether they be BA ABBs or ISA RAs) describe a landscape, they are not a (or the) journey over that landscape.  So what journeys (investments) should we make across that landscape?

Enter the well defined but often dreadfully misunderstood notion of Enterprise Architecture.  Not an enterprise's architecture (that's of course part of it), but "Enterprise Architecture" (EA).  EA is about two fundamentally different but heavily interlocked things - more powerfully described as its two value propositions (VPs); each of which is aimed at a different set of stakeholders.

BTW, I am sure it's a failure to embrace both of these VPs, understanding whay each set of stakeholders need from there enterprise's EA that is so often the root cause of EAs failure to deliver what, in every other industry is seen as the blindingly obvious.

 

VP #1: Doing things right

This is everything I have discussed so far, applied at the scale of an enterprise. It's about ABBs and RAs being used to guide and then govern (govern? Not said anything about that yet!) solution designs created by "semi-autonomous" programmes... Hold on, what on earth is "semi-autonymous"?  In any corporate enterprise, at any given moment, there will be several or even many separate programmes, all largely oblivious of each other and focused on "their" new or replacement IT or business system. "Of course my system will fit in! It's really well designed!!". Yeh, right, it might be a good design, but is it compatible with the wider enterprise?  Only of it uses the enterprises ABBs and RAs!

I characterise this VP as "Downstream EA", because its value proposition kicks in at or after a change programme has been funded and "real design" begins.  Its primary stakeholders - those who should exploit this VP of EA, are Programme Sponsors and Solution Designers.

 

VP #2: Doing the right things

This is EA's "Upstream" value proposition, of value to those trying to work out which programmes to fund (generally refered to as EA's "Transition Planning" capability) - i.e Business and IT Strategists and Consultants.  Critically, they use (the same!) ABB Framework and other EA artifacts to assess which building blocks are critical to the enterprise's future, which ones should be done away with or outsourced, and which ones are needed "to keep the lights on".  And, equally, what are the strategic or tactical implementations of those ABBs, and which implementations should be removed or replaced.

So "Upstream EA" is about working out where the enterprise needs to spend its IT investment budget next year - analysing the gaps and planning for transition from the "as is" business and IT estate to an aspirational "to be" state.

Of course, as well as understanding the benefits of various Transition Initiatives, there is a need to understand the costs - which generally needs some form of outline design performing before the initiative can be costed, approved and hopefully become a planned programme.  I trust you will not be surprised to hear me call this "Enterprise Scale Solution Design"... design probably done by Enterprise Architects in the role of solution designers.  It is NOT, as many would suggest, "an Enterprise Architecture"!!!

This VP's primary stake holders (although they probably don't know it) are not just Strategists and Consultants - as with the downstream VP, "those that do" need to be sponsored to ensure their work is valued:  in this case it's not a Programme Executive - he or she has a selfish focus on their Solution Design,  It is the enterprise's CxOs: the executives responsible for ensuring the enterprise as a whole is successful, and that no one all-powerful  business unit or business line get's its own way.

"Although they... don't know it"?  Eh?  Can you imagine the board of a high tech eeroengine company not knowing their enterprise has a sound understanding of the architecture and design of three spool, high bypass ratio turbofans, and that deviation from that might be a good idea in isolation ,but scarily risky for the enterprise as a whole? So how can the board of a financial institution "not care" about the current and future architecture of their banking systems?  It beats me, but it's true...

Finally, I am happy to acknowledge that the blended term "Enterprise Architecture - helping enterprises do the right things right" was created while I was employed by IBM, and is therefore their copyright.  

Reflection: "Curator"... Really?

It strikes me that "curator" might seem an odd noun to use, other than it appeals to my love of words and alliteration (did I say words were my bailiwick?)

But it's more than that... curator's don't lurk in dark dusty corners, examining their prize exhibits; they are responsible for showcasing the things they are responsible for, helping others understand the significance and purpose of the artifacts they are exhibiting.  Recently I was thrilled to go to a Rodin and Moore exhibition, that presented the work of these two great sculptors in a fantastic outdoor setting, allowing the public to really understand and appreciate the differences and similarities between their work.

I wish a solution designer had reacted to my exhibition - sorry ABB Framework of "ABB exhibits" in the same way!

Creator or Curator?

Historically, and probably still today in over 90% of the enterprises I ever worked with, the ABBs and their implementations presented in the Enterprise’s Architecture ABB Framework are created, published and championed by a small community of Enterprise Architects, who encourage, cajole, and maybe even pressurise their numerous Solution Designers to use them.

Right at the start of this blog I said “[over the years] I've learnt a lot about politics, people, power, persuasion, passion... and a little about computers”.  And it’s these 5Ps that I think really make the difference to an architecture’s success.

The first sign of this in this blog was my reflection on language (shared language = one community, one community = co-operation and shared goals).  Here’s another, equally critical factor.

Many years ago I was teaching a Solution Design class to a 20 senior Designers from a leading UK Pension company.  I’d been discussing the power of “System Context Diagrams” (more on these later) and how they not only help designers understand what their users will be doing with (or for) the system; they are also a powerful means of understanding the capabilities and competencies of their systems’ users.

And one of the more vocal guys in the group said… “Hold on.  I’m designing systems for the same users as Joe over there is.  Surely it would be a good idea if we shared our understanding of our users’ capabilities, how they use computers, and so on?”   And then the magic… “Why don’t Joe and I work together to define a proper set of user specifications, that we all (by whom he meant all 20 designers in the class) can use in our work?  We can then give that list to you (me, the Architect) to look after for us, and to help ensure we conform to them in our designs!”

A really influential moment:  which is the more likely to succeed?  If “I” create something, and insist “you” use it, will you?  Or is it more likely if “the plural you” create the ABBs then use them, giving them to me to look after on behalf of you all?

In other words, in my experience, the most successful Architectures are those created by those who are expected to use them – the Designers.  Architects then have the equally vital role of curator:  ensuring the ABBs remain valuable and used, ensuring conformance (or allowing exceptions). 

(There is another angle to this that I’ll return to later – ensuring the wider context in which the ABBs are created is relevant to the enteprise as a whole, and not just a “codification of today’s stuff”.  I distinguish this as using Architecture to “do the right things”, whereas the theme for a few posts now been using it to “do things right”.)

Reflection: Packages – argh!... or are they?

There is one final thought here, that probably does cause a lot of confusion in the LEGO® box…  that, often, the “ABB implementations” are not actually just one thing.

Vendors will be really happy to say – “my product X is a really good implementation of ABB Y… and Z too!”  Which means their product X is actually a package of stuff, probably reasonably cohesive and self contained, but sufficiently “bloated” for them to say “it does everything!”.   So the same thing’s in loads of compartments… sorry, ABB Categories.

Is this a good thing?  It depends!  Do you want “best of breed” implementations for each of your well defined ABBs, relying on adherence to standard interfaces and so on to ensure thy work together?  Or can you manage risk more effectively by taking a coherent collection, a package of ABB implementations that one vendor’s ensured work together in an sensible way?

It’s the old 1970’s conundrum of “Hi-Fi separates” or “Music Centres”!  I guess it depends on how confident you are that you can make the parts work…

...who makes the parts work?  You, the Architect caring for the ABB Framework, or you the Solution Designer using it's contents as you design an IT system to solve a business problem?

Reflection: Organising the ABB framework (2) - the two biggest mistakes of all…

…no!

So far, everything I’ve talked about has been “Information Technology” – the automation of Business Processes and digitisation of Business Information.  But how did we know what processes to automate, and which data to digitise?  And how best to do so?

I believe there are two factors still missing – one “horizontal” and one “vertical”

(A) We need a Business centric focus in our Enterprise Architecture!

I’m delighted that, in the last several years, the answer has increasingly become “Business Architecture”:  not just “Business Process Modelling” and “Data Modelling” (which I’d generally refer to as Business Systems Design), but the proper identification of Business level ABBs – with the emphasis squarely and unashamedly on Architecture.  And what do I mean “business level”? - thinking about the business without thought for its implementation in IT.  Things like standard roles in a business, standard activities, or standard ways of representing information.  Even “standard locations” and “standard organisational structures” are powerful, business level building blocks.

But, I am sad to say that in so many organisations Business Architecture (BA) is a distinct and separately organised notion from IT Architecture (ITA), “sitting on top of” and “completely disjoint from” each other.  How can this be sensible?  Surely both are equally critical to the Enterprise’s Architecture!  Only when I can join up the idea of a business’s standard activities (BA) to the corresponding applications (IS Architecture) and underlying infrastructure services (Technology Architecture) can I be sure I’m on the right track.  In some places, it is said “Enterprise Architecture supports Business Architecture” – yugh!  There needs to be a seamless train of thought through the layers, up and down between BA, ISA and TA.

Seamless train of thought, up and down…?  Hold on...

(B) We need to encourage a top to bottom train of thought

(As well as bottom to top!)

There are some Architecture Frameworks that choose to split the IS Architecture layer into two layers, creating a four layer horizontal framework – Business Architecture, Application Architecture, Data Architecture, and Technical(sic) Architecture.  But how do you then join the dots?  

·         If I was an Application Architect, would I not be interested in the vertical dimension “of function” more than anything else?  Understanding activities, then automation of those activities, and then the supporting services needed to keep them going?  

·         If I was a Data (or Information) Architect, would I not be interested most in the entities and data items my enterprise needs, then considering how best to digitise them together with the data management mechanisms I’d need to maintain and protect them?

·         If I was an Organisational Architect, I think my most pressing need would be to understand the roles my enterprise needs, and how to organise them into business units and so on – as well as recognising how some roles might be automated, as well as the human-machine relationship my people will have with IT as they perform their roles.

All of this points, for me, to there being a second vertical dimension to my ABB Framework, cutting down through the levels considering the high cohesion there needs to be between BA, ISA and TA in three areas:  Application Architecture (top to bottom), Information Architecture (top to bottom) and a People centric Architecture.. top to bottom.

Not "layers" - vertical slices of AA, IA and OA through the layers of BA, ISA and TA.

(Later, when I return to those two final shortcomings of the Lego® analogy, I’ll add a couple more vertical slices through this two dimensional framework.)

Reflection: Organising the ABB framework (1) - layering

Just like a “flattie” is different from a “tall”, it seems right to consider an “Authentication” ABB as something distinctly different from an “Authorisation” ABB… and these are pretty fine grained notions.  Which means there are likely to be loads and loads of ABBs across many different topics.  That’s why we’ve the notion of the ABB category – which is probably, in this case the “Security ABB Category”.  And we'll probably have a "Printing ABB Category" and "Data Management Category too.  All of these are remarkably similar "infrastructural" things - quite different from categories of ABBs associated with “Order Management” or “Supply Chain”.  In fact, the difference is really quite obvious, in that one set can be seen to be “Industry neutral” – everyone needs to do security whatever industry they are in, while only enterprises with Supply Chains are interested in the “Supply Chain" ABB Category.

So it is common to visually arrange the ABB framework’s Categories in at least (see next entry!) two layers or levels – one that is “Business Dependent” (at the level of business applications and data), and one that is “Business Independent” (at the level of technology).  My preferred naming convention is “IS Architecture” – dealing with all the stuff that relates to the Information System supporting the business whatever it may be, underpinned by the “Technology Architecture” – dealing with the technology needed to keep the business applications and databases humming.

 It may, therefore be that two enterprises in the same industry, such as banking, may have remarkably similar IS Architectures, but – maybe because one has a centralist structure and the other a federated approach, their Technology Architectures are hugely different; whereas an enterprise in retail will definitely have a different ISA, but could adopt a strikingly similar TA to one of the banks.

I've now got two trays in my Lego box… is that it…  ?

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.