It's the new year as I write this. Have you noticed that there is a period of about a week or two before and after the New Year that

from the rest of the year? Perhaps there’s a difference in the rate of business, your social calendar, the number of “top ten of 2022” lists. Perhaps your rate of cake consumption ramps up leading to the new year, and then drops off drastically after.

Outside of that 2-week “layer” on either side of the year “boundary”, the years actually look very similar. Business as usual, as they say.

This week we’re going to talk about boundaries, and make some observations that help us develop strategies for designing, analysing and troubleshooting complex systems.

Take the ocean, for example. Most of the action happens where the water meets something else: at the shore, at the surface, on the coral reefs, or on the ocean floor. In comparison, the vast volume of ocean has relatively little going on save a few creatures moving from one boundary to the next.

At each boundary there are is an area rich in activity surrounding it - in the study of surface phenomena this is called the

.

Looking at complex systems within a production facility or laboratory, we can also identify various boundaries having a similar aggregation of effects. These occur 1) at the boundaries between the system and the wider environment; and 2) around the interfaces

of the system.

By definition all communication between two components (and eventually between the system and the outside world) must go through one of these boundaries. It’s at these boundaries where we have to make assumptions about the validity of inputs and outputs. They are also the place where components interface with the more variable (less predictable) actors in the system: for example humans and/or the physical environment.

I find this line of thinking helps when

testing parts of a system for auditing, testing, troubleshooting or to simplify how several systems could be combined. This teaches us to focus on the most active interfaces between components rather than to worry about the internals of the system. In doing this we can:

By looking at the various interfaces it helps us to identify where best to draw the lines of our boxes, and maybe consider some variations you may not have otherwise. By looking the actors “aggregating” at the interfaces, we can see more than just the obvious inputs and outputs.

Let’s say we have a multi-component computerized system that controls an instrument and syncs data to a network LIMS. Where do we focus our validation testing? Where would you focus an audit of that system? When troubleshooting, where are problems most likely to be?

We first start with the boundaries between components, and look at what aggregates there.

Of course, these days the software interface is the most natural place to start since it’s where the operators, administrators and QA do most of their interaction with the system. This is also likely to be the first place we’ll see indications of a problem, and also the easiest place to start testing.

The direct inputs here would be things like configuration, data input, GUI. We’d also interact with the outputs of the system here, such as reading data, system status and audit trails.

Looking more carefully, we might find other actors “aggregating” at this interface that need to be considered. For example:

The software-human interface is not the only place where the system interacts with the world around it.

Looking at the interface between the samples and the system we might concern ourselves with things like reagents and other consumables and the sample preparation procedures and forms. We may also want to consider the autosampler, QC plates, cuvette and/or glassware.

At the interface between the local system and the network we find everything influencing data transfer and quality - things like network performance, availability, data format requirements and any translation between the systems.

There are also the interfaces between the system and the facility’s procedures and processes - these often have indirect influences on the system - such as other SOPS, operator training programs, QC and QA programs, maintenance programs, service availability agreements, etc.

We use these boundaries to draw boxes around parts of the system, so we don’t need to ensure every chip, diode and resistor in the instrument is working correctly before we use it. Assuming we’ve chosen an adequate supplier of the system, we can usually assume things are working as they should, and if they weren’t we’d see it in the interface.

How about the other hardware interfaces? For example between the instrument, mouse or monitor and the computer? We tend to overlook these because, well, they tend to be tested, either explicitly or implicitly, at installation and then again whenever the system is used.

That doesn’t mean that we’re never going to have bugs or errors somewhere within the boxes that we’ve drawn around the various system components - sometimes parts wear out, sometimes there are bugs that only show up when certain rare conditions are met.

This is the beauty of boundaries: if we’re paying attention to what’s going on at the interfaces between the system components and what we care about, then any errors that affect us will show probably up at one or more of those interfaces. Which interface(s) the problem shows up at will also help us to isolate where the problem is.

In complex systems, most of the interesting stuff can be observed at the edges. When we're trying to deal with complex, automated, multi-component instruments and production processes, we can use this fact to identify the places to focus our attention. We also need to be aware of other actors at or near those boundaries that may influence or have side-effects.

This allows us to draw boxes around the components of our systems of interest that help us focus on the areas of behaviour we need to audit, test or analyse.

Until next time,

– Brendan