Reference Architectures - standard constructions from standard parts

Until only a few years ago I could be found arguing passionately that "all you need is ABBs".  Give a solution designer a good collection of ABBs, across a broad enough range of areas (standard components, nodes, actors) and stand back...

But in an earlier blog I also extolled the virtues of Gartner's five client server models - so there must be is more to Architecture than just ABBs:  there's something to do with templates...

Consider the following:  what if project A in your enterprise adopts "distributed presentation", and another "remote data access"?  OK, so your architecture governance processes help ensure both solutions will work on the users' standard workstations (they've both chosen the same workstation ABB!), and maybe both use the same access control services (“authentication” and “authorisation”) but... oh boy... how many different systems management mechanisms will you need?  How "universal" will the workstation need to be to support both (and other) styles of solution  that are made available to the user?

The trouble is, and not withstanding those "simple architectures" from Gartner, our industry does not have a stable, manageable set of "Reference Architectures".  We do not have "7 tried and tested ways of designing a bridge".   Yes, I can hear some of you screaming "yes we do - it's called cloud!!!".  Fiddlesticks! Cloud can "do" all 5 client-server layouts!  The challenge is to use "cloud" in a consistent and compatible way for all the enterprises solutions.  This sounds so like the late 1990s and Warp... "The answer's OS/2, what's the problem?"!

The problem is – how do we Architects ensure the enterprise’s Solution Designers’ designs work for the enterprise (let’s call that “architectural conformance”), as well as for their direct sponsors (which we can call “solution assurance”)?  The answer is Reference Architectures – standard constructions of our standard parts, that we are confident will work together when used for the myriad of applications our SDers are designing solutions for.  And, since there is no “universal set of seven” RAs, each enterprise will – at least for the foreseeable future – decide on their set of RAs that work fore them, within their industry and in ways that match their business models.  

The real difficulty, particularly for RAs created by a supplier which are then adopted by an enterprise, is the “standard parts” bit.  I know of many organisations (including those who design systems for their clients) in which an SDer is trying to use one RA in concert with – or simply alongside – another RA; and the commonality of parts between then is… zero.  It’s a bit like a child trying to build a model house or car, in which some aspects of their construction use parts from the LEGO® box… and other parts from the MECCANO box…

Is this “foolishness” common?  Yes.  In my experience it’s more the case inside vendors (even if their RAs are all made from their own products), whose focus can be “design and build”, than it is in enterprise’s who understand the full systems life cycle of design, build, run, maintain, change and decommission.

Ontology and taxonomies

Wow - maybe I should have called this "Frameworks and categories" because that's what I mean.  But I have always been facinated by wierd words (one might say it's my bailiwick)...  According to wiki, and specifically within what wiki calls "Information Science":

• Ontology: formal representation of knowledge as a set of concepts within a domain 
• Taxonomy:  the classification of things or concepts

(My highlighting).  So what? So what a lot!!!  Because it's ontologies and taxonomies that enable us to define a variety of different sorts of ABB, a classification scheme for our ABBs.

So far I've offered a definition for "ABB", and I've pontificated on judging their value and usefulness, but we are yet to name one.  Back to LEGO®...  My Lego box has 20 or so compartments.  What did I put in each?  I'm told that, when I was around 4 years old and I'd had a tantrum because I could not find the brick I wanted, Mum suggested I "sort them out".  So I'd sort my pile of Lego... by colour and maybe size on the kitchen table.  But these piles of colour quickly deteriorated as I again became frustrated at not finding "that wheel" or "that roof block" in the "red" pile. In other words, colour (red/blue/green/...) might have been obvious, but it was a useless taxonomy.  Put more formally, it's an "anti-pattern" Lego sorting algorithm because afterwards it takes too long to find what you are looking for.  An older child (or my mother when IO was 4!) realised it's much better to sort by function - piles of 2*4 blocks, one-ers, wheels, windows, and so on; putting all the red, green and blue "2*4" bricks into the same pile (or compartment!).

