Simplifying the Enterprise Canvas

The Enterprise Canvas is a model-type for use in enterprise-architecture, that can be used to describe any aspect of the enterprise, providing a consistent, unified view all the way from strategy to execution. But can we simplify it so as to build support for it in existing EA toolsets?

The full specification for Enterprise Canvas is in my book Mapping the Enterprise, which at present you can still download for free from here; there’s also a free two-page summary-sheet in PDF format. It incorporates and unifies themes from a wide variety of other model-types in common use in EA, such as Zachman, Archimate, Business Model Canvas, VPEC-T, Viable System Model, Market Model and many others, at first glance it can often seem a fairly complex beast.

The image above summarises the core service-entity and its relationships, but in addition to that, services can be described at seven distinct levels of abstraction, services-flows take place over several distinct phases (the ‘Market Cycle’), and so on. It’s a powerful way to model what’s going on within an enterprise, but there’s a lot to it; and I’d have to admit it’ll seem a bit daunting at first…

And there’s a real problem that at present there’s no EA toolset that implements it. Hence the only way to use it at present in EA modelling is via pen and paper, and then manual transfer to other more constrained, context-specific model-types. Which kind of defeats the object of the exercise, about unifying across the whole enterprise space…

So there’s a real challenge there: compress it all down into a simplified form that can be implemented on an existing EA toolset.

And courtesy of a great meeting yesterday with Alex Yakovlev, it looks like we’ve cracked it:

• one main entity-type (Service)
• one subsidiary entity-type (Exchange)
• three relation-types (flow, composition and realization)

There are also two more subsidiary entity-types (Vision and Value) that are probably optional because they’re only used in one specific context and can be simulated anyway by other entity-types (Service and Exchange respectively).

That’s it.

And it’s all close enough to common model-types such as UML, Archimate or BPMN that it can be implemented via a few minor tweaks to entity-types and relation-types that already exist within those models. Which means that we should be able to translate automatically to and from those other model-types. That’s definitely good news. (For me, anyway. 🙂 )

So, here goes: formal details for a simplified variant of Enterprise Canvas that can be implemented as a UML Profile or equivalent metamodel in any EA toolset that supports that kind of metamodelling. (Alex is aiming to get an initial UML Profile for Sparx Enterprise Architect done in the next few days – I’ll post here when it becomes available.)

Service entity-type

In Enterprise Canvas, everything is or delivers a service. One side-effect is that that means that, in a model, everything (and everyone) that does something – the service in focus, its suppliers and customers, its investors and beneficiaries, and the services that coordinate, direct and validate it – can all be represented as instances of a single entity-type, Service.

Parameters for the Service entity would depend somewhat on the abstraction-layer being represented.

At the top layer, row-0 ‘Enterprise’, a Service actually represents the shared-enterprise vision, which should be defined solely by its name. (If supported, a Vision entity should be used for this, rather than a Service.)

At the next layer, row-1 ‘Scope’, Service entities can be used (if somewhat incorrectly) as placeholders and carriers for the lists of overall enterprise-content.

At row-2 ‘Business Services’, Service entities should be used, but without much if any content, as the focus at this layer is on key relationships between enterprise-scope services.

At row-3 ‘Service-content’ and below, more detail should added, according to the needs of the respective layer (‘Logical’ implementation-independent, ‘Physical’ implementation-specific, deployment, and run-time record). Content and activity of the service should typically be described in terms of the ‘single-row extended-Zachman’ taxonomy used within Enterprise Canvas:

Toolset implementation: Start from an appropriate metamodel entity-type, such as UML or BPMN ‘Activity’, or Archimate ‘Business Service’. Rename this entity-type ‘Service’. Ensure that it has a ‘name’-parameter; other parameters are probably optional.

For conceptual compatibility with BPMN (‘Activity’), Archimate (‘Business Service’ etc) and UML Activity Diagram (‘Activity’), a Service entity should be displayed as a rounded-rectangle.

Exchange entity-type

