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.

4 Comments on “Models as decision-records (Enterprise Canvas)

  1. Hi Tom,

    >> To my mind, though, it more accurately represents decisions about that reality – about how we choose to view that reality.

    I prefer to think of models as organisational knowledge….

    “…a cognitive endeavour to extract a concept from the ‘ineffable domain’ (Boisot, 1995), where tacit knowledge is held in a concrete and uncodified state. The transition from metaphor, through analogy to model resonates with the conversion of tacit knowledge into an explicit representation employing a highly codified and abstract notation. The adoption of some modelling convention propels tacit knowledge into the ordered zone where it is available for transfer to an adjacent ontology and eventual exploitation.”

    “… a knowledge asset equires a variety of connected models, each representing othogonally some coincidence of abstraction and perspective. One model is not sufficient…a variety of models is ncecessary…”

    From “Domains, Ontologies, Models and the Knowedge Creation Cycle” By Tony Brinklow, Brighton Business School.

    Models are an expression of knowledge which underpins understanding and forms the basis for effective action and change. Think of it not as a record of decisions – but as an attempt to communicate learned knowledge and promote understanding. A model is a (part of a) theory about how the enterprise – or its context work.

    Is this epistemology or philosophy of social science? Either way happy to discuss.

  2. Tom!
    Terrific post! To comment as if I’m not confused: To create an abstract mechanism to show reality requires significant decision-making and being a result of that decision-making, is definitely a record of it. And, the resulting story in the model’s aspect (which I’m thinking is more ‘correct’ than perspective (Ian’s view works]) on reality is definitely a vehicle for prompting discussions. I completely agree with “the process of co-creating the story and the decisions that the model elicits and represents” being the heart of the matter. Going to Ian’s comments, the knowledge (the epistemology) of (in?) a model is only as good as the truth of the story leading to the model. Therefore, co-creation is an imperative. The diagram of the Enterprise Vision is a rush – somehow I have missed it in my travels.

  3. Ian – Good points throughout – thanks.

    “Models are an expression of knowledge which underpins understanding and forms the basis for effective action and change. Think of it not as a record of decisions – but as an attempt to communicate learned knowledge and promote understanding.”

    ‘Yes and no’ is how I’d have to reply to that, I think? Re “expression of knowledge”, I would have to refer back to your Boisot quote: the apparent ‘conversion’ from tacit to explicit takes place through a process of abstraction, and one of the key points about a metamodel or model-type is that it should itself make the abstraction-criteria explicit. If we don’t make it explicit, the resultant model is at risk of being derived from an arbitrary filtering of a much more complex contextual experience, which can introduce a lot of architectural risk.

    Re “forms the basis for effective action and change”, I’ll agree that that’s one use for a model, but there are many others. That’s why I used the term ‘decision-record’: we might use that decision-record to guide-change, but we might also use it in executable form (as BPEL or the like), to apply that understanding directly, or we might use it as a simple CYA historical exercise – and many, many other options.

    Re “an attempt to communicate learned knowledge and promote understanding”, to some extent that is a ‘decision-record’, surely? The decisions come in how we choose to ‘communicate knowledge’ and/or ‘promote understanding’: there are decisions about how knowledge is to be ordered, before there are any decisions to communicate that knowledge. Myron’s comment also applies here: “a model is only as good as the truth of the story leading to the model” – and both perceived-‘truth’ and ‘story’ are also the outcomes of decisions.

    Re “a model is a … theory about how the enterprise or its context work”, yes, exactly – and a theory is a set of decisions about the nature of some ‘reality’. Hence I keep coming back to this point about a model-type acting as a guide for discussion, using the metamodel and notation as a frame to constrain the discussion, and then recording that discussion in the terms of that model-type. And since we choose the respective model-type, as a filter, that too is decision that needs to be made with some care.

    “Is this epistemology or philosophy of social science?” Probably both, plus ontology, mythology, ethnography, anthropology and a whole lot more? 🙂 And yes, very happy to discuss, of course! 🙂

  4. Myron: great summary – thanks also! 🙂

    I’d agree you’re probably right about ‘aspect’ being more correct in this context than ‘perspective’ – a very useful distinction.

    “A model is only as good as the truth of the story leading to the model”: therein lies a very long discussion that we’d better postpone until later… 🙂 There’s a really fundamental dilemma here, sometimes referred to as Gooch’s Paradox: “things have not only to be seen to be believed, but also have to be believed to be seen”. One of the results of that is that, in most real-world contexts, ‘truth’ is both highly contextual and highly personal: hence one of de Bono’s ‘Laws of Thinking’, that “everyone is always right, but no-one is ever right” (i.e. ‘right’ from their own viewpoint, but never able to grasp the whole). So we choose a model-type and its underlying metamodel as a way to provide an agreed ‘frame of reference’, such that there is enough commonality to be able to build a description that can be agreed upon. The point is to remain always aware that that ‘frame of reference’ is never much more than an arbitrary choice, and that other choices are available which might well give us useful information. (For example, assessing US Army policy in terms of the Koran, the Talmud or the Dhammapada, as well as the more usual ‘Western’ perspectives.) Hence the real value of co-creation with as diverse a range of views as possible – including those of your ‘anti-clients’, in a business context. Interesting… 🙂

    “The diagram of the Enterprise Vision is a rush – somehow I have missed it in my travels.” Not sure which diagram you mean, because vision was one aspect of a couple of the Enterprise Canvas models above. For more on vision itself, see the presentations ‘Vision, Role, Mission, Goal’ and ‘What is an Enterprise?’. For more on Enterprise Canvas, see the description-page for the book ‘Mapping the Enterprise’ on my Tetradian Books publishing-website: at present you can still download a PDF of the whole book from there, as well as a basic two-page reference-sheet on the model-type. Would love to see your comments on that, anyway.

Leave a Reply

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

*