Enterprise-architecture: Clawing our way out of limbo
Blog: Tom Graves / Tetradian
A year ago, I was at Heathrow, boarding a flight to Australia. My long years of eldercare had at last come to an end: it was time for a restart.
It was a good plan. I’d worked on it for months. Present a session at an enterprise-architecture conference, meet up there with colleagues, gain a sense of the lay of the land; take a much-needed four-week break travelling the east coast in a rental-campervan, again meeting up with more far-flung colleagues along the way; and then use those experiences to decide whether I’d commit to that idea of ‘enterprise-architect as digital-nomad‘, or else go back to a more conventional form of consulting. Something like that, anyway.
Reality Department, however, had rather different ideas…
If I’d set off a month earlier, maybe even just a week earlier, that plan might have worked, and worked well. Maybe. But by the time I’d arrived in Melbourne, just one long day after setting out from London, every single part of that plan had been shredded into oblivion. Gone. All of it.
No meetups allowed.
No work available, because everything’s shut down.
No travel allowed, and no campervan either – though the rental-company kept all of the payment that I’d made for it.
And, at the start, nowhere to stay.
I’m hugely grateful for friends who helped me out of the immediate mess. I’m hugely grateful to my AirBnB host who let me extend my booking far beyond the normal limit. And I’m hugely grateful to have a relatively-stable base right now, in which to start cleaning up the weight of the past, and make a more-viable plan for the real future ahead.
The reality, though, is that for me it’s basically been yet another year largely lost in limbo. It’s taken a huge toll in every way – physical, mental, emotion, spiritual, financial, technical and more. Ouch…
And yet I have done a fair bit of work throughout this trying time. Maybe half a dozen webinars and slidedecks. A lot of new videos, an average of around one new video each week. Some twenty-five blog-posts done. The next book in the Change-mapping series completed and coming out somewhen next week. On a perhaps less business-linked level, I’ve also done maybe half of another new novel in the Viner Codex series, and now serialising some of the previously-unpublished fiction-work too. So although it’s much less than I’d aimed for, it’s a lot better than nothing. That’s good.
And it is getting better, slowly. Clawing my way out of limbo
Yet I’ve only been stuck in this limbo for a year. By contrast, enterprise-architecture has been stuck in limbo for two whole decades, and probably more.
Kind of a problem for us there…
The problem – the cause of the ‘stuckness’ – is pretty straightforward, and fairly well-understood. To put it at its simplest, it’s probably not a wise move to let IT-standards bodies define the standards for a context in which the IT is only one very small part of the actual scope. The result is that we’ve ended up with would-be ‘standards’ for enterprise-architecture that reflect that fundamental scope-error, treating the small IT-related subset of the enterprise as if it’s the whole of the enterprise.
One typical outcome of that mistake is the only visible options for implementations are constrained to this:
…whereas in most real-world enterprises, the options for implementations would include any mix of these:
Likewise, the visible scope for enterprise-architecture is arbitrarily constrained to this:
…whereas the actual scope that we need to address in an ‘architecture for the enterprise’ would be more like this:
And whilst those IT-centric ‘standards’ present a simple-seeming summary (the ‘BDAT stack‘) as their scope for enterprise-architecture, that looks like this:
…in practice, those hidden arbitrary constraints on scope collide with Reality Department in some truly horrible ways. In effect, the ‘BDAT stack’ above demands that we place business-architecture both inside and outside enterprise-architecture, and enterprise-architecture in turn must be both narrower and broader in scope than business-architecture. The result is a chaotically confusing mess that looks like this:
The practical result of that mess is that anyone who applies for an enterprise-architecture role gets sent down to the boiler-room rather than up to the executive suite, which is where we actually need to be. Instead of being placed as a high-level bridge between strategy, the PMO and more, and reporting to the executive as a whole, we get placed somewhere several layers down below the CIO or CTO, where the real-world politics of the problem make it all but impossible to do any useful work at all.
In short, Not A Good Idea…
Unfortunately, those scope-errors have become so deeply embedded in the dominant ‘standards’ for ‘enterprise’-architecture that the IT-centrism has become fully reflexive and self-reinforcing – so much so that it’s now probably all but impossible to eradicate. And the bleak reality is that every supposed ‘success’ of those dominant ‘standards’ leaves us yet further entrenched in the same painfully-pointless purgatory. Oh well.
By any sane logic, enterprise-architecture is literally the architecture of the enterprise. But the reality is that that term has been hijacked as a descriptor for something that is, at best, only a tiny, tiny subset of our actual scope – which makes it all but impossible to use the term ‘enterprise-architecture’ to describe what we do. Which leaves us stranded in limbo.
But what can we do about this? For this discipline as a whole, how can we claw our way out of limbo?
The way out seems to be the same as I’m using to claw my way out of my own limbo: go back to first-principles, re-assess the options, and move onwards from there.
(That’s actually a key distinction between architecture and design, by the way. They’re in the same spectrum, but they point in opposite directions – architecture ‘upwards’ to re-assess the range of available options, design ‘downwards’ towards implementing a single option, all in turn as part of a broader continuum that we might call ArchDesDevOpsLearn.)
And when we go back to first-principles, we can see that it’s actually not about architecture. Architecture is only the means – or, more accurately merely one part of the means.
When we look beyond architecture itself, the actual aim here is effectiveness – the effectiveness of the enterprise as a whole.
Helping organisations get better at effectiveness by getting things to work better, together, more on-purpose.
Helping organisations become more effective about effectiveness.
And whilst the elevator-pitch for the old IT-centric ‘enterprise’-architecture would be something like “We help organisations find the right IT for their current needs”, ours would be much simpler, yet also more relevant for everyone:
“We help organisations be more effective as a whole, in the midst of continual change”
And we do that with with tools, techniques and practices that anyone can use, and that are simple, clear and consistent – that work the same way everywhere, every scope and scale, every type of context or content, every timescale, every stage of the lifecycle.
Tools and techniques to help us ensure that we know what we’re doing, and why we’re doing it, at every moment, in every action.
Sure, there’s an architecture for that effectiveness. An architecture of effectiveness, too. But that isn’t the actual aim.
The actual aim, for everyone, is this: More effective. More on-purpose. Everywhere. Always.
The reality is that enterprise-architecture really is a lost cause now. It’s become stranded, probably forever, in an IT-centric limbo of ever-increasing irrelevance. Oh well.
So to be more effective, let’s refocus on effectiveness itself. And use that focus on effectiveness, not only to help us claw our way out of that limbo, but stop us from ever falling back into it again.