Services and Enterprise Canvas review – 3B: Coordination

What is a service-oriented architecture – particularly at a whole-of-enterprise scope? How do we describe the relationships between a service and those that coordinate its actions with others’? What are those other ‘coordination-services’? And what happens within those service-interactions?

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

1. Core: what a service-oriented architecture is and does
2. Supplier and customer: modelling inbound and outbound service-relationships
3. Guidance-services: keeping the service on-track to need and purpose
   • 3A: Direction
   • 3B: Coordination
   • 3C: Validation
   • 3D: Investors and beneficiaries
4. Layers: how we partition service-descriptions
5. Service-content: looking inside the service ‘black-box’
6. Exchanges: what passes between services, and why

(This post may need to be read on its own, so I’d best give the same introduction here as for the other sub-parts in this section.)

In the introduction to this part of the series, we saw how each service needs support from a variety of other services, to guide and validate its actions, and to coordinate its actions with other services, and its changes over time. We can summarise these relationships visually in the standard Enterprise Canvas model:

That cluster of services in the ‘guidance services’ block – the downward-triangle, the square and the upward-triangle – as shown above the main ‘horizontal’ value-flow, is based on the Viable System Model (VSM), which we could simplify visually as follows:

We can simplify this down again into four clusters of ‘systems’ and their service-relationships:

• direction and ‘management’ in general – systems-3 / 4 / 5 (square-symbol)
• coordination and change – system-2 (upward-triangle)
• validation and qualitative concerns – system-3* and extensions (downward-triangle)
• service-delivery – system-1 (circle)

The ‘system-1’ or ‘delivery-service’ is what we’d typically think of as ‘the service’ – the part that deals with the main ‘horizontal’ value-flow, the direct interactions with the service’s suppliers and customers, as described in Part 2 of this series. The other clusters of support-services tend not to be embedded within ‘the service’ itself, but are more linked-in via paths of interaction that are not part of the main value-flow. We could summarise this as follows:

Which leads us to the coordination-services – those support-services that assist in various types of coordination between services. In VSM, the respective system-2 has a single role, maintaining the balance and process-choreography between a cluster of system-1 delivery-services associated with a single system-3/4/5 management-services grouping; but for a service-oriented architecture we  need to extend the coordination-roles quite a lot, as we’ll see in just a moment.

Notice from those two diagrams above that the coordination-services are kind of ‘sideways-on’ to the management-services – related to them, and with them, but not part of them. That distinction is crucial, and failure to understand why it’s so crucial is a common cause of problem in mainstream management-models. In Taylorism, for example, if the distinct existence of these coordination-services is acknowledged at all, they’re assumed to be part of management’s role and remit: but in practice they cannot – in fact must not – be subsumed into management, precisely because they assist in managing what needs to happen between things rather than within them.

On the Enterprise Canvas diagram, we show this as a single upward-triangle, but in practice it’s made up of three quite distinct functions or service-types:

• coordinate ‘develop the business’ (bridge between VSM system-5 and system-4)
• coordinate ‘change the business’ (bridge between VSM system-4 and system-3)
• coordinate ‘run the business’ (bridge between VSM system-3 and system-1, and between system-1s)

We can summarise in visual form the relations between these services and the management-services and delivery-services as follows:

Yes, I do know that there are lot of lines in that diagram – but it’s not as tangled as it looks, honest!

First, remember that all of this is recursive and fractal: that’s indicated by the crimson dotted-lines coming upward from each of the coordination-service types, connecting to their counterparts in the level ‘upward’ (and, by inference, to the matching coordination-services in the next level ‘down’).

Next, although the coordination-services are of different types, they still also need to coordinate with each other. That’s the salmon-coloured lines that link between them.

For the rest of the lines, it’s simplest to describe the coordination-types one at a time.

At the big-picture level we have coordination of ‘develop the business’ – the kind of work typically done by a portfolio-management group (PMG), attached to the strategy-team. In effect, this connects to the link between policy and strategy (upper blue-coloured line), and assesses, compares, contrasts, synergises all the various change-proposals from the strategy-team in terms of their impact to the organisation and enterprise as the whole. On occasion it may also need to dip down into the detail of individual services – as indicated by the dashed mauve-coloured line – in order to test out ideas and to consider new or alternate affordances for existing capabilities within those services.

As indicated by the rightward black line here, on the diagram above, this also connects across to other equivalent ‘develop the business’ coordination-services attached to other services and service-clusters, again in order to assist in coordination across an even-broader whole. This all might seem a bit abstract, but a real-world example of this would be in standards-development or design for whole-of-context process-alignment, for sharing and coordination of change and/or operation across a consortium, throughout a supply-chain or value-net, or across an entire industry.

