The Enterprise Canvas, Part 5: Recursion, Flows and Systems

So far in this exploration of the Enterprise Canvas we’ve looked at context and values, market and supply-chain, owners and managers, and layering. The next stage needs to take us for a brief wander through the wilds of systems-theory: specifically, on recursion, flow and overall integration.

The point here is that everything is a system, is part of a larger system, contains other systems; systems ad-infinitum. In dealing with anything on the scale of an enterprise, we need to be to able to think in terms of systems and systems-of-systems if we’re to have any chance of making sense of what’s going on. Yet whilst formal ‘hard-systems theory’ has gained a well-deserved reputation for near-incomprehensibility, most of what we need here can be summarised in five simple and straightforward principles: rotation, reciprocation, resonance, recursion and reflexion.

Rotation is the simplest of the lot. Any real-world system is too large and too complex to be seen in its entirety from one view alone: to make sense of it all, we need to be able to rotate through a variety of different views and viewpoints, and merge those different views together in our minds. There’s nothing difficult about this: every enterprise-architecture framework does it; every checklist does it. The whole point of the Enterprise Canvas is that it provides a checklist to give us many different views on the service in scope. We just have to remember to use it, as a checklist, as a systematic rotation through multiple views, that’s all.

Reciprocation and resonance are a matched pair of principles that apply mainly to flows. In a simple world, flows need to balance somehow: “for every action there is an equal and opposite reaction”, and suchlike. In that sense, flows need to be reciprocal; at the market level, there needs to be ‘fair exchange’, ‘quid pro quo’ – or at least a verifiable perception of that – and so on. Reciprocation is a large part of what we’re exploring when we do a VPEC-T analysis of a flow between services. The catch is that although things do have to balance up somehow, the flows may not be a simple ‘tit for tat’: often there will be delays in a feedback-loop, or translations from one form of energy to another – for example, donors to a not-for-profit don’t get their money back, but do (we hope!) gain a different kind of satisfaction. In terms of point-to-point physics, each transaction can be seen as a simple win/lose; but when we take the resonance of those feedback-loops into account, win/lose turns out to be a special-case within a full spectrum between win/win and lose/lose. That last point applies especially in social flows and social transactions – and frequently leads to ‘unexpected’ wicked-problems if we’re not aware of what’s actually going on. To help us make sense of that, we can use the Enterprise Canvas to describe resonance and reciprocation in the interactions and flows across the whole system, especially over time.

Recursion and reflexion are another matched-pair. Recursion occurs when the same pattern repeats – or is ‘self-similar’ – at different levels of the same system. A conventional reporting-hierarchy is recursive: the same pattern repeats at different levels of management. A service-oriented architecture is recursive: the same concept of services, the same pattern of services, applies in much the same ways at every level of the enterprise. Reflexion is the inverse of this: if recursion means that every part in some ways reflects the whole, then we can also infer the whole from within every part. (Or some aspects or themes of that whole, at any rate: the fact that most things are not identical but only ‘self-similar’, always somewhat unique, means that the view we get from within any one part will always be somewhat blurry, somewhat incomplete. It’s like a holograph: every discrete part of the image also contains all of the image, but in less detail – and that loss of detail can sometimes be misleading if we extrapolate anything out too literally.)

Within the Enterprise Canvas, one of the most immediate examples of recursion is that every cell within the Canvas is also itself a service. So the Supplier-Relations cell, for example, not only provides ‘supplier-relations’ services on behalf of the service that we’re depicting on the Canvas, but to do that it also has its own Value-Proposition in presenting those services, it has its own Supplier-Channels and Customer-Channels (the latter rather than the former being how, in this case of Supplier-Relations, it actually delivers its services), it has its own Value-Creation in which it creates the value of those supplier-relations, and so on.

And each of those sub-cells too have their own flows, some of them linking externally on behalf of the main service, others linking to other cells and sub-cells within the service:

The inverse is also true: whenever we come across a business entity or function that delivers what we might interpret as ‘supplier-relations services’, we need to ask who or what service it delivers these services for, and we need to look for and identify the matching Supplier-Channels, Value-Creation, Customer-Channels, Value-Outlay and the like that provide its ‘sibling’ services in terms of the Enterprise Canvas.

Typically, whenever we go ‘down’ a level into the recursion, we move closer towards real-world implementation; and whenever we go ‘up’ a level in the recursion, we’re usually also moving up a layer of abstraction, as described in the previous article on layering. In that sense, abstraction and recursion are closely linked within the Canvas – which is also another reason why the most useful framework for layering is that of abstraction rather than, say, management-hierarchy.

But the management-hierarchy does have a key part to play in another form of recursion that links well with the Enterprise Canvas. To create some background, consider a simple business-process that creates a new account – a service that we might well use in Customer-Relations or Supplier-Relations, as a precursor to any transactions happening in Supplier-Channels or Customer-Channels. At this point it’s still a fairly abstract description – for example, we don’t care whether it’s implemented by a manual system or by IT – so from an Enterprise Canvas perspective, all of this is at the row-3 layer or System-model, the most common area of emphasis for architectural assessment. Let’s illustrate this with a (much-simplified) process-diagram in BPMN process-model notation:

These diagrams are common enough in solution-architectures, but they actually tell us very little that’s of real use in a service-oriented architecture. For example, at the very minimum, we need to know the interface flows between this process and its external ‘provider’ and ‘client’ processes; and we also need to know how it would be managed, what performance-criteria it should report, and where those reports should be sent:

Which, in terms of the simplified version of the Enterprise Canvas, looks like this:

(…and yes, each drawing faces the opposite way round: my apologies, it’s just a notation-difference in the ways that BPMN and the Enterprise Canvas show the flow of the supply-chain – BPMN emphasises the sequence of events, Enterprise Canvas the overall through-flow.)

Yet there’s still a whole lot that’s missing from this. For example, who or what manages the services-managers? Who or what coordinates this services with other services? Who or what ensures that quality is established and maintained? None of that is in here as such: and there’s a real need for some forms of guidance to make sure that these things do happen.

It’s at this point that we need to reprise part of where we started, back in Part 1, namely the idea that although in principle every service is a ‘delivery service’, there are three other key categories of service: management-services, coordination-services, and the ‘pervasive services’ that help to create and maintain quality throughout the enterprise. Adapting Stafford Beer’s Viable System Model [VSM] to a more service-oriented view of the enterprise, we can describe their relationships like this:

An alternate name for ‘management-services’ is direction, because their role is actually quite a bit broader than simple management of a business-unit or service. And another, perhaps more business-friendly name for ‘pervasive-services’ would be validation, because that’s what they do – they ensure that everything holds to the values of the chosen shared-enterprise. The actual relationships of these other categories of services, though, are almost orthogonal to each other:

Perhaps a simpler way to show this would be to link them to the frame of the overall ‘delivery-service’ – shown here as a dotted-line around the standard nine-cell Canvas:

Note that each of these attaches at the respective layer or ‘row’, as described in Part 4: the same layering and recursion applies to these services too, from most-abstract (row-0) to most-concrete (row-6).

With the exception of some of the coordination-services, few of these services have much if any impact on the day-to-day running of most of the delivery-services. Their real role is to assist in the dynamics of those services – the ways in which they can, may and must change over time to adapt to changing context and to align more strongly with the enterprise vision.

Direction represents the management-services providing oversight of the direction and operation of the unit. In turn, these services are split into three distinct categories:

• policy, purpose and identity: long-term view to ‘develop the business’ for the unit [VSM ‘system-5’]
• strategy and context (‘outside/future’): near-future view to ‘change the business’ for the unit [VSM ‘system-4’]
• direction and tactics (‘inside/now’): immediate focus to ‘run the business’ for the unit [VSM ‘system-3’]

Within the nine-cell Enterprise Canvas frame, these connect most strongly with the Value-Management cell and, from there, to Value-Outlay and Value-Return. There’s usually only one of set of these services attached to each ‘delivery-service’ unit [VSM ‘system-1’], though one of these will often be shared across and guide many sibling-units (as in a classic organisational-hierarchy).

