The Enterprise Canvas, Part 7: Patterns

We wandered through the background and theory of the Enterprise Canvas with context and valuemarket and supply-chainowners and managerslayers and recursion; we’ve made a start on putting it to use, by showing how different models can be layered on top of each other to provide a richer view of a context. Time now to add to that by exploring some example patterns.

Start with a recap on the Enterprise Canvas:

The Canvas itself is the centre section, nine cells that describe a single service at the intersection of value and supply-chain.

The labels ‘supplier’ and ‘customer’ are arbitrary labels for other players in the shared extended-enterprise. The only difference between them (and their relations with this service, too) is the respective emphasis on the direction of flow in specific interfaces; the interfaces themselves (horizontal double-head arrow for ‘relations’, triple-line for ‘main channel’, double-squiggle for ‘backchannel’) are always much the same in each case. Likewise the only real difference between ‘supplier-side’ and ‘customer-side’ on the Canvas itself is the direction that the respective cells and sub-services will face: the respective interfaces are actually the same (or ‘symmetrically equivalent’) on either side.

The ‘investor’ and ‘beneficiary’ could just as well be considered specific types of ‘customer’ and ‘supplier’ respectively: the main difference is that (through the interfaces shown as left or right double-guillemets) they provide or receive forms of value that would more typically go through the backchannel (e.g. money) rather than through the main channel (e.g. goods and services).

The vertical double-arrow represents a sort-of interface that connects services at different levels of abstraction. In real-world practice, this is reflected in the information-flows that pass between different levels of management (particularly middle-management): going ‘down’, generalised strategy is expanded out to more explicit tactics, and thence to detailed operational instructions; and the resultant activity-reports and performance-reports are aggregated and summarised ‘upward’.

The ‘guidance’ interfaces and functions – validation, direction, coordination – link this specific service with other services within the organisation and beyond to the broader shared-enterprise.

Example: for-profit business

I’ll admit this is very much a stereotype, but is actually a typical outcome of Taylorist ‘scientific management’ and current commercial law, especially in the US.

In this structure, ‘the enterprise’ is deemed to be synonymous with ‘the organisation as a whole’ (the boundary shown by the dotted line). By custom and even by law, it’s purported that the only reason that the organisation exists is to ‘make money’ for the stockholders (‘owners’); monetary return is defined as the only meaningful form of value. There is no real link – or even awareness – of a shared-enterprise beyond the organisation; relations with suppliers and customers are characterised by a combative ‘us against them’. All of the guidance-functions are subsumed into ‘direction’, possessed exclusively by the executive management on behalf of the stockholders; ‘validation’ and ‘coordination’ are replaced by ‘command’ and ‘control’ respectively, and often explicitly disconnected from anything beyond the organisation (e.g. insistence on proprietary standards and the ‘not invented here’ syndrome).

Within the service-functions represented in the main Canvas, the natural boundaries between the cells tend to be exaggerated and reinforced as distinct silos. There is often a rigid separation between development and production, and even more so between line-management (which claims the entire backchannel as its own domain, asserting rigid control over budget and all monetary matters) against all other parts of the service: the classic Taylorist separation between ‘management’ and ‘workers’.

The anomalous position of ‘marketing’ – stuck halfway between the Value-Proposition (‘product-development’) and Customer-Relations (‘sales’) cells – is a direct outcome of the disconnect from any shared extended-enterprise. Since no connection exists to link the organisation to a broader enterprise-vision, there is no possibility for a ‘pull’-based marketing model via a shared Value-Proposition; the only available alternative is product-development, in essence derived from internal assumptions about ‘something we can sell’. Without any direct engagement in the value-proposition, the organisation’s potential customers are unlikely to feel much inherent engagement in the product; hence it becomes the unhappy role of marketing to attempt, via ‘push’, to manufacture a ‘relationship’ with customers where no real reason for any such relationship actually exists.

