Building Simulations

How to think and design complex systems in SEL

Like all languages aspiring to greatness, Summit Event Language (SEL) has been designed to be excellent at certain things, while accepting that it will not do everything, and will even do some things weakly. In other words, writing SEL is to accept certain trade-offs.

One of the things SEL is very good at is modeling stocks and flows over time β€” i.e. as a simulation. In fact, although it is easy enough to use them for general purpose, the events within a model are executed based on an internal calendar, making them ideal for simulating changes over time.

Finding the Flow

To get into the flow of writing simulations in SEL is to build using events that work with, instead of against, the grain of the language. While "you'll know it when you find it", you can also more deliberately find it by repeating two phrases as you build:

"I have a thing."

And, as an extension:

"Every day/month/week/year, this thing sends some of its value to another thing."

Simulation Thinking

These phrases help you find the flow of SEL because your model is a simulation, and your events are the actors in that simulation. Before you can write a strong model, you need to establish clear thinking about the actors in your model. That's where "I have a thing" comes in handy.

"I have a checking account."
"I have a customer base."
"I have a support rep."
"I have inventory."

These are strong events!


Abstract Things

Sometimes it can be hard to find 'the thing'. That's because some of these things may not be written down anywhere. Take a hiring plan, for example. It's easy to think "I have a future hire" and build a model where each event is a position to be filled on a certain date. But what if you wanted to build a more robust model? 'The thing' is no longer future individual hires -- 'the thing' is the hiring ramp you've agreed to as an organization. "I have a hiring ramp. Every month, this hiring ramp sends a number of hires to make to a cost per hire."

The building blocks of Summit are events because they are actors on a timeline. We use SEL to define and describe how these actors should behave over time. When should they trigger, how often, and what should they do? This is where the second phrase comes in handy:

"Every ____, this thing sends some of its things to another thing."

What should a checking account do? What should a customer base do? How about inventory?

Some events are relatively inert! They don't do much, other than hold on to something. Checking accounts hold onto money. Customer bases hold customers. Inventory holds parts or products. Their do is just to be. Rather than sending any of their contents along, they simply report what they contain.

Other events are more active. They take what they're given, do something with it, and pass it along, like a pipe. Or they create things out of thin air and send those things along, like a natural spring produces water and sends it flowing downstream.

When you look at a modeling canvas, you should see a landscape of actors (events), each behaving in a simple and specific way over time. Though each event is simple by itself, the interaction of these events creates a beautiful complexity. A lot like the real world.

Systems Thinking

When connected, the events in your model form a system. How exactly are events connected? Remember,

"Every (blank), this thing sends some of its things to another thing."

Events are connected through routes, represented as arrows, that show the direction of flow within your model. But before we discuss flow, we need to understand event behavior at a deeper level.

Make Good Citizens

Because events are largely self-contained (with the exception of Event references and liquid syntax references), and because they have a simple agreement with other events, events are extremely composable. In other words, they make excellent building blocks for a larger system.

Systems emerge when we begin to connect events. We do this in the Summit editor by pointing (using the arrows) an event at another event, often called the "downstream" event. If event A points to event B, event B will receive the output of event A every time event A occurs. Event B will then take the number it receives and do something with it based on the kind of event it is. Some events will collect all the numbers they receive into a giant total (like the Pool), while others will just multiply it by some other number and pass it right along, like a pipe.

Animation, not Calculation

Although SEL "does math", it's actually best not to think of your simulation as a calculation. Though they look like spreadsheet cells, events are different creatures. They are connected actors, passing numbers around to each other, modifying them, and passing them along again. A healthy Summit model is an above-ground rail system, where each event is a station. Some numbers get on, others get off, and the train continues. Think animation, not calculation. The sums and totals you see in the output of Summit are the measurements of a simulated world you bring to life each time you run the model.