So it is with ABBs - not piles or compartments in a box, but ABB Categories in an ABB Framework; each category carefully chosen to ensure its ABBs are all the same sort of thing, but different from those in other categories: for example "authentication" and "authorisation" ABBs in the "Security" ABB category, with "backup" somewhere else.

(By the way, notice that these ABBs are specifications of function - all the different implementations (aka colours) are then options for each type of ABB (aka brick).  If this seems patently obvious, I did have a client once whose ABBs were sorted by vendor...)

So far so good - in this example we have a taxonomy of (what happens to be) Infrastructure Services ABBs within an ABB Framework we might choose to call an Enterprise Technology Framework (which we may even abbreviate to "ETF"). But these are not the only kind of ABB we should be defining!  Back in 1993 with E2E and CTA, we knew our CTA's SBBs(sic) needed to provide other sorts of ABB - such as standard constructions of hardware and software that were assured to be reliably deployed and managed by a DP Department to support these infrastructure services: in other words we had another ABB taxonomy organising collections of nodes; with different ABB Categories for nodes representing different sorts of departmental server, different sorts of workstation, machine room stuff, networking, and so on.

In other words, if our architecture's "catalogue of standard parts" is to be truely useful, supporting the Solution Designer across all aspects of their work we need an ontology of taxonomies - which in an enterprise's well formed architecture gives the solution designer all the sorts of parts they need… taxonomies - sorry, let's revert to calling them ABB Frameworks of ABB categories for standard use cases, standard actors, components, nodes, locations... there may be upwards of 20 different sorts of ABB Framework, each underwritten by the enterprise saying "you design your IT based business system using these parts, and the risk of it not fitting into our enterprise effectively and efficiently is greatly reduced".

When is a building block not a building block?

Every architecture class I have taught, and every architecture method I have used is clear on what a building block is (even if some design methods elect to ignore their existence).

It’s definition goes something like "a standard part that can be used in many different combinations with other standard parts to satisfy a variety of requirements".

I’ll discuss this definition in some detail, later, when I "discover" the idea of Reference Architectures.  But for now I want to reflect on what makes a BB a "good BB” – by which I mean one that, at the end of the year, you can say "yes, that was used many times, successfully both technologically and for good business benefit".

Think about LEGO®.  I recently watched a brilliant TV programme discussing the impact of Lego on real architecture, and how some architects directly embrace the notion of Lego in their modular structures and building project patterns – some even using it to build proper scale models(sic) of their to-be buildings.  But then they said something that I think profound.  Something I have actually thought for many years about the difference between the Lego I had as a boy and the Lego of my children:  something quite fundamental has changed.  A quick trawl via your favourite search engine will confirm there are lots who think the same...

In my childhood, the range (and size) of different sorts of Lego was very limited - I vividly recall seeing "flatties" for the first time and realizing how they could greatly expand the variety of things I could make.  I was probably 7.  So, picking and choosing parts from my (large!) box of Lego and it’s few compartments, I made houses, planes, bridges, boats, cars, and even people.  

Compare that imagineering experience to that of my kids – they had boxes (plural!) of Lego, each with a very specific picture on the lid of things such as a pirate ship or space station; and dozens and dozens of different sorts of Lego block... well, you couldn't call more than a handful "blocks".  How many compartments would their mega-box need?

In other words, it seems to me - and those in that TV documentary - that Lego is no longer a "general purpose construction toy" enabling children to realize their imagination; it's morphed into something focused on encouraging children to "make the picture on the box" (can that mean more boxes are sold, if each box makes one thing?).  I know it's not quite so extreme as an Airfix kit or a jigsaw – there is still a lot of room for using the parts in many ways; but the plethora of types of parts, some amazingly specialized with limited usefulness and - to me even more notable - the far wider range of "part size" at best hinders, and most likely masks the idea that children can use Lego’s "standard parts in many ways". 

