Data-architecture 101 and the naming-problem

The echoes of the ‘naming-problem‘ around business-architecture and the like continue to rumble on, this time via another happy Twitter-exchange with Ron Tolido:

• rtolido: @tetradian just show me the non-IT people that invented #entarch and / or #bizarch 🙂
• tetradian: @rtolido we’re in a circular-definition here: what you call #entarch or #bizarch is whatever was ‘invented’ by IT-people… //  crucial problem is that IT-people labelled as ‘enterprise architecture’ to something that wasn’t ‘architecture of the enterprise’ // likewise with IT version of ‘business-architecture’, which _isn’t_ ‘architecture of the business’ // once we sort out that mess, it becomes obvious IT-people did not invent it – but until then, we have those circular-definitions… // non-IT-people: Deming, Boyd, Beer, Alexander, even Taylor, for heavens’ sake…
• rtolido: @tetradian All true! Just pointing to the actual roots of both #entarch and #bizarch . Not saying it’s a good thing per se.
• tetradian: what you’re doing at present is propping up _fundamental_ mistake: mislabelling of ‘IT-view of business’ as ‘business-architecture’ // ‘Open Group Cert in IT-view of Business’ is fine – just don’t call it ‘business-architecture’, because it isn’t! 🙂 // Data Architecture 101: don’t assign names to things that don’t mean the same as what those things actually are! 🙂

And that last point is actually a good idea: apply a bit of bog-standard data-architecture practice to this problem. Let’s look at this whole mess from the perspective of Data Architecture 101:

— Step 1: A core principle: all entities shall be assigned meaningful names or terms – i.e. that the assigned name shall correspond to the ‘natural meaning’ of the entity.

— Step 2a: If a term that is currently assigned to an entity does not match the ‘natural meaning’ of the entity but is not in common use, the updated name for the term shall be promulgated, and action taken to dissuade use of the former misleading-term.

— Step 2b: If a term in common use is currently assigned to an entity but does not match the ‘natural meaning’ of that entity, an architectural ‘waiver‘ or ‘dispensation‘ shall be issued, acknowledging the current usage of that term.

— Step 3: If a waiver is issued, the waiver does not mean that the misleading usage is acceptable, but rather that although the fait-accompli is accepted in the present, all efforts must be made to prevent the misleading-term from becoming further entrenched, and every opportunity taken to promulgate a replacement ‘natural-meaning’ term.

This is basic stuff, the kind of routine data-architecture work I was doing twenty years ago and more. Software-coders do it every day; web-designers do it; database-administrators do it. But not, apparently, the people who purport to maintain the formal standards for this kind of work. To use a certain famous phrase, “this does not compute…” 😐

Let’s look at this in a bit more detail.

First, that principle from Step 1, the notion of a ‘natural meaning’. A term or entity can of course be assigned any name at all: sometimes projects and the like are intentionally assigned misleading names, for security purposes or because they’re being used only as ‘working title’ or suchlike. Sometimes such names do stick, misleading or not: ‘tank’ is a classic example. But in general – especially in a data-architecture or in any part of an enterprise-architecture – an entity should be assigned a name that aligns with its use and function: for architectural purposes it doesn’t help anyone if we decide to use the label ‘Glue Pot’ for a delivery-truck, for example, or ‘Salmonella Breeding Station’ as the label for the cafeteria business-unit. In general, it’s a lot more helpful if we call a spade a spade, and so on.

[We can take this a bit further, perhaps – hence the old adage that “An Englishman calls a spade a spade, but an Australian calls it a bl**dy shovel”… 🙂 ]

Hence the notion of ‘natural meaning’, that in order to minimise the potential for confusion, things should be named according to what they are or what they do.

And a simple test for ‘natural meaning’ is inversion of the term: if the inversion gives the same meaning as the assigned term, it’s more probable that, overall, the term won’t cause confusion. (There’s a proper grammatical-term for this inversion, but I’ve forgotten it: someone remind me, perhaps?) Take ‘data architecture’, for example: the inversion is ‘the architecture of data’, which in both cases is what actually happens in the practice of data-architecture – so we can be reasonably comfortable that we have something close to ‘natural-meaning’ there. In practice, ‘data-architecture’ is a term we can trust to make sense.

Likewise ‘security-architecture’, as the architecture of security; or ‘brand-architecture’, as the architecture of the relationships and the like between business brands;  or ‘IT-infrastructure architecture’, as the architecture of the infrastructures of IT-systems. These all make clear sense, whichever way round we put it; and keep the same meaning, whichever round we put it.

