Two Shapes, Infinite Possibilities

Ever tried to explain how something works and ended up drawing circles and squares on a napkin? Congratulations—you've been doing primitive system modeling. Now let's upgrade your game.

The Problem With Explaining Things

You know that feeling when you're trying to explain a complex system—maybe how your company processes orders, how photosynthesis works, or how your new startup idea functions—and your explanation turns into a tangled mess of "and then... but also... oh wait, I forgot to mention..."?

Traditional ways of explaining systems have a fundamental problem: they either show you what's in the system (like a parts list) or what the system does (like a flowchart), but rarely both. And when they try to show both? Welcome to diagram hell—seventeen different diagrams that don't talk to each other.

Enter Object-Process Methodology, or OPM.

The Big Idea: Just Two Things

Here's what makes OPM refreshingly simple: everything in any system can be described using only two fundamental building blocks:

1. Objects — things that exist
2. Processes — things that happen

That's it. Two concepts. No more, no less.

But here's the magic: these two concepts, combined with a handful of ways to connect them, can describe literally anything—from how coffee gets made to how the human immune system fights viruses to how SpaceX lands rockets.

Objects: The Nouns of Your System

An object is anything that exists—physically or conceptually. In OPM, we draw objects as rectangles.

Some examples of objects:

• Physical things: Coffee, Car, Robot Arm, Patient, Document
• Conceptual things: Order, Account Balance, Risk Score, User Permission, Temperature

Objects have a superpower: they can have states. A Coffee object might be hot or cold. An Order might be pending, processing, or shipped.

States are shown as rounded rectangles inside the object:

Why states matter: States let you show conditions without creating a new object for every variation. Instead of having "Pending Order" and "Shipped Order" as separate things, you have one Order object that can be in different states. This keeps your model clean and reflects how the real world actually works.

Processes: The Verbs of Your System

A process is anything that happens—any activity that transforms objects. In OPM, we draw processes as ellipses (ovals).

Some examples of processes:

• Physical actions: Brewing, Welding, Transporting, Assembling
• Conceptual actions: Calculating, Approving, Validating, Notifying

Here's the crucial insight: processes transform objects. A process might:

• Create an object (bring it into existence)
• Consume an object (destroy or use it up)
• Change an object's state

This is the core dynamic of OPM: objects sit there existing, and processes come along and do things to them. Then other processes do more things. And that's how systems work.

A Quick Example: Making Coffee

Let's model something simple: making coffee.

Objects we need:

• Water
• Coffee Grounds
• Coffee (with state: ready)
• Coffee Maker (our instrument—more on this later)

Process we need:

• Brewing

Here's what happens:

1. Water and Coffee Grounds are consumed by Brewing
2. Brewing creates Coffee (in its ready state)
3. Coffee Maker enables Brewing (it's needed, but not used up)

Even this simple example shows OPM's power: in one view, you see:

• What exists (water, grounds, coffee, coffee maker)
• What happens (brewing)
• How they relate (consumption, creation, enabling)

No separate "class diagram" and "sequence diagram" and "state chart." It's all right there.

The Object-Process Test: Is This a Noun or a Verb?

Sometimes it's not obvious whether something should be an object or a process. Here's a simple test:

Ask these three questions:

1. Does it involve the passage of time?
2. Does it relate to a verb?
3. Does it transform something?

If you answer yes to all three, it's a process. Otherwise, it's probably an object.

Example: "Flight"

1. Does flight involve the passage of time? Yes (it takes time to fly)
2. Does flight relate to a verb? Yes (to fly)
3. Does flight transform something? Yes (it changes the airplane's location)

→ Flight is a process

Example: "Airplane"

1. Does airplane involve the passage of time? Not inherently
2. Does airplane relate to a verb? Not really
3. Does airplane transform something? No, it exists

→ Airplane is an object

The Two Modalities: Pictures and Words

Here's another superpower of OPM: every diagram has an automatic textual equivalent called OPL (Object-Process Language). It reads like plain English.

This bidirectional graphics-text representation means:

• Visual thinkers can read the diagrams
• Text-oriented folks can read the OPL sentences
• Both are always in sync because they're the same model

What You've Learned

You now understand the core philosophy of OPM:

1. Everything is either an Object or a Process
2. Objects exist; Processes happen
3. Objects can have States
4. Processes transform Objects (create, consume, or change)
5. One unified model shows structure, function, and behavior together
6. Two equivalent views: graphical (OPD) and textual (OPL)

In Part 2, we'll dive into the actual visual language—the symbols and connections that let you draw OPM diagrams.

About OPM: Object-Process Methodology is an ISO international standard (ISO 19450:2024) developed by Prof. Dov Dori at the Technion - Israel Institute of Technology. It's used in systems engineering, software development, business process modeling, and scientific research.