Ending the shoot-out at the EA Corral

Anyone who’s involved in enterprise-architecture will know there’s a huge ongoing clash-of-the-mindsets between those who think it’s all about IT and that EA should belong as part of the IT-department, versus those who think it’s about a much larger picture and probably belongs more under strategy or some such. So, who’s right? And how do we resolve the fight so that we can all actually get some work done?

Well, my own views lean strongly towards the second camp – enterprise-architecture as ‘the architecture of the enterprise’. And of course I’m right, so of course the IT-centric guys are wrong. That’s obvious, isn’t it? 🙂

Uh… no…? Perhaps not…?

And since we claim to be systems-thinkers, perhaps we should apply a bit of that systems-thinking to our own context here?


First thing that came up about this this morning was that phrase of de Bono’s: everyone is always right, but no-one’s ever right. Sure, enterprise-architecture is wicked: but enterprise-architecture itself is a wicked-problem. Everyone has ‘the truth’ from their own perspective – but it’s only ever a partial perspective onto the whole, hence can never be ‘The Truth’ about that whole.

In other words, everyone’s right, in their own perspective about EA – but none of us is right, has ‘the truth’ about the whole of EA.


Or, perhaps more accurately, oops… a heck of a lot of fight about something that shouldn’t be a fight in the first place…

Hence what really came up for me this morning was that this is remarkably like the fight between scientists and engineers that I described in the ‘Unbreaking‘ post:

In the research-laboratory, the scientists’ work was about big ideas with big scope, experimental approaches, explorations that might ultimately dead-end anywhere, and materials-tests that might well run for years.

The engineers’ work was often also about experiments and tests, but on a smaller scale with smaller scope and on much shorter time-scales: it was always about getting this job done, right here, right now. Not about far-distant ideas, but about real results, for real clients who wanted real answers really right now, or yesterday for preference. No waiting about, they said, we get things done! Not like those airhead ivory-tower scientists: we guarantee to get any job done in three days max, they can barely get a job done in three years!

Sound familiar, perhaps? 😐

To take my own example, a lot of the tools I’ve developed are about working with strategy and the big-picture, with timescales often measured in years; many of the ideas that I’m working on at present in the ‘Really-Big-Picture EA‘ scope won’t come to fruition for many years to come, and maybe never at all. In that sense, much of my work sits in a metaphoric equivalent of the Scientists there.

[Don’t get too tangled up in titles here, though. For example, unlike certain people in this space, I don’t make any spurious claim to be a ‘scientist’: in practice the reality-oriented way I approach things is much closer to that of an engineer, though probably the closest title would be technologist or ‘toolmaker’. The point is that in its overall aim, this type of work is more about the Scientists’-style emphasis on far-future rather than the Engineers’ emphasis on right-here-right-now.]

By contrast, the longest timescale that most IT-oriented enterprise-architects would work with will be around two to three years – the duration of a typical full cycle of the TOGAF-ADM. These are business time-cycles, not big-picture time-cycles; it needs to be aware of the big-picture wherever possible, but the emphasis is very much on right here, right now. In that sense, these are the metaphoric equivalents of the Engineers in that example.

[I’ve often used the label ‘IT-centric’ for these types of enterprise-architects, because their work centres so strongly around IT. In practice, though, the same applies to anyone else who’s doing any form of front-line delivery-oriented architecture-type work at a whole-enterprise scope: hence process-architects, security-architects, facilities-architects, knowledge-managers and many others of that ilk.]

Which brings us back to ‘everyone is always right and no-one is ever right’. Both Scientists and Engineers think they’re the only ones who are right, and that the others are wrong. And that’s typical, right the way across the whole business/enterprise space: for example, whenever we do a Five Elements workshop to explore this with a business’ executive-team, boy will the epithets fly… 🙂

Yet when we look at it in terms of the whole, it should be obvious that everyone is right: they all have different views into the same whole. One way to illustrate this is with a set of four distinct perspectives into that whole:

  • outside-out: develop a broad understanding of the overall business-ecosystem, in its own terms, independent of our own organisation
  • outside-in: develop a broad to detailed understanding of how others would interact and transact with our organisation, from their perspective, such as in a customer-journey
  • inside-out: develop a detailed architecture for each business-domain, each from its own perspective, in order to interact with a customer-journey from the business‘ perspective
  • inside-in: develop a broad understanding of what clean-up would be required within each domain in scope, in order to enhance local efficiency and reliability

Our Scientist enterprise-architects tend to focus on outside-out and outside-in – the big-picture, about strategy, and about the literally-emotive feelings that drive issues such as customer-journey and the broader enterprise as a whole.

