More on the ‘This’ game for enterprise-architecture

A great session yesterday with Kevin Smith, brainstorming ideas for the ‘This’ game for service-oriented enterprise-architecture.

I’d originally envisaged ‘This‘ as a kind of card-game, with questions and supporting-information printed on playing-cards:

There would be that small set of mandatory ‘setting-the-scene’ questions – perhaps printed on cards with a different-colour back – but all of the others would be in a card-deck that could be shuffled into random order.

(Note, though, that playing-cards would be just one form of implementation: there are plenty of other ways to implement the same idea, some of which could make great use of current consumer-technology. More on that later.)

In an early stage of the game, we would ‘Start Anywhere’, picking any appropriate point (or item, rather) as our ‘This’ with which to start. Once we’d done the ‘What is This?’ questions, we would pick random cards for new questions, add any new items to the model as suggested, and then use any ‘move’-options from the questions to move to another item that we’ve just created, to use it as our new focus, our new ‘This’.

At some point we would have populated enough of the model to see the larger picture start to emerge. From there we can go back and start to populate the detail of the model in a more systematic way, using the question-cards in structured sequences rather than solely at random.

The current text of the questions – ‘What is This? – tends towards an ‘as-is’ model. It might be better to reframe the questions for a ‘to-be’ model, creating ideas about the future rather than the present or past; the catch is that in English it leads to an awkward structure – ‘What would This be?’ – in which we lose that useful reinforcement-emphasis of ‘This’ at the end of each question. Probably simpler just to use an implied future-tense for the whole of the game – ‘In the future, What is This?’ – and keep the text as it is.

One theme that came out of that brainstorming-session was a literal gamification: if you’re going to call it a game, said Kevin, why not make it into an actual game? For example, award points for asking questions; award even more points for answers. Perhaps different numbers of points for different types of answers: some for an answer that adds detail about the current item, more points for answer that adds further items to the model.

We could use multiple sets of question-cards – each participant with their own set of cards, perhaps. That would introduce even more serendipitous randomness into the exploratory stage, and perhaps further opportunities for gamification.

The game can be a distributed game, with people in different locations, and also at different times. Imagine a bunch of executives, each with their iPads or whatever, all accessing a shared screen, showing the action, sharing the annotations, exploring multiple perspectives and multiple views, with a facilitator updating the shared screen (and the model beneath it) in real-time. The ‘card-game’ notion helps keep the focus on one item at a time, whilst allowing a lot of individual freedom and space for ‘positioning’ within the game. Each interaction also feeds towards the overall model.

We can also imagine this as a personal game, hosted on a smartphone or other handheld. The device screen shows just the current question-card, with space to enter responses – which, depending on device-capability, could include audio-, photo- or video-capture as well as text or simple sketch-graphics.

(Conceptually at least, this ‘personal game’ should be quite straightforward to implement as an app, because most of it is little more than access to hosted-backend, display a card with predefined text and graphics, and support appropriate information-capture – all of which is supported as standard in most app-APIs. Access to the backend-host doesn’t even need to be in real-time: it can be done by batch-download, local-store, and then batch-update with feedback to resolve any merge-issues. There are some complications in displaying the Enterprise Canvas model being created in the background, but even those should not be hard to resolve, as it doesn’t involve any actual real-time drawing of links between entities: they’re generated from the responses to questions, not by direct user-interaction.)

In modelling with This, (almost) every link implies a flow – because that’s one of the key modelling-constraints in Enterprise Canvas. If it isn’t a change in layer-of-abstraction – a realisation-relation – or a decomposition to another level of granularity – a composition-relation – then it must be a flow-relation: those are the only three choices we have. And a flow-relation always implies that there’s something exchanged: so what is that Exchange? What are its content, structure, protocols, driving events, values, trust-concerns, and so on? There’s a lot of information there that we need to capture, explore, discuss… Unlike the association-relation in so many other notations, we can’t get away with saying, “Well, they’re just sort-of-related, aren’t they?” – we need to explain what that relationship between those entities is, what it entails, what it brings to the overall enterprise. A useful challenge in itself.

The more I explore this idea, the more I see it’ll need a new kind of EA toolset – one that supports a much better balance between structure and narrative, a different way of engaging everyone in the overall architecture. More on that in another post, though.

Any comments so far? Any ideas of your own on This?