Toolsets, pinball and un-dotting the joins

What is enterprise-architecture, anyway? What’s it all about? Where does it add value to the enterprise? Kinda important questions for enterprise-architects, it would seem…

Given that, then it seems it might be worthwhile to leverage some of those recent posts on toolsets for enterprise-architecture – ‘New toolsets for enterprise-architecture‘, ‘More notes on toolsets for EA‘ and ‘And more on toolsets for EA‘  – and use them to shine a bit more light on enterprise-architecture itself. Kinda ‘eating our own dogfood’, if you like – though if we’re not careful, the mixed-metaphors might be at risk of getting real messy there!

Let’s step back a bit first, and look at the ‘Why’ of enterprise-architecture. What I’ve argued before in various posts here – and about which most people seem fairly happy – is that our real business role is that we act as custodians for a single core qualitative idea: that things work better when they work together, on purpose.

As with all qualitative themes in an enterprise, it’s actually everyone’s responsibility; but as enterprise-architects we kind of ‘hold the flag’ for that ideal, and help people to keep on track to that theme, at every level and in every context, as appropriate. What we might describe as ‘classic’ IT-oriented EA does tackles this mostly within a somewhat constrained scope, scale and context, whereas a ‘whole-enterprise’ EA aims to cover the entire enterprise context (in ‘Just Enough Detail‘), but the guiding-principles and overall concerns are essentially the same in each case:

Yet how do we do this work? If our aim is to get things to work together better and more on-purpose, what do we actually do to make this happen? Uh… – that’s where the explanation gets kinda blurry, doesn’t it?

The real answer is somewhere between “Lots” and “Whatever it takes” – which, whilst we know what that means, is not an answer that most business-folk would either understand or accept. And the bald fact is that until we can give them an answer that they can understand and accept, we’ll probably continue to struggle to explain the real business-value of enterprise-architecture. So, yeah, this is kinda important to us…

So let’s apply enterprise-architecture to our own work. Let’s look at what’s going on right now; at what’s working, what’s not working, where there seem to be gaps, and so on. Let’s ask about how we could make the ‘things’ in our own work work better, together, on-purpose.

As before, one useful start-point for this is Damien Newman’s ‘the Squiggle‘:

Excellent though it is, the Squiggle can be a bit misleading. That diagram is a literally flattened-out view of something that in reality is much more multi-dimensional – and as described in the post ‘Pinball-wizard‘, we need to be able to bounce around as appropriate throughout all of those dimensions. For example, whilst moving ‘along’ and ‘around’ that flat view of the Squiggle, we’ll also be bouncing up and down the various layers of abstraction, from most-general to most-concrete, as in this visual-summary from the Enterprise Canvas suite:

At each of the layers, we collect different types of information – sometimes very detailed, as in some of the recent posts on toolsets, sometimes much more abstract, as here. Particularly in the earlier stages of the Squiggle, we’re constantly testing out ideas, exploring what’s feasible or not-feasible in a technical or commercial or political or operational sense, what fits better or not-better with the overall aim: pinball indeed. In practice, we won’t be able to do our jobs properly unless we can play an appropriate game of pinball across all of the respective enterprise-context and enterprise-domains.

What most people see from us – or want and expect to see from us, rather – is only the output from the very end of the Squiggle: designs that people can implement, or, even better, things that people can use, straight away, without having to think about it. Nice, safe, certain.

What they don’t see – or don’t want to see, perhaps – is all the ‘messy stuff’ that happens before that final stage of certainty. To them, that’s just “Magic Happens Here”, or, more usually, just a conveniently-ignored and/or swept-under-the-carpet ‘Somebody’s Else’s Problem‘…

Yet whenever there’s a ‘Somebody Else’s Problem’, somewhere there has to be a real ‘Somebody Else’ to take on the problem: and in this case that ‘Somebody Else’ is us. We are the magicians here, the alchemists who turn confusion and uncertainty into business gold. In that sense, our real value comes from our being able to work through the whole of that process, recursively, fractally, all the way from “I don’t have a clue…” to “Here it is, ready to go”.

So to demonstrate the value of what we do, a key challenge here is to show that there is a real process that we follow, involving real hard work, rather than just some conveniently-ignorable “It just happens”. Otherwise known as joining the dots, all the way from beginning to end.

Which is a key part of what we’re supposed to be helping others to do.

Which, it turns out, we’re actually not so good at doing for ourselves.

Oops…

And one of the key contributors to that inability to join our dots is that the tools that we use are persistently ‘Dotting the joins‘ – fragmenting any possible whole-of-process view into a diaspora of disconnected dots.

To illustrate the point, let’s go back the Squiggle, and map onto that path each of the tools that we use during the overall process: whiteboard, Porter Five Forces, Business Model Canvas, Powerpoint, Excel, Archimate within a ‘proper’ EA toolset, or whatever. We could perhaps colour-code them according what part of the Squiggle they address – green for high-uncertainty, say, and red for high-certainty. The result would look something like this:

To us, this kind of mapping should make perfect sense: after all, we know that the line is there to connect all of these disparate dots, because that’s the path and process that we know we followed. Yet other than us, no-one else knows that that linking path exists – because they don’t experience it. And the exact path of the Squiggle is created anew, in somewhat different form each time, with every architecture task – so even if we could describe the exact path we took, it almost certainly wouldn’t be the same the next time anyway, or the next, or the next.

In effect, the only thing that connects the dots is us – which can be kinda tricky when we try to explain what really happens within our work. This point perhaps becomes more clear if we take away the Squiggle, and just leave that visual list of all of those tools in our toolset:

So in terms of the overall enterprise-architecture story, which tool does what, when, where, how, why? If “things work better when they work together, on purpose”, how do these tools work together? With what purpose? How does each one support the purpose? How does each one lead forward to the next, and support the whole-as-whole? What is the path via which we arrived at some conclusion, such that we could, if need be, retrace our steps?

Uh…

Uh…

Oops…

And that, folks, is why I’ve been saying that we need a common means to connect and share information between all of our tools. (Or, at least, as many of them as can be brought to share, because the over-proprietary ones almost certainly won’t be allowed to play. Oh well.)

Which is what all of this discussion about toolsets and the like is really about. It’s not about defining new tools – we have plenty enough of those already. It’s about defining a platform that can link our tools together – about un-dotting the joins, such that we too can ‘join the dots’ across the whole of our work, in the exact same sense that we ask our own clients to do.

Something worth exploring further, I’d suggest?