But when we try this inversion with the supposedly-‘official’ usages of ‘enterprise-architecture’ or ‘business-architecture’, it just doesn’t work:

— enterprise-architecture:

• natural-meaning (from inversion): the architecture of the enterprise (i.e. organisation as a whole, plus extensions into the value-network and overall ecosystem within which it operates)
• common-usage in TOGAF, FEAF etc: the architecture of the IT-systems in use within the organisation, with some reference to the usage of those systems within the organisation’s business

— business-architecture:

• natural-meaning (from inversion): the architecture of the business (or, more specifically, ‘the business of the business’)
• common-usage in TOGAF, FEAF etc: anything not-IT that might impact upon IT, organised and described solely in terms of its actual or potential impact on IT

In both cases the IT-oriented common-usage is a very long way from the natural-meaning of the term – which guarantees confusion as soon as we move outside of the narrow confines of an IT-oriented view. And in both cases that common-usage meaning describes only a very small subset of the scope of the natural-meaning – in other words, wherever the IT-oriented common-usage is dominant, it represents a serious term-hijack that blocks visibility of the remainder of the natural-meaning scope.

Which, in any competent data-architecture, would clearly indicate that have a couple of seriously-invalid term-usages here. Which means we need to do something about it. Which brings us to Step 2.

It’s clear that Step 2a can’t apply here, because both of these invalid terms are very much ‘out there’.

Which means that we move to Step 2b: we issue a waiver.

But we do not forget what a waiver actually means here, and what responsibilities it places on all of us, collectively, in terms of action we must take in future to correct the architectural risk. In particular, it does not mean that we simply throw up our hands in the air and say “oh well, it doesn’t matter” – because clearly it does matter, because equally-clearly that usage of the term will not make sense to anyone outside of the ‘in-group’ cabal. Instead, the waiver says that we must take action to correct the fault – exactly as with any other type of architectural fault.

Which brings us to Step 3. What we actually need in this case is the metaphoric equivalent of a full ‘Cease & Desist’ order, to demand that people not only stop all use of this misleading usage of the terms, but take action to correct all materials in which either of those two misleading usages occur. For example, TOGAF would need to be rewritten from scratch: given the natural-meaning, it wouldn’t be allowed to use the term ‘enterprise-architecture’ just about anywhere in the whole document, and ‘Phase B: Business Architecture’ would either cease to exist, or be reconstructed as a proper multi-domain structure, within which ‘the architecture of the business of the business’ is merely one amongst many other domains that can impact upon IT.

Let’s not beat about the bush here: that is what needs to happen. Anything less represents not only only an architectural risk on a major scale, but an ongoing risk whose impacts increase exponentially with every passing day.

Sadly, Reality Department indicates we’re very unlikely to get this – not least because it would require Open Group, CapGemini, Federal Enterprise Architecture, Gartner, Zachman and all the rest to recall every scrap of their past publications on ‘enterprise’-architecture, and rewrite the whole darn lot. But we need to say, and continue to insist, that this is what needs to happen in future. We do not simply allow them to continue promulgating these (and many other) fundamentally-wrong term-usages in the enterprise-architecture space.

That’s Data Architecture 101, as applied in a perfectly straightforward way to current ‘enterprise’-architecture – what the Americans call ‘eating our own dogfood’.

And if we aren’t willing to do it to our own work, why on earth should anyone else trust us to do it to theirs?

Pretty simple, really.

So, whatcha gonna do about it, folks?

—

One separate but related and very important addendum: I am not knocking TOGAF in itself here, nor anything or anyone else in the IT-architecture space. IT-architecture is extremely important, and Open Group and others have been doing sterling work in that space for many years. To my mind, no-one should doubt this, and I’m very happy to sing their praises on that part of the work, and invite and encourage others to do likewise.

All that I’m saying is that what TOGAF etc call ‘enterprise-architecture’ should not be called ‘enterprise-architecture’, for the simple reason that it is not ‘the architecture of the enterprise’.

Likewise the somewhat jumbled collection of bits-and-pieces that TOGAF and its ilk call ‘business-architecture’ should not be called ‘business-architecture’, for the simple reason that it is not ‘the architecture of the business’.

[The latter point should be obvious when we consider that TOGAF’s ‘business-architecture’ assumes that the entirety of the non- IT executive – in other words, the CEO, CFO, COO, CMO, CHO and any non-IT CTO, and all of their respective domains – can all meaningfully be lumped together as ‘the business’, with only IT needing aany differentiation from the rest. Anyone who’s had any dealings at executive-level will know that it’s, uh, not quite as simple as that? :wry-grin: ]

Best leave it there for now, I guess. Over to you?