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… 🙂

3 Comments on “Pinball-wizard

  1. In conversation, I often describe architecture as a multi-disciplinary practice. Wikipedia has the following here which is consistent with a lot of your posts re: both the nature of the work and reaction of others:

    Multidisciplinary work is often seen as revolutionary by skill-centred specialists, but it is simply a fundamental expression of being guided by holism rather than reductionism, as described by Jan Smuts in his 1926 book Holism and Evolution. One of the major barriers to the multidisciplinary approach is the long-established tradition of highly focused professionals cultivating a protective (and thus restrictive) boundary around their area of expertise. This tradition has sometimes been found not to work to the benefit of the wider public interest, and the multidisciplinary approach has recently become of interest to government agencies and some enlightened professional bodies who recognise the advantages of systems thinking for complex problem solving.

  2. From my book, 2009

    Avoid the trap of the selection of “top-down” vs. “bottom-up”
    – use the “pinball” style

    Another typical symptom of getting stuck in the design phase of your BPM system is the existence of endless discussions about the necessary “granularity” of the services:

    “If we select a top-down style then we will create coarse-grained business-related services, but we are not sure whether such services are implementable or reusable. If we follow a bottom-up style then we will implement too many fine-grained services for which the business value is not obvious.”

    Actually, any such discussion is misplaced at this stage. What should be discussed is how to build future flexibility into the BPM system which will allow the rapid and painless adaptation of services to increase or decrease their granularity. Small and agile improvements may be required in different layers – rather like the multiple refinements of a ball trajectory in a pinball machine.

    This pitfall is extremely common, so take care! We think its root is in the traditional (vs. agile) development practices which aim to provide a perfect system straight away – in such a system all services shall have the “right” granularity.


  3. Most of my architecture comments are knowledge maintenance oriented. This entry is no different. “ the risks and costs of experimentation, in effect keeping the cost (in every sense) of experiments inversely proportional to the level of uncertainty:” All too often we have uncertainty as previous change in process and systems was managed through then left.

    While Entropy always wins – a lift in progress performance and the corresponding reduction in uncertainty can be achieved by organisations who manage knowledge. Obvious I know but as architects we need to show business that agile, devops, cloud are ALL just trying to deal with ambiguity in place because knowledge was not managed.

    Often – these new approaches make it worse. Watching organisations proud of their new high value digital artifacts start to unravel after the teams who built them move on is painful. They start with – its ‘self documenting’, move into ‘we’ll hire someone to fix it’ and end up with ‘what actually happened’.

    Architecture MUST cover pinball parlor being aware of the LIFE of shopping strip or centre customers, process and technology too.

    End of knowledge management entry.

Leave a Reply

Your email address will not be published. Required fields are marked *