Overall, not a happy picture; certainly not a very effective one. It is also, unfortunately, very common. Oh well… Yet a comparison of this dysfunctional structure with the generic Enterprise Canvas further above indicates what can be done to improve matters – of which the most urgent and important is to break the delusion that the organisation ‘is’ the enterprise, and instead connect the organisation with the shared-vision and shared values of its broader market and extended-enterprise.

Example: not-for-profit charity

This is somewhat less of a stereotype than the previous example, but still very much generic. (Much the same principles as here should apply to the government context, since that too is nominally ‘not-for-profit’; but in practice the ‘guidance’ functions there often tend to be subsumed into the executive, much as in the dysfunctional for-profit model, and with much the same dysfunctional results.)

In this example, the charity aims to deliver a service to its beneficiaries, yet to do so must engage donors to provide the resources needed in order to deliver those services, and hence must also act as a direct and explicit intermediary between donors and beneficiaries. (The same principles apply to almost any charity, but charities in practice often have very complex relations between many different types and roles of providers; for this example we’ll keep it simple, and imagine a charity that provides clothing to victims of natural disasters.)

Here the boundaries of the organisation (shown by the dotted-line) may include the ‘direction’ guidance-functions – as in a standard for-profit business – but the ‘validation’ and ‘coordination’ functions must extend beyond the organisation itself. On the ‘coordination’ side, this charity must coordinate its service-delivery with other charities and services that operate the same disaster-zone – medical, shelter, food, rescue, security and suchlike; and on the ‘validation’ side, the charity’s services and activities will only make sense to donors and beneficiaries alike if they connect to a shared-vision such as “keeping people safe, warm and comforted after an emergency”. (Many charities start off with something like a ‘product-development’ model, designing support-services of some kind as a metaphoric equivalent of ‘something we can sell’, and then delivering those services: but as a ‘push’-type activity it may be difficult for it to make sense even to the nominal beneficiaries, and unless the connection is made to a ‘higher cause’ that will engage others, the charity will soon run out of resources, and fail. All the problems and potential mistakes faced by commercial ‘startups’ apply just as much to charities and other not-for-profits: the only difference is that resources and ‘profit’ may be measured in a different way.)

The value-proposition here is straightforward: given the shared-vision, there is a clear need for clothing to replace that lost in natural disasters – a need which will be all too evident to the intended beneficiaries, and will also make immediate sense to potential donors. This in turn implies the need for a service to deliver such clothing in a disaster-recovery context (the Value-Creation cell, here described as ‘service-operation’) and for some form of management, in donor locations, on the spot in the disaster-affected region, and in logistics in between (the Value-Management cell, here labelled ‘service-management’). The linkage to value and enterprise-values is therefore reasonably clear, though we will have to drill down from this very simple row-2 model all the way to a row-5 detailed-implementation model to get a proper picture of what all of this would entail in practice.

On the donor side, we need to explain what the need is, and why it’s important (Supplier-Relations, here labelled ’cause-marketing’) and encourage two-way conversations that will engage people directly in the enterprise-values and thence in the charity’s value-proposition. Assuming this engagement does happen, we’ll also have created the space for transactions to occur, much like a supplier-relationship in a commercial context – in this case supplying either clothing, or money to assist in delivery of that clothing, or both (Supplier-Channels, here labelled ‘fundraising/collection’).

On the beneficiary side, we need to identify appropriate ‘customers’ for our clothing service; and given that this is a disaster-recovery context, gaining their trust will also be crucial here – hence, again, the importance of two-way communication to create engagement in the shared-vision (Customer-Relations, here shown as ‘beneficiary-relations’). We then need to match their needs with the available resources, both on-the-spot and via requests further back along the charity’s logistics chain (Customer-Channels, here labelled ‘service-delivery’).

