Context-space mapping with the Enterprise Canvas

Over on the LinkedIn Business Architecture list, my colleagues Pat Ferdinandi, JD Beckingham and Ron Segal have all helped a lot in challenging me on the Enterprise Canvas concepts. Pat in particular has been has been pushing hard for some more concrete examples of how it all works in practice.

On the other side, I haven’t really posted anything here as yet on the ‘final’ version of the context-space mapping methodology. There are a few scattered posts from a few months back, but the main description is in the chapter ‘Day 8: Putting it into practice’, in my most recent book, Everyday Enterprise-Architecture [at present you can still download the complete PDF e-book via that link].

So it seems worthwhile to develop a worked-example to show how all of these tools and techniques fit together in real-world use.

And for me, right now, the obvious example to choose would be my own work and business. I’m a futurist and maker of conceptual tools, working mainly with the arcane abstractions of enterprise-architectures: none of those attributes and emphases are exactly conducive to fame and fortune… 🙁 It’s true I do get by well enough at present, yet I would like my work to be better known and more commonly used, and – no surprises here 🙂 – it’d be good if it could bring in a better income, too. So how can I make that happen? What do I need to do that’s different from what I’m doing now? What do I need to change in the architecture of my own enterprise?

And I’m not alone in this: I know a lot of enterprise-architects and others – especially those of us working in the very new field of whole-of-enterprise architectures – who are in much the same boat at present. In our own quiet ways, all of us are wrestling with much the same questions:

• What business am I in? – really?
• Who else would be interested in what I’m working on? What value do I add right now? – if any?
• Where could I add value? In what contexts?
• With whom would I need to work with in on this? Who would be my prospective partners, clients and other business-relationships?
• For whom could I most add value? Who would pay for it? – and why would they pay for it?
• How can I describe that value? How could I prove that value?
• How would I deliver that value? How would I prove that I’ve delivered it?
• How much could, would or should I charge for this?

And so on: all pretty fundamental questions, really – especially in business. Sounds like a good candidate for some serious exploration – which is where context-space mapping and the Enterprise Canvas come into the picture.

This’ll probably take several posts, but let’s get started.

Context-space mapping – a quick review

For many people, the initial problem with context-space mapping is that although it’s a very simple idea in practice, it can be surprisingly hard to explain on paper. The core of it comes down to just four keywords:

• sensemaking – making sense of the context
• strategy – deciding what to do with we’ve discovered
• structures – we look for patterns, for structures, for something that’s stable enough for us to build something on it or with it or around it
• solutions – we identify and/or define the detail of what we’re going to do within the chosen context

At first, that often looks like it would be a straightforward step-by-step process, and in fact it’s portrayed that way in some frameworks such as the TOGAF ADM (Architecture Development Method), which would match up to the above as ADM Phase A-D (sensemaking and some aspects of strategy), Phase E (strategy and high-level structures), Phase F (structures and solution-plan) and Phase G (solution-implementation) [with Phase H as a wrap-round to prepare for sensemaking again in a new cycle]. Reality, though, is a great deal messier than that – hence, for example, why the TOGAF specification describes the process as ‘iterative’, which is something of a polite understatement! 🙂 So although those four steps above do represent the overall flow of what happens, in practice we’ll usually pass through most of these steps many times, in many different ways, and in just about any order, jumping back and forth between the respective emphases as we go.

In essence, we ‘go for a walk’ in a kind of imaginary-world, in order to make sense in the real one. The imaginary-world is our sense or understanding of the context in scope – in this case, a business and its business-models, including the practical implementation and execution of those business-models. What we want to end up with is a detailed picture of what to do, to make all of that happen back in the real-world, and also – and this is important – some clear hints about what we need to watch for and to do to change that plan on the fly in response to the actual circumstances at the time: “no plan survives first contact with the enemy”, or, more generically, first contact with reality.

To guide us, we start off with some fairly simple map – often just a list of categories of things or ideas or attributes. We then add more and more detail to that sensemaking map as we go. Walking around – metaphorically speaking – gives us many different views over the context, from many different directions, sometimes as a big-picture overview, sometimes right down into the fine-detail. At times, quite without warning, as TS Eliot put it, “…the end of all our exploring // Will be to arrive where we started // And know the place for the first time.” Using different model-types as overlays on the map creates further views – not so much filling in all of the missing pieces on a jigsaw, as adding richness and depth to a hologram where every point contains every other point.

That’s the everyday world of an enterprise-architect. It’s also a quick way to go crazy if we don’t make proper use of that map. Many people get stuck in analysis-paralysis, for example; others mistake someone else’s prepackaged ‘solutions’ for strategies, and wonder why nothing works any more. Everything is built up, layer upon layer, from the base-map with which we start, and to which we return whenever we realise that we’ve gotten lost somewhere. So the maps we use will matter a lot.

Context-space maps have two distinct components: the base-map, which provides a common frame of reference for a set of context-space maps; and any number of cross-maps – other models overlaid onto that base-map – that provide alternate views and categories for sensemaking in the same context. In practice, typical characteristics for a good base-map include:

• universality: it covers the entire scope of a given context – in principle, at least
• sensemaking: its purpose is to guide sensemaking and decision-support (rather than design and implementation of a specific ‘solution’
• simple partitioning: it divides the context into a small number of regions or ‘domains’ (from three or four to a dozen at most), and often including a ‘none-of-the-above’ region
• fluid boundaries: the boundaries between regions may be allowed to move, blur and/or be somewhat porous
• usage-dependent layout: its layout may not be semantically significant, and may take any appropriate form, such as a horizontal or vertical single-dimension, or multi-dimensional form such as the four-axis/three-dimension tetradian

In systems-theory terms, each base-map is a rotation that provides multiple views into the same overall space. Ideally we also want it to illustrate the balance in the context (reciprocation and resonance), and preferably the layering (recursion and reflexion) in that context too.

The Cynefin-categorisation – Simple, Complicated, Complex, Chaotic, and the ‘none of the above’ Disorder region – is one frame that’s proved useful as a base-map; another, especially where the context is mainly about flows of some kind, is the VPEC-T frame – Values, Policies, Events, Content, Trust. Another is the Zachman frame, with its six core questions: What, How, Where, Who, When and Why. The frame we’ll use for this purpose, though, is one that’s somewhat larger in scale and scope: the Enterprise Canvas.

The Enterprise Canvas – a quick review

As with context-space mapping, the essence of the Enterprise Canvas is one very simple idea: everything in the enterprise is (or is part of) a service of some kind, and every service – in principle, at least – adds value to the overall enterprise. Each service sits at a kind of intersection where the vision and values of the enterprise crosses the flow of value (the ‘supply-chain’ or ‘value-web’) around the various players in the enterprise – a point of value-creation, as the core of service-delivery:

Each service has its own value-proposition, which defines and guides what value will be delivered by the service; and its own value-management, which ensures that the respective value is actually created and delivered. On either side of this kind of ‘vertical axis’ are the main flows of value-exchange with other players in the enterprise, either as ‘suppliers’ or ‘customers’ relative to this service; for a variety of practical reasons we partition these flows in terms of what needs to happen before, during and after the main types of value-exchange, which are managed by supplier/customer relations, by supplier/customer channels and by value-outlay/return respectively. In effect, every service in the enterprise can be described in terms of this simple structure.

(If that doesn’t make much sense as yet, don’t worry: it should all become more clear as we go through this worked-example.)

The other important point is that we need to be able to describe these services in terms of layers of abstraction, from most-abstract – ‘the enterprise’ as a whole – right the way down to most-concrete – the fine-detail of action-plans and action-records. There’s more detail about the layers here, but again, don’t worry too much about it just now: the main point to note is that we’ll often see what may seem to be the same service re-appearing in different layers, but actually at different levels of abstraction, going ‘down’ towards real-world implementation, or ‘up’ towards re-structure and redesign.

There are also several different versions of the Canvas – summarised here – depending on whether we’re looking solely at the service itself (for which we’d use the version nicknamed the ‘brick’), its flows and links with other players (the ‘beetle’), or its integration into the enterprise as a whole (the ‘robot’). Most of the time we’ll use the simpler version – the ‘brick’ – which is essentially the same as in that cross-diagram above.

So that’s what we’ll use as our base-map. To get started with the context-space mapping, we’ll move to the topmost layer of the Enterprise Canvas – row-0, ‘Enterprise’ – to address the first question in our review: “What business am I in?”

Identifying the enterprise

Probably best to start by defining what’s meant by ‘enterprise’. (Perhaps it’s best to think in terms of ‘shared-enterprise’ or ‘extended-enterprise’ here: many people use ‘the enterprise’ as a synonym for ‘the organisation’ – which is not a good idea, because they’re not the same, as we’ll see in a moment – but we’ll have to allow for the fact that people do this.) To use the definition from the FEAF document A Practical Guide to Federal Enterprise Architecture:

[An enterprise is] an organisation or cross-functional entity supporting a defined business scope and mission.

An enterprise includes interdependent resources – people, organisations and technology – who must coordinate their functions and share information in support of a common mission or set of related missions.

Again, note the booby-trap here: ‘enterprise’ is not the same as ‘organisation’. The Practical Guide warns:

…it must be understood that in many cases, the enterprise may transcend established organisational boundaries – e.g. trade, grant management, financial management, logistics.

An organisation is a formal structure of some kind, in essence bounded by rules, roles and responsibilities. But an enterprise in this sense is more like something that happens between or ‘above’ any individual organisation: “interdependent resources … who coordinate … in support of a common mission” and so on. The point is not just the processes via which that coordination happens, but the underlying idea – the ‘why’ – that makes it “a common mission or related set of missions” shared across all of those “interdependent resources”, the reason or decision that links everyone together in this shared activity.

Identifying the underlying enterprise will tell me why I work for or with a particular organisation. It tells me why I work in that particular enterprise rather than in any other. And it also indicates who it’s likely I could collaborate with, because they’ll all be people or groups or corporations have an interest in this same enterprise.

Importantly, the enterprise is also emotive: if it’s described properly, it will literally give the people involved in that enterprise a reason to get out of bed in the morning. The organisation is just rules, roles and responsibilities; but the enterprise matters.

What we need up in row-0 of the Enterprise Canvas is a kind of ‘enterprise descriptor’ – usually referred to as the vision – and a related set of core-values that identify the highest priorities to guide decision-making. There’s a lot of discussion about ‘vision’ in business, and unfortunately many of the commonly-promoted examples are no more than empty marketing-puff – almost useless for any practical purpose, especially in enterprise-architectures. A ‘vision’ that does work consists of a very brief phrase – usually no more than four or five words – with a distinctive three-part content and structure:

• a descriptor for the content or focus for this enterprise
• some kind of action on that content or focus
• a qualifier that validates and bridges between content and action

These components may occur in any order, but all of them need to be present. For example, take the vision for the TED conferences, “ideas worth spreading”: ‘ideas’ [content]; ‘worth’ [qualifier]; ‘spreading’ [action] – clear, succinct and emotive. And note that none of these describe the organisation at such – but do describe the focus, the area of action, and the key value-metrics which define the meaning of ’success’. That’s what we need to look for at this stage.

So in my own case, what enterprise am I in? Which enterprise – or type of enterprise, at least – best lines up with what I do? That suits the way I work, the kind of things I want to do, and so on? With the Enterprise Canvas, one tactic is to go right to the other end of scale of abstraction, down to row-6, where options are not so much unchanging (as they should be in row-0), but unchangeable, because they’re in the past. In short, what can I learn from my own history?

(I’m using a personal-business example here, but the principle is essentially the same for an organisation of any size – for-profit, not-for-profit, government or whatever.)

Overall, for me, that’s more than four decades of professional past to explore, across many different industries: graphic design and pre-press, medical education, skills-research, information-systems, aeronautical engineering, telecoms, logistics, banking, utilities, just to name a few of the more mainstream examples. But there’s one common theme that seems to run through every one of these examples: the quest for effectiveness, in almost any of its myriad forms. That’s true for my work with individuals, and their development of skills and competences; for teams and work-groups, or for specific aspects of an organisation; sometimes for organisations as a whole; and more recently, with enterprise-architectures, across groups of organisations or even entire industries. And it’s clear that I’m passionate about it, too – which means it fits that criterion that it needs to be something “strong enough to get someone out of bed in the morning”.

‘Effectiveness’: is that the content, the qualifier, or the action? Not sure yet: so keep wandering around in the context-space for a little while longer.

Try another tack: a descriptor can be either about content, or focus. So what’s the focus here? – would that help to clarify the shape of this enterprise? Somewhat recursively, it seems that the focus of this enterprise is actually enterprises themselves, about coordination and collaboration and competence, again at every level, from the individual right up to the scale of entire economies.

Okay, this seems to be getting somewhere: this enterprise that I’m in is about effective enterprises, or enterprise-effectiveness – something like that, anyway. And ‘effectiveness’, as I’ve come to understand it over the past couple of decades, has five distinct strands that are close to being values in their own right:

• efficient: optimises use of resources, minimises wastage of resources
• reliable: predictable, consistent, self-correcting, supports ‘single source of truth’ etc
• elegant: clarity, simplicity, consistency, self-adapting for human factors
• appropriate: supports and optimises support for business purpose
• integrated: creates, supports and optimises synergy across all systems

In effect, effectiveness happens when everything supports everything else, always pushing towards enterprise purpose, the respective enterprise-vision. And all of that – about enterprises and effectiveness – does fit very well with what I do. Or rather, that’s the descriptor and the qualifier for the vision – I still need to identify that ‘action’-component.

And that last part of the vision still isn’t quite clear as yet. It’s a verb something like ‘creating’ or ‘making’ or ‘building’ – it’s obviously not ‘destroying enterprise effectiveness’, for example. (Don’t laugh: some people really are engaged in the enterprise of destroying enterprise-effectiveness – such as those whose passion is about breaking up the enterprise of organised-crime.) I’ll choose ‘creating’ as the action-verb for now: given the recursive, re-entrant nature of context-space mapping, I can always come back to adjust that kind of fine-detail later.

So let’s put all of this together, to give me a preliminary row-0 for my Enterprise Canvas: the enterprise that I’m in is about creating more-effective enterprises, expressed via those five themes or principles of effectiveness – efficient, reliable, elegant, appropriate, integrated.

Note that unlike an organisation, this enterprise isn’t something I own, or control – in fact it’s more like that it owns me, because it’s such a core driver for everything that I do. In principle I could choose anything as ‘my’ enterprise – but in effect it’s more that this one chooses me.

And that’s the principle here, especially when we move up the scale to a company or an entire corporation: we’re looking for that to which the organisation would naturally align. Once we have clarity on that, then many of the classic organisational problems suddenly become a whole lot easier: we stop arguing about ‘business/IT-alignment’, for example, because both sides can now align to the same enterprise-vision. That’s what all of this exercise is about: creating clarity, enhancing effectiveness.

What happens next is that we use that enterprise-vision to tell us a lot more about the business that we’re in – including all the other players in the same overall enterprise. That’s what we’ll start with in the next article in this series.