Our Engineer enterprise-architects tend to focus on inside-out and inside-in – the tactics and operations that get things done, especially in terms of the way the business itself sees things. Monetisation, for example, happens at the end of the Process phase in the business-cycle: and to many business-folks, that monetary end-result is almost the only thing that matters. Since it’s the business-folks who are paying our bills, it’s kinda obvious that we do need to pay attention to their needs….

The catch here is that, with all those business-pressures, it’s easy to lose sight of the big-picture. And as we saw with the real-life case of the research-laboratory, unless we do something to bring things back into balance, the Engineers’ view will always ‘win’: Metal (performing, real-time Process, the Engineers) will always cut down Wood (forming, new Purpose, the Scientists) far faster than Wood can split Metal. The trap is that if the Engineers do ‘win’, we end up creating an architecture with a short-cut cycle that is actually guaranteed to fail: one that supports the inside-out short-term by ignoring and creating more and more outside-in ‘enterprise-debt’ for the longer-term. That’s an architecture that looks good in the short-term, but in the not-too-distant future will inevitably drive the business into a fatal crash-and-burn: in other words, not a good idea…

But if that’s the kind of outcome that we’d expect – and, in reality, do indeed see – from the over-dominance of the IT-centric architects, what can we do about it? We can’t simply assert that the big-picture Scientist-style enterprise-architects are the only ones who are right – because everyone is always right. And also there’s the blunt reality that the Engineer-style enterprise-architects are a darn sight better than the Scientists at getting things done, in practical, usable, real-world form. So what we actually need here is better balance across the whole – and better respect between the warring ‘tribes’…

Yet how do we do that? Well, one approach could be based on what we did with the scientists and the engineers in the research-laboratory: we first acknowledge that the conflict is inherent in the nature of the work itself – in other words, that it’s no-one’s fault that the conflict exists – and we then create an architecture that, rather than feeding the conflict, instead feeds mutual-support across and around the whole working-space.

If the fight is between Scientists and Engineers – between purpose, far-future, the ‘forming’ phase of the project-lifecycle, versus process, right-now, the ‘performing’ phase of the life-cycle – then we’d need to bring the other three phases of the life-cycle much more strongly into the overall picture. The diagram above summarises what we did in the architecture of the research-laboratory – but what would be our equivalents here? Some themes that seem to suggest themselves include:

storming/People (‘Fire’): Given that the conflict is inherent in the relationship between big-picture and operations-level implementations, we need explicit mechanisms for ongoing arbitration and conflict-resolution. For the scientists and engineers in the research-laboratory, this business-function was ultimately responsible to and reported direct to executive level; in our case, though, there’s no current equivalent to ‘executive level’ – and the few existing organisations that could perhaps be put forward for that role, such as Open Group or OMG, are all very firmly in the Engineers’ camp, which would almost certainly cause more problems than it could solve. That too is something we’ll need to resolve.

norming/Preparation (‘Earth’): In the research-laboratory, we dealt with this by a redesign of the scheduling-system, built around an explicit but extensible ‘service-catalogue’. For EA, a service-catalogue would likewise seem a worthwhile idea: each ‘domain’ within the overall EA space provides its own specific types of services to the whole. Probably the nearest equivalent to a whole-scope ‘scheduling-system’ is the role of maturity-models in continual-improvement of tactical- and operational-level architectures; the catch there is that too many of the existing maturity-models are essentially IT-only, and tend to focus more on measuring maturity than in doing something useful with that measurement. What we need instead are maturity-frameworks that place a stronger emphasis on what needs to be done to lift the EA-capability from one maturity-level to the next: the framework in my book Doing Enterprise-Architecture is one such example, but no doubt there are others that might well work better for other contexts.

adjourning/Performance (‘Water’): In the research-laboratory, we developed a new structured information-system such that the engineers’ results-outputs became more accessible and reusable within the scientists’ work. The equivalent here is that those of us who work in the big-picture space really do need much stronger, more-structured and more-explicit feedback from real-world practice, so that the new tools and techniques we develop will be properly grounded in and properly reflect how things actually work ‘at the coal-face’. At the very least, one thing we urgently need, across the whole EA-discipline – and have urgently needed for a long time now – is a common content/exchange structure for all types of EA models, for content-sharing and linking across all vendors’ toolsets and across the whole of the EA toolset-ecosystem. Over the past few years I’ve done a lot of work on ideas towards metamodels that could help in this, though it’s really a job for people much more experienced in metamodels than I am: but the real point is that we need it, and we need it now.

We’d also need something, even if perhaps a bit more implicit, that would ‘hold the centre’ for the entire EA discipline, to maintain awareness across the whole of the whole as whole. Again, there’s no existing organisation that would seem well-suited for that role: yet we do need one, right now.

