Direction and governance flows in Enterprise Canvas

This one’s a quick item of technical detail about service-modelling with Enterprise Canvas, as requested by Oliver Baier:

• OliverBaier: Enterprise Canvas: Does the XG flow go down to the next *lower* layer? If not, how does it relate to eg the XD flow?

The quick answer that I gave Oliver on Twitter was as follows:

• tetradian: Enterprise Canvas: XG does connect to next ‘lower’; XD in part includes XG but with broader scope. Will blog.

Hence, this post.

The labels ‘XD’ and ‘XG’ relate to flows between the service in focus (the one we’re mapping on an Enterprise Canvas frame) and, respectively, other services that provide ‘direction’-services (‘XD’ flows), and ‘child’-services that this service manages and governs (‘XG’ flows) – as seen on this version of the Enterprise Canvas summary-diagram:

This part of Enterprise Canvas draws strongly on Stafford Beer’s Viable System Model, which, in service-oriented terms, partitions service-relationships as follows:

• system-1: service-delivery – the service itself, the core service represented on the Enterprise Canvas – also encapsulating any ‘child’-services (coordinated by XG-flows) – and exchanges with other service-partners (indicated by XT-, XC- and XB-flows)
• system-2: coordination between services, both under the same governance (peers under the same service-hierarchy) and elsewhere in other parts of the service-hierarchy, or with service-partners (coordinated by XK-flows)
• system-3star: keeping all services on-track to enterprise vision and values (coordinated by XV-flows and exchanges)
• system-3: classic run-time ‘inside/now’ management-role, allocating resources and collating performance-information (coordinated by part of XD-flows)
• system-4: business-intelligence/change ‘outside/future’, to identify how the service needs to change to adapt to its context (coordinated by part of XD-flows)
• system-5: identity and purpose, establishing and maintaining the big-picture ‘why’ for the service (coordinated by part of XD-flows)

In the classic Taylorist view, system-5 remains the exclusive preserve of ‘the owners’, and everything else other than system-1 service-delivery is conflated into a hierarchy of system-3 ‘management’ The system-2, system-3star and system-4 services are all blurred together and merged into an expanded yet often ill-defined system-3; the XV and XK-flows are all merged into the XD-flows, or deemed not to exist at all. In effect, the XD- and XG flows are then regarded as conceptually identical, rolling downward through the management-hierarchy, which is partly embedded within yet also somehow separate from any aspect of service-delivery itself:

This does sort-of work if (but only if) we’re modelling a segment of a system or service where the flows consist solely of information, and where system-4, system-5 and even system-3star are in effect handled entirely ‘outside’ of that part of the system, with no direct connection with this service at all – such as can occur with IT-based automation, for example. In those cases, the respective XD- and XG-flows are essentially the same in structure, and can even be largely the same in their content, too.

Once we move outside of that narrow constraint, XD- and XG-flows can differ a lot:

• XG-flows consist primarily of virtual-assets (such as information about activity-goals and performance-criteria [going ‘down’] and performance-reports [coming ‘up’]) and sometimes also physical-assets (distribution of physical resources for service-activities and tasks)
• XD-flows will often also incorporate or leverage relational-assets (‘who’ – links between real people) and/or aspirational-assets (‘why’ – identity, purpose, commitment, motivation)

Crucially, XK and XV-flows here are not conflated into the XD or XG-flows:

• XK-flows primarily provide coordination between delivery-services, and hence often not ‘within’ immediate service-management or service-governance
• XV-flows link services to means to keep on-track to value, and in the case of audit to the respective value must be separate from immediate ‘management’ – often mandated as such by accreditation-schemes or even by law

In short:

• in Taylorism, the XD and XG-flows are regarded as essentially identical – an assumption that can render the system inherently fragile (insufficient to match the requisite-variety of the context), and potentially unable to adapt to changes in context
• more validly, in certain simple types of information-oriented automation, the XD and XG-flows may be similar or the same, if all system-4, system-5, system-2 change-coordination and system-3star values-management is handled ‘outside’ of the service itself
• in all other contexts, XG-flows represent a selected subset of XD-flows, sufficient only for immediate resource-management and performance-management of a related set of ‘child’-services, that themselves link into their own context-specific XD, XK and XV-flows, linking them directly to the ‘big-picture’ for direction, coordination and validation respectively

I hope that makes sense?