A system is a point of view – natural for a poet, yet terrifying for a scientist.
Gerald Weinberg, An Introduction to General Systems Thinking, page 52.
Up until this point, I haven’t really addressed the idea of “a system” directly, but systems are implicit in all of these discussions. A “system” is the thing that is broken; it is the thing that we are trying to figure out. I’ve written about mental models – those are models of a system. So it is probably past time to talk about the idea of a system in a bit more depth.
Weinberg defined a system as a point of view, and went on to describe a system as a way of looking at the world. This turns out to be a useful definition for a troublehacker. It can be tempting to define the system as an instance of an running application, but if a system is a point of view, then there are as many systems as there are points of view. The application is not one thing; it can be many things depending on what point of view we adopt. In fact, Box’s models and Weinberg’s systems have a lot in common.
Here’s a model to consider: A system is a collection of hardware and software components around which we can reasonably draw a boundary.
The act of drawing a boundary is an expression of a point of view. The things inside the boundary are important to this particular viewpoint. What’s outside (the environment) is less important. Still, things come into the system from the environment (the inputs) and leave the system (the outputs), so we shouldn’t ignore the fact that there is something outside the system.
In this model, the system contains components which interact to deliver the functionality of the system. Our point of view will influence which components we include. If you’ve ever seen architecture diagrams (like these examples), you’ve seen this in practice. The components selected for inclusion in an architecture diagram are reflecting a point of view – that of the system architect. Things that are important to the architect’s viewpoint are included in the diagram, and what’s not important is left out. And there is always something left out – no architecture diagram can ever completely capture the complexity of a deployed software system!
You can also think about the components as systems in their own right, which could be expanded into a different collection of components with their own interactions.
This model of a system leads to a number of useful questions we can ask:
- Do the components, when taken together, form a functional whole?
- Do component interactions cause undesirable side effects?
- Is the system resilient to changes in the environment?
- Is the system stable over a wide range of inputs?
- For any given set of inputs, does the system generate the expected set of outputs?
- Does the system adversely impact the environment?
- What are the properties of the system (like performance, reliability, and so on)?
- How does the behavior of a component impact the overall system behavior?
The answers to these questions would form the basis for a pretty good system test plan, actually. And the questions are equally helpful in thinking about the ways in which a system might be broken, which makes them pretty handy for troublehacking as well!
I’ll explore some of these questions in more detail in future posts.