The Enterprise Canvas, Part 8: Integration

Over previous articles in this series, we established some of the background and theory of the Enterprise Canvas with context and value, market and supply-chain, owners and managers, layers, and recursion. We then started to explore how to put this to practical use, with a detailed process that links to a variety of other architecture-models, and some example-patterns for specific architectural contexts.

The other promise, way back in the introduction, was that the Canvas can be used as “one model to rule them all” within enterprise-architectures – not by ‘ruling from above’, or replacing anything else at all, but by providing a unifying frame through which all the different model-types at all the different levels can link together and support each other. So in the this final section I’ll skim through a wider range of model-types that are in common use in or around enterprise-architectures, to show how the Canvas could be used with each of them to support an overall integration across the architecture.

As in the previous article, let’s start with a recap on the Enterprise Canvas, using the ‘beetle’ version of the model:

Each Canvas represents and describes a single unit or entity that provides a service of some kind. It sits at an intersection of value and action: the ‘vertical’ axis defines what ‘value’ is for the respective enterprise, the ‘horizontal’ axis describes how the unit links in with a supply-chain or ‘value-web’ of of services that each add value to the overall shared-enterprise.

Three types of horizontal flows (the horizontal double-arrow, triple-line and double-squiggle) represent interconnections with other parties that take place before (‘relations’), during (‘main-channel’) and after (‘backchannel’) the main or more-tangible transactions with those parties.

Three types of vertical flows ‘below’ the Canvas link to investors (left double-guillemet), more-detailed implementations (vertical double-arrow) and beneficiaries (right double-guillemet).

Three further types of flows – shown above the Canvas, but in essence each orthogonal to the others – link the overall service to a more enterprise-wide support, with information and emphasis on values and value-implementation (‘validation’, downward-pointing triangle), on purpose, strategy and tactics (‘direction’, small square), and on cross-functional coordination and change-management (‘coordination’, upward-pointing triangle).

These flows indicate the items that need to be exchanged across them; with whom are what these should be exchanged – ‘suppliers’, ‘customers’ and so on – is another question entirely. Sometimes it’s useful to start from a list of stakeholders and identify the respective flows from there; sometimes it’s better to start with the flows, and identify the respective stakeholders. It’s important to do both, though, because that’s the best way to identify gaps that could otherwise render the service non-viable.

Architectural frameworks and model-types

VPEC-T – Values, Policies, Content, Events, Trust – is, as we’ve seen in other articles in this series, probably the most useful frame with which to assess the various flows between this service and its stakeholders. You’ll find more details on the VPEC-T model at www.lithandbook.com.

Archimate is an upcoming standard notation for IT-oriented components of enterprise-architectures, originally developed in the Netherlands and now adopted as an international standard by The Open Group. (There is an intent that in the medium-term it should extend to cover a true whole-of-enterprise scope, but at present it’s still mostly constrained to IT-oriented architectures only.) It defines architectures in terms of the usual three IT-oriented ‘layers’ (Business, [IT] Applications and [computer-based] Technology) and three interlinked ‘vertical’ emphases: Static Structure (data etc), Behaviour (services and functions) and Active Structure (roles and interfaces). From a Canvas perspective:

• Archimate ‘layers’: ‘Business’ primarily sits in the row-2 to row-3 Canvas layers, whereas ‘Application’ and ‘Technology’ sit in parallel domains in the Canvas row-3, row-4 and sometimes row-5 layers.
• ‘Static Structure’: data-items and other artefacts would translate to content that is held and/or manipulated within the Canvas cells or exchanged via the Canvas flows (it would be considered primarily as ‘Content’ in VPEC-T terms, or as ‘assets’ in modified-Zachman terms).
• ‘Behaviour’: each service in each Archimate layer would typically be modelled on its own Canvas, whilst processes and functions would typically sit in the Value-Creation cell of the respective Canvas.
• ‘Active Structure’: roles would typically translate as external parties, interfaces as Canvas flows, and components (‘device’, ‘application component’, ‘network’ etc) as part of the respective Supplier/Customer-Channel cell.

TOGAF (The Open Group Architecture Framework) is another very well known framework in IT-oriented ‘enterprise’-architectures, in essence consisting of a well-defined process (Architecture Development Method [ADM]) and an underlying metamodel. The metamodel is less well-structured than Archimate’s, but the same general principles apply as for Archimate: in fact there is an ongoing effort within the Open Group to align the two models, so any differences should fade away in the relatively near future. The ADM works well with the Enterprise Canvas, but in its standard form is still very IT-oriented and almost unusable beyond IT; over the past few years, though, I’ve done a lot of work to adapt it for use at a whole-of-enterprise scope, as documented in some of my books such as Bridging the Silos and Doing Enterprise-Architecture and in TOGAF-conference presentations available on Slideshare, and also summarised in a brief two-page reference-sheet.

