General System Theory is the field of study dedicated to understanding, analyzing, and manipulating complex systems. It provides an unparalleled toolset for explaining and discussing systems of all sizes and it is one of the most important and yet most unknown areas of study in software development. In this talk, I give an introduction to general systems thinking as it applies to software-driven systems and I use it as a framework to talk about my current work building a distributed system orchestration application.
2. @hallie_parry
About me
Salesforce - 7 years
LMTS - systems architect
CMU ’07 - BFA/CS
I do things that other people can’t or won’t do
All images and video used in this presentation are original works by Hallie Parry
3. @hallie_parry
Side note: art and cs
GST: system of art, system
of science, how do those
things relate
How do I use art?
studies, POCs
11. @hallie_parry
What is a system?
“A system is an interconnected set of elements
that is coherently organized in a way that achieves
something…a system must consist of three kinds of
things: elements, interconnections, and a
function or purpose.”
-Donella, Meadows. (2013-01-18). Thinking in
Systems: A Primer (Kindle Locations 327-329).
Chelsea Green Publishing. Kindle Edition.
12. @hallie_parry
What is a system? (cont'd)
elements
"What things make up the system?"
interconnections
"How do these things relate to each other?"
purpose
"What does the system do?"
13. @hallie_parry
What is General System
Theory?
“the interdisciplinary study of systems in general,
with the goal of elucidating principles that can be
applied to all types of systems at all nesting levels
in all fields of research.” -Wikipedia
14. @hallie_parry
But what is it really?
an abstraction strategy
a set of abstractions created to make sense of the
world around us
24. @hallie_parry
Case Study: Army of
Darkness
our self-configuring, self-deploying, self-monitoring
data center orchestration project
25. @hallie_parry
Wrap up
intent, audience, studies
things that make up a system: elements,
interconnections, purpose
signals and boundaries
agent-based systems
Army of Darkness
27. @hallie_parry
Further reading
“Thinking in Systems: a Primer” - Donella Meadows
“Signals and Boundaries: Building Blocks for
Complex Adaptive Systems” - John H. Holland
“An Introduction to General Systems Thinking” -
Gerald M. Weinberg
Editor's Notes
I’ve worked at Salesforce for 7 years. Currently, I architect systems. I build self-* systems: self-assembling, self-managing, self-constructing. Before that, I was at Carnegie Mellon. I have a Bachelor of Fine Arts with a double major in computer science.
Anyone who has talked to me for more than about five minutes can tell you I have a BFA. There are two reasons for this: first of all I’m very proud of it. Secondly, my art degree is invaluable to me. When I say I have a BFA in art and cs, everyone assumes that I do animation or design. I don’t. My concentration is drawing and painting. But I use art every single day at my job.
The full story of how I use my art background in my software job is a separate talk, but very quickly I’ll talk about three art concepts that make me a better developer.
I always consider my audience when I’m communicating and I’m ALWAYS communicating. Code, documentation, tech talks, blogs. My audience might be just me, or it might be just my teammate, or it might be a room full of people I’ve never met. I am constantly asking myself what my audience already knows, what they want to hear, and what I want them to understand.
If you go wander through the Legion of Honor, somewhere in their permanent collection you’ll find a small platform with tiny sculpted feet. These are studies made by Auguste Rodin (of “The Thinker” fame) because he wanted to understand feet better. I do similar things with software. I build projects because I want to understand things better. Not because I want a proof of concept or because I have some eventual feature that I want to build, but because a piece of technology or a strategy deserves my attention and understanding.
This, to me, is the most undervalued attribute of system theory. I first got into system theory when I was listening to a coworker talk about his current project. I was really impressed by the strategy he used to explain it because he sounded brilliant and it was clear he knew what he was talking about, and it was also clear that he understood the scope of his work in a way that I’d never seen. So I asked him to tell me what his secret was, and that’s how I got into GST.
The ability to explain your work intelligently is priceless and system theory provides an excellent set of strategies for doing just that. And so throughout this talk I’ll be harping on how this field of study is influencing how I talk about my work.
General system theory looks to identify common behaviors across unrelated systems and classify them according to these behaviors. This is a powerful tool because it means that by deriving behaviors about one system, you don’t have to rederive those same behaviors for any other systems in the same class. We’ll talk more about this later.
Fundamentally, GST is a way of reasoning about systems. This is important because EVERYTHING is part of a system. Nothing exists in a vacuum. When you’re talking about a thing — an animal or a piece of code or a newspaper — you have to talk about the systems which affect it in order to contextualize it. Systems provide context.
As I said, nothing exists outside of a system. And this is especially true for the code you write. Let’s say you’re writing a mobile app. That app exists in a system that also includes the phone and all its hardware as well as the network it uses to pull data. All of those system elements will affect the way you design your app, so it’s important to understand what they are and how they interact.
The most useful abstraction strategy I’ve found when talking about my work is signals and boundaries. If I’m trying to understand a system, I start by figuring out where the boundaries of the system are. Then I identify the signals that cross those boundaries. If this sounds vaguely familiar it’s because this is exactly how we think about APIs. An API is a boundary and the functions in the API allow signals to pass through the boundary. This is also the most useful abstraction I’ve found for explaining systems.
This is an abstraction strategy so you can draw your boundaries anywhere you want. This is useful for defining the scope of your understanding. Here we have two different scoping boundaries, and thus, two very different understandings of what makes us up. We could go even smaller and talk about single cells, or we could expand out and talk about families and communities.
In this example, every time the ball hits a wall, it bounces off. This sounds like basic physics, but in the world of simulation it’s actually a signal sent to the ball by the boundary of the system.
The beauty of system types is that systems that share a type are effectively identical. Knowledge gained in one system can be applied to another system of the same type.
One of my favorite types of systems to talk about is agent-based systems. These systems are characterized by the fact that they’re made up of individual agents, each with similar behavior, and each with limited awareness. Usually the agents are only aware of themselves and their immediate environment. I find agent-based systems fascinating because they give rise to emergent behavior. They also make the best visualizations.
This is a simple agent-based system in which each particle — or agent — has a constant velocity and a decay rate. The particles are emitted from a static emitter at a fixed rate.
This simulation is identical to the last one except I’ve added a weak gravitational force. As you can see, even though gravity is weak, the change in behavior is dramatic.
This simulation is identical to the previous one except that now the emitter follows the location of the mouse.
In each of these simulations, each agent was only aware of its own position, velocity, acceleration, and decay. Velocity was random within a tightly bounded range. And yet the behavior of the systems differ sharply and visibly with just a few tweaked parameters. This is why I love simulating agent based systems: for the emergent behavior that shows itself in the simulations.