More on backbone and edge

How do we build the right support in our architectures for the balance between certainty and uncertainty? How do we decide what needs to go into backbone, edge, or somewhere in between?

This is a follow-on to the themes in various recent posts such as ‘Migrating from edge to backbone‘ and the slidedeck for my IASA UK Summit presentation ‘Backbone and edge – architecting the balance between continuity and change‘. It’s actually a collation of the notes for that slidedeck, including a swathe of themes and ideas that didn’t make it into the slidedeck itself.

First, an overview using the standard ‘problem; situation; complication; resolution’ structure:

— problem: stability versus change; sameness versus uniqueness.

— situation: Waterfall (‘control’) versus Agile (‘anarchy’).

— complication: one-model-fits-all doesn’t work

• forced-sameness can scale, is fast, work with low skills, but can’t cope with variation or fast change
• forced-difference can’t scale, is slow, requires high-skill

— resolution: apply appropriate model to each context:

• first, identify ‘appropriate context’
• model: control (backbone) <-> complexity (domain) <-> contact (edge)
• governance:
  • backbone: Waterfall-type governance
  • domain: context-specific mix of Waterfall and Agile
  • edge: Agile-type governance
• difference of content: read-only (best in backbone) versus read-write (better in domain or edge)
• difference in context: sameness (backbone, domain) versus uniqueness (domain, edge)
• difference of context: pace-layering, variety-weather, turbulence in present and/or in futures)

Some practical guidelines:

— for sanity’s sake, use a service-oriented approach to architecture

— use a systems-thinking / design-thinking approach to assessment, modelling and design: fractal, self-similarity, ‘everything is connected’; also supports a ‘start anywhere’ principle

— suggest using the Enterprise Canvas concept-build (consistency from big-picture to fine-detail)

— apply filters to select appropriate ‘positioning’ for governance and design:

• high-dependency: implies backbone
• wicked-problems: implies domain and/or edge
• (un)certainty: certainty to backbone, fuzzy to domain, uniqueness to edge
• read-only (system-of-record)
• experimental: implies edge
• regulatory context: zero-tolerance implies backbone, flexibility-allowed implies domain

— governance themes:

• backbone: use Waterfall, keep uncertainty to minimum, focus on ‘fail-safe’
• domain: use complex-aware – e.g. make wicked-factors explicit, acknowledge continuous ‘re-solution’ rather than supposedly-permanent ‘solution’
• edge: use Agile, focus on ‘safe-fail’, design to learn

A brief note on pace-layering versus backbone-and-edge:

— backbone-and-edge is about:

• certainty versus uncertainty
• common (shared) versus unique
• stability versus instability

— pace-layering is about different rates of change

— pace-layering is a factor that impacts on decisions around backbone-and-edge, but is somewhat orthogonal to it

— also pace-layering will need to take variety-weather into account: variability of impact, variability of rates of change

Develop this a bit further with a medical example:

— on the one side, we need certainty about:

• it’s this person: this client, this agent/member-of-staff etc involved in these transactions
• it’s these actions: this prescription, this surgical-procedure, this record etc
• it’s this location: the patient lives at this address, is in this bed in this ward, the operation will take place in this surgical-theatre etc
• it’s these resources: these instruments, these consumables, this anaesthetics-cylinder etc

— on another side, we expect inherent uncertainty about specific or unique aspects of context:

• their own illness
• the day on which something might occur
• the weather on that day
• what they ate or drank or medications they took on that day before arrival
• the staff available on that day
• the equipment, medicines and other resources available in situ on that day
• triage and priority on that day
• sociopolitical interactions – prejudices, assumptions, religious beliefs, values etc of family, social milieu, social-workers, staff and others

— somewhere between, we have the messiness of social-complexity:

• family
• the ‘shoulds’ of politics, religion etc
• the often-politicised trade-offs of triage, priorities, case-management etc
• wicked-problems (often caused by over-certainty)

— for the ‘certainty’ side, we need to governance to assist in creating and maintaining that certainty

— for the ‘uncertainty’ side, we need governance to assist in maintaining value, and minimising failure-demand arising from misplaced over-certainty or ‘control’

— for the ‘complexity’ mid-range, often the emphasis will be more about before and after real-time, rather than at real-time (i.e. there’s little to no time for complexities at run-time)

Various useful comparisons (certainty on the left, uncertainty / uniqueness on the right):

• rates of change (pace-layering): slow <-> fast (don’t have time for Waterfall with fast pace of change)
• distant from action: any level of variety <-> at point of action: max 5-10 decisions
• platform provides certainty <-> affordance / use provides usefulness
• ‘true’ <-> ‘useful’
• remove complexity <-> work with complexity
• release <-> beta/alpha
• production <-> skunkworks

As I said at the start, this is just a set of notes, but hope it’s useful to someone, anyway.