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".