Services and Enterprise Canvas review – 3: Guidance-services

What is a service-oriented architecture – particularly at a whole-of-enterprise scope? How do we describe the relationships between services that are not in the main value-flows? What are those other ‘support-services’? And what happens within those service-interactions?

This is the third in a six-part series on reviewing services and the Enterprise Canvas model-type:

Core: what a service-oriented architecture is and does
Supplier and customer: modelling inbound and outbound service-relationships
Guidance-services: keeping the service on-track to need and purpose
Layers: how we partition service-descriptions
Service-content: looking inside the service ‘black-box’
Exchanges: what passes between services, and why

In the previous post in this series, we saw how a service is ‘a means to an end’, that it usually sits at an intersection between ‘horizontal’ value-flow and ‘vertical’ intent, and that we need to assess not just the main transactions in that horizontal flow of value, but key interactions that need to take place before and after those transactions:

We also saw that we could usefully view a service in terms of its ‘supplier-facing’ (inbound) and ‘customer-facing’ (outbound) activities, as well as the activities that itself does to create, deliver and manage its own value to and in the shared-enterprise – giving us a kind of three-by-three matrix of activities within the service:

And we can describe the child-services in each of the cells in that three-by-three matrix in generic terms that would apply for services at every possible level and context:

It’s an abstraction, of course: in practice, we could – and probably would – partition up the ‘child-services’ in many other different ways, according to the modelling-need. And remember, too, that it’s recursive, that we need to think fractal, not linear: every one of those ‘child-services’ is also a service in its own right, with its own value-proposition, value-creation, value-governance, its own ‘suppliers’ and ‘customers’, its own exchanges with other services – and its own ‘child-services’, too, potentially all the way upward and downward to infinity.

Yet even in those simple abstract forms above, this ‘Enterprise Service Canvas’ provides enough of a visual-checklist to help us make sense of the service-transactions and interactions that take place in a service-delivery such as this:

Or this:

Or even – if perhaps with a bit of extra explanation – something like this:

Yet there’s much more to services than just those transaction-oriented descriptions. In part it’s to do with that ‘vertical’ crosslink that we described in the previous post, where services connected with each other via the value-proposition, which in turn provided a means for the respective services to find common-ground in the respective values and purpose. In part it’s about shared-purpose itself. But to look at this in more detail, we could usefully turn to the work of a cybernetician named Stafford Beer, and the Viable System Model that he and his colleagues developed from the 1970s onwards.

First, though, let’s run through a checklist of what might be needed for a viable service. In a ‘viable organism’ – and hence a ‘viable service’ – every system and subsystem has some means:

to do its tasks (a ‘doing system’)
to sense (and report on) its internal and external environment
to coordinate its activities with other systems
to remember (a repository of knowledge about its past)
to plan its activities (strategy and tactics, often with others)
to adapt to and, where possible, improve its environment

And in principle, at least, it will have a sense of its own purpose: at the least, in generic terms, every service exists to serve a need.

The ‘doing system’, and the links to and through a sense of purpose, are what we’ve already covered above: it’s the rest of that checklist that we need to explore here. Which is where we turn to the Viable System Model (VSM):

Which, at first glance, is all but completely impenetrable… – in part because it’s trying to cram all of the elements and their interactions, all of the recursion, and all of the relationships with ‘the outside world’, all into one diagram. To make full sense of it, you’ll need to read the book, such as Stafford Beer’s Brain of the Firm, or Patrick Hoverstadt’s The Fractal Organization.

For our purposes here, though, we can simplify it down to a kind of summary-checklist. In the VSM model, each system – or service, in our context – is made up, in some way, of a set of specialised sub-systems:

5 – identity / policy / purpose (green square, in the diagram above)
4 – ‘outside / future’ [inc. strategy] (yellow square)
3 – ‘inside / now’ [management] (red square)
3* – sporadic audit / review (pale-blue downward-triangle)
2 – coordination (mid-blue upward-triangle)
1 – operations (lilac circle)

