What do enterprise-architects actually do? What unique contribution do they bring to the enterprise?
What triggered this was one paragraph in Len Fehskens’ item on current and future enterprise-architecture, in the Open Group blog ‘2013 Open Group Predictions, Vol.1‘. Here’s the first sentence of that paragraph:
Something I saw in 2011 that became almost epidemic in 2012 is conflation — the inclusion under the Enterprise Architecture umbrella of nearly anything with the slightest taste of “business” to it.
Well, yes. I’ve seen others complain about that too – and there’ve also been more than a few raised eyebrows at some of the things that I’ve associated with the ‘
#entarch‘ hashtag over the past year or so. Yet in that blog, Len interprets this ‘conflation’ as a problem:
This has had the unfortunate effect of further obscuring the unique contribution of Enterprise Architecture, which is to bring architectural thinking to bear on the design of human enterprise.
Len Fehskens is one of my EA heroes, yet I’ll have to disagree with him somewhat here: to me it seems he’s missed the crucial point where those themes converge. The seeming conflation “of nearly anything with the slightest taste of ‘business'” into the scope of EA shouldn’t be seen as “obscuring EA’s unique contribution”: it is EA’s unique contribution. The conflation is the architecture: it’s what we need – not what we should avoid.
Yet we do need to look at this in the right way. It’s not that enterprise-architects should attempt to do “anything that has the slightest taste of ‘business’ to it”: that’s micromanagement, not architecture. Instead, what architects do is connect: we join the dots, link between the boxes, build bridges between the silos, get people talking with each other, to help create a clear sense of the whole as whole. As Jurgen Dahlberg put it in a recent tweet:
- RT @greblhad: Unity, not uniformity, is the aim of great Enterprise Architecture. #TheArtOfEnterpriseArchitecture
To be honest, architecture doesn’t do much of anything that’s visible on the surface: and most its deliverables don’t make much sense in those terms, either. Most of the ‘doing’ within an enterprise is the role and purview of domain-specialists – whereas architects are cross-functional generalists whose real role is is to connect between things. Architecture connects: that’s its real purpose.
An architecture needs to be able to connect between anything and everything that’s in scope for the context of that architecture. It doesn’t attempt to do everything that’s in scope: but it does need to understand everything that’s in scope, in just enough detail, and with awareness of what and how it depends on what, in order to unify and connect between everything and everything else that’s in scope for the context of that architecture.
If something’s in scope for an architecture, it’s ‘in scope’ because something else depends on it being there: so if the architecture can’t connect between everything that’s in scope, the architecture as a whole could be placed at risk. To be viable, an architecture must be able to connect everything in scope with everything else in scope.
Or, to put it another way round, if something in an enterprise depends on something else, then by definition that ‘something else’ is in scope for the enterprise-architecture. And it’s the connections that are the real focus of interest for the enterprise-architecture – not necessarily the ‘somethings’ themselves.
To give a concrete example, that Open Group ‘predictions’ blog includes four items:
- ‘Big Data’ (Dave Lounsbury)
- [IT] Security (Jim Hietala)
- Enterprise Architecture (Len Fehskens)
- Cloud (Chris Harding)
On ‘Big Data’, Dave Lounsbury says:
To allow humans to keep on top of this flood of data, industry will need to move away from programming computers for storing and processing data to teaching computers how to assess large amounts of uncorrelated data and draw inferences from this data on their own. We also need to start thinking about the skills that people need in the IT world to not only handle Big Data, but to make it actionable.
Straight away there are architectural issues there: for example, a shift in paradigm from structured ‘control’ to a more free-form inference, and the very different skill-sets needed for the latter paradigm. On security, Jim Hietala talks about much more free-form threats – in essence, the same shift in paradigm, which also means different connections between Big-Data and security. On cloud, Chris Harding explores the need for better means to connect disparate services and disparate forms of access – again, much the same kind of challenge, again needing new types of connections between cloud and everything else. Yet on enterprise-architecture, Len Fehskens somewhat bewails the same thing happening in enterprise-architecture itself – even though it’s just another instance of the same overall pattern.
Architecture connects between everything that’s in scope; so enterprise-architecture connects everything that’s in scope for the enterprise. And there’s a recursion here: architecture is part of the scope of architecture. Once we remember to apply architecture to itself, as well as to everything else, it should be obvious that “the inclusion under the Enterprise Architecture umbrella of nearly anything with the slightest taste of ‘business’ to it” is actually something to celebrate – not a problem, but a real sign of improvement.
Where Len is right to worry is the tendency towards ‘fads’ in enterprise-architecture. For more than a decade, an obsession with organisational-IT was almost ‘the only game in town’ for EA; then three years ago external-IT cloud-services became the ‘fad-du-jour’; two years ago, as Len says, it was a rather blurry notion of ‘enterprise transformation’; last year the big buzz was around an even blurrier notion of ‘business-architecture’; and this year, well, who knows what it’ll be? I won’t make any predictions there, other than that I know it’ll be yet another nuisance for us: it’s the same shallow ‘silver-bullet’ thinking, one crass example after another of the fundamentally-flawed notion of ‘somewhere-centrism’, that some one thing is ‘the centre’ around which all of the architecture revolves.
In reality, everything depends in some way, either directly or indirectly, upon everything else: so the only way that works is to recognise that everywhere and nowhere is ‘the centre of the architecture’, all at the same time. As soon as we make out that some one domain is ‘the centre’ of the architecture, by definition we’ll have broken the unity and symmetry of the architecture – which means we’d have also set it up for failure in some ‘unexpected’ way. In short, ‘enterprise’-architecture that somehow forgets to include the whole of the enterprise: not a good idea…
The unique contribution of architecture is that it connects, helps make whole, helps link strategy to execution, intent to action, action to value – all that kind of stuff. Enterprise-architecture is just another expression of the same idea: architecture at an enterprise scope, architecture whose scope is ‘the enterprise’. Yet specialists will only work within their own specific domains, often without much if any sense of connection with anything else: so the unique contribution of enterprise-architecture is that it can connect everything and anything across all of the enterprise, to create that whole as unified-whole.
Everything and anything in scope for the enterprise is necessarily a part of that enterprise-architecture, yet often only as something to connect, not necessarily always as something to design – a distinction that’s often very important in practice!
And that’s also our value-proposition: we connect, and deliver value through those connections – whereas others often sit only within their own specific boxes.
This, surely, is what it means “to bring architectural thinking to bear on the design of human enterprise”. After all, anything less would not be enterprise-architecture, would it? 🙂