Managing Complexity

You know the shapes. You know the links. Now let's tackle the real challenge: explaining complex systems without making your audience's eyes glaze over.

The Complexity Problem

Here's the truth about systems: even "simple" ones get complicated fast.

Take making breakfast. Sounds simple, right? But model it completely and you'll have:

• Multiple parallel processes (toast while eggs cook)
• Decision points (scrambled or fried?)
• Nested sub-processes (cracking eggs is part of cooking eggs)
• Conditional requirements (need milk if scrambled)
• Multiple agents (maybe two people cooking together)

If you try to show all of this in one diagram, you get a visual hairball that explains nothing.

OPM solves this with a beautiful concept: hierarchical organization through in-zooming.

The System Diagram (SD): Your 30,000-Foot View

Every OPM model starts with a System Diagram (SD)—the highest-level view of your system.

The SD should answer one question: What is this system's main function?

The SD contains:

1. One main process (the system's core function)
2. The beneficiary (who benefits from this function)
3. Key objects involved at the highest level

Example: An Online Store

That's it. The SD is intentionally simple. It says "here's what this system does" without getting into how.

In-Zooming: Looking Inside Processes

In-zooming is how you show what's inside a process—its sub-processes.

Graphically, the process ellipse expands to contain its children:

The Timeline Principle: Within an in-zoomed process, vertical position = execution order:

• Processes at the top execute first
• Processes at the bottom execute last
• Processes at the same height execute in parallel

Sequential vs. Parallel Execution

Sequential (one after another):

Parallel (happening at the same time):

Multi-Level Zoom: Going Deeper

You can in-zoom multiple levels, creating a hierarchy:

SD (Level 0)
│
├── Shopping
│   │
│   └── SD1 (Level 1)
│       │
│       ├── Browsing
│       │
│       ├── Selecting
│       │
│       └── Checkout Processing
│           │
│           └── SD1.3 (Level 2)
│               │
│               ├── Cart Review
│               ├── Payment Entry
│               └── Order Confirmation

Each level gets its own diagram. You're not cramming everything into one view—you're organizing by detail level.

The Navigation Convention:

• SD = System Diagram (root)
• SD1 = First zoom into SD
• SD1.3 = Zoom into the 3rd process of SD1
• SD1.3.2 = Zoom into the 2nd process of SD1.3

Thick Contours: Marking "More Detail Available"

When a process has been in-zoomed elsewhere, it gets a thick border to signal "there's more detail if you drill down."

Object In-Zooming: Looking Inside Things

You can also in-zoom objects to show their internal structure:

Key difference: Object in-zooming shows spatial/logical arrangement, not temporal sequence. (Objects don't "execute" in order—they just exist.)

Special States: Initial, Default, and Final

Some states have special meaning:

Control Flow: Events, Conditions, and Exceptions

For more sophisticated models, OPM provides control mechanisms:

Event Links (marked with 'e')

An event link means "this triggers the process to start":

Condition Links (marked with 'c')

A condition means "process only occurs if this state exists":

Best Practices: Making Models That Actually Help

After all this theory, here's practical advice for creating useful OPM models:

1. Start at the Top

Always begin with the System Diagram. Ask: "What's the ONE main function?" Get that right before zooming in.

2. The 7±2 Rule

Each diagram should have 5-9 elements. More than that? You need to in-zoom or split things up.

3. Name Things Well

• Processes should be verbs or verb phrases: "Processing," "Validating," "Calculating"
• Objects should be nouns: "Report," "User," "Temperature"
• Be specific: "Order Processing" beats "Handling Stuff"

4. Follow the Transformation

When modeling, trace what gets consumed, created, or changed. If a process doesn't transform anything, question whether it belongs.

5. Use States for Conditions

Instead of creating many similar objects, use one object with states:

• ❌ Bad: "New User," "Active User," "Suspended User" (three objects)
• ✅ Good: "User" with states new, active, suspended (one object)

6. Separate What From How

High-level diagrams show what happens. Lower-level diagrams show how. Don't mix.

7. Show Interfaces at Boundaries

When objects cross between in-zoomed and outer contexts, show them at the boundary to make data flow clear.

Real-World Example: Coffee Shop Order System

Let's bring it all together with a complete multi-level model.

SD: The Big Picture

SD1: In-Zooming Order Fulfilling

Your OPM Toolkit: Summary

You now have everything you need to model systems with OPM:

The Building Blocks:

• Objects (rectangles) and Processes (ellipses)
• States (rounded rectangles inside objects)
• Transforming links (consumption, result, effect)
• Enabling links (agent, instrument)
• Structural links (aggregation, generalization, exhibition, classification)

Managing Complexity:

• System Diagram (SD) for the overview
• In-zooming for process detail
• Vertical position for execution sequence
• State suppression for focus
• Thick borders to signal "more detail exists"

Best Practices:

• Start at the top, zoom as needed
• 5-9 elements per diagram
• Clear naming (verbs for processes, nouns for objects)
• States instead of duplicate objects
• Separation of what vs. how

What's Next?

You're now equipped to create OPM models for real-world systems. Here are some things to try:

1. Model your own workflow — How you process email, handle meetings, or complete a recurring task
2. Model something technical — A login system, a deployment pipeline, or an API flow
3. Model something physical — A manufacturing process, a cooking recipe, or a home automation system
4. Teach someone else — The best way to solidify understanding is to explain it

And remember: the goal isn't perfect diagrams—it's clear thinking. OPM is a thinking tool as much as a documentation tool. Even if no one else ever sees your diagrams, the act of creating them clarifies your understanding.

Resources for Going Further

• ISO 19450:2024 — The official international standard for OPM (if you want the formal specification)
• OPCloud — Web-based OPM modeling tool (opcloud.tech)
• OPCAT — Desktop OPM tool from Technion
• Model-Based Systems Engineering with OPM by Prof. Dov Dori — The comprehensive textbook

Thank you for following this tutorial series. Now go model something!