So my wooden box with its few dozen compartments was pretty useless to my kids.  I'm delighted to say they loved the idea of a sorting box, and even (when older) tried sub-dividing the larger compartments to take more sorts of parts, but basically most bits went into a heap in the “other parts” compartment.

So what's the  range and variety of your ABBs?  Do you have so many that their usefulness is limited too narrowly? Do they do generally useful things just like Lego's "4 by 2" blocks and flatties, or would you compare them to Lego’s ray guns and pirate ship hulls? Most importantly, do they go together well?  Are they well proportioned like all the sub-types of flatties and ordinary blocks?  Because IMHO if they're more like ray guns and ships' hulls, they're not good ABBs.

Reflection: the power of language (2) – my first proper IT “mental model”

Secondly and specifically, I found this separation between "solution" (design) and "guidance" (architecture) provided me with my first “working mental model” of how to think like a professional Architect who is trying to exploit IT in solving their enterprise’s business problems.

Back in 1993 I was “on the edges” of an amazing effort to craft a repeatable approach to the design of infrastructure(*); something called the IBM End2End Infrastructure Design Method (E2E).  For the first time since my days with aero-engines I saw people trying to agree on how they did “systems thinking”, this time about systems made of IT.

They invented the SBB, the System Building Block (when asked “What’s an SBB?” the answer was “What do you want it to be?”  More on that later!).  At its heart, this was the idea that systems were constructed of standard parts – and that those standard parts should be common across all the systems in an enterprise.  

In other words, if you want to create an IT environment capable of supporting an enterprise’s myriad of applications, all doing an amazingly diverse range of things and yet sharing and exchanging information, then it’s probably a good idea for the enterprise to guide and govern the way those otherwise independent systems are built, and is there a better way of accomplishing that than the enterprise’s architect giving each application’s designer “the enterprise’s catalogue of parts” from which to work?

And in E2E, an SBB was exactly that.  An opportunity for the EAer to guide the SDer in selecting “approved” or “well understood” parts, rather than them going off and doing their own thing.  As it happens, in 1993, the EAer used a sister method to E2E called CTA (Corporate Technical Architecture) that was the forerunner of todays EA methods, all of which call these things ABBs (Architecture Building Blocks), which we’re now careful to describe as a specification rather than as a technology (with selection criteria to allow appropriate technology choice of course!), but the basic idea remains. 

Reflection: the power of language (1) – words, words, words

Why did I choose that topic for my first “meaty” blog?  There are two quite distinct reasons.  

First and generically, it reflects the power of language. 

It has always struck me, right from my days as an engineering undergraduate, that the proper use of words is vital in every single profession.  In fact, I’d go so far as to say that using words properly is the key indicator of a mature profession – imagine if doctors spoke to each other in woolly terms!  But back to engineering – what’s the difference between “stress” and “strain”?  In everyday conversation, we use the words interchangeably:  “I’m under so much stress/strain at work”.  But to a mechanical engineer they represent two fundamentally different things – percentage elongation (strain) and force per unit area (stress).  If your discussing the movement of a bridge under load, you do not want to get that mixed up…

So why do we use words in such a woolly fashion?  “That’s an architecture”  “No it’s a design!” And how many different ways are there of getting the word “component” into a conversation, each and every one of them being different?  What's the difference between a "connector" and a "connection"? (For the avoidance of doubt, it's a big difference.)

Only when we can agree that we will use our words properly and unambiguously, both at at the coffee machine and the drawing board, will we genuinely be able to call ourselves professionals.

What is "Architecture"? It's not "Design"!

Put five IBM Architects in a room, ask that question, and stand back...  And, if the energy levels sag, ask the supplemental “what’s the difference between architecture and design?”

From the myriad of arguments that ensue, I see two common themes:

1.      “Architecture is the big picture stuff, design is the detail”

2.      “Architecture provides the guidance and governance to ensure good design”

Of course both ideas are critical – the first suggesting mechanisms for breaking large systems down into manageable chunks (“systems of systems” etc), while the second offers, at any scale, a sense of “that architecture would be a good basis for that design”.  