And leadership is going to be the big challenge here. For example, in terms of that framework above, we need eleven distinct types of leadership: one within each of the five metaphoric domains, one between each pair of domains, and yet another to ‘hold the centre’.

And yes, I know it’s a lot. Yet to me that’s what we’re going to need, in some form or another, if we’re to have any real chance of ending this pointless ‘shootout at the EA Corral’…

Anyway, enough for now. Your thoughts, comments, suggestions, anyone?

2 Comments on “Ending the shoot-out at the EA Corral

  1. Tom,

    Great post! I agree with your view of what EA should be. But is it actually sufficiently and consistently practiced as it should be – in any company/government etc..?

    I would love for the answer to be yes but honestly just don’t believe it. Perhaps less than <2% of the companies that even have EA's practice it in it's purest sense. Almost all of the job descriptions are for the engineering style you mention and even those that aren't described in the engineering-esque view tend to be that way in reality once the job starts.

    It's great to be a pioneer in a new field and push it into the world. But in the end, the EA must earn a paycheck and put food on the table. They need to do what is needed to stay relevant now – and this is the engineering view.

    I was surprised to hear that an engineering view of 2-3 years out with greater focus on the current years tactics is not enough. How much longer does the science view take into account? 10 years? C-level folks care 98% as far as their next annual bonus. There is also the question of when things get tight economically in a company – like in most companies! Who is the first to be cut? The guy thinking 10 years out or the guy making things happen now. If the 10 years out guy gets cut every time bad times come, how does an EA practice ever mature? It turns into an endless cycle of "starting" EA and killing it before it reaches as trusted strategic advisor to the CEO.

    The (impossible?) question, however, is this, how do we convince companies that they need EA in the "science" role? Does it take individual EA's clawing their the way out of companies IT departments, convincing the CEO? Good luck, not likely to find a critical mass of EA's successful going down the "convince" route. Perhaps the best answer is some new uber powerful cross industry entity with a lot of marketing/funding needed – with gargantuan buy-in from member entities across industry and the globe. Great, then join the bandwagon of "yet another EA" industry entity. Good luck with that. Perhaps then the answer is to convince all the big entities to merge and agree on the purest view. Now that would be a revolution….

    Sorry for the rambling… Thanks

  2. Hi Eric

    “is it actually sufficiently and consistently practiced as it should be – in any company/government etc..?” – the client I worked with earlier this week (market cap c.$1bn) has been doing this for at least a couple of years now; various of my clients (one 30,000-employee corporation comes to mind) have doing so for nigh on a decade. Yes, sure, it’s always a struggle to get the balance right and maintain business-credibility, but it works.

    “The (impossible?) question, however, is this, how do we convince companies that they need EA in the ‘science’ role?” – the short answer is that we don’t even try to convince them. We just do it – by stealth, if need be, but we do it. We don’t actually have to convince anyone else at all: but we do need to ‘convince’ ourselves. If we don’t get why this is so important, then no-one else will: simple as that, really.

    “How much longer does the science view take into account? 10 years?” – I’m a bit concerned that you may have missed the point here. There’s no separation of views or time-perspectives: it’s just that the EA-role must include the longer view, whereas in general the solution-architect won’t need to think much beyond the current project. My own work has spanned timescales from sub-microsecond (high transaction-densities) to millennia (legal compliance on hazardous-materials management) to indefinite-future (enterprise-vision), but that range is only because I’ve worked with so many solution-architects whose work has covered different parts of that scale. As a result, though, I’m used to thinking in terms of multiple timescales – which can be very relevant in resolving certain business-problems and, especially, in identifying key types of kurtosis-risks.

    “The guy thinking 10 years out or the guy making things happen now” – there isn’t an ‘either/or’ here. It’s a ‘both/and’: “the guy thinking 10 years out” is also a “guy making things happen now”. That’s the whole point. Even though we may be thinking 10 years ahead, what we do is always focussed on what has to happen right here right now. The guy who only thinks 10 years ahead is a too-easy target to cut when times are tight, as you say; but the guy who only focusses on ‘making things happen now’ shouldn’t work as an enterprise-scope architect, because that scope needs the long-view. And if no-one’s holding the long-view, well, that company isn’t likely to have a long future… simple as that, too.

    “Perhaps the best answer is some new uber powerful cross industry entity with a lot of marketing/funding needed” – like you, I doubt it: nice dream, but ain’t gonna happen. Even if it did, I would be extremely wary of its motivation: we’ve had enough ‘term-hijack’ problems already with narrow-focus groups purporting that they alone have ‘the truth’ about enterprise-architecture or anything else. :wry-grin:

    “Sorry for the rambling…” – ’twas not a ramble, was solid good sense. And anyway, I, uh, don’t think I have much right to complain about anyone else rambling on, given the length of so many of my posts here! 🙁 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *