Enterprise-architecture is dead.
As a term, anyway.
Although it had been dying for quite a while, we do have some certainty now about when it died; we know how it died, and even why it died. And whilst some of us may hope that there might yet be some way to revive the corpse, reality is that it just ain’t gonna happen now – or at least not within any kind of timescale that we’d need. Oh well.
The problem, though, is that we don’t have any other term that would do that job: nothing else that would mean the literal ‘the architecture of the enterprise’.
Some have pushed for ‘Business architecture’ as a possible substitute. But it doesn’t have the same meaning: it’s literally ‘the architecture of the business’, not ‘of the enterprise’ – and despite some people’s assumptions, ‘business’ and ‘enterprise’ are not the same thing. In part because of that, business-architecture tends to focus too easily upon commercial concerns alone, ignoring all other forms of enterprise. Hence, to use an old quote, “Close, but no cigar”.
Then there’s ‘Enterprise Design’, promoted by Milan Guenther and some others. I can see why folks might push this – at least it has ‘enterprise’ in the term, and it is related to architecture. The catch is that architecture and design are not the same: it’s the same spectrum, but they point in opposite directions – architecture ‘upwards’ toward a family of options, design ‘downwards’ toward a single option. So again, “Close, but no cigar”.
The only term that would work properly for this is ‘Enterprise-architecture’.
Which we can’t use any more.
Yet how about we look at this from a whole other direction?
Instead of squabbling over a label for what the discipline is or does, why not focus instead on the outcomes of the discipline?
And in that sense, what this discipline really exists to do is to help create greater effectiveness across the whole of an enterprise.
Or, in short, enterprise-effectiveness.
The nice bit is that we don’t even need to fight about the meaning of ‘the enterprise’. Whatever the scope and scale, it’s still ‘the enterprise’ – the same desired-outcomes still apply, whichever way we choose to define ‘enterprise’ itself. A lot simpler, really.
And ‘effectiveness’? – well, there might be a few minor arguments over definitions, but in essence that’s straightforward enough too. For example, to keep it simple, I define effectiveness as the intersection between five main themes: efficient, reliable, elegant, appropriate, integrated. There are a fair few nuances, of course – perhaps in particular that efficiency is a subset of effectiveness, and not a contrast to it – but in essence that’s probably all that we’d really need to start on.
Hence, for example, we can take even an overly-simplistic strategy-tool such as SWOT, and refocus it towards enterprise-effectiveness. That should give us something such as SCORE – Strengths, Challenges, Options, Responses, impacts on Effectiveness:
Following the principles of the enterprise-architects’ mantra, we start off by accepting that we don’t know; then we explore the interdependencies, iterating back and forth between each of those SCORE themes until we have ‘just enough detail‘ on which to build the decisions that we need. It’s still simple, yet it’s not simplistic – a very big difference, and a powerful difference too.
So perhaps take a look at your existing tools, methods and frameworks for enterprise-architecture, business-architecture, enterprise-design or whatever, and think about what would happen if you reframed them in terms of enterprise-effectiveness. What difference would it make? For example, would it make it easier to ‘sell’ to executives and suchlike?
Comments / responses / suggestions, perhaps, anyone?