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
• more sophisticated modules composing functionality provided by lower-level modules so managing complexity
• cohesive data and software services forming a platform (long-lived) used by lightweight applications (ephemeral)
• 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.