On business-architecture and enterprise-architecture
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.
Tom,
I always enjoy your articles. Always thoughtful and I look forward to reading more on your thoughts about fixing EA.
Many thanks, Cort – much appreciated! (As I’ve just said to Gene, the next post in this brief series should be out tomorrow.)
Agreed that BDAT is only appropriate to EWITA (or EITA as I’ve been referring to it for a while now).
I’d think a analogous stack for true EA would be something along the lines of capabilities, services, markets & information (please note, I’m thinking out loud here, so this isn’t a fully-formed proposal by any means).
EITA would intersect EA, but in a subordinate, and hopefully, cohesive manner.
I’m working on a follow-on post, which should be out by somewhen tomorrow (though should I owe US folks an apology for posting anything on 4 July? 🙂 ).
The equivalent for the BDAT stack is actually the fractal usage of much the same pattern as in BDAT, with the base of that base-relative pattern being whatever is the current focus of the architecture and/or the current business-question. Capabilities, services etc are ‘items for focus’ (in that fractal sense), rather than BDAT-equivalent patterns in their own right.
(That may not make sense – apologies, I seem to be blithering in an over-technical way tonight. Too darn tired, I expect. But I hope it’ll make more sense when you see it in the next post, anyway?)
Hi mr tom. the big challenge for me, for the “EA’s”, is to make to understand the business and the enterprise clearly for all interested and the easiest way!!!!!!! one of the best way to do this, is think small by parts.. as you are making “solution architecture”
it is my idea…
Hi Juan – yes, that’s a big challenge (it always is… 😐 🙂 )
A very strong agree on the importance of solution-architecture, because that’s where the real work of architecture connects to the ground, the real-world. Yet on its own, solution-architecture is not enough: we need an architecture at larger scope (whole-of-organisation, at the least) to make sure that the individual ‘solutions’ connect up with each other, and support the whole as whole.
I would say that every would-be enterprise-architect should spend some years working as a solution-architect, because that’s where the skills to link things together would be developed. Yet it’s essential for solution-architects to keep expanding their scope and competences: extend outward from IT-specific to include into the scope other themes such as skills, security, lifecycle-management, financialisation, business-models and more. At a whole-of-enterprise scope, by definition we need to be able to cover everything that happens in the enterprise, over every possible timescale, from milliseconds or less to millennia or more. It does take a long time to learn how to do that… 🙂
(By the way, if you need materials in Spanish, do let me know – I have a colleague in Mexico who’s working on translations, and it would be useful if we could find out more about people’s practical priorities for us doing this.)
Good article, and I basically agree.
Starting from business capabilities and enterprise information objects are, for me a good starting point. Then you can model the enterprise services required to support those biz cap, and attached the necessary processes, roles and organization, in an overall enterprise design => business operating model.
Thanks, Marcel. Agreed that capabilities and services are a good starting-points – hence various of my tools such as SCORE and Enterprise Canvas. The aim of this post was somewhat different: to get people to think of BA as an integral part of EA, rather than as something separate – and that to do that, we need to claw the term ‘enterprise-architecture’ away from those who still insist on misusing the term to mean ‘detail-layer IT-architecture’. It’s only once we do that that, that we can usefully start to sort out the mess within business-architecture itself.
Absolutely right on the money (yeah, cruel joke there, Tom). So I will remind you of the old Yugoslavian proverb — tell the truth and run like hell.
Rae
“yeah, cruel joke there, Tom” – ooh, you cruel woman indeed… 🙁 🙂
“tell the truth and run like hell” – well, yeah, been kinda doin’ that for most of my life – does get a bit exhausting after a while… 🙁 🙂
(Thanks anyway, of course! 🙂 )
Completely agree that we are focusing way too much on Enterprise IT Architecture in traditional EA Frameworks such as TOGAF. But correct me if my understanding is wrong – one of the major objectives of EA is business-IT alignment and the other is driving transformation.
Based on the above understanding the traditional BDAT stack serves us reasonably well on the business-IT alignment bit. However, it comes up short on the driving transformation bit where Phase B of TOGAF the supposed business architecture seems to come up short.
What I envision as a business architecture should include what the business’ core capabilities are (the purpose of the business), what kind of business services are provided by the business and what the people organization supporting these services look like – somewhat similar to a business operating model. Thinking out loud. Look forward to hearing your views.
@Tom – as usual very interesting insight and a wonderful article – look forward to reading/discussing more in detail.
Thanks, Alok.
On “correct me if my understanding is wrong – one of the major objectives of EA is business-IT alignment and the other is driving transformation” – close, but not quite. I’d suggest that it would be more accurate if it should read as: “one of the common objectives of EA is improved business-IT alignment and another is driving transformation”.
The point here is that there are many other potential concerns and/or usages for EA: for example, strategic assessment of technologies and their future impact on business-models (e.g. IoT, AI, smart-cities, autonomous-vehicles), response to changes in legislation or standards (e.g. GDPR) or political/social changes (e.g. Brexit, ‘America First’, anti-immigrant sentiment, re-skilling for ‘one-industry towns), and support for futures-assessment of big-picture kurtosis-risks (e.g. global pandemic, global financial destabilisation, large-scale trade-war or ‘hot-war’, geospatial events such as magnetic-pole inversion or Carrington-type solar-flare event).
The BDAT-stack works well if and only if the focus for the current EA effort is IT-infrastructure. It can (and often is) misleading for anything else – and the distortion increases rapidly with increasing distance from that single arbitrarily-presumed ‘The Focus’.
On business-architecture itself, there’s a lot of good discussion. There’s the Alex Osterwalder school, who focus more on business-model; there’s the folks around Ashridge, who focus more on operating models; there’s Chris Potts, who focusses on EA more as enterprise-investment; and people like Lambert, who seems to have a broader scope, though I’ve forgotten the details. I’d agree re everything you’ve listed (capabilities, business-services, people-organisation), but we need to add a whole load of other themes just at the business-level itself: finance, for example, plus skills-management, lifecycle-modelling and associated succession-management, governance, standards/regulation-compliance and a whole load more. To be blunt about it, the ‘IT-business alignment’ concerns may not be easy, but they’re the easy bit of the architecture…
The other trap, that I warn about more in the following two posts, is that BA is not the place where we stop – it’s not the top level of the architecture. If we think it is, we’ll walk ourselves into a whole heap of pain without understanding how the heck we got there. 🙁 Context, context, context – it’s always about context. Which is what makes this kinda hard – especially when working with people who don’t understand just how important context really is.
>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].
In my historical explorations of the roots of enterprise architecture, I have never encountered the term “enterprise-wide IT-architecture” in any of the early documents. I have only found references to it in the later work of people like you and me. Can you provide a source that confirms this “older” usage? My impression is that the term “enterprise architecture” has been misused to mean something different from what one would expect it to mean since it was first proposed.
len.
Thanks, Len. Probably the first time I came across the term would probably have been in an slidedeck by Dana Bredemeyer (including sketches by Ruth Malan), ‘What it takes to be great in the Role of Enterprise Architect’, October 2002, and/or a matching Cutter Consortium article (same title, published in Enterprise Architecture, Vol.7 No.8, co-authored with Ruth Malan), dated 2004. (I have PDFs of both of those, and can send them to you if you’d like, though I probably ought to ask permission from Ruth and Dana first.)
In slide 6 of the slidedeck shows EWITA as EIA (Enterprise Information Architecture) plus EAA (Enterprise Application Architecture) plus ETA (Enterprise Technology Architecture), with ‘Business Architecture’ providing planning-inputs only (i.e. ‘anything not-IT that might affect IT’), with the whole wrapped up as ‘Enterprise Architecture’. In other words, almost exactly the BDAT-stack, as per TOGAF et al.
In another document or slidedeck of theirs (I’ll have a hunt for it, because I believe I still have it somewhere – if not, we can ask Dana and Ruth), they did a diagram showing the historical development of EA, from ITA (IT Architecture) to EWITA (enterprise-wide IT architecture) to ‘EWITA + BA’ (i.e. TOGAF8.1-style ‘business-architecture’ added) and onward beyond that point. It was that curve and the implied ‘onward…’ bit that was always crucial to me, and the rest of the team we had at Australia Post back in 2004-2006, because the ‘onward beyond IT-centrism’ was absolutely core to the people-oriented/whole-of-system aspects of our business-context there.
Dana and Ruth’s ‘EWITA website still exists: see http://www.ewita.com/ – it has content going back to at least 2001, and I’m fairly certain that in various places Dana said that he and others had been using the EWITA term for several years at least before that. (Again, we can easily check with them about that.)
Hope this helps? – and thanks again.
Thanks for the sources Tom. “Older” suggested to me prior to the pretty-much-from-the-beginning misuse, which would have been in the mid ’80s and early ’90s. Once we’re into the ’00s I suspect this is instead the first signs of pushback on the original misuse of the term, rather than than proper early use that subsequently went awry. When I started making the distinction between EA and EITA around 2006, it was definitely in response to my frustration with the “hijacking” of the name EA as an example of synecdoche, the use of name of the whole to denote one of its parts.
Thanks, Len. Would perhaps be good to pull Ruth or Dana into this, because they would know those older sources, and how far back they actually went.
For me, perhaps the crucial point was Dana’s/Ruth’s history-of-EA curve. It starts out showing that at the beginning there was no pretension of ‘enterprise’ about it, that it was just plain ‘IT-architecture’. It then expands the scale to the explicit EWITA – enterprise-wide IT-architecture – that indicates that ‘enterprise’ relates scale (large-scale IT) rather than scope (‘the enterprise’). BA then gets patched in on the top, to describe IT-related context – but it’s still clear that it remains being IT-focussed. And then there’s that onward curve, indicating that there’s further expansion still to come. Which is kinda where we came into the picture, isn’t it?
I don’t see that as pushback as such, more just Dana and Ruth being a darn sight more careful about their terminology than most of their peers. Which, knowing them (or Ruth, at least, in my case), doesn’t surprise me at all. 🙂
References to older definitions usually end up going back to documents from NIST, IBM Journal, etc. PRISM is another source that Len brought to light and outlined in a JEA article.
I have offered commentary on this topic – see https://www.linkedin.com/pulse/origins-evolution-enterprise-architecture-peter-murchland
Thanks for that link, Peter, and the points and references that you’ve given in that post.
My only concern is that all of these relate to the relatively-recent developments of IT-centric ‘enterprise’-architecture (i.e. EITA or EWITA), with no acknowledgement of any prior-art at all. This leads to the same circular argument that people like Graham Berrisford and Matthew Kern are wont to make, that (their concept of) ‘EA’ begins with IT, and therefore IT and IT-related topics are the only valid concerns for EA.
If, by contrast, we do include prior-art from earlier periods, we gain a much richer and more realistic picture of what EA as an ‘architecture the enterprise’ would entail. For example, the Dowding System (UK Air Defence, 1930s-1940s https://en.wikipedia.org/wiki/Dowding_system – still the core basis for most air-defence systems today), Walt Disney’s Disneyland and EPCOT theme-parks (1940s onwards), Ford’s ‘integrated factory’ concept (1900s-1930s) or the New York and Erie Railroad (combined org-chart and capabilities/services-model, 1855 https://commons.wikimedia.org/wiki/File:Organizational_diagram_of_the_New_York_and_Erie_Railroad,_1855.jpg ). If you wished, you easily take this back at least the Roman Army (with its flows of people, materiel and information), and probably much further back again (such as to the financial and other records of the Hittite empire in c.1250BCE, or equivalents in the early Chinese dynasties). So although the (much-misused) label of ‘enterprise-architecture’ is, yes, relatively recent, the overall practices of what we would understand as enterprise-architecture go back a very long way indeed.
Tom
I agree that there are some fundamentals relating to “organising” and “management” that precede any of the “recent” frameworks which have emerged under the umbrella of systems thinking and architectural thinking – no matter what entity these thinking tools were directed towards.
In the last twelve months, I have read “The Puritan Gift” and “My Years with General Motors”, both of which highlight some important developments in organising and managing. Perhaps it is time to write an article that draws out these long-standing fundamentals, reminding us that not all that sounds new is necessarily that new!
>that (their concept of) ‘EA’ begins with IT, and therefore IT and IT-related topics are the only valid concerns for EA.
When people say things like this, I imagine someone from a different profession saying the analogous thing about their profession, e.g.:
Medicine began with leaches and trepanning, so leaches and trepanning are the only valid concerns for medicine.
Aeronautical engineering began with small gasoline engine powered biplanes, so small gasoline engine powered biplanes are the only valid concern of aeronautical engineering.
Yep. :wry-grin:
(Re “Medicine began with leaches and trepanning, so leaches and trepanning are the only valid concerns for medicine”, I read the BMJ (British Medical Journal) quite often – and yes, we’ll occasionally come across assertions remarkably similar to that one even now… 😮 🙂 )
>My only concern is that all of these relate to the relatively-recent developments of IT-centric ‘enterprise’-architecture (i.e. EITA or EWITA), with no acknowledgement of any prior-art at all.
My “historical summary of EA” is limited for practicality’s sake to things that called themselves “EA” (usually an egregious exaggeration) or that directly preceded things that called themselves EA.
I agree with Tom that people have necessarily been practicing some form of “real” EA since the dawn of time, even if not explicitly or particularly well.
And for the record, the JEA article about the PRISM report was by Roberto Rivera.
len.
Thanks, Len. We do need to keep reminding people that ‘the architecture of the enterprise’ is not new, and that some (maybe many?) of the modern practices are almost trivial by comparison with some of those older analogues/examples (especially under the conditions and technologies of the time).
Finally catching up on my reading …
I’ve seen so much of start where you are and decide what changes you want to make.
What is missing that you have brought out many times is the idea of the heart … what’s the value system of the “enterprise” … how it impacts outside itself or how some other “enterprise” impacts your value system.
A previous post you mentioned changing away from “enterprise” due to the polluted definition. You were leaning towards “change architecture”. That would allow you to start anywhere, including the base if necessary.
Moving towards ‘change-architecture’? Yeah, true – especially as the term ‘enterprise’-architecture is so consistently misused that it’s become worse than meaningless.
But for much the same reasons, even the term ‘architecture’ is or is-fast-becoming meaningless as well. Hence why increasingly I’m pulling back to the simplest description I can give: ‘maker of tools for change’.