The ‘This’ game and EA toolsets

Continuing on the theme of the ‘This’ game for engaging people in enterprise-architecture exploration and development, as described in the two previous posts ‘This: an exploratory game for service-oriented EA‘ and ‘More on the ‘This’ game for enterprise-architecture‘.

The final note in that last post was about EA toolsets, and the need for appropriate support for the output of the game – and perhaps even the game itself – within the toolset. And that point actually brings together a whole stream of different threads that I’ve been tracking for some years here: enterprise as story, toolsets and their user-interfaces, metamodels and architecture-repositories, whole-enterprise scope, notation-agnostic modelling and a whole lot more.

There are (at least) two fundamentally-different viewpoints on enterprise-architecture: as structure, and as narrative. Most current EA toolsets focus only on the ‘structure’ side, and do so variously well; but there’s almost nothing to help us tackle the narrative side of the story, and even less to help us bring those two sides together. Which, in practice, is a serious problem, because story is actually what engages people in the architecture…

In short, we need our EA toolsets to help us bring a better balance between structure and story in the architecture.

To put into context, consider a few scenarios:

Scenario 1: The team reckon they’ve done well with their work on the new business-model, all laid out on the wall on a Business Model Canvas. But how are they going to implement it? Will it actually work in real-world practice? What are the pitfalls and hidden ‘gotchas’ that could cripple the new model’s viability?

To address these concerns, they set up for a game of ‘This’. One of the architecture-team leads, Maria, takes on the role of modeller, using an application on her iPad, the screen hooked up to a data-projector on the wall, but also coupled to the other team-members’ tablets and laptops. (The screen will also show the current manually-selected or randomly-selected ‘This’ question-card.) She also sets up a conference-microphone to capture an audio-channel.

Maria uses the camera on her iPad to take a snapshot of the current model on Business Model Canvas, and pulls the photo into the application. There, she marks up the graphic with zones and links, each of which – behind the scenes – is also noted as a Service or flow-relation in the underlying Enterprise Canvas.

The team choose an arbitrary starting-point, and build outward from there, as per the guidelines for the game. Instead of using the rather sparse Enterprise Canvas notation, Maria pulls up more-descriptive icons and images from a palette – trucks, parcels, people, machines, money, whatever – and places them on the screen as the current ‘This’; behind the scenes, though, the application stores the information in Enterprise Canvas notation. The audio-channel is attached both to the overall model, and to the entity for the current ‘This’; later, the audio-track can be played back, highlighting in matching sequence each of the items described in the model.

During the game, the discussion indicates that some changes will need to be made to the initial business-model. Maria uses the underlying Enterprise Canvas to recreate a new version of that model, in Business Model Canvas layout.

Scenario 2: Two days after the business-model meeting, Maria re-checks some of the people-connections captured in the Enterprise Canvas model during the ‘This’-session, for the purpose of building a list of stakeholders for one of the side-projects arising from the new business-model. She notices that she didn’t capture one person’s name, the process-owner for a related business-process – she remembers that his first-name was Steve, but not the surname. She clicks on the respective icon, and plays back the audio-channel that was captured at the time: Steve’s surname – Cartwright – is now clear, and she types the full name into the model. As she does so, a link to the company’s HRM-system brings up further contact-details for Steve, including several photographs. She selects one photograph, and sets it as the surface-view for that icon in Enterprise Canvas.

Later that day, Arjun reviews the business-model, using the zooming model-display. In the drill-down into the ‘Key Activities’ section of the Business Model Canvas, Steve’s photograph now appears in place of the previous abstract ‘person’-icon. Clicking on the photograph, Arjun sees all of the information on Steve’s role in the proposed business-model, and can also play back the captured audio both from that meeting, and another discussion that took place earlier in the day.

