Systems Thinking Chapter 10: Modeling Together - Part 2
This is Part 2 of Chapter 10 from “Learning Systems Thinking” by Diana Montalion. Part 1 covered what modeling is and different modeling approaches. Now we get into the practical stuff. How do you actually use modeling to solve real problems? Diana brings back the MAGO case study to show us.
MAGO Returns
Remember MAGO? The giant magazine publisher from previous chapters? Let me refresh your memory because it’s been a while.
MAGO was the biggest magazine publisher in the world. Before the internet ate everything, they had state-of-the-art publishing software. Millions of copies distributed physically every week. Life was good.
Then digital happened. They did what everyone did back then. Took their print content, exported it with a script, and shoved it into a web page. Their entire data architecture, workflows, everything revolved around one concept: the “page.”
Digital traffic exploded. Millions of page views per day. They built apps, hired more tech people, added subscriptions, tracking, image distribution. The CTO’s team grew bigger than the content team. But here’s the funny thing. A huge chunk of their content was still being “distributed” by people copying and pasting from one software to another. Classic.
Then product teams started going rogue. One team built “their own” software. Others followed. Soon the whole system had zero conceptual integrity. The original print software was becoming obsolete. MAGO needed a complete restructure. Not just of software, but of how people think about the system.
Problem Space vs. Solution Space
Here Diana drops one of my favorite ideas in the whole book. She quotes Efrat Goldratt-Ashlag: “There is no sense in talking about the solution before we agree on the problem.”
Simple? Yes. But think about how many times you sat in a meeting where everyone was arguing about solutions while solving completely different problems.
Diana says when a group cannot solve a problem, they are usually solving different problems. I felt this one in my bones. Twenty years in IT, and I’ve watched this happen hundreds of times.
She gives a perfect example. Imagine six MAGO team members in a room:
- Person A thinks the problem is “obsolete software needs upgrading”
- Person B thinks it’s “we aren’t digital-first”
- Person C thinks “product doesn’t have enough control”
- Person D thinks “we aren’t leveraging the cloud”
- Person E thinks “our data is fragmented across SaaS tools”
- Person F thinks it’s just decreasing ad revenue
Six people. Six different problems. All talking about “solutions.” No wonder nothing gets done.
The fix? Separate problem space from solution space. First, make sure everyone agrees on what the actual problem is. What is keeping the system from serving its purpose? What is the impact? Who is impacted? How will we measure change?
Diana’s own take is interesting. She says the real problem is “the world has changed around us.” The mental models that built the current system don’t fit the new world anymore. But she also says none of these answers are “the right” answer. Most of those problems are real problems. They are also symptoms of a deeper systemic problem. If the team invests time to find that systemic root, they might actually fix things.
This takes time. But it is worth the investment.
Linear vs. Nonlinear Modeling
Diana revisits the linear vs. nonlinear thinking from Chapter 3, but this time adds a modeling column. This is where it gets really practical.
Instead of modeling a solution for one new channel (linear), model the underlying capabilities that support delivering content to any emerging channel (nonlinear). Instead of designing an API that shares a “page” with other software, create a data model that structures and semantically names the information the system distributes.
One example I really liked: the linear approach says “build services that use APIs or shared databases.” The nonlinear approach says “design an event-based system that supports adding new services without direct integrations.” The modeling technique? EventStorming.
Another good one: instead of just replacing old software parts (linear), reconsider the context in which those parts operate (nonlinear). Model it using the Value Flywheel with Wardley Mapping.
Instead of “lift-and-shift to the cloud,” explore the potential of cloud-native tools to actually solve the problem. Instead of designing one-off features for short-term needs, model capabilities that support current features AND potential future ones.
The pattern is clear. Linear modeling solves today’s problem. Nonlinear modeling builds a system that can handle tomorrow’s problems too.
Patterns Revisited with Modeling
Diana then takes the patterns from Chapter 9 and adds modeling activities for each one. She splits them into three categories.
External patterns. The world changed. Information used to be scarce. Now it’s everywhere. Revenue used to be predictable. Now MAGO competes with free content. Staff used to stay for decades. Now people stay 2-5 years. Information used to live on pages. Now it can be any shape or form.
For each shift, there’s a modeling approach. Model information flows across the system. Where is information stuck, missing, duplicated? Model business processes for each revenue activity. Do they share components? Interview teams about their communication process. Model something that encourages collective reasoning.
Technology patterns. Enterprise software with batch exports became event-driven systems. Single taxonomy became dynamic relationships. One tech team became many teams with multiple architects. Manual processes need automation. No tests became layers of test coverage. Weekly releases became many siloed release processes.
Modeling activities here: model the events, model information relationships, model the decision-making process, model where manual work still exists, model quality assurance needs across the system, model continuous delivery and find the blockers.
Process patterns. Focus shifted from delivering the magazine to delivering technology initiatives. Planning went from structured weekly meetings to ad hoc teams. Budget moved from supporting better content to supporting better technology. “The way we’ve always done it” became a blocker.
Model a system that delivers content to many emerging consumers. Model activities necessary to deliver change. What does everyone have in common? What needs to be different? Use the domain model to guide investment.
Go Model
The chapter ends with a practice exercise. Diana encourages you to just start modeling. Don’t use a template. Use modeling as a thinking tool. Start with a question: “How does this work?” or “What is the relationship between X and Y?”
If you’re stuck, pick from these questions:
- How does information flow?
- What events happen in the system?
- What are the boundaries?
- What are the building blocks?
- What is the delivery process?
- How are people organized?
- How is discourse structured?
She also provides a solid list of resources: Cynefin Framework, ArchiMate, C4 model, TOGAF, UML, ADRs, Design Thinking, EventStorming, Wardley Mapping, Team Topologies, and several O’Reilly books on the topic.
My Take
What I like about this second half of Chapter 10 is how concrete it gets. The MAGO example is not just a toy scenario. It’s basically every large organization I’ve ever worked with. The “six people solving six different problems” thing happens everywhere. In banks, telecom companies, government agencies. Everywhere.
The problem space vs. solution space distinction is something I now use in almost every meeting. Before jumping to solutions, I ask: “Wait, what problem are we solving here? Are we all solving the same problem?” You would be surprised how often the answer is no.
And the linear vs. nonlinear modeling table is worth printing out and taping to your monitor. Next time someone says “we need Kubernetes,” you can ask “but what problem does that solve for the system?”
This is Part 2 of 2 for Chapter 10.
Navigation: