We now do another sideways move, to explore how we might use a modified version of the classic Zachman framework to assess the content and activities of each entity (or service) in scope.

This also helps to demonstrate some of the real power and value of context-space mapping as an enterprise-architecture technique. We always start the mapping process with a suitable base-map – in this case, the Enterprise Canvas – which we use as a base and common cross-reference for all of the current sequence of sensemaking and model-development.

(There are quite a range of other models we could use as a base-map for context-space mapping, such as the Five Elements frame, the modified-Zachman frame, the Cynefin categorisation [simple, complicated, complex, chaotic, 'disorder'], Nigel Green and Carl Bate’s VPEC-T, Richard Veryard’s Lenscraft, and Sohail Inayatullah’s Causal Layered Analysis; we’ve used the Enterprise Canvas here because it’s the best fit for this type of enterprise-architecture work, but other frames may well fit better for other tasks.)

Given that base-model, we can cross-reference to other model-types to give us further information and further clarification, but always anchored back in the same base such that everything links together in a consistent way. In this case we’ll use a modified version of Zachman that leverages the layering of the Enterprise Canvas, and that also covers a broader scope than Zachman’s usual IT-specific examples.

The single-row extended-Zachman frame

Classic Zachman consists of a grid with six columns and five rows. The set of columns have been assigned various labels at various times, but in essence are What, How, Where, Who, When and Why. The five rows represent layers of abstraction, from the overall business-context down to detailed implementation-plans for real-time action.

The layers or rows of the Enterprise Canvas exactly match the Zachman rows – in fact extend them slightly, with one extra row at top and bottom, to include the unchanging enterprise-vision (row-0), and the also-unchangeable past (row-6).

Because we’ve already included the Zachman rows in the structure of the Enterprise Canvas in this way, we don’t need to use those rows in our use of Zachman here – we already know what Zachman row we’re in, because we know which Canvas row we’re in. That makes things much simpler, because we only need to work with one row at a time. Yet Zachman’s easily-remembered interrogatives of  What / How / Where / Who / When / Why turn out to be surprisingly misleading when we get down into the detail of what’s needed for an enterprise-architecture – so we’ll need to amend the column-headers and contents to resolve that. And it turns out that there’s an entire dimension missing in the original Zachman – a set of segments to describe entity-types and/or decision-types – so we do need to include that here.  Overall, this gives us a simplified yet extended version of Zachman that we can use in conjunction with each row of the Canvas:

Zachman classically splits everything into primitives and composites: a primitive is something that can be defined or described in terms of a single cell, whereas a composite straddles across cells. So pure data, for example, is a primitive, a virtual asset, whereas a book is a physical ‘thing’ that contains information, and hence is a composite physical+virtual asset. A function changes assets, yet can do nothing on its own until combined with a capability (an ability to work on an asset-type at a particular skill-level), a combination that we describe as a ‘service’; a ‘process’ represents a sequence of service-requests; and so on.

(A composite should not be able to straddle Zachman rows, but that doesn’t concern us here, because we’re only working with a single row at a time anyway. Note, though, that a pattern can straddle more than one row: for example, one very common design-pattern in data-architecture is that the abstract [row-3] ‘many-to-many’ data-relationship may be implemented [row-4] as a cross-reference-table.)

At the real-world level (Canvas row-5 ‘immediate-future’ and row-6 ‘past’, straddling either side of the ‘Now’), everything must, by definition, be an ‘architecturally-complete’ composite of “with <asset> do <function> at <location> using <capability> on <event> because <decision>“. One of the main roles of architecture is to apply abstraction (moving ‘up’ the rows towards row-0 ‘Enterprise’) to split the composites apart into smaller composites and primitives, so as to enable reconfiguration and redesign into other, more effective ‘solutions’ for the given context.

Assets are entities for which we are responsible. (Note that this is not the same as ‘resources’. There’s a crucial distinction between ‘possession-based’ versus ‘responsibility-based’ concepts of economics which would take too long to explain here. Conventional economics is based on notions of ‘rights’ of possession, whereas internally a business will operate on responsibilities – for example, a process-owner is the person who is responsible for that process, not the person who ‘possesses’ it. The shortest summary is enterprise-architectures only work when we use a responsibility-based model thoughout, and that in essence ‘resources’ become assets when we take on responsibility for them.) As described in the market-metaphor, asset-types include:

• physical ‘things’
• virtual items such as data and information
• relational links between real people
• aspirational links between people and abstract ideas, represented by brands in one sense, but also by morale, by values, and by the idea of the enterprise itself

An asset may also be represented by any composites between these types. In practice, it’s probable that most real-world entities are composites in this sense: for example, a key point in marketing is creating emotional attachment to objects – in other words, a composite of physical and aspirational.

(Some people would argue that financials are a special-case, another type of primitive. A few moments’ thought, though, would show that financials are actually a composite of virtual and aspirational – information about a belief, where each currency represents a brand that implies ‘rights’ to resources. Architecturally speaking, money isn’t a value, it’s actually a belief about value – and often a very muddled belief at that!  So yes, financials are important, especially in any for-profit organisation: yet over-emphasis on financials is a proven cause of failure in enterprise-architectures, and for our purposes we do need to keep them in their place.)

Functions will use, reference, act on, change and/or return assets, and hence can be described in terms of the same asset-types.

(Note that, architecturally speaking, the function is only one part of ‘how’, a description of what usages or changes will apply to those assets: it doesn’t describe the ‘with-what’ aspect of ‘how’, which is represented by the capability that actually enacts the function. In classic machine-design or functional-programming for IT-systems, function and capability are merged within the machine or the program itself; but in fact it’s an arbitrary constraint, and one that doesn’t apply when processes are enacted by real people, or when we move back to the abstract for process- or service-redesign. Architecturally, it’s important to keep function and capability separate at a conceptual level, and be aware of how and why we merge them in each service-implementation.)

Locations can also be described in terms of the same asset-types: physical locations; virtual locations such as a URL or an IP-address; relational locations, such as displayed in an org-chart; and even aspirational locations, such as relationships between brands; or composites of these types, such as the composite physical+virtual location of a data-server. It’s also best to describe time as a kind of abstract-location: for example, events may occur in time – in other words, may be located in terms of time – but are not actually part of time itself.

Capabilities need to be described both in terms of the asset-types they act on, and the skill-levels or decision-abilities used in that action:

• simple rule-based decisions such as following a predefined step-by-step process or checklist
• more-complicated algorithmic or ‘hard-systems’ capability that still assumes predictable rules but can accommodate many branches, delayed-feedback, damping and the like
• heuristic or ‘soft-systems’ capability, often using guidelines or patterns to interpret emergent contexts with complex inherent uncertainties, such as so-called ‘wicked-problems‘
• principle-based decision-making for contexts that are unique and inherently unpredictable

The asset-type distinctions for capabilities are relatively straightforward, but the distinctions about skill-levels become crucially important in process-design, because physical machines, IT and real people have very different capability-curves. In general:

• physical machines can usually only work on physical assets, and are best-suited to following rule-based decisions
• IT-systems can work on virtual-assets and, via control of physical machinery, physical-assets, using rule-based or algorithmic decisions, but are still limited in capability for pattern-recognition, and in general should not be used for decision-making in inherently-unique contexts
• real-people can work on any types of assets, with varying skill-levels, though in many (most?) cases are notoriously not well-suited to the rigid rule-following and mechanical repetitive-tasks assumed and required in Taylorist ‘scientific management’

Attempts to use the wrong types of systems in a given context will usually lead to ineffectiveness and, in many cases, ‘unexpected’ failure. One all-too-common example in enterprise-architecture is the tendency of IT-evangelists to promote the notion that there is an IT-based solution for every possible problem, and that such IT-based solutions are inherently the ‘best’ option in every case. It’s true that IT may be the most effective option in some cases, but it causes catastrophic failure in others, yet the IT-centrism itself blocks out the information needed to identify why the failure will occur.