In both cases the backchannel (Value-Return and Value-Outlay, here labelled ‘beneficiary-results’ and ’cause-results’ respectively) is significantly different from that in a commercial context. For a business, ‘success’ is a profitable sale; income and costs alike can, it seems, all be reduced to monetary metrics, which makes the measurement of ‘success’ a mere matter of quick calculation – all very simple and straightforward. But as soon as we realise that there are other forms of value in play than money alone – as is immediately evident here, if perhaps less so in a commercial context – then we need to look for a much broader definition of ‘success’, in fact drawn directly from the shared-values of the extended-enterprise. In this case the charity would probably not expect any payment from the beneficiaries for the clothing: what will matter much more instead will be some form of proof that the service-delivery was in accordance with the shared-values of the enterprise – hence, for example, all those photos of happy, smiling, well-clothed children that we would expect to see passing through the backchannel, to appear as ’cause-results’ on the charity’s website and in reports to donors. The backchannel closes the loop of value; and its balance overall, across all relevant forms of value, provides the proof that the organisation has indeed delivered added value in terms of the extended-enterprise’s vision and values.

Note that it’s not true that money doesn’t matter here: it does. In fact it matters a lot, not least because potential donors are very quick to withdraw support from any charity that is perceived to carry too much overhead in any form, monetary or otherwise. The key point here is that money is not the only form of value in play in the overall transactions of the charity – a point which, architecturally, also applies in every ‘for-profit’ organisation as well.

Example: ITIL IT service-management

For this next example, let’s pick on something more in the mid-range: IT service-management within a large organisation. The typical reference for this is ITIL Version 3 [PDF, 58pp], the IT Infrastructure Library:

This describes service-management overall in terms of five distinct strands: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Process Improvement. So: map those core ideas onto the Enterprise Canvas, and see what we get in terms of an overall pattern for service-management. The result shows that it does all fit quite well:

One immediate point is that the definitions of ‘customer’ and ‘supplier’ are fairly fluid here: many actual stakeholders will take both types of roles at various times, so it definitely does help if – as the Canvas allows us to do – we take a symmetric view of the respective relations, main-channel and backchannel interfaces.

Another key point is that it does depend strongly on a clear value-proposition, here summarised as “the right IT services, when we need them”. All of the ITIL processes revolve around that core idea, and the values that lie behind it. The ITIL specification helps in this, too: for example, in describing Service Strategy, the Overview document states:

The service strategy of any service provider must be grounded upon a fundamental acknowledgement that its customers do not buy products, they buy the satisfaction of particular needs. Therefore, to be successful, the services provided must be perceived by the customer to deliver sufficient value in the form of outcomes that the customer wants to achieve.

Achieving a deep understanding of customer needs, in terms of what these needs are, and when and why they occur, also requires a clear understanding of exactly who is an existing or potential customer of that service provider. This, in turn, requires the service provider to understand the wider context of the current and potential market places that the service provider operates in, or may wish to operate in.

A service strategy can not be created or exist in isolation of the over-arching strategy and culture of the organization that the service provider belongs to. The service provider may exist within an organization solely to deliver service to one specific business unit, to service multiple business units, or may operate as an external service provider serving multiple external businesses. The strategy adopted must provide sufficient value to the customers and all of the service provider’s stakeholders – it must fulfill the service provider’s strategic purpose.

All of this requires very strong linkages beyond the service itself – almost the exact antithesis of the Taylorist-style model for the ‘for-profit business’ example above. In the Enterprise Canvas, these linkages are provided by (or rather, modelled as) the guidance-services: the structured layers of ‘validation’, ‘direction’ and ‘coordination’, as described in the ‘Systems’ section of Part 5 of this series of articles.

To model ITIL in its entirety, we would probably create a separate Enterprise Canvas at row-2 for each of the five major service-streams, shown in parallel on a single diagram, and linked upward to the organisation (row-1) and the extended-enterprise (row-0). We would then expand downward, into a more detailed set of row-3 models (some of which would be shared across two or more of the ITIL service-groups), and then downward again to row-4 and beyond. But it’s clear that it does all fit well: a very useful exercise for any group of enterprise-architects with suitable time to spare, perhaps? 🙂

