Let’s take a step towards understanding and building “Systems.”
My favorite Systems Engineering textbook defines a System as:
a set of components which are related by some form of interaction, and which act together to achieve some objective or purpose. Components are simply the individual parts, or elements, that collectively make up a system. Relationships are the cause-effect dependencies between components. The objective or purpose of a system is the desired state or outcome which the system is trying to achieve.
We construct systems to achieve certain objectives such as accepting and fulfilling an order for a customer, delivering an email, or sending people to the Moon and returning them safely.
When designing technology systems, we often first think about how to organize and assign responsibilities between components built from software, hardware, and the matter in-between. We think carefully about how information flows between components, the format it is in, and the volume of data and actions. These are important matters, but so far the humanity is missing from this view.
Oh the Humanity!
Where are the people? People use systems exist to complete their objectives. People build systems. People operate systems. Some systems even make people more efficient, scalable, or profitable. People should play a central role in the design, build, and operation of Systems, but they are often represented trivially or missing from the “System” diagram entirely. And so the point of the System is missed.
For example, designers and operators use customer feedback (input) to improve the system and change configurations to control it. These people are as much a part of the system as any software or hardware component. Certainly the actions that people take upon or within a system may have wide-ranging effects. The ‘root cause’ of a system failure is often ascribed to ‘human error,’ finally including people in the system, if only for indictment. But let me ask you…in the last system you designed, built, or operated, was it designed to provide information to people as clearly and carefully as it did the software components? Do people feel in control of that system?
We have invented many tools and concepts to incorporate people in our daily system design and operations work such as:
- User Stories: whose standard form is phrased: “As a <persona> I want to <take some action> so that I can <achieve some objective>
- Sequence Diagrams: a person often triggers the sequence of events or plays an important role in within the sequence such as a review step
- Isolation: separating instances of systems or components so that they operate independently of peers and are not impacted by a single failure or accident
- Constraints: engineered limits for components that enable engineers to specify the minimum and maximum ranges for a process to operate in and a control mechanism that pushes the component back to the safe range when a limit is hit
- Monitoring: dashboards and alerts inform people of the state of the system or conditions that may require action
- Runbooks: a scripted set of actions executed when a specific set of condition arises to contain or remediate an operational problem
These tools and others help us build systems to serve people safely. When we don’t design and build systems with people in mind, people usually bear a misplaced burden. Systems designed without people in mind often provide information that is hard to interpret, lack straightforward operational controls, require changes whose (worst) effects are difficult to anticipate, and demand people perform precise tasks routinely. Consequently, people feel:
- lack control over their environment and workload
- frustrated by unclear decision-making and incident response processes
- drained from the swings between monotonous and chaotic or intense situations
These are some of the most common causes of burnout (Mayo Clinic).
What’s Next
Not all systems are equal. Inputs, outputs, components, relationships, and dynamics vary widely between systems. However, there are frameworks that help us make sense of systems and classify them into several types. Each system type responds best to different tools and management tactics. We will introduce the Cynefin framework and illustrate how it works with a few examples. These examples will show you how you can manage each system type with confidence and even transform one system type into another. And with that, you will be a few steps closer to gaining System design super-powers.
#NoDrama
