The Summit Way

How to think in Summit Event Language (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. This article is written to make you aware of those trade-offs so you can spend more time enjoying the art of building in Summit, and less time frustrated with its intentional shortcomings.

Finding the Flow

To get into the flow of writing 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 ____, this thing sends some of its things 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.

Well-Behaved Events

First, there is no minimum behavior for an event. Like an empty line of code, an event can "do nothing." The true minimum requirement for something to be an event is that it record its behavior, or lack thereof ("I did nothing!").

An event records its behavior by reporting on two attributes:

  • Balance: how many things it contains
  • Flow: how many things it has received or sent

At the very bottom of SEL then, is the certainty that every event at all times has a value for balance and flow (the most recent value to have been sent or received by the event).

Second, there are constraints on the behavior of an event.

  • An event may not access the value of other events,
  • An event must accept a single number as its input,
  • An event must return a single number as its output.

Make Good Citizens

Because events are self-contained, and because they have a simple agreement with other events (you may send me a number and I'll send you a number), 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 model 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.


Did this page help you?