Context-space mapping with Enterprise Canvas, Part 5: Service content

In the previous articles about context-space mapping with the Enterprise Canvas, we looked at the topmost layer, the extended-enterprise and enterprise-descriptor or vision; then the next layer down, summarising all the player in the enterprise ecosystem; and took a first high-level look at the organisation’s business model with an exploration of value-proposition and business-relationships. All of that was moving ‘top-down’ through the enterprise, so we took a brief detour to see how the same principles can be used for ‘bottom-up’ strategic review, where a re-think of existing technology can lead to a new strategy and even to a new enterprise.

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.