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…  ?