Next, there are coordination of ‘change the business’ services – the kind of work typically done by a project-management office (PMO) or individual project-managers. In effect, this connects to the link between strategy and direction (mid blue-coloured line), and derives requirements for change, and, with those services, tests and assesses strategic and tactical impacts of individual proposed changes. On occasion it may need to dip down into the detail of individual services – as indicated by the other dashed mauve-coloured line – both to test out implementation-ideas and also to coordinate the implementation of changes into live business-services.

As indicated by the respective rightward black line, this also connects across to other equivalent ‘change the business’ coordination-services attached to other services and service-clusters, again to assist in coordination of design and implementation of business-change, where this occurs between service-clusters or broader silos. In other words, this would be the usual cross-domain or cross-functional work of a project-office or the project-manager for a multi-disciplinary or multi-stakeholder project.

Finally, there are coordination of ‘run the business’ services – literally, run-time coordination. As per VSM system-2, part of the scope of this set of services is to manage run-time load-balancing and coordination between the individual services of the service-cluster associated with the respective direction-services (VSM system-3) – as indicated by the purple-coloured lines. between the ‘run the business’ coordination-services and the respective set of delivery-services (VSM system-1). To do this, it also needs to connect with – yet not as such be controlled by – the respective direction-service, and in some cases tap into the information-flows and other flows (lower blue-coloured lines) between that direction-service and the respective delivery-service.

The key role for this class of coordination-services, though, is about process-choreography and suchlike between services and service-clusters – the kind of functions provided by process-engines, business-rule engines or protocol managers right down at the code level, or service-brokers at every level from web-service right the way up to entire industries. On the core section of Enterprise Canvas, it’s what’s needed to create the connections, and coordination of exchanges, at each of the outward-facing interfaces – towards ‘supplier’ or ‘customer’ – for the main ‘horizontal’ value-flow. On the diagram, above that type of connection is indicated by the black line going rightward from the coordination-service, and, again, the purple lines connecting to the individual delivery-services.

In effect, what we’re describing here is a checklist of services that are needed for coordination of interactions between services. These functions are not covered by ‘management’ in the usual sense – or, more to the point, should not be subsumed into ‘management’.

Most of these coordination-services above represent extensions to the original system-2 function in the VSM. Some people might argue that all of this was already covered by system-2, at different levels of recursion, but in fact it isn’t the case:

• First, the VSM was primarily about flow of information, whereas these abstract coordination-services might be required in practice to support any type of flow or asset-exchange – physical, virtual, relational and/or aspirational. (These asset-types will be described in more depth in Parts 5 and 6 of this series.)
• Second, in the VSM system-2 connects only between system-1s and to system-3, but not to system-4 and system-5 – and the latter, as above, represent types of coordination that are fundamentally from merely recursing to ‘upward’ levels via links to system-3 alone.
• And third, VSM system-2 does not describe any form of ‘bridging the silos’: instead, everything passes ‘upward via system-3, in a form worryingly close to a Taylorist-type model.

Separately, though, there’s one other form of coordination that’s described in VSM but rarely appears in any of the diagrams: an ‘any-to-any’ connection described by Beer as an ‘algedonic‘ link. The term literally means ‘pain/pleasure’, and in essence is the kind of link typically reserved for emergency-use only, but is very necessary in many types of organisations and their architectures. A real-world example is a public email-address or ‘open-door’ policy for a CEO, which allows any employee – or even outsider – to contact the CEO direct about any key issue.

There’s more detail on all of this, together with in-depth analysis and checklists, in the post ‘Enterprise Canvas as service-viability checklist‘.

Anyway, to summarise:

• every service needs some means to manage coordination of change of itself as a whole – coordinate ‘develop the business‘
• every service needs some means to manage and coordinate the myriad of structural and design-level changes to itself, in response to internal and external need – coordinate ‘change the business’
• every service needs some means to manage and coordinate run-time links between its sibling-services in the same service-cluster, and with services in other service-clusters – coordinate ‘run the business’
• every service is likely to need an ‘any-to-any’ connection with other services, such as for emergency response, or notification of non-manageable exceptions

Almost by definition, a service will be unable to provide any of those coordination-functions directly within itself, because the whole point is that such coordination-services operate in the spaces between other services.

We’ll stop there for now, and move on to explore the ‘validation’-services in the next post in this series.

As usual, any comments or questions so far?