The Zachman framework is probably the ‘granddaddy’ of all enterprise-architecture frameworks, and an essential counterpart to the Enterprise Canvas. (The standard version is unfortunately still somewhat IT-centric – for example, the only asset-type (‘What’) listed is Data, the only decision-type (‘Why’) is [IT] Business-Rule – and needs some modification to be usable for whole-of-enterprise architectures.) As described in Part 4 of this series, the Enterprise Canvas layers are an extension of the Zachman layering, and directly compatible with it; and as described in Part 6, a single-row version of the modified-Zachman should be used to assess the content and structure of a Canvas and each of its cells.

VSM, Stafford Beer’s Viable System Model, was one of the core inspirations for the Enterprise Canvas. Although the original model primarily focussed on information-flows, the same concepts can be applied to flows of any asset-types, both simple and composite. On the Canvas:

• VSM system-1 (operations or service-delivery): represented by the nine-cell core of the Canvas
• VSM system-2 (coordination): represented by the ‘coordination’ guidance-service (upward-pointing triangle)
• VSM system-3* (audit): represented by the ‘validation’ guidance-service (downward-pointing triangle)
• VSM system-3 (planning and control), -4 (near-future) and -5 (far-future): represented by the ‘direction’ guidance-service (square)

Beer’s concept of an algedonic high-priority feedback-path that can bypass the normal channels is extremely important, and should be considered when assessing any or all of the Canvas flows. For more information on the standard VSM and its application in business, see Patrick Hoverstadt’s excellent The Fractal Organization; for more on its adaptation for service-oriented whole-enterprise architectures, see my book The Service-Oriented Enterprise.

Context-space mapping is the actual framework and process on which the Enterprise Canvas is based, and is described in more detail in my book Everyday Enterprise-Architecture. [At present the entire content of the book is available for free download via that link.] The underlying process draws strongly on John Boyd’s OODA (observe, orient, decide, act) model for agile problem-solving, crosslinked to a concept of sensemaking-domains derived from my book Inventing Reality (originally published in 1986). In context-space mapping, we choose a base-frame as a core-model, and then cross-map to other compatible model-types whilst we ‘go for a walk’ – metaphorically speaking – through all of the different perspectives offered by the base-model and the cross-maps. The Enterprise Canvas was designed for use as a base-map in context-space mapping; as described in Part 6 of this series, other useful base-maps or cross-maps include the modified-Zachman framework, the Cynefin-categorisation, RACI and SWOT, and the Five-Element lifecycle and effectiveness frameworks.

Strategic frameworks and model-types

The Business Model Canvas was in some ways the starting-point for this work, and the Enterprise Canvas was intentionally designed to be compatible with it. As  shown in Part 2 of this series, business-models developed with the Business Model Canvas can be mapped directly onto an Enterprise Canvas for architectural expansion ‘downward’ towards implementation, and ‘upward’ for verification of alignment with the vision and values of the shared-enterprise. The book Business Model Generation by Alex Osterwalder et al. should be regarded as an essential companion for any work with the Enterprise Canvas, especially at a row-2 or row-3 level for business-architectures.

The OMG/BRG Business Motivation Model [PDF] provides a standard framework to assess business drivers and business goals, and would particularly apply to the XD flow between the core Canvas and the ‘direction’ guidance-services. Be warned, though, that its method for definition of ‘vision’ – which should be the key to the entire enterprise – conforms almost exactly to how not to frame an enterprise-vision, and in practice is all but guaranteed to cause failure, especially over the longer-term. To avoid major architectural problems, use the more functional framing for shared-enterprise vision, as described in Everyday Enterprise Architecture, or in my presentation ‘Vision, Role, Mission, Goal‘ on Slideshare.

Other common strategy-frameworks that would work well with the Enterprise Canvas include Porter’s Five Forces, Blue Ocean Strategy, Porter Value-Chain and the ubiquitous SWOT. In each case we would typically use the framework to assess the service or organisational-unit in the Canvas, comparing it against others (such as for competitiveness analysis) or assessing the flows between the service and other players in the shared-enterprise (supply-chain partners, competitors etc). SWOT would be used to assess strengths, challenges, opportunities and the like in the usual way, on the service as a whole, on individual cells, on flows, and on stakeholder-relationships, as summarised in Part 6 of this series.

