Calling a halt

Enterprise-architecture is a mess.

And I’m not the one to fix it.

That’s become all too clear to me right now – particularly after the farrago around that previous couple of posts about specialism-trolling, and the almost total non-response to that pair of in-depth series that preceded them.

At the very least, we do need to stop pretending that enterprise-architecture right now is anything much more than a near-irredeemable mess. I’ve done my best to sort it out over the past few years, but there are just too many vested-interests in it remaining the same near-irredeemable mess. Let’s be blunt about this: the trailing-edge of enterprise-architecture is a straight-out disaster-area, riddled with people still trying to drag EA back into the 1980s at best; and even most of the purported leading-edge of EA is still somewhat stuck in the past, mired in self-important ‘solutioneering’ around the supposed centrality of IT in everything. By contrast, I’ve been focussed forward onto the needs for the next few decades, on tools that would support a literal ‘architecture of the enterprise’ for every type of context, at every level, all the way up to a full global scope. There’s kind of a mismatch in expectations there…

There are still way too many stupid arguments around EA, that should have been resolved long since. Such as about what is or isn’t in scope (real answer: whatever the scope of the enterprise is). Or whether something is or isn’t fractal (real answer: it’s fractal when something is self-similar – both same and different – at multiple scales). Or whether… well, choose-your-argument, really, there’s any number of ’em. 😐 Utterly pointless, all of it.

And I literally do not have the time to waste on that kind of crap any more. I can’t wait around for the rest of the EA world to catch up – and for even the supposed ‘leading-edge’ of EA to wake up to some really fundamental truths about the trade that should have been more than self-evident at least a decade or more ago. Oh well.

Sigh.

So I’m calling a halt on this.

No more arguments. If you don’t like what I say, or the way I do things, go somewhere else.

I know I’ve alienated some real colleagues recently about this, but I just don’t have that kind of time or energy to waste. Not any more. Not at my rather-too-advanced age, certainly.

— If you want to know how to work with the future of enterprise-architecture, or how to work with real enterprise-architectures that extend a long way beyond the arbitrary confines of big-IT, take a wander around here for a while.

— If you want to stay stuck in EA’s past, take a look around just about anywhere else.

Sure, that might sound a bit arrogant at first, but that’s just too bad. Whether you take me seriously or not is up to you. That’s your choice: I’m not going to argue about it, anyway. Simple as that, really.

In some ways I perhaps shouldn’t even describe myself as an enterprise-architect these days – though to be brutally blunt, I know a lot more about both the theory and the practice of enterprise-architecture than many of those who parade themselves around with that label. Instead, I make tools for enterprise-architecture – tools for change. Or, to be more precise, I make meta-tools that help and guide others to build their own tools for change within their own specific context.

That’s what I do: I make meta-tools for a literal ‘architecture of the enterprise’ and the like. Tools such as SCAN, for example, for mapping out sensemaking and decision-making:

Or SCORE, for strategy-work:

Or Enterprise Canvas, for service-oriented enterprise-architecture:

…and its subsidiary tools such as the ‘holomap’, mapping out the enterprise context and stakeholders:

Right now I’m perhaps the only person who does any of this kind of work in the enterprise-architecture space – on a consistent basis, at least, with meta-tools that are designed to work consistently across the whole of that space. Yes, these tools are usable for any kind of architecture, so yes, they can be used for IT-architectures too. But to constrain them to IT-architecture alone is to miss the point – in exactly the same sense that to constrain ‘enterprise’-architecture to IT-architecture is to miss the point. Yet as per the previous post, people get so hung up on that point that they miss the real point: in any real architecture, the point is that there is no ‘the point’ – everything depends on everything else, there’s only ever ‘the everything’, in which everywhere and nowhere is ‘the point’, all at the same time.

In a way, those tools that I make are nothing special. They’re not all glitzed-up and glossy, like This Year’s Model straight off the car-lot: they’re plain old everyday workhorses, the tractors and Transit-vans and Toyota Landcruisers of the EA world, built for reliability, versatility, adaptability in the face of anything that we might need to throw at them. They work. Quietly, in the background, without fuss or bother or razamatazz or certification-scams: they just work. Yet those tools do depend on specific understandings, specific terminology: and I’m very clear about that – such as that crucial distinction between ‘is true’ versus ‘as-if true’, for example, that still scarily-few people seem to understand…

If you want to talk about the tools themselves – how to use the tools, in real-world practice – then yeah, I’d really like to know about that. Very happy to talk with you, to explore, to argue, to find the best way to adapt the tools, find the best to get something to work for some specific purpose, some specific context, then yes, sure.

But if you just want to tell me I’m wrong, because what I’m doing doesn’t make sense in terms of someone else’s narrow-focus theory, which itself probably doesn’t even make sense in its own terms anyway, let alone anywhere else? Nah, not interested, not going to play that game: don’t bother, just include me out, okay?

It should, I hope, be self-evident that trying to play random mix-and-match with terminology and suchlike, without understanding any of the distinctions between tools and meta-tools, or how they work or what they’re built for? – well, yeah, that’s never going to work well, is it? Likewise trying to use them completely out of context? – well, yeah, no surprise that doesn’t work well either. Kinda stupid right from the start, like complaining that a heavy-duty agricultural tractor doesn’t have a high 0-60mph acceleration or the right attachment-points for the baby-carriage or the bicycle trainer-wheels, or that the high cabin and the power-take-off shaft and the lack of go-faster stripes make it look it kind of ugly at the shopping-mall. You what…?!?

And yet that’s exactly that I’m seeing so often right now in enterprise-architecture, just about everywhere, just about all of the time. Despite all of my warnings about this, people do keep on doing or demanding exactly those kinds of kludges, or demand to use it with someone else’s seriously-substandard tools, and then wonder why it doesn’t work. And then make it out that it’s somehow all my fault that they can’t make sense of the resultant mess. And then expect me to sort it out for them all over again, at my own expense in every sense, whilst they sit on the sidelines, grumbling, complaining and, in too many cases, mocking me as well.

So yeah, I’ve kinda had enough of that, thank you… – and I’m calling a halt on that kind of crap.

Nope, sorry, folks, I’s just not gonna play those kinda games no more. I’m not going to argue about it. If you can’t be bothered to listen, and you break it, or can’t be bothered to use it properly, you can darn well fix it yourself – don’t complain at me. I’ve got better things to do with what little remains of my life.

Enough said for now.