Models as decision-records (Enterprise Canvas)

This one is mainly about enterprise-architectures, but also applies to just about any other usage of models – visual, mathematical or whatever – in pretty much any other discipline.

There’s a common perception that a model represents some kind of reality, either in the present, the past, or some intended future.

To my mind, though, it more accurately represents decisions about that reality – about how we choose to view that reality. (‘Executable’ models such as a BPMN/BPEL diagram are encoded mechanisms to apply and repeat those same decisions in the future.)

A model-type and its underlying metamodel therefore act as a guide and checklist for discussions about that reality. The discussions build a story about reality, which we then document as the final model.

In enterprise-architectures and elsewhere, perhaps too much attention is paid to the final models, and perhaps not enough attention to the process of co-creating the story and the decisions that the model elicits and represents. The metamodel of the model-type acts as a checklist of themes to discuss, in much the same sense as in Atul Gawende’s The Checklist Manifesto; the resultant model records the concerns and choices and decisions that were made whilst working through the checklist represented by the model.

A few model-types are intentionally designed to focus on this process of discussion – eliciting requirements, identifying gaps and ambiguities and perceptual clashes and the like – with the final model almost as an afterthought, providing an aide-memoire about the conversation. Nigel Green’s VPEC-T is one such example; and another is the Enterprise Canvas, which I’ll use as the base for the remainder of this post.

We could start, for example, with one of the simpler variants of the Enterprise Canvas, focussing on a single service and its context:

In effect, the model-type provides us with a checklist of questions:

• What is the service?
• What ends does it serve? – ultimately, the overall ‘vision‘ for the extended-enterprise
• What does it achieve at present? – the difference between desired-ends and realised-ends, that would typically drive change in the design of the service
• In what ways, and by what means, does the service add value to the overall enterprise? – what the service does, and why it does what it does
• What part does this service play in adding value, in the overall flow of value around the enterprise?
• From whom or what does this service obtain value? – its ‘suppliers’ or service-providers
• To who or what does this service deliver value?- its ‘customers’ or service-consumers

We then move to the next level of the Enterprise Canvas model-type – which ultimately based on the same underlying metamodel:

Here we add more detail about the value-flows between this service and its suppliers and customers. In the Enterprise Canvas concept, we split this into three main sets of interactions: those which occur before each main-transaction, setting up its context; those which occur during the main-transaction – the flows of assets and information which are often thought as ‘the transaction’; and those which follow after the main-transaction, to deal with completion-concerns such as verification and payment.

To discuss each of these flows, we would typically use another another checklist such as VPEC-T – either the original information-oriented version, or the modified generic version more often used with Enterprise Canvas, or a combination of both:

• Values: What are the values and assumptions that underly this interaction (‘flow’)? What forms of value are exchanged, transferred or referenced in this flow?
• Policies: What policies, regulations and other decisions apply to this flow?
• Events: What events trigger the flow? What messages are passed back and forth to initiate the flow? In what forms?
• Content [original VPEC-T]: What content is conveyed via this flow? In what forms? – information, physical objects, other assets?
• Completions [modified version]: What events mark the end of each flow? How does the service know and acknowledge that the flow is complete? To whom or what does it report the various levels of completion? – within the service itself, to the service-‘owner’, and for all of the parties engaged in that flow?
• Trust: What trust is needed between all parties before any interactions, particularly main-transactions? In what ways do completions (or lack of them) enhance or damage that trust? – for example, do flawed transactions create anti-clients?

At the next level of the Enterprise Canvas, we split the internals of the service into a 3×3 matrix of subsidiary services: the same ‘before’, ‘during’ and ‘after’ main-transactions, and supplier-facing (‘inbound’), internal operations (‘this’) and customer-facing (‘outbound’):

For each of these cells we would delve more deeply into the respective content and operations and business-rules and so on. The model-type itself defines or implies a stream of questions and checklists to apply here, as described in various earlier posts here.

We could then extend all of this to the complete version of the Enterprise Canvas model-type, including links with guidance-services (validation, direction and coordination), investors and beneficiaries, and the information flows between layers of service-granularity:

For each of the flows (‘X..’) we would apply a checklist such as VPEC-T above; for each of the cells and ‘external’ items, we would apply the respective content-checklist. The point is to elicit conversation, deep-questioning, requirements, concerns; the resultant model is simply a record of those conversations, with the structure of the model-type acting as a ‘checklist of checklists’.

We can also use the same model-type as a checklist from a lifecycle-perspective:

Here we view the Enterprise Canvas somewhat ‘sideways-on’, with the core operations – Value-Proposition, Value-Creation and Value-Governance – placed on one side, and the matching ouitward-facing handlers for supplier or customer-relations on the other. We already know that the VPEC-T checklist (original and/or modified version) can be used for each flow: here we find that we can also use it as a lifecycle-view, from before main-transactions (Values and Policies), initiating and during main-transactions (Events and, optionally, Content), and after main-transactions (Completions and Trust). On the ‘inside’ of the service, the Five Elements sequence (adapted from the classic Group Dynamics lifecycle) provides a similar lifecycle-checklist for the operations of the service itself. The two cycles link together step-by-step, to provide another means to guide discussion about the nature, role and operation of the service.

So when you next look at a model – any model – perhaps think of it as a record of a conversation, a record of discussions and decisions, with the model-type providing a checklist to guide that discussion:

• What difference does that make to how you see the collection of models that have in your enterprise-architecture, and other architectures?
• What options does that view provide in how you use your available model-types?
• How would you use your model-types differently, perhaps with different audiences?
• What other model-types would you need, to act as more-accessible checklists for specific groups of stakeholders?

Just an idea, to play with, anyway.