Pervasives and the VSM algedonic link

How do we keep on track to enterprise purpose? Perhaps more to the point, how can we know when we’re falling off-track, in time to recover?

To me, one of the keys here is the perhaps least-known part of the Viable System Model (VSM) – the algedonic link.

‘Algedonic’ literally means ‘of pain/pleasure’, and, as the Wikipedia entry for VSM explains:

Algedonic alerts … are alarms and rewards that escalate through the levels of recursion when actual performance fails or exceeds capability, typically after a timeout.

In classic VSM, examples might include a ‘stop-the-line’ signal on an assembly-line, or an error-message percolating up the code-hierarchy within a computer-application.

For various practical reasons, descriptions of algedonic signal-channels are often absent from standard VSM reference diagrams such as this one:

Which can lead to serious gaps in system-design, or even misinterpretation of VSM as just another Taylorist top-down hierarchy. But some versions of the VSM base diagram do illustrate algedonic links, such as in this example by Nick Green, showing ‘Algedonic Alerting’ as a black dotted-line link from VSM system-1 to systems-3, -4 and -5:

Even there, it somewhat misses the point, because algedonic signals won’t traverse solely to the ‘direction’ elements (systems-3, -4, -5) of the current recursion, but may be sourced anywhere, and likewise need to be vectored to and/or picked up anywhere. For example, if the ship is in danger, and the danger has been spotted only by the most junior-ranking crew-member, that message needs to go as quickly as possible to where it needs to go – not trickle slowly up and down the respective hierarchies.

Which, with a bit of exploration around this, kinda indicates that algedonic-signals may not only need to break the hierarchy, but may go not just upward but in any direction – up, down, sideways, round – and also may need to be:

• one-to-one – specialist emergency-message (“integrity-sensor signal lost in section A6”)
• many-to-one – collation-point for range of emergency-messages (“hull breach in section A6”)
• any-to-any – urgent info-request  (“does anyone know how to fix the hull-breach in section A6”)
• one-to-many – urgent action-request (“anyone near section A6, help with evacuation if you can”)
• one-to-all – immediate-action (“section A6 containment has failed, abandon ship!”)

Note that this often must bypass the hierarchy – especially if some aspect of the hierarchy itself is the source of the problem – as it is in insuperordination, for example. And in some contexts – such as a warship under fire, in that example above – the hierarchy itself may be structurally-unstable: locking all communications to a rigid hierarchy is a recipe for disaster if all of the decision-makers at the ‘top’ of the hierarchy-tree can be wiped out in a single blow.

Yet the hierarchy is (in principle at least) there for a good reason. In VSM, as per Agile, or Deming, we’d usually aim for a business-equivalent of the principle of subsidiarity: we want to resolve any decisions as close to the point of action as we possibly can, and only pass decisions elsewhere when we really need to do so. For the latter, though, we do need clear guidance as to when and why we need to pass information and decisions on to others, and know where to pass it to – and the hierarchy gives a clear structure for how and when to do this, with whom. It works well for most ‘normal’ decisions and information-flows (and coordination-signals along end-to-end ‘horizontal’ process-flows would account almost all of the rest – although oddly those horizontal paths don’t seem to get any mention at all in VSM). For the most part, it’s only for emergency-signals or any-to-any connections ‘in the heat of the battle’ that the hierarchy may become more of a hindrance than a help.

In many organisation, though, almost every decision is treated as an emergency – hence the phrase ‘fire-fighting’ and the like. In those contexts, it’s very easy for the algedonic links to become almost the only real communication-channel – and those links will get flooded pretty quickly unless there is some means to identify what really is an emergency, and what isn’t.

Which is where we can usefully extend VSM with some key concepts from Enterprise Canvas:

To illustrate this, we can strip Enterprise Canvas right back to its VSM-compatible core, using the same colours as in the first VSM diagram above, and with a more dimensional-type layout:

From that simplified core, the key that we need so as to make the algedonic links work is represented by the pale-blue downright-pointing triangle – the validation-services. In VSM terms, this is system-3*, ‘sporadic-audit’, but in Enterprise Canvas it’s much-expanded to cover all of the support for what I’ve described as pervasive needs: any qualitative concern that is ultimately the responsibility of everyone in the enterprise. These typically include themes such as product-quality, health-and-safety, security, financial-probity, environment, ethics and more.

(Architecturally, the respective list of these ‘pervasives’ and their relative priorities is derived from the vision and values of the overall shared-enterprise within which the organisation operates.)

Up to now, I’d described validation-services in terms of four distinct types of activities:

• 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)

Which – remembering that there’s one of these sets for each values-theme – we could summarise visually in Enterprise Canvas form as follows, with enaction at run-time happening within the service itself:

In effect, the pervasive-services are the means via which we keep on-track to enterprise-purpose, as indicated by the respective value-themes for that shared-enterprise.

Yet once we add the role of the algedonic-links into the picture, it seems clear (to me, at least!) that in essence the algedonic links are part of the pervasive-services. That relationship with the pervasives gives the reason why a whistleblower should blow the whistle, why a nurse should speak up when the boss is wrong, why a junior rating should signal the bridge to warn that the ship is in danger – and how to to identify what is wrong, too. The drive to use algedonic links is often experienced as an almost visceral or ‘antibody-like‘ response to values-concerns – and no matter how disruptive such a response may be to those ‘in charge’ or whatever, it’s a response that is crucial to the viability of the enterprise.

(Together with that point about subsidiarity, this also indicates why assembly-line workers – and not the management – need to be in charge of the stop-signal for the respective assembly-line. Managers’ bonuses may well depend on quantity, but from an enterprise-perspective, in terms of fitness-for-purpose and the like, it’s more usual that quality comes before quantity – whether the managers like it or not. US carmakers learnt that lesson the hard way…)

If we’re to keep the enterprise on-track to purpose, we need to make it clear that responding to values-concerns is not a choice but an explicit responsibility – and one that applies to everyone.

To make it work, we also need to provide clear means via which people can enact those responsibilities – which might consist of channels as simple as a published email-address, a social-media account or hashtag, or a plain ordinary open door. And we need to make it safe for people to use these channels – a point that is too often forgotten…

The other side of this is that the values-themes themselves indicate what should and should not go through those channels. They’re priority-channels: they need to be used and respected as such, by everyone. Again, though, safety is paramount, so if someone misuses an algedonic channel – including not using it as needed – then that in itself would be a kind of algedonic incident from which everyone can learn: a nice recursion of the same principles applied to itself.

Note too another crucial point that is too often missed: the pervasives are accountable to the entire shared-enterprise – and not solely to the organisation’s ‘the management’. The pervasives are enacted within the organisation as the respective validation-services, and interact with the organisation’s management and the like, but must not be regarded or treated as subject to ‘the management’. In fact it’s more the other way round: via the pervasives, the management – the direction-services, or in VSM terms the organisation’s systems-3/-4/-5 – holds itself accountable to the shared-enterprise – as one or more VSM-recursions ‘above’ the organisation. The detail of how all of this needs to work to practice is in the post ‘Services and Enterprise Canvas review – 3C: Validation‘, but a quick visual summary is as follows, where the purple-line represents the foundational link with the overall shared-enterprise:

We also need to remember that ‘pain’ is literally only one half of ‘algedonic’: the other is ‘pleasure’. The crucial point here is that, to the shared-enterprise, ‘pleasure’ is just as important as ‘pain’: whilst pain indicates that we are, or are at risk of, going off-track, pleasure indicates that we are on-track with the enterprise-purpose. In providing support for whistleblowers, we also need to support our other whistleblowers – the ones who blow the whistle for joy, rather than in warning.

The exact same principles as above apply for this need too: the algedonic-links provide channels for any appropriate variation of any-to-any communication about pleasure in the shared-enterprise sense, success, something-to-celebrate – and, again, channels that should be used appropriately, in accordance with the respective values-themes.

It’s all straightforward enough to identify, define, design, build and operate: we just need to do it, that’s all.

Practical implications for enterprise-architects

To identify and define the requirements for algedonic-links, some practical questions:

• What are the vision and values of the respective shared-enterprise(s) within which the organisation operates?
• What needs arise for pervasive validation-services within and beyond the organisation, to support alignment with and compliance to each of those values?
• What algedonic-signals – ‘pain’ and/or ‘pleasure’ – would, could or might arise in relation to alignment with or compliance to those values?
• From where and whom would those signals be sourced? – both within and beyond the organisation?
• What variants of ‘any-to-any’ communication-channels would you need to support, for each of those algedonic-signals?
• How would you ensure that each message is appropriately vectored to the relevant recipients?
• How would you ensure that appropriate action is taken on each algedonic-message?
• How would you ensure that appropriate response is vectored back to the initial source and to other ‘interested parties’, within an appropriate timescale?
• Over the somewhat-longer term, how would you ensure that appropriate lessons-learned and systemic-change (if required) arise from each algedonic-message?

We also must not ignore or underestimate the politics of this:

• Who, both within and beyond the organisation, has actual or potential vested-interest against the occurrence or receipt of algedonic-signals?
• What fears underlie each of those vested-interests? – for example:
  • fear of disruption
  • fear of ‘loss of control’
  • fear of loss of reputation
  • fear of exposure
  • fear of loss of privilege, profit or suchlike from identification and dismantling of hidden disservices that benefit that stakeholder at the expense of others in the shared-enterprise
• What will you need to do to mitigate those fears and the vested-interests that arise from them?

The politics aspect is by far the hardest part of this, but we do have to deal with it – not least because those feelings are fundamental facts for this type of context. For some practical guidance on how to do that part of the work, see the post ‘Professionalism, waivers and the hard questions‘.

Let’s leave it at that for now, anyway – over to you for questions or comments, if you wish?