Scenario 3: Juan has been tasked with developing the IT-architecture for the e-commerce component of the new business-model. His business-unit has standardised on Archimate notation for all IT-architecture models. He opens the Enterprise Canvas model, and, using it as an active backplane, identifies Canvas entities that would map directly to Archimate equivalents: Canvas ‘Service’ to Archimate ‘Business Service’, ‘Application Service’ or ‘Infrastructure Service’, Canvas ‘Exchange’ to Archimate ‘Business Interface’, ‘Business Object’ and so on. He explores the additional detail recorded in the ‘This’ session to identify Archimate ‘Business Function’, ‘Business Event’, ‘Business Actor’ and the like. As he adds these entities to the Archimate model, they’re also attached to the Enterprise Canvas model in the backplane via composition-relation links into the respective Canvas ‘Service’, ‘Exchange’ entities and flow-relations.

Scenario 4: The following morning, one of the business-model team, Vasily, remembers that more detail was needed about warehouse configuration, for potential locations – both physical and logical – for new sensors that will be needed for logistics-tracking in the new business-model. He goes down to the warehouse, takes his smartphone out of his pocket, calls up the Enterprise Canvas model, selects the ‘New Sensors’ entity, and starts a new game of ‘This’ with that entity as its starting-point. He manually selects the question ‘What are the locations of This?’, and attaches to that card the photos that he takes, direct from the phone’s camera application.

In the Enterprise Canvas, Juan has already been identified as one of the people responsible for the ‘New Sensors’ component of the business-model. He receives a notification that new items have been added to the Enterprise Canvas; he opens that part of the model, reviews it, and adds new entities to his Archimate model, which are automatically linked back to the Enterprise Canvas.

So there we are.

Plenty of other scenarios we could add, too: about a meetup in a cafe, about people exchanging ideas in the elevator, about how this information might be used by a project-manager and her team, by a process-designer to gather feedback from the factory floor, by managers using a dashboard in high-level resource-planning, and so on. But that’s detail enough for now: four interlinked scenarios, all working on the same models in different ways, with different software-applications, on different hardware-platforms, for different purposes, all supporting each other.

So is that what actually happens in practice at present? Is that how we do our everyday architecture work?

Uh, no…

In which case, why not? Seriously: why not?

On the surface, it’s all straightforward enough: the work itself is essentially what architects and others do already. The only trouble is that it’s well-nigh impossible to do most of this in any existing EA toolset: most tools now should be able to cope with the Archimate-specific part of the modelling, but that’s about it – and they probably wouldn’t be able to link any of that model to anything else. As for the rest? – well, forget it, guys, you’re outta luck…


It should all be seamless, pretty much exactly as described in those scenarios above. In practice, it isn’t. In fact, the way we have to do it at present is a frustration-filled, kludge-ridden, error-prone mess of manual translations, bits of paper, scribbled notes, anguished phone-calls and worse. Hence no surprise that it often doesn’t work very well – if at all.

Yet there really is no need for it be that way, and no reason for it to be that way either.

To which the only remaining question is: Why? Why is it this way?

To me at least, it seems that the only real reason is that the current EA-toolset market is crippled by its own lack of imagination – and that’s all that’s holding us back.

Okay, yes, sure, there’s a sizeable amount of development-work required. But seriously, none of it would be hard to an experienced developer, someone who’s familiar with the current generation of development tools. Everything I’ve described above is already available in various apps and elsewhere – there’s nothing new as such in any of it. The only reason I haven’t done it myself is that I’m way out of date on that whole area, and it would take me months or years to do what a current developer would know how to do in days.

Have a wander around this blog: I’ve already done most of the conceptual work that’s needed for this, on toolset-ecosystem, overall requirements, metamodels, user-interface, underlying notation-agnostic structures and so on. For example, take a look at these posts:

So I’m serious about this: it’s all there – a huge market, just waiting for the first person with the nous to pick this up and run with it.

Is anyone up to this challenge? And if not, what do we enterprise-architects do about it?

Comments/suggestions, anyone?