These ‘systems’ interact with each other, to act on and with the external world – the amoebic blob shown to the left of the diagram. As with the ‘service canvas’ model we’ve been exploring, the Viable System Model is recursive: each layer contains the next, to whatever depth required – as indicated by the lilac-coloured square for the recursion of systems 3/4/5 next to each ‘operations’ circle, and the tiny repetitions of each type of system-symbol nested inside the circles or lilac-squares.

We can also link this, for example, to the needs of quality-management, because interactions between these sub-systems support improved processes and/or self-adaptation to a changing environment:

X – exception-management for short-term (1↔3, 1↔4)
C – corrective action (review of 3* / X↔3 / 4, also driver for P)
M – issue-tracking / issue-management (usually triggered by X, 2 and/or 3)
P – process-improvement (interaction up and down between any 1..↔..5)

We can then use these lists of ‘systems’ as filters to review, for example, a Capability Model or Business Model. Gaps would point to unrecorded functions, lost opportunities for improvement, and/or untraceable costs. That extended set of VSM ‘systems’ also provides a useful checklist to evaluate services:

5: what is the service’s purpose? who/what defines policy?
4: what is the current strategy? outside relationships? who defines these?
3: how are the service’s tasks defined, managed and monitored?
3*: what random checks / audits are required to verify service performance?
2: how is the service coordinated with other services?
1: what does the service do? how does it do it? how does it support its ‘downline’ child-services (if any)?
X: how does the service identify and resolve any run-time exceptions?
C: what corrective-action does the service undertake for causes of issues?
M: how does the service track and manage quality-issues and other issues?
P: how does the service monitor and manage improvement of its processes?

In VSM terms, all we’ve really dealt with so far is system-1 (the ‘doing’ of the service), and the topmost level of system-5 (overall identity and purpose for the service within its overall enterprise). For our services to be ‘viable’ – to work together, and to adapt proactively to change – then we really do need to review all of those other interactions as well.

In practice, and as illustrated by the VSM itself, most of those other ‘systems’ are not so much ‘built-in’ to the respective ‘doing-service’ – the system-1, the ‘transactional’ or ‘service-delivery’ part of the service that we’ve explored so far – but are more linked-in to that core delivery-service as providers of support-services or ‘guidance-services’. Note, though, that although each of the actual respective interactions themselves follow the same kind of pattern as for all other service-transactions, they’re not part of the main ‘horizontal’ value-flow – in fact they’re all sort-of orthogonal to it, as we might illustrate thus:

As in that diagram just above, we could cluster these guidance-services as follows:

direction – systems-3 / 4 / 5 (square-symbol)
coordination – system-2 (upward-triangle)
validation – system-3* and extensions (downward-triangle)

If we then use the VSM circle-symbol to represent the respective core delivery-service, as the system-1 to which all of those guidance-services relate, we could expand our previous sketch-summary of the service and its relationships as follows:

Yet there’s also another type of service-relationship that isn’t covered by VSM, or anything we’ve looked at so far, and that’s the relationships – if any – with investors and beneficiaries. (We need to look at those two stakeholder-groups separately, because they’re not necessarily the same people…) The respective links are similar to the usual ‘horizontal’ value-flow, but they’re different in that they kind of go the opposite way: an investor is like a supplier, but it puts into the service what a supplier would usually take out, and a beneficiary is like a customer, but it takes out what a customer would usually put in. We can describe these relationships visually on the sketch-summary as follows:

Which, when we put all of them together, gives us the ‘robot-chicken’ standard layout of Enterprise Canvas:

Note again, though, that – as indicated in those coloured regions in the diagram above – the interactions with the guidance-services, the main ‘horizontal’ value-flow, and the flows to and from investors and beneficiaries, are each of fundamentally different types: don’t mix them up! (If we do mix them up – as happens a lot in many mainstream business-models – we guarantee getting into serious trouble, without being able to describe how or why it’s happened: not a good idea…)

But this post is long enough already, so I’ll split the remainder of this part of the series into four sub-posts: