Pinball-wizard

Chatting with a colleague the other day about where I’d gotten to so far with my explorations on new toolsets on enterprise-architecture. I’d been talking on what I saw about what it needed to do overall; then a bit about the range of devices it needed to be accessible on; then a bit more about HTML5 frameworks for device-independent design; and then on into some of the finer points about the trade-offs between MySQL versus SQLite versus MongoDB versus Neo4J and suchlike as suitable data-storage. At that point he pretty much exploded: “That’s not enterprise-architecture!”, he roared. “Enterprise-architecture is big-picture, big design – you shouldn’t be looking at any of that of low-level stuff!”

Yet when we talk with software-developers and suchlike, we get hit with the opposite kind of complaints: “If you’re agile, who needs architects? Architecture’s just Big Design Up Front, isn’t it? – if everything’s emergent, that kind of upfront thinking is just the wrong thing to do!”

As architects, looks like we’re wrong pretty much whatever we do, doesn’t it?

It’s not quite as bad as that, though. It’s not a simple ‘either/or’, with both sides wrong, and us as pig-in-the-middle: it’s more about subtle shades of grey and suchlike. I think it was Gene Hughson who once commented here that “Computers are binary, but people aren’t!” – and neither is the real-world, for that matter. And certainly Gene’s recent post ‘Who Needs Architects? – When Tactics Do Not Add Up To Strategy‘ gives me some hope that architects do still deliver real value – as does Simon Brown in his writings on software-architecture and the need for ‘Just enough up front design‘.

But what is ‘just enough’? How do we know when enough is enough?

Well, it depends, doesn’t it?

Which takes us right back into that loop again… Sigh…

Maybe there’s a need for a better metaphor here?

All of which kinda reminded me of that classic song by The Who:

Yep – enterprise-architect as Pinball Wizard. 🙂

Think of architecture as a game of pinball, where the aim of the game is not so much to rack up a numeric score, as to develop new understandings about the respective context. In classic pinball, it’s a ‘finite-game‘: we play to ‘win’, the score itself is the only thing that matters, and hence we always want to keep going for as long as we can. But in architectures, we know we’re in a broader ‘infinite-game‘, in which we play to learn, and in which it’s the usefulness of the understandings that matter most. Hence we’ll play for long enough – just enough time, giving us a score of just enough understandings – to give us what we need for the current task: at that point, we let the ball go, turn towards other tasks, and come back to play another game whenever we need it.

To develop understanding about some architectural concern, a domain-architect will bounce the focus around their domain-context quite a bit. No surprises there.

But the catch for enterprise-architects is that, by definition, enterprise-architecture must cover every domain in the respective enterprise – which means that we’ll likely find ourselves bouncing around a lot. Everything depends on everything else; and everywhere and nowhere is ‘the centre’, all at the same time. Everything is just as important as everything else: the architecture can be made or broken not just by the high-level ideas and decisions in the abstract but by practical constraints around what’s achievable right here, right now.

(Getting that balance of ‘just enough everywhere’ right is crucially important. To understand that point, we only need to look at what happens when the balance isn’t right, and something crucial gets missed out of consideration, often at the smaller scale: Le Corbusier’s infamous irreparably-leaking roofs, for example; Frank Lloyd Wright’s maintenance-nightmare of the Marin Civic Centre; Norman Foster’s boxy, echoing airport-terminals that somehow leave no place for people; Rafael Viñoly’s curved ‘Walkie-Talkie’ office-building as unintended solar-furnace – the list goes on and on…)

That’s what creates the need for that bounce, the pinballing-around, from high-level to fine detail, up, down, sideways, round. It’s also where the challenge lies for the enterprise-architect – and doing it all in a viable, usable timescale, too. To paraphrase that song’s lyrics somewhat:

a pinball wizard, it’s got to be a thrill
a pinball wizard, it’s such a subtle skill

Rack up that score! Build the understanding! Cling! Flash! Go! Don’t let that ball drop until you want it to drop!

There’s another reason for the bounce, too. Sitting up in an ivory-tower somewhere, all just Big Ideas, without testing anything, without any contact with the real-world? – yeah, that’ll likely lead to the more disastrous end of Big Design Up Front, all right. Or stuck in Analysis Paralysis. But if we also get out there, allow ourselves to bounce around the context-space in whatever way feels right – “he plays by sense of smell”, as the song puts it – we can then experiment, test, compare and contrast, link big-idea to real-world practicality, use real-world innovations to inform big-ideas again, bounce, bounce, up, down, sideways, round. And that’s when things start to gain a better chance of becoming real. Of being real, too. The point here is that the real process of developing new ideas is inherently messy – as illustrated so well by Damien Newman’s ‘the Squiggle‘:

(This also illustrates again why so many of us get so frustrated by the existing ‘enterprise-architecture’ toolsets: for the most part, most are only of much use right over at the far end of the Squiggle – not in the beginning or the middle, where we most need their help!)

In a recent Tweet, Alex Osterwalder took the Squiggle one step further, cross-mapping it to the risks and costs of experimentation, in effect keeping the cost (in every sense) of experiments inversely proportional to the level of uncertainty:

One of the key points about playing ‘pinball-wizard’, as an enterprise-architect, is that for those early stages most of the experiments are little more than ‘thought-experiments’ – at most a scribbled hand-drawn diagram, a few quick lines of code, or whatever the equivalent might be – that each cost next to nothing in time, money or whatever, but deliver useful insights that can then be applied and cross-linked elsewhere in the overall context-space. So yes, there were, for example, good reasons why I looked at those different database technologies for possible toolsets: I needed to keep hold of the big-picture focus, yet I also needed to understand what was (is!) feasible in terms of real-world support for those questions around identity, content, connection, change, navigation and search that we’d need for any implementable toolset. I do spend a lot of time up in the ‘big-picture’ domains, it’s true: but all of that runs a real risk of a fall into myopic meaningless unless I do continuously connect it back down to the real-world as well.

Yet there’s one further twist we need to note. When we play ‘pinball-wizard’, yes, we’re the player, choosing which buttons to press, which flippers to flap, in order to keep the ball in play for as long as we need. Yet we’re also the metaphoric ball that’s being bounced around in that context-space – which means that we are the ones who need to take all the hits from those bounces, too. Hence kinda ‘ouch!‘ at times, as most of us know all too well… – but that’s the way the game goes, isn’t it? 😐

Clunk! Plang! Bzzz! Rack up that score! Ding-d-ding-ding!

Pinball-wizard indeed… 🙂