The Exchange entity-type represents what is passed between services, or involved in relationships between those services:

Exchange entities should only be used in models representing row-3 ‘Service-content’ or below. The content of the exchange should be described in terms of the ‘Asset’-column in the single-row extended-Zachman taxonomy above.

Toolset implementation: Start from an appropriate metamodel entity-type, such as UML Activity ‘Object’ (‘Document’), BPMN ‘Data Object’, or Archimate ‘Business Object’. Rename this entity-type ‘Exchange’. Ensure that it has at least a ‘name’-parameter, and preferably a text-box and/or checklist to summarise the content of the exchange, as above.

The Exchange entity-type could be represented in several different ways, depending on the content of the exchange, and the notation used as the base for the metamodel. A suggested default would be the ‘data object’ type used in several notations, as above. Alternatively we might use different symbols to represent different asset-types used in the respective exchange: for example, a box for physical objects, a page for information, a stick-figure for relations, and a flash for brands and other aspirational-assets.

However, given that many exchanges may involve multiple asset-types or composites, it may be better to use only the default, or to allow annotation of the single entity-type, allowing one or more of the asset-type symbols as ‘decorations’, similar to the ‘decoration’ add-ons used in Archimate to distinguish between service-types.

Vision and Value entity-types

The Vision and its concomitant Values are the ultimate anchors for everything that happens in the shared-enterprise – or, to put it the other way round, every service and exchange must in some way help towards the realising of the shared-enterprise vision and its values:

The Vision and Value entities should appear only in row-0 ‘Enterprise’, and are the only content that should appear in that row. For most purposes, only one Vision should be used: multiple Vision entities should only be used for the special case of assessing clashes between multiple shared-enterprises impacting on an organisation. (If necessary, a suitably-labelled Service entity may be used as a substitute for a Vision entity.) Use of Value entities is always optional in modelling; any number of Value entities may be attached to a Vision via composition-relations.

Everything in row-1 ‘Scope’ should have a realise-relation to the Vision and, optionally, to one or more of the Value-entities (if any).

