Thanks to Cory Watson for reminding me of this one. Also, if your a community member, keep an eye out of next weeks office hours session! (If you’re not a member, you can join here)
This is a paper by Erik Hollnagel. In it he talks about the various types of barriers, how they can be used to affect accidents, and how to analyze them as part of a system.
On the surface it might seem strange to talk about this given that these are very much physical things, and software is very much not. But if the increasing discussion of guardrails that I’ve been hearing especially lately, I think its a useful concept.
Thinking about the different ways that barriers are presented to users can help us determine where similar things exist in our software, and if they’re a good fit for what we’re trying to achieve.
Types of barriers
Hollnagel tell us there are number of ways that we could classify or categorize barriers, but only the “barrier nature” has enough detail or variety to be useful for “extensive classification”
Note that I’ve updated some of the language here from some of Hollnagel’s later work on the subject (which I’ll cover in a future analysis).
There are 4 types of barriers:
Material/Physical
These keep something from happening or being accessible or keep some effect from spreading. Examples are walls, fences, and buildings. These are real, actual, physical things. Note that they may not prevent whatever they’re designed to prevent in all cases, but will at least slow it down in some way.
Functional
These are also called active or dynamic barriers. These “work by impeding the action to be carried out, for instance by establishing a logical or temporal interlock.”
Because these barriers work by setting up some sort of condition that must occur before something else can happen, they are not always visible, though there’s usually something to show the user its there.
Examples of this type of barrier include locks, both of the physical key kind and the digital password kind.
Symbolic
These barriers “require an act of interpretation in order to achieve their purpose.” This means that a human must respond in some way to the barrier.
In contrast to a functional barrier that creates some sort of pre-condition, “a symbolic barrier indicates a limitation on performance that may be disregarded or neglected”.
Examples of symbolic barriers are reflecters that indicate teh edge of a roadway or any sort of audible alarm. Things like information, whether it be warning signs or interface design also fall into this category.
Immaterial/Incorporeal
This category can be a bit confusing, especially since symbolic barriers may not have material, but this category refers to things that require the user to have some sort of knowledge. If they don’t, the barrier is in effective.
These include things like rules or guidelines. They may physically exist in a book, but their usage as barrier relies on the user knowing about them.
We can think of these sorts of barriers as being the barriers imposed by the organization, they are things that do not exist physically, functionally, or symbolically in the system.
Classifying barriers
What category a barrier falls into isn’t always clear. One physical object can have multiple barrier types.
Hollnagel gives an example of a door. The door itself is a physical barrier. But it may also have a lock, which is a functional barrier. It could also have some sort of warning sign on it, which would be a symbolic barrier.
It’s more common than some object provides multiple barrier functions that it is to find objects that just provide one.
For example, procedures. Instructions are not themselves barriers, but they can contain warnings and “conditional actions”.
After all this Holnagel says that usefully categorizing barriers requires two different approaches, one to “accident analysis” and one for “system design”.
Most of the time, known barriers are looked for in risk analysis. This is similar to how latent failure conditions might be examined. But risk analysis is not a complete accident analysis method.
System analysis
We can keep these ideas in mind as we analyze our systems. Perhaps in a post-incident review we notice that only immaterial barriers existed. That doesn’t necessarily mean that adding a barrier is always the right thing to do, each time we add a barrier there is some amount of work that it adds, either to care for it, train for it, etc…
System design tends to focus on making sure “the system functions as specified.”
This is, of course, important, but it’s also important to look at how the system might fail.
This is very similar to the points made in Role of Software in Spacecraft Accidents about allowing negative conditions in specs. In specifying what the system must not do. We also need to understand how the barrier itself might fail.
Takeaways
- Often we here about “guardrails” in software, especially in SRE type contexts lately. Its useful to understand what sorts of barriers can exist in our system and what they can accomplish.
- The 4 types of barriers are: Material, Functional, Symbolic, and Immaterial.
- Material barriers are things like a wall or a fence.
- Functional barriers are things like a lock in the physical or digital sense.
- A symbolic barrier is something that must be interpreted like an alarm.
- An Immaterial barrier requires the user to have some knowledge and includes things like rules and policies.
- Adding barriers isn’t always the right answer as each bariary added changes the work in some way and has some cost to maintain it.
Subscribe to Resilience Roundup
Subscribe to the newsletter.