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?

Hmm…

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.

Hmm…

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?