On business-architecture and enterprise-architecture – more detail
The key point from the previous post – ‘On business-architecture and enterprise-architecture‘ – was that we must stop misusing the term ‘enterprise-architecture’ for something that it isn’t.
And we can even fix TOGAF so that it doesn’t make that mistake any more.
There are some key things that TOGAF does get right:
- architecture is iterative
- architecture needs to connect big-picture aims with actual change at the operational level
- even with an iterative structure, there is still a definite overall sequence to the work
- technology (and IT in particular) is likely to be a necessary aspect of that work
Yet there are several key things that TOGAF still gets wrong about enterprise-architecture – even horribly-wrong, in some cases. These include:
- the iteration-structure needed is not linear (as per the TOGAF Architecture Development Method [ADM]), but fractal
- the focus for architecture-scope should not always be IT-infrastructure technology (as mandated by the BDAT structure that underlies ADM phases B/C/D), but instead allow any scope at any scale and any level
- a review of current trends in technology (as per ADM Phase H) is not sufficient as, nor maybe even relevant to, a ‘benefits-realisation / lessons-learned’ after-action review for iterative-development
- nowhere is the term ‘enterprise’ meaningfully defined (it’s not in ‘Definitions’, or anywhere else in the text)
That last point, about the meaning of ‘enterprise’, is where the current mess about ‘business-architecture’ arose, and is still evolving – mostly for the worse.
So let’s sort this out step-by-step.
First, ‘enterprise’. The core problem here, as per that previous post, is that there are two fundamentally different meanings of ‘enterprise-architecture’:
- the literal meaning, as ‘the architecture of the enterprise’ (whatever ‘enterprise’ might mean – we’ll come back to that in a moment)
- a lazy contraction of the term ‘enterprise-wide IT-architecture’ [EWITA] as ‘enterprise-architecture’ (as if IT is the only element in the enterprise that might need architecture)
Hence the first problem we face is that it’s the latter sense, not the former, that is embedded in TOGAF, FEAF, DoDAF, TEAF and virtually all of the ‘mainstream’ ‘EA’-frameworks, and in most discussions in the mainstream press. It’s also the reason why, at present, most who describe themselves as ‘enterprise’-architects still report to or below the CIO – not the whole board, as would be implied for the literal meaning of ‘the architecture of the enterprise’.
(For reference, our EA unit at Australia Post, more than a decade ago, did report to the entire board – and our remit was indeed ‘the architecture of the enterprise’.)
In short, most current usages of the term ‘enterprise-architecture’ imply something with a very different and much narrower scope than the term would literally mean. And the blame for that confusion lies squarely with the people who created and promoted those ‘EA’-frameworks – and yet who, now knowing that it is misleading and wrong, still promote that same mistake today.
One key outcome of that mistake is utter confusion about the relationship between business-architecture [BA] and enterprise-architecture [EA] – or, in short, where does business-architecture sit?
- If we use the literal meaning of EA as ‘the architecture of the enterprise’, then BA is, yes, one valid and important sub-domain of EA. That’s how we get the apparent validity of the BDAT-stack, as used in TOGAF and elsewhere: EA as Business, Data, Applications, Technology. For this meaning, BA would be positioned ‘within’ EA.
- If we use the lazy-meaning of EA as a contraction of EWITA, then BA provides the business-context for EWITA-as-‘EA’. In other words, BA as ‘the architecture of the business’ would be positioned ‘above’ EA.
Although the term ‘Business Architecture’ is used in TOGAF, it’s clear from a reading of ADM Phase B that it’s little more than a randomised grab-bag of ‘anything not-IT that might affect IT’ – and despite various claims to the contrary, it’s still not much about business-as-business. Which might at first seem sort-of fair-enough when we note that Open Group, in this example, is an IT-standards body – not a more general business-standards body. But the problem is that, in TOGAF, ‘business-architecture’ ends up being both a sub-domain within EA, yet also above ‘EA’ – both at the same time:
Hence the confusion. Lots of it.
So let’s disentangle that confusion.
The way out is two-pronged:
- be clear about the meaning of ‘enterprise’
- be clear about the fractality
(Doing so would also clear up the mess with ADM Phase H, as we’ll see in a moment.)
First, the meaning of ‘enterprise’. Perhaps the most important point is that, from an architecture-perspective, ‘the enterprise’ is not the same as ‘the organisation’. I go into this in some detail in my post ‘Organisation and enterprise‘, but the simplest way to summarise the difference is to say that ‘organisation’ is more about structure, whereas ‘enterprise’ is more about story – the emotive intent, the drivers, that give that structure a reason to exist.
(Another way to view this distinction: ‘organisation’ is ‘that which we are organising’, whereas ‘enterprise’ is ‘that about which we are organising’ – the surrounding context for that which we’re organising.)
At the whole-organisation level, there’s a set of relationships that look somewhat like this:
But the key point is that this isn’t just about the organisation as a whole: instead, this is fully fractal. For example, if we think of any given service as ‘the organisation in scope’, then ‘the enterprise in scope’ is the respective overall context for that service. We’d typically describe this overall-context in terms of at least three distinct layers ‘outward’ from that service – transactions, direct interactions, and indirect interactions:
And, when we look ‘downward’ from whatever it is that’s our current focus for the architecture, the same also applies, fractally, with services within services within services:
So whilst use of the BDAT-stack entraps TOGAF into giving us an architecture that can see only this:
…what we actually need from a fully fractal enterprise-architecture is more like this:
…extending ‘outward’ and ‘inward’ with services implemented not solely by IT, but by any appropriate combination of people, machines and IT:
Which brings us back to the TOGAF ADM again, because there is a simple fix to the TOGAF ADM that could give us all of this – enabling the TOGAF ADM to tackle any architecture scope and scale, with any content, any mix of sub-domains, at any level.
(For what it’s worth, I first proposed this to Open Group back in around 2006 or 2007 – well before the sad missed-opportunity that was TOGAF 9. A full decade later, they still haven’t gotten round to fixing that fundamental mistake. Oh well…)
All it requires is one quite small tweak to the way we frame scope in ADM Phases B/C/D.
In the present ADM, each of those phases specifies a scope, as per the BDAT-stack: Business, Information-Systems (Data/Applications), Infrastructure. Then, for each of those phases, separately, we then apply to the respective predefined scope for that phase what is, in effect, the same set of views as earlier above: transactions, direct-interactions, indirect-interactions.
So yes, the standard ADM does sort-of cover the full context of the overall predefined BDAT-scope – which would be fine only if that predefined IT-centric scope is all we’d ever need to cover in an ‘enterprise’-architecture. And it covers even that arbitrarily-constrained scope only in a fragmentary way, with different domain-specialists carving out out their own separate views of the architecture. Which is exactly what we don’t want in an architecture-of-the-enterprise.
But why not just switch the whole thing round? – and require those domain-specialists to work together?
We can do that if we drop the BDAT-stack and its hardwired assumptions about scope – and instead identify in Phase the respective scope for each iteration, based on the business-question with which we started the iteration.
Then, given that iteration-specific scope, move progressively down towards the detail in Phases B/C/D, respectively covering big-picture or indirect-context (Phase B), direct-context (Phase C) and transaction-oriented detail (Phase D). In each case we gather the information we need for each relevant time-horizon – so-called ‘present-state’ versus ‘future-state’ and so on. Again, all of this is fractal, and, overall, looks somewhat like this:
Which, incidentally, also gives us the basis for a more meaningful (or at least mnemonic) relabelling for each ADM phase:
- A: Aims – business-purpose or business-question for this iteration, plus success-criteria
- B: Big-picture – big-picture overview of scope implied by aims
- C: Context – direct context and stakeholders for the scope implied by the aims and revised at big-picture level
- D: Detail – detailed review at the transaction-level scope as implied by the aims and revised at big-picture and direct-context level
- E: Evaluate options – assess trade-offs, gap-analyses, time-horizons and more, for the full set of domains in the full revised scope
- F: Find solutions – define actions to implement the respective changes, with any implied fractality of actions
- G: Governance – apply appropriate governance/metagovernance (Agile, Waterfall, whatever) to each of the identified actions for and within implementation, again iteratively and fractally (i.e. not so much DevOps as ArchDevOps)
- H: How did we do? – enact after-action review for benefits-realisation and lessons-learned, in context of the success-criteria from Phase A, and to identify potential needs for future iterations
Note again that – unlike the standard TOGAF-ADM – all of this is fully fractal:
- it can be applied in exactly the same way for any scope, any scale, any level, any type of implementation
- iterations can be nested to any required depth, with each iteration taking the exact same form
- the same overall method is applied in all domains – business, security, branding, applications, finance, data, skills, applications, buildings, IT-infrastructure, whatever
- the same overall method is applied to all modes of implementation – every possible combination of people, machines and IT
That fractality might at first seem somewhat complex, but its pattern-based approach actually makes management of views into the overall architecture vastly simpler than with trying to predefine every possible type of scope. Hence, for example, that same fractal pattern underlying the actual set of relationships behind the BDAT-stack:
Yet when we look at business-architecture, the pattern indicates that it’s not the same as that above, as implied by the BDAT-stack, but more like this:
This fractality also helps us make more sense of the CIO’s view of the business-world – which doesn’t properly match up with the BDAT-stack at all:
And even for IT-oriented architectures, we could say and show much the same for IoT (Internet of Things), cloud, mobile, embedded, wearable, distributed-AI and many, many more.
We get all of that, and more, if we dump the BDAT-stack from our architecture-frameworks, and instead use proper, meaningful relationships between ‘organisation’ and ‘enterprise’.
Enough on that for now: over to you for comment, perhaps?