Services and Enterprise Canvas review – 3C: Validation

What is a service-oriented architecture – particularly at a whole-of-enterprise scope? How do we describe the relationships between a service and those support-services that keep it on-track to enterprise-purpose? What are those other ‘validation-services’? And what happens within those service-interactions?

This is another sub-section 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 validation-services – those support-services that keep the performance of services on-track to enterprise-values and enterprise-purpose. In VSM, the respective system-3* has a single very small role, as a random-audit of system-1 delivery-services to confirm that they really have done what they’ve said they’ve done. For a service-oriented architecture, though, we need to extend the validation-roles a lot, as we’ll see in just a moment.

Notice from those two diagrams above that the validation-services are kind of ‘sideways-on’ to the management-services – related to them, and with them, but not part of them. As with the coordination-services, that distinction is crucial, and failure to understand why it’s so crucial is a common cause of problems in mainstream management-models. In Taylorism, for example, if the distinct existence of these validation-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, not least because these types of validation must, by definition, apply to every service in the entire enterprise, and hence management itself must also be subject to their scrutiny.

To make sense of the validation-services, we first need to step back a bit.

Back in Parts 1 and 2, we talked about the enterprise-vision, how it’s always larger in scope than any of the organisations or stakeholders that connect to that vision, and how the vision and its values provide the ‘vertical’ cross-check for the value-proposition.

Once we’ve identified the vision or purpose, there are values that would inherently fall out of that vision or purpose, or are concomitant with it. From the values themselves, we derive principles – the first level at which values become actionable, in sensemaking and decision-making. And it’s only when we do make those values actionable, that any assertions about those values, and the purpose behind them, would gain any real-world meaning. It’s to make sure that those values are meaningful, and applied in real-world practice in everything the organisation does, that we need the validation-services.

In essence, each set of validation-services provides a means to guide continual-improvement towards a key ‘idea’ or assertion that expresses a value that’s of importance to the enterprise. Some common examples include:

• occupational health and safety – “people should be healthy and safe, at work, and because of work” (otherwise few people will risk working for and with us)
• quality – “the products and services we create and deliver should be fit-for-purpose, to the best of our ability” (otherwise few suppliers or, especially, customers, will want to deal with us)
• probity – “we should be honest in what we do and how we keep track of what we do” (otherwise the systems are likely to fail)
• fairness – “we should be fair in all our dealings with ourselves and others” (otherwise we create anticlient-type business-risks, within the organisation as well as beyond it)
• security – “we should take all appropriate care of all assets and asset-types for which we are responsible” (otherwise few people will trust us, and our systems are likely to fail)
• knowledge-sharing – “we should share information and help each other learn the requisite skills for the work” (otherwise, collectively and over time, we will forget what we know, and how to do what we do)

Enterprise-architecture itself is in some ways a type of validation-service, providing support for the core idea that “things work better when they work together, on purpose”.

The key point, and the reason why the validation-services are needed, is that enacting enterprise purpose and values is everyone’s responsibility. What the validation-services do is provide a means via which people can take on that personal-responsibility, and continually improve in how they act towards that value.

In practice – as can be seen in part via that list above – it’s often the case that each value and validation-service is supported by a relatively small core-team whose job it is to ‘hold the flag’ for the respective value. Also in practice, each of these core-teams would (or should) typically report direct to the organisation’s senior-executives – because in most cases, it’s that executive board who are formally liable and accountable for compliance to the respective laws, regulations and standards around that respective value.

Again, though, enaction of enterprise values is everyone’s responsibility – not just the responsibility of that core-team or the executive. Which is why the validation-services ultimately need to pervade through every element of the enterprise, all the way down to even the smallest action, the smallest asset, and each and every line of code. Which is why, in turn, we really need to pay attention to all of this in a service-oriented enterprise-architecture – because without it, the architecture will not succeed in real-world practice. Simple as that, really…

On the Enterprise Canvas diagram, we show all of this as a single downward-triangle. In practice, though, there will always be multiple validation-services – at least one for each enterprise-value – and each validation-service, in turn, is itself made up of, or implemented by, four quite distinct functions or service-types:

• develop awareness of the value and its importance to the enterprise (because if people aren’t aware of the value and its importance, nothing about it is going to happen)
• develop capability to enact at run-time the requirements of the value (because if people don’t know how to support the value, they probably won’t)
• enact at run-time the requirements of the value (because it’s the personal responsibility of each person or system to support the value within every action – and we can’t control this)
• verify compliance to the requirements of the value (because we need meaningful tests and metrics, to support a culture of continual-improvement)

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

Let’s go through each part of that diagram, step by step.

First, as with all of Enterprise Canvas, all of this is recursive and fractal. Every validation-service in effect appears in some form or other either within or linked to every service. We indicate this recursion with the mauve dotted-line linking ‘upwards’ to the next level of recursion above, and, by implication, also to the services ‘below’ in the recursion.

Next, validation-services are an expression of policy – as indicated by the upper solid black-line. Although VSM describes its only validation-service as system-3* – a kind of adjunct to system-3, the direction-services that we typically see as ‘middle-management’ – it would be more accurate to describe ‘system-3*’ overall as system-5*, an expression of policy, not ‘management’.

[This point perhaps cannot be hammered home enough, but it’s essential to understand that validation-services cannot and must not be subordinate to ‘management’. Instead, it is of absolute necessity that ‘management’ itself is and must be subordinate to the validation-services, as the expressions and guardians of enterprise-purpose. The enterprise-purpose and the shared-enterprise in general is the ‘sea’ within which the organisation operates: by definition, the organisation’s business-purpose is and must be subordinate to the shared-enterprise purpose, otherwise the shared-enterprise will and must eventually shut the organisation out as a player in that shared-enterprise of suppliers, customers, market and more. If we ever get this one wrong, and allow ‘management’ to place themselves or the organisation itself ‘above’ the shared-enterprise purpose – as is, unfortunately, pretty much built-in to Taylorism and similar business-concepts – then we would all but guarantee business-failure, especially over the medium to longer term. Not a good idea in an enterprise-architecture… – You Have Been Warned, etc?]

The validation-services do connect to the system-3 direction-services for two key concerns. One of these – as indicated by the dashed black-line – is purely practical: the validation-services must coordinate with the direction-services for the former to do their work with the respective delivery-services, without disrupting the overall work that is under the latter’s purview and direction. The other is that the validation-services share information with the direction-services – as indicated by the green dashed-line – to ‘close the loop’ on the delivery-services’ actions, and provide confirmation and audit of the reports passing between direction-services and delivery-services – as indicated by the solid blue-lines. (In essence this latter concern is the equivalent of the VSM system-3*.)

As indicated earlier above, the validation-services themselves have four main functions in relation to the delivery-services – three of which are indicated by the lower solid black-line:

— Develop awareness of the importance of the respective value, throughout the respective delivery-services. In essence, this is typically a communication-exercise, through information-sessions, posters, the core-team explicitly ‘holding the flag’ for the value, and, perhaps most effective, as expressed through anecdote and story, shared between individual people, and as expressed through personal-example by senior executives and other reference-points or role-models.

(See, for example, the Australian consultancy Anecdote for practical resources on how to do this type of ‘story-work’ within the organisational context.)

— Develop capability in how to enact the value in real-world practice. In essence, this consists of training and skills-development, plus the development of service-designs, service-interfaces, service-interaction designs and service-performance metrics and usages that implicitly support the requisite behaviours, and dissuade behaviours or choices that would go against the enterprise-values. This would be implemented in practice by any appropriate mix of in-house or external skills-development services – the classic ‘training-provider’ and suchlike.

We’ll also see these capabilities embedded implictly within sensemaking and decision-making tools: business-rules, work-instructions, guidelines, principles and suchlike – all of which we’ll often come across, or even develop ourselves, within an enterprise-architecture. Note that these will themselves often expand outward into hierarchies of their own: overall principles devolving to strategic principles to design principles to implementation principles to operational principles, and so on.

Also another key concern to note here is the need for guidance about the necessary trade-offs between the different enterprise-values – such as where security clashes with knowledge-sharing, for example.  Explanations of the ‘why‘ as much as the ‘how‘ become important in this, as well as anecdotes and stories to illustrate the relative priorities for the values in different contexts, and how different trade-offs do and don’t support the overall enterprise-intent.

— Verify compliance and performance in terms of required support for the respective value. (Note that this would, by definition, usually take place after the the requisite real-world run-time action, as described below: I’ve placed it here because uses much the same ‘external-guidance’ service-links as implied by the solid black-line connection on the diagram above.) In essence, this provides the closure for a PDCA-type continuous-improvement loop – specifically, the ‘Check’ phase, to assess performance. Although some parts of this may be automated, at some point there must always be a human check somewhere within the loop, because this is about improvement of performance against a human value.

In some cases these assessment and verification processes may take the form of a random-audit, as per VSM system-3*. Likewise, some of these assessments may or must be managed via services ‘external’ to the organisation itself – such as is typical with legally-mandated audit of financial-probity, for example – or where ‘external’ certification is a requirement for doing business within the respective market – as is typical for assessments of process-, product- or service-quality where they affect other partners in the supply-chain or value-web.

Parts of this information – yet in most cases not all of it – would be shared with the respective direction-services, as in the description of the dashed green-line connection earlier above. The ultimate reporting for these validation-services is to system-5 (‘purpose, identity and policy’), not to system-3 (‘direction’ and ‘management’).

Finally, there’s where the work for support of values actually happens – as indicated by the dotted orange-line connection and orange downward-triangles within the delivery-service:

— Enact at run-time the previously-learned training and skills in support of the respective value. In essence, this is just doing whatever is needed, to support health-and-safety, quality, probity, fairness, security, knowledge-sharing and whatever other values are important to the enterprise. This is also where the trade-offs and priorities learnt in ‘Develop capability’ need to be put into practice, varying as appropriate with the specifics of different contexts.

Having done the work, we then test how well we did – such as through an After Action Review, perhaps. (The ‘external’ validation-services may also have a role to play here, providing in-person facilitation for such reviews.) Note, though, that there’s usually no such thing as doing the work ‘right’ or ‘wrong’, in the classic linear ‘true/false’ sense: instead, it’s about doing better – or, we would intend, at least not doing it worse – in terms of the respective value.

One of the fundamentals of a values-based service-architecture is we never do reach final closure, final ‘perfection’: instead, however well we’ve done, we could always find some way to do it better, using priorities and meaningful metrics – rather than arbitrary ‘targets’ – to guide us. In this it’s fundamentally different from the often overly-simplistic (and often inherently-dysfunctional) goal-based or target-based ‘true/false’ tests around which so much of Taylorist-style ‘management’ is built. The two approaches might perhaps look similar from the outside, but in practice can be almost completely incompatible with each other, with ‘targets’ and suchlike inherently poisoning any attempts to do values-based improvement: so don’t mix them up!

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: for each enterprise-value:

• every service needs some means to know what is important to the enterprise as a whole (and not just to ‘management’…) – develop awareness of the respective value
• every service needs some means to know how to enact support for what is important to the enterprise as a whole – develop capability to enact the respective value
• every service needs to do whatever is necessary to support what is important to the enterprise as a whole – enact at run-time the requisite sensemaking, decision-making, and actions for the respective value
• every service needs to test and improve on its support for what is important to the enterprise as a whole – verify compliance and performance in relation to the respective value

Responsibility for support of the respective enterprise-values belongs to everyone in the enterprise, and hence must pervade every service within the enterprise. In practice, the presence of links with ‘external’ validation-services will help in much of this, and in some cases may be mandated in law or by custom – particularly for verification of performance in relation to those values.

We’ll stop there for now on the ‘guidance-services’ as a whole, and move on in the next post to explore the roles of and relations with investors and beneficiaries.

As usual, any comments or questions so far?