More on simplified Enterprise Canvas

Following on from the previous post on ‘Simplifying the Enterprise Canvas‘, a few more notes on how to use the notation, and some practical matters on modelling.

Perhaps not quite as technical as some of the other recent posts, but I’ll admit that if enterprise-architectures and the like are not of much interest to you, you might want to skip this one. If that is of interest, though, please do read on! 🙂

Information in the Service entity

I said in the previous post that the Service entity needed a name-parameter and not much else. Which was just plain wrong: my apologies…

If we follow the principles of ‘The Metamodel To Rule Them All’, the Service-entity is going to need to carry a lot of descriptive information, about what the service does, what it is, who or what does it, what it uses, where it fits within the overall scheme of things, and so on. (Part of that was implied when I mentioned the use of the ‘single-row extended-Zachman’ to map out service-content – but all that information has to be stored somewhere.)

All of that implies that the Service-entity will need at least one more parameter, and probably several of them. The minimum requirement would be a free-form text field, probably to be used in wiki-style format. A separate and distinct description-field would be useful, too, to help build a service-glossary and service-catalogue.

It’s simple enough to add this in the toolset-metamodel: it just needs to be done from the start, that’s all.

Layers and realization-relations in Enterprise Canvas

A reminder that the layers or ‘rows’ in Enterprise Canvas parallel those in Zachman: they are layers of abstraction – not arbitrary pseudo-‘layers’ of implementation, as in classic IT-centric ‘enterprise’-architecture.

The set of layers in Enterprise Canvas are a slightly-extended variant of the Zachman set:

The ‘row-0’ above the Zachman set provides compatibility with ISO-9000 and the like, and represents an unchanging permanent-anchor – specifically, the shared-enterprise Vision and its concomitant Values.

The ‘row-6’ below the Zachman set represents the past, what has actually happened within our architecture; all of the other layers represent future intent, progressively moving closer towards the real-world detail of ‘the Now’ as we move down through the rows. This gives us the support we need for architectural review following a continuous-improvement process such as PDCA or After Action Review:

• What was supposed to happen?
• What actually happened?
• What was the source of the difference?
• What can we learn from this, to do differently next time?

In Enterprise Canvas, we use realization-relations to link between rows – and only between rows. We don’t use realization-relations to connect between the pseudo-‘layers’ (‘Business’, ‘Applications’, ‘Technology’ etc) in TOGAF and Archimate and the like.

In most architectural work we’ll focus on row-2 to row-4, shown here as Business-model, System-model and Design-model – otherwise known as ‘business-context’, ‘logical’ and ‘physical’. A ‘logical’ (implementation-independent) design realises – i.e. makes more concrete – the support for a business-need or business-service described in the ‘business-context’; a ‘physical’ (implementation-specific) design realises an implementation for a ‘logical’ service; and so on. (Going the other way, the ‘logical-service’ is the reason for the existence of the ‘physical-service’, the ‘business-service’ is the reason for the existence of the ‘logical-service’, and so on all the way upward to the shared-enterprise Vision.)

If we’re working only within one row, we don’t need (or use) any realization-relations in our model. We only use realization-relations to describe linkages between different layers of abstraction, such as how a specific implementation realises a business-need.

Beware of pseudo-‘layers’

I know I’ve said this several times in various posts, but it needs to be hammered home: the ‘layers’ used in IT-centric frameworks such as TOGAF and Archimate are not layers of abstraction, and hence should not be used as layers in enterprise-architecture models. Those pseudo-‘layers’ are highly misleading, as they blur the fundamental distinctions between abstraction and implementation-type: for example, the so-called ‘Business’-layer is often used as a random grab-bag containing a jumbled-up mess of any non-implementation-specific abstraction and anything that might be classed as ‘not-IT’. The resultant scrambling of inter-entity relationships is illustrated well in this diagram from the Archimate specification:

Archimate v1.0, Figure 39: (c) Open Group 2009

The relationship between ‘Business Object’ and ‘Data Object’ is correctly shown here as a realization: it crosses a boundary between layers of abstraction. However, all of the other links would be shown in Enterprise Canvas as variations on a theme of composition – i.e. relationships that do not cross layer-boundaries.

Be wary of implicit inter-layer transitions in ‘containment’ views

‘Containment’ is a popular space-saving technique supported by many toolsets, such as Phil Beauvoir’s excellent free Archi cross-platform toolset for Archimate (funded by UK JISC). Within the model, an entity can ‘contain’ other entities, which usually implies that the ‘child’ entities have composition-relations with the ‘parent’.

In Enterprise Canvas, this is implied in the matrix-subdivision of the core Service entity into nine subsidiary cells:

And also implied in the ‘before / during / after’ split of the inter-service flow, as represented in this metamodel by the Exchange-entity:

There’s no doubt that this is ‘cleaner’ and (usually) easier to read than doing the same thing with composition-links:

However, do beware that in some cases, the ‘containment’ may actually be a realization-link, not a composition-link. A very common example is where we would want to show an implementation-independent (row-3) service ‘containing’ the implementation-specific (row-4) services that bring that higher-level abstraction into reality. The catch is that that’s a realization relationship – a transition between rows, or layers of abstraction – rather than a simple matter of granularity within the same layer. Hence if we use ‘containment’, we need some means to distinguish between composition-relations and realization-relations for the implied links between the ‘parent’ and its ‘children’.

One way to do this is that, in keeping with the dotted-line of the realization-relation, we could use a dotted-line rather than solid-line for the boundary of a Service-entity or Exchange-entity. What’s not immediately clear, though, is to which entity we should apply the dotted-line, because the realization could be considered to go either way. One convention we could use is that if only some of the ‘children’ have realization-relations with the parent, then the dotted-line would apply to each of those children; whereas if all of the children have realization-relations with the parent, the dotted-line should apply to the parent:

It would be good if the toolset could manage this automatically for us, but in almost all cases we should be able to do this manually if need be.

Alternate modelling for Exchange entities

The Exchange-entities represent whatever passes between Service-entities in a flow-relation between each other.

In the standard modelling-usage that I described in the previous post, the Exchange is literally placed between Service entities, and the flow-relation links directly to the Exchange on both the ‘incoming’ and ‘outgoing’ side:

This is probably the best way to model Exchange-entities if there’s a strong emphasis on flow-content – as there is in VPEC-T analysis, for example, where we focus on what a service would need or provide before looking for other services that would provide or consume that inter-service content.

But if we’re more interested in relationships between services, with only secondary interest in the content of what passes between them, it may be better to attach the Exchange-entity to the respective flow-relation, rather than visibly interposing it in the flow:

The disadvantage of the ‘attached-Exchange‘ option is that it’s not well suited to showing a split into subsidiary-Exchange items linked to the attached ‘parent’ via composition-relations: visually it becomes too messy, and hard to ‘read’. If you need to show composition / decomposition, use the in-flow format instead.

Ideally, the toolset and its metamodel should be able to support both display-formats. If it can support only one variant, use the in-flow format, rather than the ‘attached’ format.

Keeping things simple

Remember that one of the key aims here is to keep things simple, without ever dropping down into the over-simplistic. If we ignore for the moment the row-0 special-case of the Vision and Value entities, there are only two entity-types in the entire notation: Service, which does something; and Exchange, which represents something that passes between services. That’s it.

Because of that principle that ‘everything is a service’, it should be straightforward to substitute a graphic or photograph for the Service-entity in a model – which should make it much easier to create variations of models that will make visual sense to executives, line-managers and other non-architects, whilst still retaining the formal rigour of the model beneath the visible surface.

And there are only three types of relationship possible between those entities, which in turn follow very simple rules:

• flow-relations (between services) or composition-relations (internal structure of services and exchanges) can only connect within a single ‘row’ or layer of abstraction
• realization-relations (from abstract to concrete) can only connect between layers of abstraction

Again, that’s it.

It would be helpful if the metamodel could also include common non-semantic items such as groups and junctions and annotations, but they’re not required as such for the notation: they’re just useful.

And because the notation is so simple, it allows the true complexity in the context to emerge and surface cleanly through the modelling process. We don’t get distracted by arbitrary pseudo-‘layers’: it’s just the enterprise, as enterprise.

For many modelling-purposes, the only relation-type we’ll need is the flow-relation. For example, a simple supply-chain with switching between multiple suppliers:

Or a business-model with multiple client-segments, where we use Exchange-entities to record the different transactions and transaction-content for each client-group:

We use decomposition – modelled via composition-relations – to drill down into more details about structure. When we’re aiming to model trade-offs between implementation-options, or service-substitutions in disaster-recovery, we start to see the real value of a notation that doesn’t make arbitrary distinctions between IT-based, machine-based and manual service-implementations:

For most modelling, we won’t use realization-relations at all. The main occasions where we would use them are:

• mapping ‘logical-to-physical’ transforms, and other moves from abstract to concrete
• mapping dependencies of ‘why’ / ‘how’ between the layers – for example, showing how a specific service contributes to the overall aims of the shared-enterprise

But that’s about it, really. Very simple. And yes, best to keep it that way as much as we can.

Enterprise Canvas – the full set of service-relationships

Because the notation consists of just two main entity-types and three relation-types, it’s certainly simple when compared to other notations. And at first glance it also looks simple when compared with the original Enterprise Canvas summary of inter-service relationships:

Not quite so simple, though, when we map out in this notation the full set of relations shown in that visual-summary above, including the relative roles of each of the flow-relations and all of the implied composition-relations:

That should, I think, give some idea of the full power of the Enterprise Canvas and its underlying concepts: there’s a lot in there…

The original Enterprise Canvas is compact and concise, but it’s likely to be hard to implement in any of the existing EA toolsets. (That original notation is still probably the best for rough-sketches on paper or whiteboard, though.) This simplified version is somewhat less concise, but it would be much easier to implement in an EA toolset, and easier for us to increase its uptake and more general adoption across the EA disciplines. Ultimately, though, just choose whatever works best in the context!

Comments / suggestions as usual, if you would? Many thanks for reading this far, anyway.