Example: BPMN process-model

This one is perhaps a bit unfair, but it is a pattern, and one that will help to demonstrate why there should be serious concerns about the limitations and incompleteness of so much current so-called ‘enterprise-architecture’. To illustrate this, let’s return to the very(!) simple BPMN diagram from back in Part 5:

The process-model purports to describe the service of creating an account – in other words, something that we would expect to model on the Enterprise Canvas. So let’s map this onto the Canvas, and see what we get:

For which the short answer is “Not much”… only a tiny subset of what we actually need in order to make sense of it as a service:

  • There’s no concept of any precursors to transactions – the content and interfaces for the usual Supplier/Customer-Relations cells.
  • There’s no concept of any backchannel – the content and interfaces for the Value-Outlay/Return cells.
  • There’s only the most minimal of content for Value-Management, namely the small part that deals with the decision-making and business-logic with the execution of the process.
  • There’s no ‘why’ anywhere in the process-model – no Value-Proposition, no known reason why this particular process and service should even exist.
  • There’s no linkage anywhere to ‘the big picture’, the guidance-services that link this process to the various qualitative concerns, or even to the inter-service choreography need to coordinate the execution of the complete end-to-end business-process.

(To be fair, the equivalents of ‘Supplier’ and ‘Customer’ and their interfaces would be represented by headers in parallel swimlanes – but that still doesn’t tell us anything about the coordination of the full end-to-end business-process.)

The Canvas itself doesn’t show the assets (the account-record, for example) or the triggering events, or the location either (something else that’s absent from the BPMN model); but all of those are items that we would expect to pick up straight away by applying an extended-Zachman view to the respective cells (especially the Value-Creation cell, here shown as ‘process execution’). Likewise a VPEC-T assessment of the interfaces would tell us much more about the respective flows than we have here in the BPMN model.

Again, I know this example has been a bit unfair, somewhat of a straw-man (rather than a robbie-the-robot? 🙂 ). But what worries me is that I’ve seen all too many examples where BPMN diagrams and the like have been presented as ‘architecture’ – even as ‘enterprise-architecture’… which it isn’t. At all.

What this pattern does show us, though, is how use a BPMN diagram to populate this part of the base-content for an Enterprise Canvas – and then go on from there to fill in all of the blanks, to build the complete of the service that we need for an architecture.

So: that’s it – a few Enterprise Canvas patterns to play with. But how does all of this fit in with all the other models that abound in enterprise-architectures? Something to explore in the next and final article in this series! 🙂

2 Comments on “The Enterprise Canvas, Part 7: Patterns

  1. Tom, Good to see the examples.

    I was particularly intrigued by the BPMN one as it demonstrates what a BPMN diagram doesn’t show us.
    It indirectly also illustrates why there is a need for BPM to be part of EA rather than something separate as some blogs have proposed – i.e. because you need EA to complete the missing parts of the picture.

  2. Yes, agree re “there is a need for BPM to be part EA rather than something separate”.

    Though perhaps another way to put it is that EA needs to be interested in everything. BPM is a distinct discipline in its own right, with its own distinct skillsets: but enterprise-level problems do arise if it isn’t properly connected with everything else. Given that BPM is a specialist discipline, it’s not really its job (or often its competence) to think in terms of overall cross-enterprise impacts: that’s what EA is there to do. All that we need to ask of BPM is that they respect the need for cross-enterprise integration, and at least listen to the advice and suggestions from elsewhere that we bring to them from other specialisms in the enterprise.

    That’s also what I meant by the Enterprise Canvas as ‘one map to bind them all’: it’s not a panacea, ‘Life The Universe, Everything’, it’s just a really useful way to bind together all manner of other models, highlight the gaps, and provide pointers as to how to fill those gaps. That’s what I hope this shows, anyway.

    Thanks again, of course. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

*