On EA-framework columns

More from the email conversations with Michael Ellyett.

[Oops… this post’s gotten even longer than the previous one – better put in a ‘More’ link:]

This thread started by my saying that I was beginning to doubt whether we should use Zachman’s “What’, ‘How’ and so on to describe primitive-layer columns – that we ought to stick to descriptive labels such as ‘Asset’, ‘Function’ and so on instead. Michael commented:

Zachman starts with the interrogatives: what?, who?, how?, where?, why?, when? – and I propose to add which? – which way something (what) is presented. There many problems with semantics (i.e. with respect to how these terms are used) – but in general I think Zachman-like perspectives useful, and I think the idea of trying to achieve as normalised view of things as useful (obviously objects span views with their – methods, properties, messages, rules etc. – and concepts like inheritance, encapsulation are not elegantly dealt with in a normalised model – as per Zachman’s).

My “which” column (which way) – deals with modes, forms, media, mechanism, tooling etc. which don’t alter the inherent nature of what, but do alter the mechanism (not how something is done). If one applied Zachman to EA (self-referentially) one would see there is a gap in this area.

Applying “Zachman to EA (self-referentially)” is exactly what I’ve been doing. But there’s a subtle problem here which relates to the risk of confusing “a normalised model” (i.e. design – in this case, the meta-model layer) and the de-normalised models we need for implementation. What I’m asserting is that the presentation description (Michael’s ‘which’ column) is not a primitive – it’s de-normalised – and thus should not be present in a primitive-layer framework. The ‘which’ column is indeed useful as a design-layer perspective – as per another of Michael’s comments:

I have thought further about the issue of primitives – and I think the very term is misleading. I think (and have long called) the columns perspectives.

– but it’s at least one level above that core foundation. And at times we do have to be able to go right back to that foundation-level in order to be able to restructure what we’re aiming to do – otherwise we’re stuck with whatever assumptions happen to be locked into the composites implied by ‘process’ or ‘presentation’ or whatever, which in some cases are so extreme as to make re-thinking impossible. More on that in a moment, but to get there we need first to address another comment from Michael:

Maybe in some theoretical, philosophical, ontological ways one can prove that there are primitives, but I am not convinced. [snip] The very word primitives is risky – as the primitives are defined in terms of other primitives e.g. word (which are in turn defined in terms or other word ad infinitum)…

Agreed, any ‘primitive’ is a construct, but what I’m looking for as boundaries in the framework is a set of fundamental distinctions. For the root-level columns, for example, BPMN puts this quite well, by explicitly indicating four of the six categories I’ve used – event, function (‘task’), capability/role (‘swimlane’) and asset (a subset, as ‘data-object’) – and somewhat implies a fifth, namely ‘location’. (The sixth column, ‘decision’, is present in BPMN as ‘gateway’, but is clumsily handled and in a misleading way – IMHO 🙂 ) Looked at this way, Michael’s ‘which’ is indeed a perspective into the framework – the normalised model – but cannot be part of that layer of the model: it’s a view of a specific type of composite, a model of an interface between the primitive-layer function (‘how’) and capability (‘who’). The kinds of fundamental distinctions I’m on about are as follows:

  • asset: identified as countable, measurable ‘things’ of different kinds [of which more below], which can be directly associated with and in some sense ‘owned’ by the enterprise
  • function: identified as some kind of activity which causes a change to some asset(s), and/or results in decision(s), and so on
  • location: identified in terms of coordinates within some predetermined schema
  • capability: identified as an ability to create a desired change, decision etc –
  • event: identified as a coincidence between assets, locations, functions etc
  • decision: identified as a selected trigger-point at which an attribute of something indicates a change of meaning