Service-entities that are used to represent (‘validation-services’ (i.e. services that deliver ‘validation’ support for other other services, via a flow-relation with a ‘validate’ role), should generally take part in realise-relation chains that ultimately link up to a respective Value entity (if present).

Toolset implementation: In both cases, start from an appropriate metamodel entity-type, such as the Archimate ‘Service’-lozenge or ‘Meaning’-cloud for Vision, and the Archimate ‘Value’-oval for Value. In both cases, the only parameter should be a name of descriptor for the respective vision or value.

For simplicity, the representation should draw on that used for the respective base-type – i.e. lozenge, cloud or oval:

Although usage of distinct Vision and Value entities would be preferred, for clearer modelling, a simpler metamodel-implementation could use a Service entity as a substitute for the Vision entity. In this case, to keep the metamodel as simple as possible, no Value entity should be defined, and hence no specific relation-type links need be defined; instead, the single Service should used as the anchor-point for realise-relations with all layers of abstraction and concretisation (‘rows’) from below.

flow relation-type

Service-entities are connected to each other by flow-relations, to which Exchange-entities may be attached or imposed to indicate what is exchanged between those services:

The flow-relations should only be used in row-2 (‘Business Services’) and below. In row-3 and below, each flow should also take on a distinct role, representing the Enterprise-Canvas inter-service relationships, as follows:

• provide: simple provision of products and services, used to link with other services in Supplier and Customer relationships to this service (a Supplier is a source for or ‘provides’ a flow; a Customer is a destination for or ‘consumes’ a flow)
• invest: a flow from a service in an Investor relationship to this service
• benefit: a flow to a service in a Beneficiary relationship to this service
• coordinate: a flow or exchange with a service in a Coordination guidance-relationship to this service
• direct: a flow or exchange with a service in a Direction guidance-relationship to this service
• validate: a flow or exchange with a service in a Validation guidance-relationship to this service

(An open or ‘unspecified’ role should generally be used in row-2 flow-relations, and in other rows for flows in which the role has not yet been determined.)

Connection-rules are as follows:

• a flow-relation may link a Service-entity to another Service-entity.
• a flow-relation may link a Service-entity to an Exchange-entity, or an Exchange-entity to a Service-entity.

Note that flows can only link ‘horizontally’ across a row (layer of abstraction). They cannot and must not be used to link between services and/or exchanges in different rows.

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘flow’. The parameters should include an optional name, an identifier for the role (e.g. via dropdown-list), and an optional text-area to describe the content (if no Exchange entity is attached), triggering-events and other relevant information.

For consistency with Archimate, BPMN and UML, the flow-relation should be represented by a dotted-line ending in a solid arrow-head, indicating the primary direction of the flow:

(For flow-relations in which there is no emphasised direction of flow, an arrow-head should be used at both ends.)

composition relation-type

In addition to layers of abstraction (‘rows’), we often also need to model layers of granularity (composition), in which we examine in finer detail of the structure and implementation of a Service or Exchange.

The nine subsidiary cells of a service within Enterprise Canvas (a matrix of inbound / self / outbound, and before / during / after the main-transaction) and the three subsidiary flows in an inter-service exchange (again, before / during / after the main-transaction) are somewhat-abstract examples of composition or decomposition. However, these are merely the standard partitionings used in Enterprise Canvas, and any appropriate alternate partitioning may be used instead.

One somewhat-confusing example of composition/decomposition is the purported ‘layering’ in TOGAF or Archimate. In that context, parts of a service may be composed of (actually, implemented by) software applications, which in turn are in part composed of (actually, hosted on) physical IT systems and networks.

All of these can be modelled by composition relations between Service-entities, and between Exchange-entities:

The composition-relations should only be used in row-2 (‘Business Services’) and below. In row-3 (‘Service Content’) and below, it may be necessary to annotate the composition to add further specifics about the nature or sub-type of the composition, for example:

• composition: the ‘child’ services or exchanges are of the same general type as the ‘parent’
• aggregation: the ‘child’ services or exchanges are a mix of structurally-different types relative to the ‘parent’
• assignment: the ‘child’ service or exchange is of a structurally-different type taking on the role of a ‘child’ to the ‘parent’
• used-by: the ‘child’ service or exchange is ‘realised by’ a structurally-different type to the ‘parent’ (e.g. business-service implemented by software-application, in turn hosted-by physical-IT) but at the same level of abstraction

(Note that in Archimate and UML these are all defined as different relation-types. For this context they are best understood as variants on a theme of composition/decomposition.)

The default meaning for a composition-relation is that the ‘child’-entity is of a structurally similar type to the ‘parent’ – i.e. a simple composition/decomposition relationship.

Connection-rules are as follows:

• a composition-relation may link a Service-entity to another Service-entity.
• a composition-relation may link an Exchange-entity to another Exchange-entity.
• a composition-relation may link a Value-entity to a Vision-entity.

Note that composition/decomposition relationships can only link within a row (layer of abstraction). They cannot and must not be used to link between services and/or exchanges in different rows. To link between rows (i.e. different layers of abstraction), always use a realization-relation – a composition-relation should never be used for this purpose.

Take especial care when emulating an Archimate ‘assigned-to’ or ‘uses/used-by’ relation: these are often used in Archimate in a very misleading way, as a kind of analogue of a realization-relation, but one that occurs at the same level of abstraction. Their main function in Archimate, TOGAF and many other IT-centric frameworks is to provide links between their purported ‘layers’ (Business, Application, Technology), which in reality are arbitrary subset-partitions of the conceptual-space. In effect, ‘Business’ is used for anything that involves purpose or human concerns; ‘Application’ is used for all information-related concerns (but for IT-maintained information only); and ‘Technology’ for anything to do with IT-hardware (with no allowance for any non-IT forms of technology). These pseudo-‘layers’ have no intrinsic relationship to layers of abstraction, and again are often highly misleading in enterprise-architecture practice. “You Have Been Warned” etc…

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘composition’. The parameters should include an optional name, an identifier for the sub-type (e.g. via dropdown-list), and an optional text-area to describe the composition/decomposition context.

For consistency with Archimate, BPMN and UML, the composition-relation should be represented by a line ending in a solid diamond-arrowhead, with the arrow-head pointing to the ‘parent’:

For other Archimate variations such as aggregation, assignment and used-by, it is probably best to use the respective Archimate line-decoration (open-diamond, dot and line-arrow respectively).

realization relation-type

Links between layers of abstraction – for example, a transform between a ‘logical’ implementation-independent (‘row-3’) service and a ‘physical’ implementation-specific (‘row-4’) instantiation of that service – should be modelled via realization-relations between Service-entities and between Exchange-entities:

The realization-relations should be used between all rows, as appropriate, to create a full trail of dependencies between ‘Why’ (abstract, moving ‘upward’ between rows) and ‘How’ (concrete, moving ‘downward’ between rows).

There are no sub-types of realization-relation.

Connection-rules are as follows:

• a realization-relation may link a Service-entity to another Service-entity.
• a realization-relation may link an Exchange-entity to another Exchange-entity.
• a realization-relation may link a Service-entity ‘upward’ to a Vision-entity or Value-entity.

Note that realization relationships can only link between rows (layers of abstraction). They cannot and must not be used to link between services and/or exchanges in the same row. To link within rows (i.e. the same layer of abstraction), always use a flow-relation or composition-relation – a realization-relation should never be used for this purpose.

Take especial care when emulating an Archimate ‘realization’ relation. These are generally correct, in the sense that they usually link between different levels of abstraction (for example, Data Object realises Business Object); but note that in Archimate they can also be used to link between entities at the same level of abstraction. As usual, the problem here is the misleading pseudo-‘layers’ (Business, Application, Technology) in Archimate, TOGAF and the like.

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘realization’. The parameters should include an optional name and an optional text-area to describe the realisation context.

For consistency with Archimate, BPMN and UML, the realization-relation should be represented by a dotted-line ending in a open-triangle arrowhead, with the arrow-head pointing to the more abstract ‘parent’:

No sub-types are required for the realization-relation.

Some comments on modelling

This simplified version of Enterprise Canvas does incorporate all of the original features, but in somewhat different form: a significant amount of the information – particularly around relative roles of services – is now carried within the entities and flows, rather than as per the original entity-notation. There are also some potential inconsistencies in the way relations are mapped in the ‘Scope’ layer (row-1). In some ways this version is simpler to use, but a side-effect is that more responsibility for correct modelling of underlying detail is passed to the modeller rather than explicit in the notation.

By default, colours for entities and flows are not semantically significant. Use colour in any way which suits the meaning best.

A quick summary of the full simplified notation is as follows:

One crucial area of concern is around inter-layer (inter-row) relationships – i.e. via realization-relations. In common with UML and BPMN, Enterprise Canvas demands a rigorous approach to proper modelling of links between versus within the respective layers of abstraction. However, anyone whose main architecture-modelling background is via Archimate, TOGAF or the like may not be fully aware either of that rigour, or of the need for it in practice. The problem is that because of the explicit IT-orientation and implicit IT-centrism of those frameworks, separation of layers of abstraction is blurred together with pseudo-‘layers’ of implementation-category, as described above: ‘Business’ for purpose and human focus, ‘Application’ for (IT-specific) information, and ‘Technology’ for (IT-specific) physical hardware. In effect, the ‘Business’ pseudo-layer includes both purpose/human implementation (row-4 and below) and most items in implementation-independent layers of abstraction (row-3 or above). This cavalier approach to layers of abstraction is a major cause of problems when trying to use Archimate and the like in any non-IT-centric context.

In short: use flow and composition-relations only within layers of abstraction (rows); use realization-relations only between rows. Don’t mix them up!