(Note too that a capability is embedded in or enacted via some kind of asset: in a machine (physical) or a computer-program, or via a relational-asset to a real person. [It's essential to understand, by the way, that real people should never be described as 'assets', either in an architecture, or anywhere else. This is the whole point about relational-assets: the relationship is the asset, not the person - it's the relationship with the person that creates the access to that person's capabilities. If the relationship is damaged or destroyed, almost all value will be lost, even if the person is physically present.] Zachman’s label for this column – ‘Who’ – sort-of makes sense in relation to real people, but makes no sense at all when the capability is embedded in anything else: this would then force us to merge function and capability together for machines and IT, but not for people, further compounding the architectural errors described above.)

Events are triggers for action, and can again be described in terms of the same asset-types: physical events; information-events, signals and other virtual-events; relational events, such as a phone-call or the arrival of a prospective customer at a store-counter; and even aspirational-events, such as a change of brand, or an event causing damage to morale. As usual, many if not most real-world events will be composites of these types, and for many purposes a broader notion of event as a kind of ‘package’ may be more useful – see the VPEC-T framework for more on this. Note also the point above about time: events occur in time, but are not actually part of time itself.

Decisions represent the ‘why’ or ‘because’ of the enterprise. Decisions are usually built up in layers or hierarchies of dependencies, with the question ‘why?’ moving upwards through the layers, and ‘because’ moving down. (The enterprise-vision is the ultimate ‘Because.‘ of the enterprise: note the period/full-stop, which indicates that the layering of ‘why’ stops here! ) There are many ways we could describe this layering – for example, see the Business Motivation Model [PDF] standard – but probably the most useful categorisation is the same set as for the skill-levels in capabilities: rule-based, algorithmic, heuristic and principle-based. Again, most (and arguably all) real-world contexts require composites of those decision-type categories, as a chain of exception-trapping and escalation: a key point is that any real-world process-design will need to ensure that the ability to make appropriate decisions does indeed exist at each escalation-level in the context, otherwise the overall process is guaranteed to fail on some ‘unexpected’ event.

Using the extended-Zachman frame with the Enterprise Canvas

Fine: but how do we use all of this categorisation and theory – especially with the Enterprise Canvas? What use is it?

The obvious point is that we need all of this to tell us what happens within each entity. It also helps us to distinguish between the cells in the entity (or, to put it the other way round, the cells specialise in different areas of the Zachman frame): the core functions of the entity-as-service take place within the Value-Creation cell; the supplier-side or customer-side Channels deal with the main transaction-events; the Relations cells are especially important for dealing with relational and/or aspirational-assets; and so on.

Another option is that we can use this to tell us which Canvas layer we’re working in at any given point. For example, if we’re dealing with records – in other words the past, the ‘as-was’ – then by definition we’re in row-6. If we’re looking at relationships between entities, we cannot be above row-2; if we’re looking at lists of things, we could be anywhere up to row-1, but if we’re looking at attributes of things, we can’t be above row-3. The moment we mention a specific technology or technique, we’re in row-4 or below. These are all fundamental to architecture-driven redesign, and help to prevent us from treating any prepackaged ‘solution’ as an architectural requirement – unless we choose to do so, of course. The only true architectural requirement is the enterprise-vision and its associated core-values: everything else is just implementation, at varying levels of abstraction.

The relationships between primitives and composites is also important here, because the higher up we go in the layering of the Enterprise Canvas, the more we need to be working with primitives – or at least to understand the primitives that make up the core-composites. Conversely, the closer we get to the real world, the more likely it is that we’ll be dealing with complex composites-of-composites, which we’ll probably need to break down into simpler components in order to enable redesign. If we think of a ‘complete’ composite as straddling all cells in the single-row extended-Zachman frame, and a primitive as the least-’complete’ that we can get, then in essence one of our most important architectural concerns comes down to this:

Things are usable to the extent that they are architecturally ‘complete’;
things are re-usable to the extent that they’re architecturally ‘incomplete’.

To enable new architectural options, we need to be able to split our composites apart. So, as an author, I might think of myself as a writer of books. But a printed book is actually a composite, a ‘bundling’ of information in a specific physical form – and as an author, my actual product is the information, not the physical book. (It would be the other way round for someone who worked in a printing business, of course.) Once I understand that point, it opens up a whole raft of new possibilities, new options to deliver the service represented by that information. For example, I could dispense with the physical book, and present the same content in electronic form, as an e-book. I could split up the content in different ways, perhaps serialised in smaller chunks in an online magazine. I could present it another virtual-medium, via video or voice. Or I could deliver it via a relational-asset channel, otherwise known as in-person consulting.

To make something re-usable, we need to move up the layers of abstraction, splitting apart the implementation-composites to expose the ‘bundling’ that could perhaps be recombined in new ways; and to make something usable, we need to go down the layers, linking each item into more and more ‘complete’ implementation-bundles. At the point where it touches the real world, everything must be architecturally-’complete’. That’s what the layering describes.

The other key point about the extended-Zachman is that it acts as a checklist to make sure that we line things up correctly: for example, that we don’t try to use IT for something for which it’s not well-suited, or which it can’t handle at all. Another example (which should be obvious to everyone, but painful experience indicates that it isn’t…) is that a record of a ‘something’ is not the same as the thing itself. The record is information – a virtual-asset – whereas the thing referred to in the record could be any type of asset at all – a physical object, a data-event, a business-relationship, or whatever. So the moment someone mentions that we have a record of something, we need to look for the matching audit-process or equivalent – such as data-cleansing and de-duplication – that ensures that the records do line up correctly with the respective items: because if that audit-process doesn’t exist, we have an architecture that almost guarantees service-failure.

And we can also use the same checklist-approach to ensure proper coverage for disaster-recovery, business-continuity or just everyday operations. Machines fail, computer-systems fail, power-supplies or network-connections fail, whole buildings can be swept away in a natural or man-made disaster: we may well need ‘manual’ processes to take over at a moment’s notice. Which means that we need that processes to exist, and people with the appropriate skills to do them – and know how to switch over to those ‘manual’-processes, too. All of those are items that we can check by using the extended-Zachman checklists, in a layered way:

• Given the asset-types list, what capabilities are needed to work on them?
• Given the decision-types list, what exceptions will cause a decision to be escalated – all the way up to truly-unique yet business-critical events?
• Does the skill and capability exist to resolve that escalation? Via what means will that capability be delivered?
• How can we design the service-interfaces to be ‘transparent’ to the implementation-method – for example, such that people can take over when an IT system fails, or a machine can take over when people are overloaded?
• What are the trade-offs?
• What are the costs – in any sense of ‘cost’?

That’s where this kind of assessment will help, combining the precision and detail of the extended-Zachman frame with the layering and simplicity of the Enterprise Canvas.

A practical example

To put this into practice, I’ll use the example of the enterprise-model for our own enterprise-architecture business.

For row-0 ‘Enterprise‘, there’s nothing to do. Strictly speaking, we could label everything at this layer as being part of the ‘Why’ or ‘Decisions’ column, but in reality that would make relatively little sense. It’s more useful to think of the enterprise-vision – “enhancing enterprise effectiveness”, in this case – as being more like a backplane that sits behind every subsequent use of the extended-Zachman frame in the other layers, and to which everything should connect.

In row-1 ‘Scope‘, all we should have are lists that point in some way to the enterprise-vision and its values. In an earlier post we identified the probable list of players in this enterprise; here we should use the extended-Zachman to identify other key entities in scope for the enterprise of ‘enhancing enterprise effectiveness’:

• assets: mostly information about new ideas and techniques, with some emphasis on person-to-person relationships to support responsibilities; not many physical ‘things’ involved here
• functions: most of the work is in the ‘validation-services’ group – creating awareness of the need and options for enhancements, developing capabilities to create enhancements, and assessing and reviewing enhancements to overall effectiveness – which could apply to any aspects of enhancing effectiveness in an enterprise
• locations: the work may take place in and/or apply to any type of location
• capabilities (action): activities in scope may be about any type of asset, but the capabilities that are actually used in this enterprise mainly involve assessing, reviewing, consulting and training
• capabilities (skill-levels): skill-levels for assessment, review and consulting generally need to be at the high to very-high levels (pattern-based to principle-based), although implementation of enhanced processes may be at any skill-level down to low (simple rule-based)
• events: the main trigger for these activities will be a perceived need or desire to enhance enterprise effectiveness – the actual source of that trigger may take any form, such as a physical failure, a signal about an out-of-range condition, a person-to-person discussion or concerns about flagging morale
• decisions: most of the sensemaking and decisionmaking in this enterprise tends to address complex and/or unique contexts, requiring pattern-based or principle-based decisions respectively – although effectiveness itself may be supported by decisions all the way down to simple checklists

We’d have to admit that this doesn’t tell us all that much, mainly because this specific enterprise itself has to cover such a wide scope, and much of it is recursive in the sense that it uses techniques to look at techniques, or information to look at information, or decisions about decisions. But we can note, for example, some of the items that are not in scope: not many physical items, for example, or simple- or algorithmic-level skills that could be implemented by IT or machines. There may be a lot of information, but ultimately most of that information is going to have to be assessed by real people.

In row-2 ‘Business‘ we start to look more closely at what our own business has, does and uses – which, by comparing this with the row-1 lists, tells us the extended-Zachman items that we expect to be used or implemented or provided by other players in this enterprise. This forms the basis of the relationships between players, that is the core of this layer. From our perspective, this tells us which groups of players might be likely customers for us, and the relative priorities for each; which groups might be useful suppliers and, again, their relative importance to us; which others provide ‘validation-services’, ‘direction-services’ and/or ‘coordination-services’ to help guide what we do and how we do it; and who our potential investors and beneficiaries might be, and what types of values would be in play overall. That’s quite a lot, so the extended-Zachman assessment definitely starts to become useful here.

For the moment, we’ll do this with our ‘as-is’, and then develop a ‘to-be’ from the comparison with row-1. Note that at this stage, in row-2, we’re only concerned with the broad outline that can be used to identify potential business-relationships:

• assets:
  • physical: computers/office-equipment, library, vehicles etc
  • virtual: books, presentations, websites/domains, research-repository etc
  • relational: wide range of business-/peer-contacts
  • aspirational: clear commitment to enterprise-architectures and effectiveness
  • financial (composite): [not disclosed]
• functions:
  • physical: [usually not relevant]
  • virtual: creation of ‘texts’ (especially methods, methodologies, metamodels etc) and analysis/synthesis of clients’ contexts
  • relational: development of contacts for own organisation and between others
  • aspirational: creation of clarity on clients’ direction (e.g. strategy, tactics, motivation)
  • composite: consultancy for business-change, creation of new methods and tools, creation of customised methods and information-structures
• locations:
  • physical: office-based and mobile
  • virtual: web, email, telephone
  • relational: various peer-networks
  • composite: conferences etc
• capabilities (action): methodology and modelling, idea-development, writing/presenting, analysis/synthesis, consultancy; media including pre-press for book-production; familiarity with IT-development
• capabilities (skill-levels): main skills-base is methodology/modelling, idea-development, writing/presenting and consultancy
• events: triggers for action are mainly direct contact (e.g. leading to discussion and/or consultancy) or new idea
• decisions: most decision-types are complex to unique-context (pattern-based to principle-based)

We can now compare this to the row-1 description for the overall enterprise, to identify what we do not do in the enterprise. Anything we don’t have or don’t do, and that is part of the enterprise, will imply the need for a potential business-relationship – it’s as simple as that.

But what kind of business-relationship? To clarify that, we pick some example-organisations and do a quick row-2 for each as above, and then compare against our own row-2 map. In conventional business-terms:

• anyone who covers some other aspect of the enterprise is a potential supplier
• anyone whose focus is another enterprise but could service a specific need here – e.g. travel – is also a potential supplier
• anyone who has need of the types of services that we offer to the enterprise is a potential customer
• anyone who offers the same types of services that we do is a potential competitor, with the implied ‘threat’ dependent on closeness of match – functions, locations, capabilities, skill-levels etc

For any business-architect, this will be familiar territory: SWOT, Porter Five Forces, Value-Chain Analysis, Business Model Canvas and so on. In the Business Model Canvas, for example, most of the content for the ‘Key Activities’ and ‘Key Resources’ cells would come from the extended-Zachman frame. A key difference here, though, is that the Business Model Canvas is optimised for analysing and developing the business model – for example, in a for-profit organisation, the summary of how that organisation makes its monetary profit – whereas the Enterprise Canvas is more about the operating model, the operation of the organisation and enterprise as a unified whole. (Ross, Weill and Robertson’s justifiably-lauded book “Enterprise Architecture as Strategy” also aims to describe the operating-model, but in practice only from an IT-oriented perspective.)

In row-3 ‘System‘ and row-4 ‘Design‘ we start to get into the kind of fine-detail already familiar to business-architects and enterprise-architects: nothing much new here as such. What is different is the way that we can now link all of this ‘upward’ to the decisions and choices in row-2 and above, and ‘downward’ into the fine-detail of implementation. The key distinction between row-3 and row-4 is level of abstraction: row-3 is always in generic terms, so as soon as we mention a specific technology, a specific location, that fact places us in row-4. Note that although we might describe these under the simple extended-Zachman headings, in practice many more of the items are composites, becoming increasingly-complex composites as we move ‘downward’ towards real-world implementation:

• assets:
  • physical: office-equipment, library, vehicles etc, duplicated in both main bases (Britain and Australia); most computers are portables (laptop, netbook, tablet) configured for on-site use, with a mix of Windows, Macintosh and other operating-systems, using text-development, diagramming, modelling and other software
  • virtual: books and other texts are produced in physical and e-book formats, available via online and book-trade distributors; presentations at conferences and online; websites/domains; research-repository for internal use etc
  • relational: wide range of business-/peer-contacts in Australasia / Asia-Pacific, Europe, North America, Latin America
  • aspirational: clear and public commitment to enterprise-architectures and effectiveness, as describes in articles, presentations etc; established brand-names and reputation
  • financial (composite): [not disclosed], requires accounts/accounting in multiple currencies, with separate tax-liability for each main base
• functions:
  • physical: mostly background-activities, but includes travel, manual shipping of books, manual processes of writing and diagramming etc
  • virtual: creation of ‘texts’ (book, presentation, audio, video etc), especially on methods, methodologies, metamodels etc; also models, metamodels, development-plans and other context-specific consultancy-artefacts for clients
  • relational: development of contacts for own organisation and between others, via in-person [relational+physical], web or phone [relational+virtual] and/or reputation [relational+relational/aspirational]
  • aspirational: creation of clarity on clients’ direction (e.g. strategy, tactics, motivation), using visioning, motivation-models, futures techniques etc
  • composite: consultancy for business-change, creation of new methods and tools (such as context-space mapping, Enterprise Canvas, Five Elements enterprise-architecture, extended-TOGAF, extended-Zachman, whole-of-enterprise service-models, SEMPER diagnostic, etc), creation of customised methods and information-structures
• locations:
  • physical: two main bases (Britain, Australia), otherwise anywhere in the world as required
  • virtual: websites, weblogs, Twitter, LinkedIn, Skype, Slideshare, other trade-specific networks, direct email etc
  • relational: various peer-networks
  • composite: conferences on enterprise-architecture, business-architecture, business-transformation etc
• capabilities (action): methodology and modelling, idea-development, writing/presenting, analysis/synthesis, consultancy; also pre-press for book-production, for in-house only; and some limited IT-development (mainly database, website-code and concept-demonstrator prototypes), also mostly in-house
• capabilities (skill-levels): methodology and modelling up to meta-meta levels; idea-development, writing/presenting and consultancy are main public skills-base; pre-press and IT-development are both low-priority and, for IT especially, probably somewhat out-of-date
• events: triggers for action are mainly in-person contact [relational+physical], online contact [relational+virtual] or new idea [virtual, or virtual+relational for collaborative development]
• decisions: most decision-types for enterprise-architectures, consultancy and methodology-design are complex to unique-context (pattern-based to principle-based)

That’s a fair summary of everything that we have and do as a business. We could now, for example, use the underlying Enterprise Canvas to explore in more depth how each of these assets and functions and the like can be split up in terms of the various emphases of each cell in the Canvas: in the Value-Proposition and Relations cells, to build and maintain the business-relationships, for example; or the Channels and Value-Creation cells in terms of what happens in the various transactions with our suppliers and customers – who in some cases can be the same person or entity, of course.

Or we can use VPEC-T (Values, Policies, Events, Content, Trust) across each of the supplier-side and customer-side transaction-flows, and cross-map the results to the extended-Zachman. The VPEC-T ‘Policies’ lines up with the extended-Zachman decision, ‘Content’ lines up with asset, and ’Events’ obviously lines up with event (though in the VPEC-T specification an ‘Event’ will also always include at least some kind of message or other virtual-content within itself).

And we could also apply a RACI matrix (Responsible, Assists, Consulted, Informed) as a cross-map to the extended-Zachman, to the VPEC-T assessment, or to the Enterprise Canvas and cells for our own organisation and/or for any of our related business-organisations. This would tell us who is responsible for or about each item, and what forms each of their respective responsibilities would take. In our own case this is relatively straightforward, given the small size of our organisation; but in a large organisation these matrices can become very complex indeed. Perhaps more to the point, doing this at various layers and with various cross-maps can help to highlight real concerns about mismatches in responsibilities: often there will be two or more people who have ‘exclusive responsibility’ for the same item at different levels of abstraction, for example; and gaps in responsibility-coverage are also disturbingly common, again especially in large organisations, where boundaries and overlaps often become blurred over time through merger, acquisitions and other forms of organisational restructures.

As you’ll no doubt see by now, there are many other ways we could explore this, and this could go on a lot further – all the way into into the dreaded ‘analysis-paralysis’, if we’re not careful. One of the most important skills here is to know when to stop! But whichever way we do it, the principle remains the same: we start from an appropriate base-map – the Enterprise Canvas, in this case, though we could have chosen one of the others – and then use other model-types to provide further cross-maps, further information, further sensemaking, highlighting all the different dependencies, and all the different options. Everything links back to the base-map: that’s why the balance of simplicity, depth and versatility in the Enterprise Canvas matters so much.

But this article is already way too long, so we’d best stop here for now. In the next article we’ll explore how to use all of this in another way, using another core concept in whole-of-enterprise architecture that enables one of its most valuable traits: the ability to start anywhere.

Up until this point we’ve been working top-down, starting from the most abstract layer, the ‘extended-enterprise’. But we do need to to remember that there’s no reason why we have to work only in this direction, and often many reasons why we should make use of the more freeform approach that context-space mapping will allow. And in the usual serendipitous way – via an article in IndustryWeek, ‘Assessing Product Innovation Assets: What’s in your attic?‘ – we now have a useful reminder that the vision and strategy for an organisation may also be reconstructed bottom-up.

Low-cost innovation doesn’t have to be boring or incremental. Sometimes true innovation is as easy (and inexpensive) as evaluating the technologies and capabilities you currently have and expanding them to a new industry or customer base. It is a particularly powerful product innovation strategy during an economic downturn, yet too few companies today are taking advantage of it.

[An] important message for business leaders: “Use something you already own to generate income in a whole new way.” Truly innovative and resourceful manufacturers can embrace this message by reevaluating their existing assets, intellectual property, and product lines to develop completely new streams of revenue with little investment. The assets are already in their “corporate attics.” All a company has to do is unlock the revenue-generating power of those assets.

So let’s use the examples from that article – and a couple of others – to see how this works, in terms of context-space mapping and the Enterprise Canvas.

The examples we’ll use are Swatch, Mars M&M customisation, Oceaneering animatronics, Play-Doh and Nokia. (The middle three examples are from the IndustryWeek article – the respective quotes appear below.) In each case we’ll assess the context and the trigger for change; the relationship between the new market and the old; the role of and impact on technology; and the impact on enterprise-vision, echoing back down through the organisation itself.

For Swatch the trigger for urgent change was the shift in watchmaking from fine mechanical-engineering to digital displays and thence to digital movements. By the late 1970s the Swiss watchmaking industry – with a long tradition of unsurpassed engineering excellence but at high price, even in the mid-range – had been decimated by Japanese competition. The only apparent market that remained was for luxury craftsman-watches, and even that seemed under threat. In the early 1980s Nicolas Hayek combined business-restructure, technological innovation and radically different marketing to reframe the Swiss watch-industry – most of it under the new ‘Swatch’ brand – and reclaim its previous preeminent position.

The market for the new type of watch was actually a new ‘Blue Ocean‘ niche, presenting a new concept of the watch as a low-cost, almost transitory fashion-statement, where the notion of ‘the watch’ is linked less to the raw function of timekeeping than to the statement about self. In effect, this is actually closer in concept to the ‘luxury’ end of the market – both markets are more about the joy of time and relationship to time, rather than time itself.

New technology included the use of plastics and ultrasonic welding, and an almost Taylorist approach to manufacturing and reduction of number of components. This experience was also carefully echoed back into the ‘old’ Swiss-watch industry, retaining its ‘craftsman’ focus but combined with lessons-learned from bulk-manufacture.

The marketing for each of the sub-markets is different, yet interestingly the enterprise remains the same, if anything becomes more explicit, as something like “expressing the joy of time”.

Mars has had the technology to write “M&Ms” on little candies without smudging for decades. Recently, it created a multimillion dollar business using the same machine to let people write customized messages on their M&Ms.

As described in this BusinessWeek article, the trigger for what is now MyM&Ms was an idea from within Mars’ ‘Advanced R&D’ unit – not the marketing department.

The new market (promotions, special events) is significantly different from the regular market for M&Ms (retail candies/sweets), but leverages strongly from the main market in that the underlying product is well-known – in fact the ‘unique selling-proposition’ largely depends on the idea that this is a special personalised version of something that is not new.

The technology is actually much the same as in the main market: real-time labelling of mass-produced product. The main difference is that the new version of the labelling-technology permits mass-customisation. The market would not exist without this mass-customisation technology.

The core enterprise is significantly different from that of the main Mars company: although the enterprises are related, the focus here is on the customisation rather than on the underlying product (a point emphasised by the fact that Mars are also starting to provide mass-customisation of others of their products). The Mars website describes core-principles but no explicit vision-descriptor; it’s notable, though, that MyM&Ms is marketed through its own distinct website. The probable enterprise-descriptor for MyM&Ms would be something like “celebrating who we are”, compared to a probable main-organisation enterprise of something like “the enjoyment of small moments in the everyday”.

Oceaneering once only applied its hydraulic technology to deepwater remote operated vehicles and other oilfield related products – that is until the company met with some Hollywood executives who wanted to use the technology to power large dinosaurs for Jurassic Park. Revenues from the entertainment industry now make up over 15% of Oceaneering’s top line.

As described above, the trigger for the new market appears to have been a chance meeting, or a cross-connection made by someone within the entertainment/animatronics industry rather than by the company itself.

Functionally, the new market is very similar to the old, namely highly-specialised engineering applications for hydraulic technologies and control-systems. The main difference (as with their space-engineering applications) is that the application itself is outside of their main area of expertise in marine and underwater systems for oilfields, and hence will require much closer collaboration with the end-client.

The technology is essentially the same as in their main market – if anything, is actually simpler, or at least for use in less-extreme physical environments.

The enterprise can remain unchanged as long as the focus is on the activity (i.e. engineering) rather than on the purpose or application of that activity (oilfields or animatronics or space any of their other ‘advanced technologies’ areas).  Unfortunately their ‘About’ page includes a ‘Mission Statement’ that is an almost perfect example of what to not do in an enterprise-descriptor (“Oceaneering’s mission is to increase the net wealth of its shareholders by providing safe, cost-effective, and quality-based technical solutions satisfying customer needs worldwide”), and it seems clear that the emphasis of identity is very clearly on the main application (“Oceaneering is a global oilfield provider of engineered services and products primarily to the offshore oil and gas industry, with a focus on deepwater applications”), and the animatronics section does not even rate a mention anywhere in that description (“Through the use of its applied technology expertise, Oceaneering also serves the defense and aerospace industries.”) Despite the Industryweek reference, and the apparently sizeable contribution to corporate income, the animatronics application appears to be a poor fit with Oceaneering’s current identity: if that is the case, it should almost certainly be split off as a separate-but-linked enterprise, much as with the relationship between MyM&Ms and the parent Mars Group.

Play-Doh used to be a wallpaper-cleaning product with dwindling sales. All it took was the willingness to change markets and a clever revenue-sharing agreement with Captain Kangaroo to convert Play-Doh into one of America’s most successful children’s toys.

As described on Wikipedia, the trigger for the new market was a request in 1955 from a school-teacher – a relative of the company founders – for “a safe and fun modeling clay substitute”; they sent her “a sample of a non-toxic compound used to clean wallpaper”, which the children used to make Christmas decorations, with results that were described all round as “a hit”.

The new market is fundamentally different from the old: from trade cleaning-products to children’s toys.

The technology is essentially unchanged; in later developments the formula included colourants and minor changes to improve plasticity, but the basic bulk-mixing technology remains almost identical.

The enterprise is radically different, largely following the change in market: from something like “effective and reliable cleaning for the building-trade” to “safe and fun modelling” (an enterprise which does not restrict the market solely to children). Much as with Mars and MyM&Ms, but even more so, the base-technology is the same but the enterprise-vision are so different that they must be operated as separate divisions or even formally-separate organisations. Over the years, the Play-Doh production and marketing has been acquired and transferred more and more into a ‘toy’-oriented enterprise; the original parent-company Kutol continues as a manufacturer of cleaning-products specialising in hand-hygiene.

Nokia is perhaps the most extreme example of an organisation that has mutated and reinvented itself and its enterprise many times over the decades.

The Wikipedia page shows it starting out in the mid-1860s as a lumber company – initially named after the town in which it was located, Nokia – and later moving into electricity-generation in the 1900s. The trigger for that change was recognition of market-opportunity.

In the 1910s the organisation is essentially taken over by another company, a rubber-products manufacturer, which later, in the 1920, acquired a cable-manufacturer. The trigger in the first case seems to be commercial opportunity, retaining the name because of the location; the acquisition would have been driven by parallel interests, in that rubber would have been for insulation.

In the 1930s, and onwards into Finland’s somewhat tangential engagement in the Second World War, Nokia changes to more of an industrial conglomerate, including products such as paper, bicycle and car tyres, footwear, cables, televisions and consumer-electronics, electricity-generation equipment, communications equipment, plastics, aluminium and chemicals. All of these products and business-lines can be traced back to the four roots of the corporation: lumber, electricity-generation, rubber and cables.

However, the spread of market and and scope of enterprise were far too broad to be practical, causing major financial losses in the late 1970s and 1980s, and arguably a major contributing factor in the suicide of the then CEO, Kari Kairamo.  During the late 1980s and 1990s Nokia refocussed itself around telecommunications, divesting itself of the rubber, cable, footwear and consumer-electronics divisions.

Its current enterprise is summarised by its tag-line “connecting people”. Guidelines for corporate culture are described in the document The Nokia Way; the Wikipedia article indicates that up until May 2007 the defined core-values were “Customer Satisfaction, Respect, Achievement, Renewal”, and redefined as “Engaging You, Achieving Together, Passion for Innovation, Very Human”.

The Nokia history indicates the problems that arise when an organisation grows without an explicit of identity to act as a guide to what should and should not be included as the organisation expands by natural growth and by mergers and acquisitions. Over time, the enterprise – and hence organisational identity – becomes less and less clear, leading to excessive tensions across the entire organisation. The break-up in the late-1980s and 1990s was a necessary foundation for its later growth, because each sub-unit could now align with a more-clearly defined enterprise-vision.

Looking back at all of these examples, it’s clear that strategy can be driven bottom-up as well as top-down. Sometimes, as with MyM&Ms and Play-Doh, the change in strategy requires the creation of a new enterprise, distinct from that of the parent. In both those cases, the technology essentially remained the same, with the new identity linked to the new market. In effect, the new identity is based on a new role for the technology.

In the case of Oceaneering, the new application of the existing technology remained under the old enterprise. It would in fact have been a good fit to the existing enterprise, if that enterprise had focussed around the technology rather than its application. However, the organisation’s declared enterprise is firmly linked to the application (underwater oilfields) rather than the technology (specialist bespoke hydraulic-engineering). The apparently highly-profitable animatronics division barely even rates a mention on the website, and is not included at all in the organisation’s stated vision or mission. It seems likely that a split similar to that of Mars and MyM&Ms will be necessary in the fairly near future.

A few important points have come up in the comments to those two articles, though, which are worth reiterating here before we move on.

One is to remember why we’re doing all of this. It’s not about abstract ‘blue-sky’ thinking: it’s about building a stable platform for organisational change. In enterprise-architecture, this needs to be a platform in which all of the other architectures – business-architecture, process-architecture, skills-architecture, values-architecture, security-architecture and, oh yes, all the IT-architectures too – can all interweave and interlink and intermesh into a single unified, dynamic whole. But although we talk a lot about the extended-enterprise here – especially in these ‘higher’ layers – this isn’t actually for anyone else at all: unless someone seriously-senior decides otherwise, all of this is solely for our own organisation (or client, if we’re doing this work as external-consultants). Working this way, whatever we develop is always in the context of this broader extended-enterprise: but our own organisation (or client) becomes more and more the centre of our attention as we move down the layers. That transition of emphasis starts to happen here. In short:

In enterprise-architecture, we create an architecture about an enterprise, but for an organisation.

It’s really important to remember that point – not least because it’s the organisation, not the extended-enterprise, that’s paying our bills!

Another point that came up in the comments is that the usual nine-cell structure of the Enterprise Canvas can be a bit misleading in these upper levels. The nine-cell structure is really a kind of functional-decomposition – who’s handling what interfaces, and why. But functional-decomposition assumes or describes specific interfaces and relationships – and we haven’t even got that far yet. In row-0 and row-1 we only deal with each entity as a whole, without any internal subdivision into cells. It’s only here, in row-2, that we start to introduce the idea of relationships and roles between entities, which eventually leads us to relationships and roles within entities, which leads us in turn to that nine-cell structure. If you try to use the nine-cell structure in rows 0 or 1, or in most of the work in row-2, you may have missed the point somewhere: at those levels, it’s only about each entity as a whole.

And finally, I would hope that by now you’ll have realised that this can be a lot harder to do than it might seem at first glance. It’s so easy to fall back to organisation-centric habits, where the organisation is placed as the sole centre of everything. The blunt fact is that it isn’t that ‘sole centre’ at all: in fact, the organisation only has a reason to exist if it’s placed within the context of its extended-enterprise. If we don’t understand that broader context, we would have nothing to guide us when that context changes – which, these days, can happen on a literally moment-by-moment basis. One of the keys here is that the description of that enterprise is literally emotive – it drives change. So although a lot of thinking and analysis will be needed here, ultimately it’s not a rational matter – it’s about what feels ‘right’, about identifying what is valued. This is especially true of the vision-descriptor: we need to keep exploring that context-space until we hit upon a phrase that can engender emotions and commitment that are literally strong enough to get people out of bed in the morning.

Anyway, time to move on: time to start looking at the business of the enterprise, and of the organisation itself. To summarise where we’ve gotten to so far with this example, we’d established a row-0 ‘Enterprise’:

We then started a Zachman-style row-1 ‘Context’ with a conventional market-based view of our enterprise, with our own organisation as its centre:

Which didn’t show us many options. But as we started to explore what that enterprise-vision meant in practice, and what kinds of stakeholders would be engaged in that vision, we realised that the actual enterprise was much broader than our current market:

Which should create many more strategic opportunities than we were able to see before. To make this work, though, we first need look more closely at the meaning of a common business-term: value-proposition.

Rethinking the value-proposition

In much of the conventional business-literature the term ‘value’ is linked indivisibly with price, or even equated with price. This is certainly the view associated with neoclassical economics, currently the dominant paradigm in most mainstream economic thinking. (If it can be called ‘thinking’: a more accurate term would probably be ‘superstition’ or, more literally, ‘cargo cult‘. My opinion, for what it’s worth, is that I’m continually astounded by the gaping flaws in both observation and reasoning in most so-called economics: the flaws in key concepts such as ‘rational-actor theory‘ are so blatant and so fundamental that I still find it almost impossible to understand how nominally-sane, nominally-intelligent beings can take those concepts seriously at all. But I digress…)

We also see other value-laden terms – ‘value’ in a somewhat different, broader sense – in the idea of ‘value-proposition as a means of positioning a product or service relatives to those provided by direct or indirect competitors: for example, the product is purported to be cheaper, cleaner, easier to use, more ‘green’, more ‘exclusive’, and so on. That type of modelling and comparison does become relevant when we get down to the fine-detail of business-models and the like in row-3 ‘System’ and, far more, in row-4 ‘Design’. But here, in row-2 ‘Business’ and above, there is a much simpler definition of value:

Value is whatever the enterprise-vision says it is.

The enterprise-vision – and particular the Qualifier in the vision-phrase – defines what is most valued in and by the extended-enterprise. In effect, it’s a condition of membership of the enterprise that the respective value or values are assigned to a high or even highest priority by each player in the enterprise.

The enterprise-values are not always assigned the highest priority, by the way, for the simple reason that every person and organisation exists within multiple enterprises – the enterprise of professional discipline, a family, a community, a country, humanity as a whole, and so on. Technically speaking, an enterprise is a ‘system’: every system – every enterprise – is contained in and intersects with other systems. The enterprise in scope that we’re exploring here is the one that’s of primary business-interest to our organisation – the enterprise about which we’re building an architecture for this organisation – but it’s essential to remember that it’s not the only enterprise that exists.

As part of their membership of the extended-enterprise, each player in the enterprise commits to delivering some kind of value to that extended-enterprise. In the context of this layer (row-2 ‘Business’ and above), the value-proposition is the value that the entity may and can bring to the shared-enterprise. In effect, the value-proposition is the choice of value to deliver, the ability to deliver that value, and the commitment to deliver that value.

Which brings us back to some of the questions with which we started this series: What can I/we do that creates value? Where could I/we add value? What role could I/we play within this enterprise? What capabilities (and hence, when linked with a role, ‘missions’) could I/we bring to make this enterprise happen? Who do I/we need to work with to make this happen?

There’s an important recap we need to do here, though. The enterprise-vision is energising, literally emotive, a literal driver for action. If we feel committed to that enterprise, yet have no apparent value to bring to the party, we perhaps need to do some deeper exploration – which we’ll tackle here shortly. But if we try to force-fit our skills and so on to an enterprise to which we don’t feel that same emotive commitment, the amount of value that we can add will be much less: being in the ‘wrong’ enterprise is literally ‘de-motivating’, certainly passively so, and often actively, and always reduces effectiveness for all parties involved. (This is true for all types of work, but especially so for knowledge-work or decision-work, as Daniel Pink explains well in his book ‘Drive‘.) This is a major reason why Taylorism and monetarist-economics are so ineffective in practice: they force just about everyone to be in the ‘wrong’ enterprise. It’s something we need to watch for, very carefully, if we want our organisations and our own work to be effective, valuable and valued.

The same questions apply to every player in the enterprise: What is their value-proposition? What can they do to make the vision come to life in the real world? That’s the nature of an ecosystem: in principle at least, everyone brings something to the party:

This delineates each party’s role relative to the enterprise – the ‘vertical’ dimension for each Enterprise Canvas element, the commitment to create value in the enterprise.

Their roles relative to each other within the enterprise – the ways in which value moves around within the enterprise – provides the ‘horizontal’ dimension for the Enterprise Canvas element:

In effect, the linkages in that horizontal dimension represent the value-propositions we have for each other within the enterprise. A couple of layers further down towards implementation, this leads us to the kind of value-proposition that would typically underpin a conventional business-model – better, cheaper, faster and so on – but we need to remember that all of that actually comes from here: the value we offer to the enterprise as a whole, and the dynamic flow of value around the enterprise that brings the enterprise-vision to fruition.

Value-relationships

Looking at these ‘horizontal’ relationships is what brings us ‘downward’ to row-2 (‘Business’) in the layering of the Enterprise Canvas. For example, there’s the (very simplified!) example row-2 diagram for the TED Conferences shared-enterprise, from the ‘Layers‘ article in the initial Enterprise Canvas series:

This is also the first point at which we need to start thinking in depth about our own organisation, as an entity in its own right rather than solely in terms of an extended-enterprise.  Whilst still keeping the extended-enterprise as a whole in mind, we need here to be ‘self-centric’ for a while:

• What value could I/we add to the extended-enterprise? – our value-proposition to the whole, the reason we are here?
• Which other players need the value we create for the enterprise in order to create their value for the enterprise? – who are our customers?
• What value (such as in the form of products or services) do we need from other players in order to create that value? – who are our suppliers?
• Which other players deliver complementary value to the extended-enterprise? – who are our partners?
• Which other players deliver the same value to the extended-enterprise? – who are our competitors?
• Which other players will support us to get started (or continue) to deliver value to the enterprise? – who are our investors?
• Which other players will we support whilst delivering value to the enterprise? – who are our beneficiaries?

And we also need to look at this in terms of the extended-enterprise as a whole:

• Which other players help to keep the overall value-web moving? – who are the coordinators, the suppliers of ‘coordination-services’?
• Which other players help to identify direction of the overall enterprise? – who are the futurists and/or historians, the suppliers of ‘direction-services’?
• Which other players will help to keep us on-track to the vision and values of the enterprise? – who are the regulators, the suppliers of ‘validation-services’?

Each of these relationships implies a value-proposition of some kind – a mutual value-proposition, since the aim is that value will be exchanged between the parties. The most problematic relationship, of course, is that of ‘competitor’: whenever we have two or more players purporting to deliver the exact same value, this implies – and potentially creates – ineffectiveness within the overall extended-enterprise. Sometimes there is genuine value in such ‘competition’: for example, redundant-duplication also supports resilience, in reducing the risk associated with any single point of failure. Constructive ‘competition-with‘ also helps to drive innovation and creativity to push the overall enterprise forward towards its vision. Destructive ‘competition-against‘, though, is something we do need to avoid, for everyone’s sake. Techniques such as Blue Ocean Strategy can help a lot here: what we need to look for is a niche that fits well with our own competencies and capabilities, fits well with our sense of the enterprise as a whole, and which complements rather than competes directly with anyone else in the shared-enterprise.

Note that although we’re starting to get closer here to conventional strategy-development and business-model development, we’re still not there yet: in fact the proper ‘business-models’ and the like don’t properly begin to emerge until down in the next layer, row-3 ‘System’. What we really look at here is just one question:

• Given each player’s value-proposition in the overall extended-enterprise, what would that imply in their relationship with us?

Or, to put it the other way round:

• Given our own value-proposition in the extended-enterprise, what relationships with us would that suggest to others?

The answers to either version of that question provide the prototype for our organisation’s business-models. And importantly, by the value-driven nature of those relationships, that would be a self-marketing ‘pull’-type business-model – a huge advantage over the conventional ‘push’-type marketing-model, where the absence of any self-evident reason to relate forces us to manufacture a sort-of-relationship from nothing.

So to apply all of this for our main example here, my own enterprise-architecture consulting-business:

• What is the vision for the overall extended-enterprise? – “enhancing enterprise effectiveness”
• What are the key values here? – examples include the five dimensions of effectiveness – efficiency, reliability, elegance (in the generic sense), appropriacy, integration – and direct derivatives or compounds such as resilience, simplicity and integrity
• What is our own value-proposition to the extended-enterprise? – we provide tools, techniques, training and insight on enterprise-effectiveness, particularly in whole-of-enterprise architectures (the intersection of structure and purpose) and whole-of-enterprise integration (processes, practices, metrics and people-related themes)
• Who would value our value-proposition? – in principle, anyone doing the practice of enhancing effectiveness within organisations

That last line tells us our nominal customer-base, which is huge: in principle, it applies to just about any organisation anywhere in the world. Too large to be practical, in fact – which is a serious problem for us. As futurists and developers of new techniques, the work we do is often a long way ‘ahead’ of the mainstream: our main customers at present tend to be early-adopters or very-early-adopters, but in almost any industry. This means that our current market is very broad but very ‘lumpy’ (“the future is already here, it’s just that it’s not evenly distributed”, as one science-fiction writer put it), so we’re faced with a classic dilemma: do we spread the net wide but risk being too generic to be much use, or limit it to a narrow domain which has a more explicit practical focus but for which there are too few early-adopters to make it viable? Getting the right balance here is going to be crucial to success.

• What products, services and other value do we need from other players? – our ‘product’ is ideas and techniques, hence anything that feeds into that, such as information, practices, test-cases and peer-review

Although this is fairly typical for a professional-services firm with a strong research-and-development focus, it demands radically different relationships from those of, say, a retail outlet or a utilities corporation. In the latter, there are clear distinctions between ‘customer’ and ‘supplier’, and hence (usually) clear boundaries between the respective relationships; whereas in this case, every customer is also a ‘supplier’ in that each context will have always have some aspects that are new and unique, and hence provide us new information, new test-cases and new peer-review. The same applies to our partners and even to our nominal ‘competitors’: we each become most effective when we each provide peer-review for each other. Conventional near-combative relationships based on ‘competition-against’ and proprietary notions of ‘intellectual property’ will guarantee failure here, for everyone: yet we also need to protect ourselves – and everyone else in our enterprise – from predatory types who unfortunately do believe that aggression leads to ‘success’. The key here is to leverage off the enterprise-vision and values: we need to assess all potential relationships – customer, supplier, partner, even ‘competitor’ – against that yardstick of shared overall effectiveness.

• Which other players deliver complementary value to the extended-enterprise? – anyone working on enhancing enterprise effectiveness in organisations, particularly those people or groups working in more specialist domains such as organisational-development, process-improvement, knowledge-management, quality-management, skills-architectures and the like

This again is a huge ‘market’ – and hence again a real risk of spreading ourselves too wide and too thin. The key point is that our emphasis on whole-of-enterprise architectures is a generalist domain, whereas most of these potential partners are specialists. So there’s no ‘competition’ as such: what we look for are synergies, to cross-leverage each others’ work. Building appropriate relationships here would be fundamental to our marketing. One of our key value-points is that as generalists we provide a means to cross-link between the specialist domains; we and our colleagues will often act as facilitators, arbitrators and ‘thought-translators‘ to reduce the risk of getting lost in translation between domains.

• Which other players deliver the same value to the extended-enterprise? – the ‘product’ is ourselves, so there are no direct competitors as such: the real ‘competition’ here is not so much for market-share as mind-share

Our greatest ‘competitive’ problem at present is misuse and misappropriation of key terms by others, which can make it almost impossible to communicate what it is that we do, and the value that we deliver. Perhaps the most important of these are the near-ubiquitous misuse of the terms ‘enterprise’ and ‘enterprise-architecture’, and thence also ‘business-architecture’. It seems that most business-people fail to understand the difference between ‘the organisation’ and ‘the enterprise’ – hence why so many references in these articles to ‘extended-enterprise’, to try to establish those crucial distinctions. And it certainly seems true that very few IT-folks seem able to grasp that serious problems can arise from conflating the term ‘enterprise-wide IT-architecture’ into ‘enterprise-architecture’: in the former, the IT-architecture has an enterprise-wide scope, whereas in the latter the enterprise is the scope. One result of such IT-centrism is that ‘business-architecture’ is often taken to mean ‘anything not-IT that might affect IT’, leaving no space to describe anything which is mostly or entirely outside of the scope of IT.

In our work, we struggle every day with the consequences of these fundamental terminology-mistakes: although there are some signs of change (such as the Open Group‘s dawning awareness that enterprise-architecture must extend beyond the ‘comfort-zone’ of IT), it seems likely that this ‘mind-share problem’ will remain with us for at least another decade or more. In the meantime, just about all we can do is, again, point to the enterprise-values, demonstrate that IT-centrism, business-centrism and the like are in direct breach of most of the ‘effectiveness’ themes – particularly ‘integration’ – and explain quietly what to do to repair the damage. Frustrating, but that’s what happens when mind-share is dominated by major misunderstandings about the nature of the extended-enterprise itself, and by mistaken, much-mangled terminology.

• Which other players will support us to get started (or continue) to deliver value to the enterprise? – our ‘investors’ are mostly ourselves, though we need to remember that many others (especially our partners) invest ideas and personal and/or professional support in what we do
• Which other players will we support whilst delivering value to the enterprise? – our key ‘beneficiaries’, again, are ourselves, though it’s extremely important to us that we also contribute to our partners’ development and to the development of the enterprise as a whole

And, in terms of the extended-enterprise as a whole:

• Which other players help to keep the overall value-web moving? – the short answer is ‘not many’: there’s a real dearth of ‘coordination-services’ across this enterprise, and a real need for an equivalent of the services that SourceForge, for example, provides to Open-Source collaboration
• Which other players help to identify direction of the overall enterprise? – other than our partners, ourselves and some futurist organisations, there don’t seem to be many working in this space: most of the industry-bodies such as Open Group focus solely on subsets such as IT, rather than on the extended-enterprise as a whole
• Which other players will help to keep us on-track to the vision and values of the enterprise? – again, there don’t seem to be any real providers of ‘validation-services’ here: there’s a real need for this

The other key point to note here is that we need to remember to keep in mind that all of the players in the extended-enterprise could play any of these roles, relative to each other, or relative to us – and likewise we to them. This awareness becomes extremely valuable whenever we need to rethink our current positioning or current market, because it greatly increases our options relative to most conventional approach to business-strategy or business-development.

Another example

We could also apply all of the above to the example provided by Pat Ferdinandi in the comments to the previous articles, a real chain of restaurants in the US called Elevation Burger. Using quotes from their website (in double-quotes below), our assessment at this whole-of-enterprise layers of the Enterprise Canvas might go like this:

• What is the vision for the overall extended-enterprise? – tag-line “ingredients matter”, implying an enterprise-vision of something like ‘making food that matters’ or ‘making food matter’

Note that the ‘vision’ on the website is a fairly standard organisation-centric marketing-style vision. It tells us quite a bit about the values and decisions made by the organisation: “a vision for an elevated product that is fresh and flavorful… for authentic, sustainably prepared food… for an elevated experience in a well-appointed and environmentally friendly setting”. But it tells us very little about the extended-enterprise in which the organisation operates – and that’s what we would need to know if we were to be trying to re-think the organisation and its relationships when the market context changes. In essence, what we have here in Enterprise Canvas terms is a (very good) example of a set of drivers at the row-3 ‘System’ layer – which is fine if we’re only refining our marketing based on the current business-model, but not much use if we need to rethink the business-model itself.

• What are the key values here? – examples include “quality ingredients”, “better for you”, “better for the environment”, “passion for good food”, “enthusiasm, drive and passion”, “bright, sincere, engaging and energetic”, “genuine enjoyment in serving others”

There are other values or emphases listed on the website, such as “organic, grass-fed, free-range”, but to me these are more likely to be detail-layer decisions – down at row-3 ‘System’ or even row-4 ‘Design’ – that express beliefs or instantiations around the more core values such as “quality ingredients, better for you, better for the environment”.

• What is the value-proposition that Elevation Burger offers to the extended-enterprise? – the company and its franchisees express the vision of ‘making food that matters’ via provision of burgers, fries, shakes, malts and cookies in a “well-appointed and environmentally friendly setting”, mainly in cities and larger towns in the US

In other words, this is the chosen role that the organisation will play in the extended-enterprise

• Who would value this value-proposition? – anyone wishing to eat ‘food that matters’, those suppliers who would provide such ‘ingredients that matter’, anyone who holds similar beliefs, anyone who would like to be a customer but is not yet resident or visiting any locations at which the organisation operates, potential franchisees (primarily those who hold similar beliefs), food-critics and other media representatives, environmental activists, restaurant-builders and other ancillary-service providers, local government, regulatory authorities and many others
• What value do Elevation Burger add to the extended-enterprise? - the organisation provides a practical instantiation of the enterprise-vision and values, via operation of restaurants that express those values
• Which other players are ‘customers’ who need the value that Elevation Burger create for the enterprise? – those who wish to eat ‘food that matters’ of the types that Elevation Burger offer (e.g. burgers, fries etc), and who place value on the food and the context in which that food is provided (e.g. “well appointed environmentally friendly setting”, via “genuine enjoyment in serving others”
• What value (such as in the form of products or services) do Elevation Burger need from other ‘supplier’ players in order to create that value? – providers of ‘ingredients that matter’ (meat, salads, bread, potatoes, milk, drinks, etc), providers of construction-services (e.g. “well appointed environmentally friendly setting”), real-estate services, marketing services (websites, advertising, flyers etc), logistics services, management and accounting services, etc, all of whom need to align with the enterprise-vision and values
• Which other players are ‘partners’ for Elevation Burger, who deliver complementary value to the extended-enterprise? – other restaurants who likewise commit to the tag-line “ingredients matter”, but who provide different types of food, such as pasta/pizza, fish, Asian-style, French/European-style, bakery etc
• Which other players are ‘competitors’ who deliver the same value to the extended-enterprise? – Elevation Burger claims there are none, at least on the US Eastern seaboard: “our founder couldn’t find the burger he had been dreaming of since he left California in 1999″

Note that although fast-food burger chains such as McDonalds or Hungry-Jacks/Burger-King might in principle seem to be direct commercial competitors, in practice they operate in a different market-segment – a different enterprise – in which price has a higher priority relative to “ingredients matter”. Or, to put it the other way round, Elevation Burger’s clientele would place a higher priority (and premium) on taste, environmental history, restaurant ambience and so on. The competition is therefore indirect (a comparison of somewhat-different extended-enterprises and enterprise-visions) rather than direct (a comparison of near-identical services and values). However, if McDonalds or the others choose (or are pressured) to re-emphasise their positioning on ingredient-quality relative to price, they might move more into the same enterprise-space. Clarity on enterprise-vision would help to mitigate this risk by creating more of a ‘pull’-orientation rather than the fast-food chains’ ‘push’.

• Which other players are ‘investors’ who will support Elevation Burger to get started (or continue) to deliver value to the enterprise? – management, direct financial-investors, franchisees, all employees and other staff, local communities, any of the ‘partner’ and/or ‘supplier’ and/or ‘customer’ groups
• Which other players are ‘beneficiaries’ whom Elevation Burger will support whilst delivering value to the enterprise? – any or all of the ‘investors’, also (in non-monetary values) farmers and other suppliers, community and environment

And we also need to look at this in terms of the extended-enterprise as a whole:

• Which other players are the coordinators, the suppliers of ‘coordination-services’ that help to keep the overall value-web moving? – examples include logistics, event- or media-organisers for shared-marketing across the extended-enterprise, collective sourcing for ‘ingredients that matter’, support-groups for organic-farming and for environmentally-friendly building etc
• Which other players are the futurists, the suppliers of ‘direction-services’ that help to identify direction of the overall enterprise? – examples include the Slow Food movement, food-critics and other writers on food, sustainability and/or urban renewal, futurists on sustainability, agriculture, food and health etc
• Which other players are the regulators, the suppliers of ‘validation-services’ will help to keep everyone on-track to the vision and values of the enterprise? – examples include support-groups for organic-farming and for environmentally-friendly building etc, certification-bodies for same plus sustainability etc

The important point in this last section is that all of the individuals or groups listed there are potential allies – and, importantly, any challenge from any of them should be regarded as a spur to action rather than as an ‘attack’, because their role is to remind Elevation Burger how to keep on-track to their own commitment to the extended-enterprise.

I’d better stop there – this has been more than long enough already! More to follow, anyway, including a look at how to re-leverage assets and capabilities that we already have, in order to support a new strategy or business-model.

We started at the top layer, aiming to identify the core ‘enterprise’ within which I work. From exploring my own professional history, it became clear that the main focus of my work is about enterprises themselves, of any size, and always with the aim of enhancing enterprise effectiveness. From that, we ended up with an initial enterprise-descriptor – or ‘vision’ – of “creating more-effective enterprises”.

Notice, though, what’s happened right here, in that paragraph above. In trying to summarise that initial rather clunky vision-statement – ‘creating more-effective enterprises’ – we’ve accidentally hit upon a better one: ‘enhancing enterprise effectiveness’. It reads better, has a smoother flow to it, a poetry almost. It does describe what I’m passionate about – and finding that passion is central to the success of an enterprise. And ‘enhancing’ is actually a much more accurate term for what I do: I don’t often create enterprises in the sense that, say, an entrepreneur would do, but I do work to enhance their effectiveness. So note that this process is typical of what happens in context-space mapping: for example, we arrive at a ‘solution’ – in this case, the initial ‘vision’-descriptor – which itself quietly dropped us back into the ‘sensemaking’ space. So the trick here is to notice what’s happening, notice these little serendipitous events – and learning how to do that is a real skill in itself. To quote one of my favourite books, William Beveridge’s The Art of Scientific Investigation:

If these discoveries were made by chance or accident alone, as many discoveries of this type would be made by any inexperienced scientist starting to dabble in research as by Bernard or Pasteur. The truth of the matter lies in Pasteur’s famous saying, “In the field of observation, chance favours only the prepared mind.” It is the interpretation of the chance event which counts. The role of chance is merely to provide the opportunity and the scientist has to recognise it and grasp it.

Anyway, that’s what we now have as the ‘row-0′ or ‘Enterprise’ layer for the Enterprise Canvas model of my own enterprise:

Now what? Very pretty and all that, but what do we do with this?

At this point we need to do brief reprise on layering and the Enterprise Canvas. Each entity described in an Enterprise Canvas model is considered to be in just one of seven distinct layers of abstraction, summarised as follows:

• row-0, ‘Enterprise‘: consists of a single entity summarising the overall enterprise, its vision and core-values
• row-1, ‘Scope‘: consists of lists of core entities, such as key assets, key functions, capabilities and services, key events, key players in the enterprise, etc
• row-2, ‘Business-model‘: describes roles and relationships between the key entities in scope
• row-3, ‘System-model‘ (aka ‘Logical model’): includes attributes and events etc to describe more detail about generic ‘families’ of options and ‘platform-independent’ solutions
• row-4, ‘Design-model‘ (aka ‘Physical model’): specifies ‘platform-dependent’ implementation-details, such as specific methodologies, technologies etc
• row-5, ‘Action-plan‘ (aka ‘Operations-model’): specifies individual context-specific instances for final work-plans, such as work-rosters, individual system-configurations etc
• row-6, ‘Action-record‘: detailed records of actual events, actual configurations etc at a specified (past) point in time

(The numbering starts at 0 rather than 1 for compatibility with the well-known Zachman framework, with which layers 1-5 here match almost exactly. Row-0 is unchanging – or should be, because if it does change, it ceases to be the same enterprise. Rows 1-5 represent various abstractions or concretisations of a potentially-alterable plan for the future; row-6 represents the unchangeable past.)

Three points to note about where we’ve gotten to so far.

One is a reminder that although I’ve chosen this as the definition for ‘my’ enterprise, it’s more accurate to say that it chose me: looking at my history and my natural focus and the like, this is the enterprise that I am actually working in, whatever I might think otherwise. Given that that’s the case, it’s more sensible all round if I become more explicit and intentional about aligning my work with this enterprise. And whether the ‘organisation’ in scope is made up of just one person or many millions, the same principles apply.

Next, this enterprise-definition is unchanging: it’s the same for to-be, as-is or as-was. (If it isn’t the same in each case, it’s not an enterprise-definition in the sense that we need here.) As in the ISO-9000 standard for quality-systems, this ‘vision’ provides a permanent anchor for everything that is done in the enterprise. When you work in a business-context that changes on a moment-by-moment basis, it can be very useful to have something that you know will not change whilst you’re working on it…

And note that there’s been no reference yet to the market, to money, or to the organisation itself. That’s intentional – and needs to be that way, too. (As you’ll see later, money doesn’t even rate a mention until we get to ‘System-model’, another three layers further down.) The point here is that the enterprise just is: it’s just an idea, an emotive idea. But until we have that idea firmly in place, and the intermediate layers properly in place too, everything else is at risk of becoming unstable, falling apart without warning – as we can see happening all too often in many large organisations. Yes, the sensemaking and decision-making will often get a great deal messier further down the layer-stack: but for now, in these rarefied levels, all we need to do is Follow The Process.

Anyway, time to move on, to look at the scope in which our organisation exists.

Identifying the scope

In strategy-development, we typically begin ‘top-down’, working our way down through the layers, in a kind of idealised view of the world, until we hit the real-world constraints coming ‘bottom-up’ -which will usually (and usefully!) force us to start being ‘realistic’. So now that we have our row-0 for the Enterprise Canvas, we’ll continue going top-down for a while – which takes us to row-1, ‘Scope’.

Row-1 is always just a list – nothing more than that. Later on we’ll probably come back to make lists of key-assets, key-functions, key-events and so on, but for now all we’ll need is a list of other players – or types of players – within this enterprise. In other words, who else is likely to be interested in the enterprise of ‘enhancing enterprise effectiveness’?

The natural tendency at this point is to start with the as-is, and list my existing customer-groups. I often describe myself as a ‘toolmaker to consultants’, especially in the enterprise-architecture/strategy space, and at first glance it seems that there isn’t much to show:

What’s worse, that market is tiny – probably no more than a few thousand of us worldwide – and, if we jump downward to the Enterprise Canvas row-2 for a moment, most of those that I and my colleagues know are not only our potential customers but potential suppliers and potential competitors as well. Sure, we also do some consultancy, either in setting up enterprise-architecture capabilities or running workshops for executives and in-house consultants – but again, one of the explicit aims there is that we’re training my own future competition each time we do so. And although IT-oriented ‘enterprise’-architecture is quite well-known, true whole-of-enterprise architecture isn’t at all well-known as yet: hence although the need for that kind of work is enormous and all-too-evident, the demand isn’t there – and won’t be, until we’ve created enough awareness of what it is and why it’s so important. The one saving grace here is that the emphasis in this market is always on quality, not quantity: those organisations who do understand what we do are well aware of what it’s worth to them, and are willing to pay for it, so that even a short assignment can fund a fair amount of ‘unbillable’ research and development for the future.

So far, so good – sort of – but in fact this would be setting our sights to far too narrow a scope. Our current market may seem tiny, but by definition the overall enterprise includes anyone with any interest in enhancing enterprise effectiveness. So for a start, it includes almost every consultant and in-house staffer working at a strategic, tactical or operational level to improve just about anything in the organisation: IT, efficiency, innovation, quality, production, skills and competencies, safety, security, risk-management, disaster-recovery – if you can give it a name and it’s anything to do with organisations, it’s likely to be in scope here. What’s even better is that all of these other people are doing work that’s different from ours – so not only may there be potential synergies there for us, but they’re also unlikely ever to be our competitors.

Yet even this is still thinking far too narrow. Who else would be interested in ‘enhancing enterprise effectiveness’, where ‘enterprise’ means anything that the organisation might touch, and ‘effective’ means that the organisation would be more efficient, reliable, elegant, appropriate, integrated, in just about any sense of those words? The short answer is “just about everyone”…

Executives would be very interested. So would investors. Regulators. Government. Business-partners. Business-clients. Standards-bodies. Environmental activists and other pressure-groups. The countries and local communities in which the organisation operates. Even competitors would be interested, if it helps to create a larger or more stable market for everyone. That’s not a small enterprise at all: it’s huge.

So far, this is just a list – a list of players in the enterprise of ‘enhancing enterprise effectiveness’. It doesn’t tell us anything as yet about the relationships between these players – which is what I’ll need to know if I’m to design a viable business-model within the scope of this enormous shared-enterprise. But that’s fine – that’s what we explore in the next layer of the model, which we’ll look at in the next post. For now, though, it’s useful just to bask for a moment in the plain fact that the enterprise – and market – that I’m dealing with is much, much larger than I’d previously believed, providing many more potential opportunities for my business if I make the effort to find them. Food for thought indeed…

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.

Yes, it’s a good article – recommended reading. And I would strongly agree with its implication that there’s a real and urgent need for discipline around business-rules. But the reason for the alarm-bells is that it’s promoting business-rules as ‘the answer’ – and for the most part IT-based ‘business-rules engines’ at that.

Which us places straight back in Taylorist territory, along with all those other classic IT-driven business failures such business-process re-engineering. Not a good idea…

The reasons why it’s not a good idea are three-fold:

• placing all the business-rules into an automated system will lead to a ‘fit and forget’ attitude unless there is a very strong emphasis on rule-maintenance – one of many ‘human factors’ that were forgotten about in BPR’s rush to ‘IT-ise’ all business processes
• identification and codification of business-rules assumes that the rules that can be derived from the people who run the existing processes are sufficient, invariant, accurate and complete – which, as early-generation knowledge-management also discovered, they rarely are…
• the viability of using automation for decision-making is dependent on the context – a fact of which frighteningly few IT-system designers seem to be aware

There seems to be a view that everything can and must be reduced to simple rules, following a cart-before-horse thinking that everything should be done by IT, and simple rules are what IT handles best. In other words, dangerously back-to-front. It’s bad enough trying to get anything useful out of IT for decision-support; but using IT for all decision-making – which is the ‘nirvana’ that the article would evidently prefer – is likely to be lethal. And I don’t quite know what we as enterprise-architects can do to prevent this headlong rush into repeating the exact same mistakes as in BPR and the rest – all that’s different this time is that it’s more explicitly coming from the ‘rules’ part of the process, rather than process-implementation overall.

This is clear if we look at it from the perspective of context-space mapping:

The point is that there’s a spectrum of abstraction of rules: principles sit at the low-abstraction end of this spectrum, rules sit at the high-abstraction end – in fact a conventional ‘rule’ is actually an extreme abstraction of a principle that applies to a specific context. If we try to use the wrong level of abstraction, especially in the wrong context or wrong type of context, we are all but guaranteed to hit serious trouble. And I see little to no awareness of that fact in most of the current literature on business-rules: instead, there seems to be an assumption that just about everything can be reduced to simple binary rules that can be implemented by simple IT, because that’s what we want to happen. In other words, the entire approach seems driven by little more than wishful thinking – which again is not a good idea…

IT-systems and simple business-rules work well together: both operate on a binary true/false logic, and both will enable high-speed binary-logic decision-trees – in other words, over on the lower right-hand side of the usual Cynefin-derived context-space base-map.

Most IT-based analytics – over on the upper-right of the base-map – work on the same binary logic as the simple systems, but introduce the ability to handle more and more layers of complication. The catch is that each layer of analysis takes a finite amount of time – which takes it further away from the ‘Now!‘ demanded by real-time decision-making. And the only real result of increased computing-power has been to increase the levels of complication in the analytics, sometimes beyond anyone’s ability to understand it – as was the case with the software systems used in many of the risk-calculation models that drove the current financial crash.

IT-systems are still not good at handling non-binary modal-logics – “the logic of probability, possibility and necessity”, such as expressed in the MoSCoW set of requirements-priorities of must, should, could and can wait. Humans are very good at modal-logic; IT isn’t. James Taylor’s article refers to pattern-based decision-making, which places it somewhat on the upper left of the base-map – but note again that each pattern-match must always take a finite amount of time, and it does not fit well with the underlying binary-logic of current IT-systems. Using IT as decision-support for human decision-making is generally okay, but the more that IT is involved, the higher the risk of what Dave Snowden describes as ‘pattern-entrainment’ – in other words, premature selection of a pattern, trying to force-fit a pattern to the context rather than ‘listening’ to the context itself. Current IT is getting much better at near-real-time pattern-matching, such as face-recognition or smile-recognition on most present-day digital cameras. Yet as anyone who’s used such systems would know, they’re nowhere near accurate enough to decide when a picture is actually any good – and sometimes we don’t want a smile in the picture. Much the same applies in business: using automated pattern-matching is great for decision-support, but extremely dangerous for decision-making.

And no IT-system is likely to be much good at dealing with real-time chaos, ‘the new’, where no possible pattern exists because it is new – but again, real people can handle decision-making in such contexts via skills and principles. In those contexts, there are no rules – and yet business-rule proponents seem to promote the delusion that their ‘business-rule engines’ can handle everything.

So I’m wary: very wary. Before letting any of such systems loose on any real-world context, I would want to make very sure that they’ve done the appropriate context-space mapping, and matched the decision-making methods to the respective contexts. But I don’t see much evidence of that: what I see instead is way too much wishful-thinking, and an almost desperate desire on both the business-side and the IT-side to try to force the world to fit their respective delusory dreams of ‘order’ and ‘control’. Oh well… Guess we have to wait and let them fail yet again, even more expensively, and then set out to tidy up the mess? – though I do worry that we’re getting close to the point where we’re no longer able to afford such expensive mistakes, in any sense of the word…

We seem to be iterating steadily towards a full description of what I’ve termed context-space mapping (as a more permanent name than the temporary label ‘tinc‘). For example, there’s been some very useful discussion on the previous post, especially by enterprise-architects Paul Jansen and Sally Bean. Paul Jansen followed this up with another Tweet:

@tetradian May the ‘chaotic approach’ be the key to #tinc? http://bit.ly/amJa1o

In fact this leads to what is probably the fundamental difference between twf and context-space mapping (aka tinc): the role of the Chaotic domain. This particularly applies in terms of the respective views of repeatability within the context.

In the hope of preventing yet more repercussions, I won’t say anything about twf‘s approach at this point, other than to express my opinion that, in the terms of context-space mapping, its focus is primarily on the Complex domain, which in turn leads to an emphasis on contexts that are ‘partly-repeatable’ in highly complex ‘unordered’ ways.

Context-space mapping, however, needs to cover all repeatability-types. As twf‘s proponent indicates, the Simple domain of presumed-repeatability is covered by Taylorism et al.; the Complicated domain of analysed-repeatability by hard-Systems Thinking and the like; and the Complex by twf and so on. But there’s so far been little or nothing to cover the Chaotic domain of ‘barely-repeatable’ events and processes. So in practice it’s likely that that’s where whole-of-scope techniques such as context-space mapping will have the most impact.

The central theme in the Chaotic domain of practice is low- to zero-repeatability: some part(s) of the practice cannot be repeated, either because the conditions have changed – including the awareness and experience of the person doing the work. Conventional ‘scientific-analysis’ approaches (Complicated-domain) rely on repeatability, so they’re actually not all that much use in the Chaotic components of any real-world task – in fact will often be misleading because they provide an illusion of predictability. In a way, the same is true of many Complex-domain techniques: they give us a much more reliable picture of an overall uncertain context, but we can’t reliably apply that in reverse to tell us what to do for a specific ‘market-of-one’, such as a specific medical diagnosis.

Ability to engage appropriately in the Chaotic-domain in this sense is almost a definition of skill. It’s also a key component of almost all knowledge-work – which is why this concern is coming much more to the fore, as knowledge-work becomes an increasingly important part of the overall economy.

At the business-process level, one of the key figures is Sigurd Rinde, whose concept of ‘barely-repeatable processes’ is the focus for his Thingamy business-process-execution software. The whole point of Thingamy is that the processes themselves are made up as they go along, by the people doing the work, expressing and applying their expertise. Underneath this, however, is a consistent Simple structure that records every decision, every artefact, every transfer of responsibility – which makes it possible to create any required reports from the process, including conventional statistical analysis. The result is nicely summarised on Sig’s other website, 30megs.com – so-called from his tag-line “Here’s 30 Megs. Now go run Germany”, which in principle is entirely feasible with this kind of decision-support/decision-tracking software. Sig is not alone in this, of course – for example, Stafford Beer developed something similar that in effect ran the entire economy of Chile for a while, way back in the early 1970s – but Thingamy is probably the best example of a software package available today that is designed for true Chaotic-domain processes.

Context-space mapping is part of what needs to happen before we settle on any technique or tool such as Thingamy. It’s about mapping the options available to us, and the decisions that we make within ‘solution-space’, as part of an overall process of sensemaking in order to arrive at appropriate actions for the context. One of the key points in this is an awareness that we are part of the context, part of the ‘solution’: in the classic Chaotic-domain sense, there is a boundary, and there is no boundary, always in the same moment.

We always start from ‘reality’ – that which in twf is termed the ‘disorder’ domain. (Everything does in fact take place within that domain: any purported subdivisions – such as Simple, Chaotic and suchlike – are sensemaking-abstractions that we place onto that domain, but are not actually ‘real’ as such.) From there, we would move into some kind of recursive OODA loop (Observe/Orient/Decide/Act), where sensemaking itself forms one or more of the earliest iterations. In those terms, context-space mapping would typically proceed as follows:

• Observe: What is ‘the context’ here?
• Orient: How do I make sense of what I’m seeing?
  1. What parts of the context appear to be unique (Chaotic), unordered or ‘wicked-problem’ (Complex), complicated but repeatable (Complicated) or universal (Simple)? Using that categorisation, map out the ‘problem-space’.
  2. Given that categorisation, what cross-maps would be useful for sensemaking?
     Note: There are an infinite number of cross-maps that could be used: some examples shown in this series include:
     • here: repeatability and action-tactics; domains and tetradian asset-dimensions; time versus focus; Jungian domains
     • here: twf tactics and types of practice; timescale versus ‘bindedness’; development of embodied ‘best-practice’
     • here: repeatability and ‘truth’; marketing versus sales; the ‘plan / do / check / act’ cycle
     • here: ISO-9000 quality-model; skill-levels; automated versus manual processes; asset-types; data, information, knowledge, wisdom
     • here: cause/effect relationships; decision-mode, timescale and level of abstraction
     • here: nature of boundaries between domains
     • here: phases of matter
  3. Using the categorisations from the cross-maps, what available tools and techniques are ‘situated’ in what regions of the maps’ ‘solution-space’? What can we learn from this?
• Decide: Given what I have learned from sensemaking, what should be my ‘action-plan’?
  1. Select from the available tools/techniques.
  2. Decide on a plan as to how, why, when, where, by whom, with what, and in what order each of the selected tools or techniques should be used.
• Act:  What am I doing as I am doing, and what do I see as I am doing?
  1. Enact the desired action.
  2. Apply the same overall OODA-loop to the action taken – recursively, where appropriate – for review, further sensemaking, decision and action.
• Repeat as appropriate.

(Some people might suggest that this kind of OODA-loop fits more within a twf-style Complex-domain mode than Chaotic-domain. True, there are important similarities, such as the shared focus on ‘unorder’ versus the Complicated/Simple notion of ‘order’. But the key distinction is that this acts on a single, individual, specific context rather than a Complex-domain collective – and is often also much closer to real-time than most Complex-domain decision-making.)

The above is a start towards how we would use context-space mapping, anyway. I’ll leave it there for now: any constructive comments, ideas and suggestions would be most welcome, as usual – over to you?

Previous posts in this series:

• Complexity, chaos and enterprise-architecture
• More on chaos and Cynefin
• Alternatives to the ‘Cynefin’ term, please?
• Solution-space: beyond Cynefin?
• On meta-methodology
• Using ‘Cynefin-like’ cross-maps
• More ‘Cynefin-like’ cross-maps
• And more ‘Cynefin-like’ cross-maps
• More on meta-methodology
• ‘tinc’ – a Temporary Inconvenience
• Context-space mapping and enterprise-architecture

Related:

• ‘Two Cryptic conversations‘