I built an electronic health record and along the way learnt a lot about how to think about the importance of medical records and data in my day-to-day work as a practising clinician, manager and researcher.

At the end of that talk (and post), I touched on the importance of building capability : in data and the software that use those data - to deliver the outcomes we want in health and care. But what does that mean? What are the capabilities that we need to build, specifically?

I would argue:

our capabilities to record, view, manipulate and infer from meaningful data - for direct care, for managing our services and for research.

depend upon

our capabilities to continually deliver safe, sustainable and secure software at pace.

and we can look to the characteristics of the highest-performing technology teams to understand that these depend upon:

small, empowered, cross-functional (multi-disciplinary) teams
appropriate modularisation, with well-defined contractual (standards-based) interfaces between those modules
fast feedback via automated testing and telemetry, monitoring and logging
fast feedback from users with iterative, agile working

and understand, therefore, there is:

mutual dependency between architecture, governance and standards

because our capabilities are determined by our teams and how they can work effectively, and that means building an architecture that breaks down our problems into solvable chunks, making sure that governance is streamlined and effective so that there are clear lines of responsibility and defining the interactions between teams and the products for which they are responsible via open published standards as one part of the contractual obligations between those teams and products.

Building products delivering outcomes : “Choose team-first boundaries”

Truly, our architecture and governance are mutually-dependent with technical standards as an integral part of the wider contracts between our modules and consequently, between our teams.

It makes little sense to govern programmes of work without respecting architectural boundaries; indeed, I would argue that many of the issues facing health and care services in Wales are as a result of ignoring this issue - such as thinking that it is appropriate to govern projects relating to patients and their interactions with services separately to projects relating to professionals, when in fact both programmes of work share many core building blocks, such as citizen identity.

So instead need to recognise the importance of constructing empowered teams to help us solve the problems we face and organise those teams into specific programmes of work.

The mantra must surely be:

long-lived products within dynamic flexible programmes,

“Flow is difficult to achieve when each team depends on a complicated web of interactions with many other teams. For a fast flow of change to software systems, we need to remove hand-offs and align most teams to the main streams of change within the organization. However, many organizations experience huge problems with the responsibility boundaries assigned to teams. Typically, little thought is given to the viability of the boundaries for teams, resulting in a lack of ownership, disengagement, and a glacially slow rate of delivery.”

Skelton, Matthew. Team Topologies (Kindle Locations 2147-2151). IT Revolution Press. Kindle Edition.

So how do we find the fracture planes within our truly complex and heterogeneous systems?

“A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts. This splitting of software is particularly useful with monolithic software. The word monolith itself comes from Greek, meaning “single stone.” Traditional stonemasons hit stones at particular angles to split the rocks in clean segments, taking advantage of their natural fracture planes. We can look for similar fracture planes in software to find the natural split points that lead to software boundaries.”

Skelton, Matthew. Team Topologies (Kindle Locations 2226-2227). IT Revolution Press. Kindle Edition.

Too often, software architecture and system design occurs as a consequence of organisational or management structures, rather than stepping back and truly understanding the problem domain and how to carve it up into manageable chunks. You need to understand Conway’s Law, and the reverse Conway’s manoevre - and place the patient foremost in the design and architecture of your systems.

Mark

This post was originally written in November 2019.