6 Comments on “The ‘This’ game and EA toolsets

  1. I was thinking that perhaps we can compare doing Enterprise Architecture with the making of a documentary (or documentaries). And that we can learn a lot from how documentaries are made, e.g. look at the course description on :

    “What happens during the course

    Learning how to make a documentary will sharpen your sense of what makes a good idea. Working in a group will give you the resources and the space to follow through on your ideas.

    Along the way, you’ll take in interview techniques, structuring stories and ideas, legal issues, practical restrictions, and audience expectations. You’ll leave with a show reel and have a good idea about where you are going next.”

    I don’t think we should aim for modeling tool(s) at this point in time but first aim for story capturing, story structuring and story production and post production tools & methods…

  2. If by “first aim for story capturing, story structuring and story production and post production tools & methods…” we mean – start with the end in mind via ‘as is’ and ‘to be’ records and views, decision support all underpinned by configuration management level discipline – I’m in too. In my view, its all about knowledge management of a companies information resource about customer, market, assets, strategy, etc – o plus some it knowledge too.

  3. @Peter T
    I mean that an enterprise architect, just like a documentary maker, is somebody who wants to create a story which should make the audience aware of something (most of the time aware of some need and way to change). And just like the documentary maker, the enterprise architect must built such a story by using other peoples stories (the stakeholder views).
    Modeling is nice but not very helpful when you want to create an engaging story (unless you think that things like dictionaries, phone-books or encyclopedias are engaging).

    So I think story-related tools are more important than modeling tools (or knowledge management or configuration management tools or…) for Enterprise Architects.

    An example of a story-creating tool is Writer’s Cafe which is used by fiction writers but which is probably also usable for non-fiction writers, like enterprise architects 🙂

  4. @Peter T – Agreed, though I see the role of story more as a kind of dance in time, weaving between as-was, as-is, as-desired, as-will-be-in-practice, and back again. We connect people to other times through story.

    @Peter Bakker – I take your point about story-tools such as Writer’s Cafe. The catch for me is that whilst I do have many tools of that kind – Writer’s Cafe, Scrivener, Ulysses, Sigil, Final Draft, Movie Draft, Celtx, Jutoh and others – I don’t actually use them much, if at all, in an EA context: I haven’t found a viable way to do so. Obviously I use MS Word for the books, and this blog for ‘work-in-progress’, but that’s about it. There’s a big hole there – a real need. And I don’t know how to fill it.

    Perhaps more to the point, I don’t yet really know how to describe that gap: I just know it’s there, and it’s huge. It’s not about story separate from structure, it’s about story with structure, about how the two relate with each other, support each other, change each other. That’s why I’m seeing both sides as integral to a new kind of EA toolset.

    For one example that’s about halfway to what I mean, see the MyCreativity add-on to the Southbeach toolset. The MyCreativity ‘story’ is always automatically generated from the model – there’s no way to do it the other way round – and it’s only ever about sensemaking, not structure as such; but it does give some idea as to the potential for what we could do when structure and story are combined.

  5. @Tom G
    “The MyCreativity ‘story’ is always automatically generated from the model”
    I think they should be loosely coupled, I would like to see models, prototypes and pretotypes emerge from stories. In my experience enterprise architects are too much involved with all kinds of abstractions but they fail to communicate their vision, intentions and goals to the people who are “living in the real world”. Enterprise architecture is too much occupied with things instead of with the people who are using or are depending on those things.

    You wrote some excellent story-related posts so I know that you can take Enterprise Architecture in a new direction and turn it into a people-oriented business if you want to…

  6. @Peter Bakker – That’s exactly the direction I’m headed right now! 🙂 The next book on my to-write stack, which I’m working on at present, is all about ‘The enterprise as story’, about ensuring that ‘the enterprise’ is first and foremost about people – otherwise it literally isn’t ‘enterprise’.

    Yet there’s a lot more to it than ‘just another book’. What I’m concerned with, in this post, is how we would set up a new kind of EA-toolset that supports a better balance between structure and story – not just one or the other, as at present.

    As for whether I can “turn [EA] into a people-oriented business”… well, we’ll just have to wait and see, won’t we? 🙂

    But thanks again, of course – many thanks indeed.

Leave a Reply

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