Structural and operational frameworks and model-types

Industry-specific structural frameworks such as SCOR (supply-chain), eTOM (telecoms) and ITIL (IT service-management) fit well with the Enterprise Canvas: each model describes its context in terms of services, each of which – with its relationships to other services – would be a candidate for modelling on a Canvas. The main value of modelling with Enterprise Canvas is that it adds distinctions between types of flows that occur before, during and after the main service-transactions, and also documents the necessary ‘guidance-service’ linkages to overall direction, cross-functional coordination and whole-of-enterprise values. SCOR is a layered, hierarchical model whose structures map to the Enterprise Canvas as follows:

• SCOR’s levels 1, 2 and 3 correspond approximately to the Enterprise Canvas rows 2-4
• the SCOR level-1 structure of Source / Make / Deliver corresponds almost exactly Enterprise Canvas linkage to the supply-chain: SCOR ‘Source’ corresponds to EC ‘Supplier-Channels’ flow and cell; SCOR ‘Make’ corresponds to EC ‘Value-Creation’ cell; SCOR ‘Deliver’ corresponds to EC ‘Customer-Channels’ cell and flow

eTOM is also a layered model: eTOM’s levels 0 to 3 correspond approximately to the Enterprise Canvas rows 1-4. As a matrix structure, services are defined within intersecting cells of the matrix, as well as within the row/column overlays themselves, but in each case the respective service and its relationships can be mapped on its own Canvas. At the highest level, the eTOM ‘Strategy Infrastructure and Product’ grouping has a strong linkage to the ‘direction’ and ‘coordination’ guidance-services modelled in the Canvas, whilst the eTOM ‘Enterprise Management’ grouping is somewhat shared across the ‘direction’ and ‘validation’ guidance-services; the eTOM ‘Operations’ grouping summarises what happens within the nine-cell core of the Canvas. Note too the strong emphasis in eTOM on ‘Customer’: this would especially be linked to the Canvas ‘Customer-Relations’ and flows on the Canvas.

I summarised a mapping for ITIL onto the Enterprise Canvas in Part 7 of this series. At the topmost level (row-1) there might be a single Canvas for ‘service-management’, but at row-2, where relationships come into the picture, we would need to model each of the five main service-groups as a separate entity –  in other words a separate Canvas for each. We would then devolve downwards as required, detailing each of the services first in generic (row-3) and then more context-specific (row-4) form.

The ISO-9000 quality-system international standard aligns almost exactly with the Enterprise Canvas layers:

• ISO-9000 ‘vision’ layer: Enterprise Canvas row-0, row-1
• ISO-9000 ‘policy’ layer: Enterprise Canvas row-2, generic part of row-3
• ISO-9000 ‘procedure’ layer: Enterprise Canvas detail of row-3, generic of row-4
• ISO-9000 ‘work-instruction’ layer: Enterprise Canvas detail of row-4, row-5

Balanced Scorecard is a useful frame to apply across the Canvas, but especially in the Value-Management cell, which is where performance data and post-transaction records should naturally accumulate. It may be useful to augment or review Balanced Scorecard’s four standard perspectives – Financial, Internal Business Processes, Learning & Growth, and Customer – with other themes from the enterprise vision and values, as appropriate. The single most crucial point, especially in a commercial for-profit business, is to loosen the stranglehold of finance-centric metrics, and to instead cover the full range of meanings of ‘value’ that apply in the shared-enterprise.

Standard review-processes and process-improvement models such as Deming/Shewhart PDCA (Plan/Do/Check/Act), Root Cause Analysis, Value-Stream Mapping and, where appropriate, Six Sigma, can all be usefully applied to the models developed on a Canvas, and in some cases modelled in relation to the activities shown on the Canvas. Conceptually and operationally, they belong as part of what the Canvas models as its guidance-services – in practice usually a collaboration between the ‘validation’ and ‘coordination’ services. Note that in general Six Sigma should not be used unless the service on the Canvas handles literally millions of nominally-identical events.

Summary

There are many, many other types of models used in enterprise-architecture, business-architecture, process-architecture, application-architecture, data-architecture, security-architecture, IT-architecture, values-architecture and so on. In many if not most cases they can either be used via direct cross-mapping to the Enterprise Canvas – as per context-space mapping – or as a secondary analysis of what shows up in cross-maps on the Canvas. The simplest suggestion is: try it and see. 🙂

So, that’s it: the Enterprise Canvas. Over to you: perhaps have a play with it, let me know what you think of it, any suggestions for improvement, and so on. And many thanks for staying with me this far! 🙂