Coordination represents the coordination-services [VSM ‘system-2’] that link units together to create webs of cross-functional processes as required. As with the ‘direction’ services, these can be split into three distinct categories:

• develop the business: coordinate portfolios of longer-term change across units – also provides cross-functional bridge between direction’s ‘policy purpose and identity’ and ‘strategy and context’
• change the business: cross-functional coordination of change-projects – also provides cross-functional bridge between direction’s ‘strategy and context’ and ‘direction and tactics’
• run the business: cross-functional coordination of run-time processes – also provides cross-functional bridge between direction’s ‘direction and tactics’ and the unit’s own processes and interfaces

Within the nine-cell Canvas frame, these connect most strongly with Value-Creation and the ‘supply-chain’ interfaces – Supplier-Channels and Customer-Channels. There’s often only one organisation-wide ‘develop the business’ strategy-coordination service, though a variable number of ‘change the business’ services, dependent on the organisation’s portfolio/project-management mix. There will be a large number of ‘run the business’ links, often forming a complete ‘shadow network’ that is almost invisible to the standard hierarchy.

Validation represents the broad range of ‘support-services’ that guide the organisation towards ever-stronger alignment with the enterprise vision and values. [In VSM this is ‘system-3*’, although in the original it only addresses financial and/or operational audit.] These services need to touch every part of the organisation, without exception, ultimately as part of the background ethos, culture and collective habits – hence the alternate label of ‘pervasive-services’. Once again, these too can be split into three distinct categories:

• develop awareness: advertise and evangelise to create awareness of the importance of the respective values and their practical implications (principles etc)
• develop capability: educate in practices and metrics to implement and monitor compliance to the enterprise-values via their derived principles etc
• verify and audit: review records and lessons-learned to assure compliance to the values

Within the nine-cell Canvas frame, these connect most strongly with the Value-Proposition cell and, from there, the ‘relations’ cells – Supplier-Relations and Customer-Relations. In principle, there should be one matched set of these services, organisation-wide, for each key value of the enterprise (e.g. safety, security, quality, innovation, knowledge-sharing etc) – although the whole point of these services is that they reaffirm that responsibility for the respective value is ultimately everyone’s responsibility. The full set of services needed will be different for every enterprise, aligning with the different needs and different values of the respective enterprise. Note that for some values such as financial probity or occupational health and safety, various laws or functional constraints may mandate that the ‘verify and audit’ services should or must be kept separate from the respective ‘develop awareness’ and ‘develop capability’ services.

(For more detail on all of these guidance-services, and the inter-relationships between them, see my book The Service-Oriented Enterprise: enterprise-architecture and viable services.)

Each of these services has their own flows that pass between them and the service in focus in the Enterprise Canvas – which, once again, is easiest to show of the diagrams with a key-character symbol that matches the respective VSM shape (square for ‘direction’, downward- or upward-pointing triangle for ‘validation’ or ‘coordination’ respectively).

So we can now put all of this together, into a single diagram – the full Enterprise Canvas, complete with all of its flows and external relationships:

Which, as one slightly unkind colleague pointed out, does bear an unfortunate resemblance to a Lost In Space-style Robbie the Robot… oh well… If in doubt – or in fear of mockery – you can always trim it back to just the flows:

Which I suppose could be said to look like some kind of beetle… also ‘oh well’… Never mind, you could just use the standard nine-cell frame, without the flows:

Or, in extremis, the minimalist back-of-the-napkin version – which you could also use to play noughts-and-crosses (tic-tac-toe) if you wish: 🙂

So, that’s it: the Enterprise Canvas – so-called because you can use it to model any type of services, at any level, anywhere in the enterprise.

And I did promise, way back in that light-hearted introduction, that this would be:

One map to rule them all, one map to find them
One map to bring them all and with mad humour bind them

Not quite sure now about the ‘with mad humour’ bit, but the remainder certainly is still true – and we’ll start to look at how that works in the next part of this series.