Each is ultimately independent of the others, but needs to be linked to the others to become complete: for example, capability needs to be linked to function in order for anything to happen, but they can be recombined in any number of ways. A composite is architecturally ‘complete’ – i.e. implementable – only when all six types of primitives are represented: “<activity> was done with <asset> by <actor> at <location> on <event> because <decision>” (where ‘<actor>’ is itself a composite of capability and asset). A composite is re-usable and restructurable to the extent either that there is fluidity in the choices for the real-world implementations of each of these primitives, and/or that the composite is architecturally ‘incomplete’ – i.e. that one or more categories of primitives are missing from the composite’s specification. Sure, at the business level, this kind of argument will always sound “theoretical, philosophical” etc; but at the design of the meta-model – which is what we need in order to do enterprise-architecture development – this ain’t theory at all: it’s utterly fundamental to our practice.

The same kind of fundamental-layer distinctions apply to what I’ve called the ‘segments’. For example, for the ‘asset’-primitive, the key boundaries are concerns such as independence, ‘alienability’, transferability, ‘negatability’ and so on – but all in terms of that which can be ‘owned’ by the enterprise, which is what makes the whatever-it-is an asset:

  • physical assets: independent (exists separately from me), alienable (if I give it to you, I no longer have it); transferable (I can give it to you); not negatable (although we might have none of that type of asset, or be owed some of that asset, it cannot actually exist as a null or negative physical asset
  • virtual assets: independent (exists separately from me – mostly), non-alienable (if I give it to you, I still have it); transferable; not negatable (I can’t really have a null or negative idea, for example)
  • relational assets: partially-independent (exists as an external relationship between two or more entities), non-alienable (if I give it to you, I still have it – probably 🙂 ); not actually transferable (I can construct conditions under which an equivalent relationship is created, but I can’t actually give you the relationship); not negatable (though we could argue about that point… ::wrygrin:: )
  • aspirational assets: dependent (exists as an internal relationship with an entity, but not as an attribute of the entity); non-alienable; not actually transferable; not negatable
  • abstract assets: negatable (e.g. financial assets are alienable but may be negative, as debts)

Again, these distinctions may at first sound “theoretical”, but they sure as hell ain’t theoretical in practice. Huge problems arise with data-quality and many other kinds of quality if we make the mistake of assuming that there’s a one-to-one correspondence between physical objects and records of those objects – the Denver Airport baggage debacle being one famous case in point. As the media-industry is discovering to its cost, basing a business-model on the assumption that virtual assets can always be controlled by ‘productising’ them as ‘alienable’ physical things falls apart as a business-model once it becomes easier for everyone to keep the asset in virtual (and hence ‘non-alienable’) form. And that fine-sounding phrase “our people are our greatest asset!” becomes a recipe for disaster if – as all too often happens – someone fails to understand that it is the relationships with the people, and not the people themselves, that are the assets: the relationship gets ‘alienated’, in a different sense, and real quick, whenever that mistake occurs… In an IT-centric ‘architecture’, we might be able to ignore these problems (for a while, anyway…); but for a true enterprise-architecture we can’t take that risk. At all. Ever.

Same applies to the Cynefin-based distinctions I’ve used as the segment-boundaries in the ‘decision’ column: rule-based, analytic, heuristic, principle-based. These are fundamentally different from each other: the first two assume a causal world, whilst the other pair don’t; the first and fourth assume uniqueness (as absolute for all, and absolute for none respectively), whilst the others assume derivation from collectives.

And so on, and so on. These are the real primitives, the foundations for the meta-model for the meta-model for the meta-model, or whatever. Everything else – including Zachman’s ‘what’, ‘how’, ‘why’ and, especially, ‘who’ – are indeed perspectives into the whole: and that’s all they are. Which in certain, perhaps-subtle, but all too crucial contexts, is no damn use to us at all.

Sure, by the time we get up to the business level, what we’ll have is perspectives on perspectives, and composites of composites of composites; and that’s certainly all that we’d expect to show to others. But as architects, we do still need access right down to those root-level primitives – because that’s the only place where real fundamental change and redesign can take place.

Leave a Reply

Your email address will not be published. Required fields are marked *