But I, for one, do not like homonyms (the same word meaning different things to different people); and therefore find such conflicting distinctions tiresome.  So, for many, many years, and based on my aero-engine days(*), I have been an advocate of definition #2, arguing that the complementary but fundamentally different ideas of architecture and design are scale free:  for example

·         there are “few” chip architectures underpinning many chip designs,

·         there’s “some” network architectures (SNA(!), TCP/IP) that form the basis of 1000’s of network designs

·         and (maybe my favourite), there are (were!) exactly five Gartner client-server architectures (“distributed presentation”, “remote presentation”, “distributed logic”, “remote data access” and “distributed database”) selected from over and over again – Cloud, anyone?

Maybe the best distinction between the two for me is… bridges – how many bridge architectures are there?  Wiki says seven.  But how many bridge designs are there?  Exactly the same number as “how many bridges are there?”!  The critical question therefore is – how do you chose the right bridge architecture for your specific(sic!) design?  It’s all a question of context…

PS:  (*)Aero-engine architectures:  for example, there are (or have been!) pros and cons to “two shaft versus three shaft; or “high bypass turbo fan versus turbo-jet”, or “reheat versus no reheat”…  Every engine design needs to choose between these architectural options.

To do, or to help do, that is the question

Originally, as with my home-grown PDP11 Finite Difference models of aero-engines, my early years in IBM’s were focused on “doing” – designing engineering computing and CAD systems for IBM’s customers using IBM’s hardware and software products (remember the IBM6150 or IBM5080?).

But, as I've aged, I've discovered a greater passion – a desire not so much to “do these things”, but to reflect on how these things are done; to expose the thought processes and thinking models that enable good system’s design.  This led naturally to working with other “methodologists” (those who study the theory of methods) down the years in the development of IBM’s methods… E2E, ISD, WSDDM, SI/AD, GSM and now UMF; always with a focus on helping others understand how to think as a systems design engineers; specifically to "my" community of engineers focused on IT systems.

I am an engineer; working with, not in IT

First and foremost, at least for the purposes of this Blog, I am an engineer.  I need to know how things are made so that I can make them work better for me and whoever else uses them.  As a child, it was my bike; as a youth, radios and "HiFi"; and as a fresh graduate it was aero-engines.  And it was around that time that I realised what I really love to do is make models.

Not models of the Airfix, Mecanno or Lego® kind (much more on these later!), but mental models – imaginings of the parts that make up the whole, and how the whole works as the sum of the parts (yes, I have a “Cartesian”, rather than “emergent” mind!).  So it was natural for me to exploit the newly available PDP11 in our department to build FORTRAN models of the insides of engines…

Then in my late 20's I joined IBM and discovered I could help others get more from their investments in computing than just payroll and accounting.

And there's something critical here – Since joining IBM I have not worked in IT, I have worked WITH IT, using it to do stuff for businesses. Yes, I have written code, but I intend the emphasis of this blog to be “how to think about using IT”, in no different a way than that of a building architect, as they “think about using” the talents of builders and suppliers, as those specialists give the architect the parts needed to design (and then oversee the creation of) our built environment - elegant, functional and maintainable buildings, bridges, towers and tunnels.

Ian's Other Blog

I'm a retired IBM Distinguished Engineer, and an IBMer. Maybe the latter needs little or even no explanation, but what's a DE?

Maybe the easiest, most practical explanation is that I was appointed an IBM DE in 2007 because my peers considered me capable of leading IBM's worldwide community of enterprise architects; an appointment entitling me to conceive, define, communicate and champion the approach (some may say method) to be adopted by several 1000 of my fellow IBMers as they create (or guide the creation) of their clients' EA.

It's been quite an experience, one in which I've learnt a lot about politics, people, power, persuasion, passion... and a little about computers.  I hope, in this blog, to share some of the insights hints and tips I've picked up on that journey... a journey that began many years ago