How architectures fail – 3: Constraints
How do architectures fail? One way is that we make arbitrary and untested assumptions about constraints – so how do we avoid that trap?
- 1: Blurring between distinct rolesof architecture and design
- 2: Starting architecture too lateand/or finishing too early
- 3: Placing arbitrary constraintson content, scope and/or scale [this post]
As in the previous post, we’ll explore this fail using a modified version of the Zachman rowsas a common reference:
…where each row (or layer) downward adds further specific detail as we move towards the real, the ‘Now’ of action:
For this fail, though, we need to include and explore not just the Zachman rows or layers, but also all of the Zachman columns too:Who? What? When? Where? How? and Why? Yet we need to do this exploration properly – for which the first challenge is that the nature and labels for the columns will change as we move down the rows:
Even worse, though, is that there’s an entire dimension that’s missing from the Zachman framework. Like so many other ‘enterprise’-architecture frameworks, Zachman’s model assumes that the only type of asset that matters is data, the virtual – whereas in any real whole-enterprise context we’ll also need to address physical things, person-to-person relational links, and more-abstract aspirational-type assets such as brands:
In Zachman terms the asset-types dimension will apply in What, How, Where, and When – though in the layers where we need them, those will appear as Asset, Function, Location and Event, together with some aspects of Capability. In a bit more detail:
There’s also the related decision/skill-types dimension that will apply to Who and Why, in the form of other aspects of Capability (skill-levels) and Decision (complexity-levels). In a bit more detail:
The realisation-process only works properly when all of those dimensions and entity-types are fully supported. For example, the architecture must not just the ability to implement IT-based services, but services that can be implemented by any appropriate combinations of people, machines and IT:
One key example of why this is so important is that in business-continuity and disaster-recovery, we would otherwise have no way to recover if the IT-services were ever to break down – which, they certainly will at some stage, given the reality of Murphy’s Law and the like.
Again, though, classic IT-centric ‘enterprise’-architecture only works on an arbitrary subset of that overall set of dimensions – with potentially dangerous risks for business-continuity and the like:
Which further compounds the fail-risks for classic IT-centric ‘enterprise’-architecture from the previous post, by showing that can only address a subset-of-a-subset of the actual context and scope that we’ll likely need to address in our architectures:
And if the architecture and design will only address this subset-of-a-subset, how will it connect up with everything else in the overall architecture of the enterprise?
So, a reminder again, that in enterprise-architecture, a subset is not the whole.‘Enterprise-wide IT-architecture’is only one small subset of ‘the architecture of the enterprise’: don’t mix them up!
Also, and crucially, beware of ‘anything-centrism’: IT-centrism is a serious problem in enterprise-architecture, but so is business-centrism and the like. We ought to emphasise here that the problem is not in IT itself, but in any over-focus on a single arbitrary domain.
One key challenge we face is that many current architecture- frameworks are ‘something-centric’: they embed arbitrary hard-wired constraints on content, scope and scale. Again, though, it’s often not so much inherent in the framework itself, as in how that framework is used. For example, what we too often see is TOGAF done wrong, riddled with all manner of arbitrary unquestioned constraints:
…whereas TOGAF done right is essentially the same, but ensures that any constraints arise from conscious choice and deliberation, without any arbitrary boundaries on content, scope or scale:
So again, beware of IT-centrism, business-centrism, all forms of ‘-centrism’ – all of them will cause the architecture to fragment and fail.
Overall, perhaps the fundamental point to take away from all of this is that subsets of an architecture are always part of a larger whole. Yes, it’s true that most times we’ll only be working on a subset – but we must ensure that that subset is always connected to the whole. And ensure that the whole is always maintained as the whole, rather than fragmented, isolated parts.
Subsets are part of a larger whole: whenever we’re working on a subset, we must build and maintain ‘hooks’ that can connect each aspect of change to the broader whole. And we also need to do this for every stage throughoutthe realisation-stack.
Subsets are part of a larger whole: specialism in frameworks is often useful, but we must ensure that they ‘play nice’ with all other specialisms – and also take active steps to guard against any and all forms of ‘anything-centrism’.
Subsets are part of a larger whole: wherever practicable, use must use tools and frameworks that are self-adapting to the needs of each context – and ensure that any specialism in our frameworks needs to be optional, not hard-wired!
Subsets are part of a larger whole: that’s probably the one theme that always need to remember here – because our architecture will fail if we don’t remember it and act on it appropriately at all times…
To summarise, How to avoid Fail #3: Placing arbitrary constraintson content, scope and/or scale:
- Always start from the needs of the context – not hardwired assumptions!
- Always connect across the whole
- Always beware of potential risks from any form of ‘anything-centrism’
And a final reminder here that our real aim for any architecture is to improve effectiveness across the whole:
“Things work better when they work together, on-purpose”
So why do architecture? It’s because life is better for everyone when things work better,things work together,things work more on-purpose,as a more effective, unified whole.
And when we do take to avoid the traps in each of those three too-common causes of architecture-failure, that’s what makes all of this work become worthwhile.