Dump the BDAT-stack!
Blog: Tom Graves / Tetradian
For a viable enterprise-architecture [EA], now and into the future, we need frameworks, methods and tools that can support the EA discipline’s needs.
Yet there’s one element common to most of the current mainstream EA-frameworks and notations – such as TOGAF and Archimate – that actively blocks our way forward: the predefined, hardwired ‘stack’ of architecture-views that the respective framework acknowledges and supports.
There are a few variants, but the most common form is the ‘BDAT-stack‘ of Business-Architecture, Data-Architecture, Applications-Architecture, IT-Infrastructure (‘Technology’) Architecture:
It looks good, it’s clear, it’s simple, it’s easy to understand – and yet for most purposes it’s just plain wrong. The blunt fact is that any framework or notation that relies on the BDAT-stack is fundamentally unfit for almost any purpose in present-day enterprise-architecture.
What it was originally designed to do, and for which it was fit-for-purpose, was the architectures of large-scale IT-infrastructures. If all that you’re working on is technology-infrastructures for classic in-house ‘big-IT’ in industries such as finance, insurance, banking and tax, the BDAT-stack will do that job just fine. Yet that decreasingly-common need is all it’s fit for – and despite many claims to the contrary, it’s never actually been fit-for-purpose for anything else.
If we do try to use the BDAT-stack as if it’s fit-for-purpose for anything more than IT-infrastructure, it will always lead us astray – risking serious damage to the architecture, and worse.
But why? Where’s the problem? Doesn’t the BDAT-stack cover everything we need – Business, Data, Applications, Technology?
No, it doesn’t – though it’s true that many people in the EA field would still misinterpret it that way. But the blunt reality is that the BDAT-stack only makes sense as a descriptor for the context for IT-infrastructure – and should not be used for anything else.
The catch that most people still seem to miss is that the BDAT-type of frame is only a base-relative descriptor of scope – not of overall scope. In other words, it’s a context-descriptor frame that’s valid only for the domain at the base of the stack – which, in the case of the BDAT-stack, is that subset of technology that specific to IT-infrastructure:
- ‘IT-infrastructure architecture’ is the actual focus for all architecture-effort
- ‘Data-architecture’ is the architecture of the subset of data maintained on that IT-infrastructure
- ‘Applications-architecture’ is the architecture of applications that are run on that IT-infrastructure
- ‘Business-architecture’ is ‘anything not-IT that might affect anything-IT’ relative to that IT-infrastructure
The stack-structure only makes sense that way round – everything base-relative, looking ‘upward’ from the base.
We can’t run the stack ‘backwards’, or ‘downwards’: doing so puts artificial constraints on the scope – which is why TOGAF and its ilk so inherently and so automatically force us towards IT-centrism in every aspect of the architecture.
We can’t use the BDAT-stack to describe contexts for data-architecture, applications-architecture or business-architecture in their own right – to do it properly, each would need their own equivalent ‘stack’, placing that respective focus-area as the base of the ‘stack’.
The crucial point here, perhaps, is that the BDAT-stack is nothing special – it’s merely one instance of a generic architecture pattern, looking ‘upwards’ or ‘outwards’ from a chosen focus-area:
Hence for the business-architecture of an organisation, for example, we should not use the BDAT-stack, but another stack in which the organisation is the base of the stack:
When we look ‘downward’ from the service-in-focus, we need to be able to drill down into any or all of the services that support that service:
And a service may be implemented by any appropriate combination of people, machines and IT: for example, IT-infrastructure is supported by a vast swathe of other detail-layer services – such as described in ITIL, the IT service-management library – which explicitly include services provided by only by people, not other IT. Our architecture would be inherently incomplete if we were to constrain the description to IT alone.
For example, to describe a business-architecture, we’re likely to need to be able to see and describe any or all of the underlying services – whether or not they’re supported on in-house IT-infrastructure:
…whereas if we try to use the BDAT approach, it would only allow us to see or describe the subset of services that are built upon the respective IT-infrastructure:
The latter probably wouldn’t even be able to include cloud-based services or customer-maintained IT – let alone human support-services or non-IT technologies. For a data-centre, for example, we can use BDAT to describe the computers, but not the building they’re in, or why the building is where it is; we could describe the network cabling, but not the power-cabling or the cooling-systems. What kind of architecture is that?
A stack-type description is useful – no question. But we need to start with an understanding of how stack-type frames actually work: they’re always base-relative. What we need is not the single BDAT-stack, but a strong understanding of the pattern of which the BDAT-stack is merely one instance. The classic BDAT stack describes only the ‘upward’ view from its selected focus-domain, whereas what we need is the generic ‘Jellyfish pattern‘ that gives us the ability to describe properly both the context ‘upward’ and the supporting-services ‘below’:
Hence, for business-architecture, what we need as a context-descriptor that is not merely the top layer of the BDAT-stack, but something that looks more like this:
The key takeaway here is that the BDAT-stack will not suffice for any form of enterprise-architecture other than for the single very narrow, very specific domain of in-house IT-infrastructure – and we need to stop pretending otherwise.
In short, for almost all enterprise-architecture, we need to dump the BDAT-stack, and use the Jellyfish-pattern properly instead.
Which leads us to another perhaps-worrying point. The BDAT-stack is hardwired into every aspect of the TOGAF framework, and many parallel structures such as the Archimate architecture-notation. Yet as we’ve seen above, the BDAT-stack doesn’t work as a context-descriptor for anything other than IT-infrastructure.
So we perhaps do need to hammer this point home: the BDAT-stack hardwires TOGAF and Archimate to be usable only for IT-infrastructure architecture. They cannot be safely used for anything else at all.
What’s even more worrying is that everything in the current TOGAF and Archimate is built around the BDAT-stack. Yet once again, the BDAT-stack doesn’t work: it’s completely misleading for almost all present-day enterprise-architecture. Worse, it also tends to give us some truly horrible conflations, all of which are again deeply embedded in both TOGAF and Archimate:
But if we take the BDAT-stack out of TOGAF or Archimate, nothing makes sense any more. Without the BDAT-stack, the framework, the method, the notation and just about everything else there kinda collapses into a pile of inchoate, incoherent rubble – a bunch of disparate entities and ‘best-practices’ without anything meaningful to hold them together. Oops…
Which in turn kinda suggests that it’s not just the BDAT-stack that we need to dump: we probably need to dump TOGAF and Archimate too. (But that, perhaps, is another story for another time?)
Over to you for comment, anyway.
Leave a Comment
You must be logged in to post a comment.
