Definition as EA anti-pattern?
If you’re an enterprise-architect and you haven’t yet come across Ric Phillips‘ wonderful EA Patterns blog, go over there right now: you’re in for a treat! To mix metaphors somewhat, I’d have to say it’s a national-treasure for the trade. 🙂
Yet there’s a definite challenge for me there, too, because as Ric says:
My goal is to share good ideas about enterprise architecture without using a lot of words.
Uh… oops… sorry… 😐 Yeah, my output does use “a lot of words”, I’ll have to admit that…
But there’s an even worse challenge for me in his most recent post:
Architecture-by-definition is an anti-pattern.
The goal of a definition is to remove noise.
You add another layer of noise when your definitions are model-specific sub-definitions for commonly understood terms. For example: service, product, capability, or system.
Special definitions introduce an additional cognitive load that easily outweighs the benefits of a more sophisticated model.
Ouch indeed – because I’ve put a lot of effort into precision on definitions on terms such as service versus product, or service versus function versus capability, or the distinctions between ‘organisation’ and ‘enterprise’. (Use the search-box on this page – to the right of or below this post – to do a web-search here for those terms: you’ll soon find some of the relevant posts. A fair few slidedecks, too. A heck of a lot, overall. Oh well.)
To be slightly more fair to myself here, most of it has been about precision of terminology for use within EA itself – not necessarily for use outside of our own discipline. Much like building-architects, we need precision of terms in some places, where others might get away with much looser terminology. (Though that loose usage is itself often highly problematic: witness the chaos caused by the near-random meanings assigned to ‘business-process’ versus ‘business-service’ versus ‘business-function’ versus ‘business-capability’ verus ‘business-unit’ and so on and so on. Sigh…)
But if Ric is right, then it’s possible – probable? – that all I’ve done is added to the confusion and ‘noise’. Has it all just been a waste of everyone’s time? Yikes… 🙁
Your opinions and comments, perhaps?
The trouble is with what Ric calls “commonly understood” terms. How do we know we have such a common understanding? Of course, the *usage* of a term is the best indication, but often, different people’s usage of a term is close, but not really the same. How do we detect small but important differences?
An example like “business function” shows that there are a lot of ways to use a term, all slightly different, but with important consequences. Nevertheless, having “special” definitions that deviate too much from some common understanding is indeed an extra cognitive load that we should avoid.
Furthermore, the level of precision needed in EA is lower than in e.g. software architecture. The closer to actual construction you are, the less ambiguous your terms must be. Maybe the IT background of many enterprise architects has made them biased towards higher precision than needed at the higher abstraction levels of EA.
I think that the right level of understanding may also be reached (at least partially) through explicit *conversation* about the terms used and the architecture as a whole, not just by having some *define* the terms and expect others to simply use a term in the defined way. But that conversation also requires an extra effort.
“The trouble is with what Ric calls “commonly understood” terms.”
Yes, exactly: even a small amount of gentle enquiry will usually indicate that the perceived meanings of the terms are neither commonly shared, nor even understood! (A bit like how ‘common sense’ is usually neither… :wry-grin: )
“The closer to actual construction you are, the less ambiguous your terms must be.”
Very good point, though I’d be wary of suggesting that the inverse is therefore true – i.e. that the further away from actual construction, the more ambiguous the terms must be. The whole point of abstraction is that it allows for more variance and more generality, but that’s not the same as ambiguity. Hence one of my not-so-minor obsessions, that we need to be precise about meta-definitions of terms such as service, function, capability, asset and so on, so that we can then deliver the required precision at the concrete level.
This comes back to Gene’s point below about “the eleven definitions for ‘service’ all cohere in a fundamental way”. The problem we have right now is that because we don’t have clarity at the meta-level, those woolly ambiguous sort-of-abstract-but-not-quite terms such ‘business function’ end up being used as would-be anchors for necessarily-precise terms at the concrete level – but since those ambiguous terms don’t cohere in any fundamental or consistent way, we risk ending up with an unusable mess.
“I think that the right level of understanding may also be reached (at least partially) through explicit *conversation* about the terms used and the architecture as a whole”
Yes, strongly agree – hence my earlier posts ‘The meaning of process‘ and ‘The social construction of process‘.
“But that conversation also requires an extra effort.”
Yes, exactly. Yet the hard part seems to be in convincing the various parties that that ‘extra effort’ is indeed important… 🙁 It’s been one of the hardest challenges in my enterprise-architecture practice, anyway.
I can see two sides to the definition issue. Overloading words can make things more complex (e.g. Merriam Webster has 11 items under the definition of ‘service’, none of which are specific to Enterprise or IT architecture), but it can also serve to provide shortcuts to understanding. The eleven definitions for ‘service’ (and that’s just the noun form, by the way) all cohere in a fundamental way. The word service immediately invokes a certain abstract mindset that is then specialized by the usage. I see that as enhancing clarity rather than adding noise.
@Gene: “The word service immediately invokes a certain abstract mindset that is then specialized by the usage.”
Exactly! As in my comments to Marc above, that to me seems to be the real key to it all: contextualised specialisation, driven by a meta-definition that supports consistency at the abstract layer.
I believe there are too much efforts spent on definitions by enterprise architects. Getting a precise definition is indispensable in science, but I understand EA more of an art than a science, and more of a practice than a theory. I fully agree with Ric Phillips that adding "special definitions introduce an additional cognitive load". But that has also another negative effect. Business people see EA as foreign when for example the legal meaning of ‘service’ has little to do with EA and SOA meaning of ‘business service’. And then EA attempts to solve this usually result in having them not only further away from business but also further away from IT. Another silo.
Thanks, Ivo. These are perhaps harder points to answer, exactly as you’ve pointed out in your blog-post linked-to above.
David Brakoniecki, in his comment to that post, brought up a couple of really important points, about “a need to rationalise the facts into a predefined world view… this is often about being right, than furthering understanding”, and also about trust, or lack of it – “Without trust, then you are essentially negotiating a contract”, and so on. To me, it’s essential to gently dissuade ‘right-making’ around definitions (“I am right, therefore you are wrong”), and also create conditions where the requisite levels of trust can be created and maintained. None of which is easy…
Both you and David wrote about definitions arising out of the practice – and yes, I agree, mostly. The catch is that some definitions and understandings must be clarified before we go too far into the work, otherwise we end up with Mars Climate Orbiter-type problems, or worse. Hence why I argue for explicit meta-definitions that don’t claim to be ‘the definition ‘, but do provide a solid anchor for contextually-oriented definitions at the level of real-world practice – much as Gene indicates above.
“Business people see EA as foreign when for example the legal meaning of ‘service’ has little to do with EA and SOA meaning of ‘business service’.”
Yes, that’s another really important point: hence although I argue that we do need precise abstract-layer meta-definitions, in general we should keep those meta-definitions to ourselves as EAs, otherwise we’ll just confuse people and muddy the waters even further, exactly as you say. An abstract meta-definition is a source or anchor for a contextually-dependent concrete definition: we can use a meta-definition as a real-world definition in some circumstances, but there’s no certainty that we could or even should attempt to do so in all circumstances.
A meta-definition is used as anchor because it’s useful to do so – not because it’s purported to be ‘true’. That distinction is extremely important.
Thanks again, anyway! 🙂
I read that line in your post as: “Architecture, by definition, is an anti-pattern.” I couldn’t relate to that. I went to Ric’s blog (thank you for the reference) and found he wrote: “Architecture-by-definition is an anti-pattern.” To me those hyphens made all the difference.
Oliver – very good point. However, I copied the quote direct from his blog, so I can only guess that he’d hit the same problem himself and edited the text to add the hyphens.
I’m in a bit of a quandary here, because I try to avoid editing my posts, but I guess this is one where I really do need to do so – especially if Ric has changed the source-text as well.
[Note: I’ve now edited the text to reflect your suggestion, but it now means that your comment above no longer quite makes sense – which is potentially unfair to you. So for anyone else reading this later, I just need to record that the original first line of the quote here from Ric’s site read “Architecture by definition is an anti-pattern”, rather than the current “Architecture-by-definition is an anti-pattern” – and hence your comment was indeed valid when you wrote it! 🙂 ]
Thanks for warning me of this, Oliver – it was a direct quote at the time, but it did need that fixup with the hyphens in order to make sense clear there.
The perennial problem of understanding what others are saying!
which is the difficulty experienced when joining any new clique or enclosed society.
It is just as much a problem for non “C” level staff to understand Boardroom chat as it is for others to join in discussions with IT people.
It is a problem for Health professionals (Doctors, consultants and Nurses)to know how to discuss a patient’s health with the patient!
There is an argument(like the medical profession?)to create and use your own language, then it can be clearly defined and at least the trained people can understand the trained people.
Except that the terms will leak out and the meanings will become diluted as more untrained people try to use parts of the language without the training.
We cannot afford to spend 5 years training our IT and Business staff in the use of a common language, the solution is to use terms and define them (constantly)I guess. For modelling systems the terms do need to be defined, otherwise we cannot verify or apply the models. If the definitions are to esoteric or contrary to popular usage, the model will fail in at least one of its aims – that of communication.
— “The perennial problem of understanding what others are saying!” – yep. 🙁 🙂
— “It is a problem for Health professionals (Doctors, consultants and Nurses)to know how to discuss a patient’s health with the patient!” – great example! (I come from a medical background – both my parents were general-practitioners, and my mother still has the BMJ delivered here each week – so I have a fair bit of first-hand experience of that point…)
— “Except that the terms will leak out and the meanings will become diluted as more untrained people try to use parts of the language without the training.” – that’s a whole suite of problems. The problem of ‘leakage’ of special-meanings that have been assigned to more generic terms is a huge one: the ‘special-meaning’ of the term ‘enterprise-architecture’ to mean the ‘the architecture of enterprise-wide IT’ is a particularly apposite point here.
— “We cannot afford to spend 5 years training our IT and Business staff in the use of a common language, the solution is to use terms and define them (constantly)I guess.” – to me, that’s where ‘Foundation’ trainings such as TOGAF Foundation and Archimate Foundation do have real value, because they do ensure that people entering a new space have at least some understanding of special-terms and special-meanings, and, perhaps more important, that such ‘uncommon language’ is in use there. On “define then constantly”, perhaps see my post ‘The meaning of process‘.
— “For modelling systems the terms do need to be defined, otherwise we cannot verify or apply the models. If the definitions are to esoteric or contrary to popular usage, the model will fail in at least one of its aims – that of communication.” – yes, that’s one of the huge wicked-problems we face: terminology is often necessarily ‘blurry’ or context-specific, but many model-types require it to be explicit, distinct and absolute. Hence why we need tools and model-types that either allow the blurriness, and/or at least allow us to add a rider to explain the special-meanings applied to any terms.
One of my former clients (Telstra, in Australia) maintained a ‘jargon-buster’ section on their intranet, specifically to tackle these issues. It’s a tactic I’d strongly recommend for use elsewhere.