On business-architecture and enterprise-architecture
Blog: Tom Graves / Tetradian
I know, I know, yes, I really am trying my hardest to break away from the ruination that is current ‘enterprise’-architecture. Yet I still keep getting dragged back there, every time I try to take a step away…
The latest has been been some comments on my earlier post ‘The bucket-list – changing direction‘, and in particular this one from Andras Szakal:
Tom – The fix is not to suggest that Enterprise Architecture needs to change but rather a practice of Business Architecture is necessary. Which is where we are heading. The challenge is that most EA practitioners land in various camps on the application of EA. In truth the current practice of EA can cover a variety of organizational / business areas and is certainly not limited to just EA-IT. But businesses leaders define these distinctions not standards bodies and we must be flexible to accommodate the landscape. Your observations seem more applicable to the evolving practice of Business Architecture.
The short answer is that yes, that’s one possible fix. But it risks being the kind of ‘fix’ that’s best described as ‘duct-tape architecture’ – in other words, a bad kludge on top of an already abysmal kludge.
The key problem here is that what most people call ‘enterprise-architecture’ is actually a contraction of an older and more accurate term: ‘enterprise-wide IT-architecture’ [EWITA]. Which no doubt seems fair enough at first – after all, ‘enterprise-architecture’ is a useful shorthand for EWITA. The catch is that that contraction becomes dangerously misleading when we move beyond an IT-only domain, and outward towards the enterprise itself.
The beloved BDAT-stack that underpins TOGAF and so many others of the mainstream ‘EA’/EWITA-frameworks is, in essence, the view looking upwards from the base of that stack:
A BDAT-type stack is always base-relative: by definition, the focus for the architecture must always be whatever’s at the base of the stack. For BDAT itself, that’s IT-hardware. If we follow the actual logic of the BDAT-stack, then what we get, for TOGAF, is as follows:
- Infrastructure-architecture (IT-hardware): primary focus for all architecture review
- Information-systems architecture (IT-applications and data): immediate transactional-context for IT-hardware (i.e. the users of IT-hardware)
- ‘Business-architecture’: indirect context in which apps and data would be used, such as to impact on IT-hardware (aka ‘anything not-IT that might affect IT’)
The point here, that way too many people still miss, is that we cannot run a BDAT-stack backwards: it is always base-relative. The mistake that is made time and again by users of TOGAF et al. is that they assume we can start anywhere in the stack – but if we do that from anywhere other than the base, the result gives us a scope that can be (and usually is) dangerously incomplete. For example, if we were to start at what TOGAF claims to be ‘Business-Architecture’, the view would not look like the BDAT-stack, but something more like this:
— in which many of the services we need to to review would not be IT-based at all. Yet if we use the BDAT-stack, then by definition almost every architecture-detail must focus on IT-hardware – with the result that, from a literal ‘the architecture of the business of the business’, much of what we need to address in the architecture would cease to be visible at all.
(That’s why, at Australia Post, more than a dozen years ago, we abandoned trying to use TOGAF and the other mainstream ‘EA’-frameworks for our enterprise-architecture: we’d learned the hard way that their rigid reliance on the BDAT-stack meant that they were hopelessly misleading for anything other than the most minute fragments of our real business scope.)
This what the classic BDAT-based ‘enterprise’-architecture frameworks tell us is the full scope of EA:
The catch, as above, is that a BDAT-type stack is always base-relative – in this case, focussed on Technology Architecture, the architecture for IT-hardware.
Which means that, by definition, such ‘EA’-frameworks can meaningfully answer only one business-question: “What is the most appropriate way to organise our IT-hardware?”
Which, clearly, is not enough – not these days, at any rate…
In short, the classic IT-centric view of ‘enterprise’-architecture will no longer suffice to meet all of our needs. So what Andras and others propose as ‘the answer’ to that problem is to build a new “evolving practice of Business Architecture” ‘above’ the classic ‘enterprise’-architecture:
But just one glance at the graphic should show us what’s wrong with that approach: it means that we now have two scopes called ‘Business Architecture’, describing different things in different ways with different players, different stakeholders, different skillsets and more. Not A Good Idea…
And yes, it gets worse, because sooner or later someone who’s doing this new ‘business-focussed Business Architecture’ is going to realise that there’s a lot more involved than just the business itself – we need to explore and understand the context for that business. In other words, the architecture of the shared-enterprise within which that business will operate. Which means that we end up with an overall concept-model that looks like this:
Which gives us business-architecture placed both ‘above’ and ‘below’ enterprise-architecture, twice? And still everything centred solely around IT-infrastructure? Yuck… – that’s really Not A Good Idea…
In short, it’s the wrong kind of fix for the problem we face here – a bad kludge on top of a bad kludge. It’s the kind of pseudo-‘fix’ that arises only because some people still refuse to recognise that using the BDAT-stack to centre ‘enterprise’-architecture solely around IT-hardware was a howling mistake in the first place.
I’ll describe in a follow-on post a bit more of the detail on what we actually need to do to fix this mess.
First, though, the right fix is to acknowledge that business-architecture is, by definition, part of ‘the architecture of the enterprise’.
The right fix is to acknowledge that business-architecture is just one domain amongst many, under the overarching umbrella of ‘the architecture of the enterprise’.
But most of all, the right fix mandates that yes, we do have to change ‘enterprise’-architecture: we must stop misusing the term ‘enterprise-architecture’ for something that isn’t enterprise-architecture.
Simple as that, really.
Leave a Comment
You must be logged in to post a comment.
