Two Maps, One Territory

A week after the Greenbox–Hartland partnership closes, the first technical integration meeting is scheduled. Tom prints the Greenbox C2 diagram and pins it to the wall behind his desk. Hartland has sent him an architecture overview in the form of a forty-three slide PDF. The two documents describe the same future world using different words, different shapes, and different assumptions about what matters. Charlotte brings in a level of C4 the team has never drawn.

The partnership closed eight days ago. The announcement went out on Tuesday, and since then the Greenbox team has spent most of its time answering subscriber emails (“does this mean you’re owned by Hartland now?”), reassuring farm partners (“no, the farm relationships are exactly the same, the whole point of the deal is that they stay the same”), and trying to work out what it actually means, day-to-day, to be in a commercial partnership with a company that’s about forty times Greenbox’s size.

Tomorrow morning at ten, in a meeting room in Hartland’s head office in Sydney, the first technical integration meeting happens. Tom is flying over this evening. Priya is joining from Melbourne. Charlotte is already in Sydney. Maya and Diane are not in this meeting, it’s an engineering meeting and Maya has been very deliberate about letting the engineers own it.

The forty-three slide deck

Tom has the Hartland architecture overview open on his screen. It arrived on Friday, attached to an email from someone called Henrik Larsen, whose title is Principal Engineer. Digital Platforms. The email was polite and professional. It said “here is a high-level overview of our technology landscape. Happy to walk you through any of it before our meeting next week.”

The attachment is a PDF with forty-three slides.

Tom has read all forty-three. He does not feel better for having done so.

The deck is well-made. It has real diagrams. It has a table of contents. It has a glossary. It has a section on Reference Architecture and another section on Target State Architecture and a third section on Transitional Architecture (FY25-FY27). Someone spent real time making this. It is clearly the kind of document a large company uses to explain itself to other large companies.

The problem is that Tom is not a large company. Tom is a developer who has to understand, by Tuesday morning, how Greenbox’s four containers are going to talk to Hartland’s, he counts, scrolling through the deck again, seventeen major systems. Maybe more. It’s hard to tell because some of the boxes on the Hartland diagrams contain sub-boxes that could themselves be systems or could be modules inside systems, and the deck doesn’t say which.

There’s a system called WMS-Core that handles warehouse management. There’s a system called WMS-Cold that handles the cold chain specifically, which might or might not be a part of WMS-Core. There’s something called OMX which is the Order Management eXchange, which connects to something called CFX, the Customer Fulfilment eXchange, and neither of those is explained in the glossary in sufficient detail for Tom to work out whether they are separate systems, a single system with two interfaces, or a logical distinction inside a mainframe that’s been running since 2004.

Tom has three questions and the deck answers none of them:

1. Where does a Greenbox subscription order go when it needs to be fulfilled through a Hartland warehouse?
2. Who owns the subscriber identity. Greenbox, Hartland, or both?
3. What’s the source of truth for stock availability, once Greenbox produce is sitting in a Hartland cold room waiting to go into a subscriber’s box?

He sends a message to Charlotte at 6pm. “I’ve read the deck three times. I still don’t know how our system talks to their system. I think the problem is that their deck describes their world and our diagrams describe our world and nobody has drawn a diagram that has both worlds on it.”

Charlotte replies in four minutes. “Correct. And that’s the diagram we’re going to draw tomorrow morning, before the meeting, so we can bring it into the meeting and use it.”

“What’s it called?”

“System Landscape. C0.”

“I thought the smallest number in C4 was C1.”

“It is. C0 is the unofficial level. Simon Brown added System Landscape later, as a supplementary view, because companies kept asking for a way to show more than one system. He calls it a Landscape view. Some people call it C0 because it’s one step out from C1. The name doesn’t matter. What matters is that you have a diagram that shows two or more systems and the relationships between them. Which is exactly what you need for tomorrow.”

Tom reads that three times. Then he Slacks Priya: “Can we meet at 8am in the Hartland lobby tomorrow? Charlotte wants us to draw something before the meeting.”

Priya replies with a thumbs up and a coffee emoji.

Tuesday 8am: the Hartland lobby

The Hartland building is in North Sydney and it has one of those lobbies that is clearly designed to make you feel like you are about to have an important meeting. Marble floor. A water feature with three vertical streams. A security desk staffed by two people whose job is to give you a lanyard with your name spelled slightly wrong. Tom, Priya, and Charlotte get their lanyards (Tom’s says TOM WATSON which is not Tom’s surname), find a corner of the lobby with some leather armchairs, and sit down with coffees from the cafe near the lifts.

Charlotte has a notepad. She has brought it specifically for this meeting. She opens it to a blank page.

“Before we go upstairs,” she says, “we need a shared picture of two systems. Ours and theirs. Not at the container level, at a level above that. The question we need to answer is: what are the big systems in this combined landscape, who owns each one, and what’s the nature of the relationship between them?”

“That’s C0?”

“That’s C0.”

She starts drawing. On the left of the page, she draws a large rounded rectangle and writes Greenbox inside it. On the right, a larger rounded rectangle, and writes Hartland Group inside it. Between them, she leaves white space.

“These are systems. Or more precisely, software systems. Each one is a thing that has its own team, its own budget, its own deployment, and its own lifecycle. In C4 terms, each of those boxes is what a C1 diagram would call ‘the system’, but today, we’re drawing the view where each system is just a box, and the interesting thing is what goes between them.”

“Isn’t that just C1 with more boxes?”

“No. C1 shows one system in the middle and its users and external dependencies around it. C0 shows multiple systems peer-to-peer, with users and shared dependencies around all of them. The distinction is subtle but important: C1 has a protagonist. C0 has a cast. When you’re designing an integration, you don’t have a protagonist, you have two systems that have to work together, and neither one of them is the main character.”

She draws:

• Greenbox on the left, containing a small note that says subscription, billing, supply matching, fulfilment. Not the full C2, just a reminder of what’s inside the box.
• Hartland Group on the right, containing a note that says WMS-Core, WMS-Cold, OMX, CFX, … 13 others. She leaves the rest vague on purpose.

Around the outside, she draws:

• Subscribers. Greenbox subscribers. They already exist. They talk to Greenbox today.
• Farm partners, they already exist. They talk to Greenbox today.
• Retail shoppers. Hartland’s customers who walk into a Hartland grocery store. They exist. They talk to Hartland today.
• Hartland drivers, the last-mile delivery drivers employed by Hartland. They talk to Hartland today.
• Courier network. Greenbox’s existing courier partners. They talk to Greenbox today.
• Stripe, Mailgun, the existing Greenbox external dependencies.
• Hartland’s payment processor, whatever that is. Tom doesn’t know. He writes a question mark on the diagram.

Then she draws the connections. Subscribers → Greenbox. Farm partners → Greenbox. Retail shoppers → Hartland. Hartland drivers → Hartland. Each one is labelled with what the interaction is.

And finally, this is the bit Charlotte has been waiting to draw, she draws a dashed line between Greenbox and Hartland, and labels it:

Partnership integration (new, unspecified)

She puts the pen down and turns the notepad toward Tom and Priya.

“That’s the diagram. It doesn’t have any detail. It has almost no answers. What it has is a frame. When we walk into the meeting, we’re going to put this in front of Henrik and his team, and the first thing we’re going to say is: this is how we see the landscape. Is that also how you see it? And then we’re going to talk about the dashed line, which is where the entire integration lives.”

Tom looks at the diagram.

“This is the thing I wanted on Friday.”

“I know.”

“It took you four minutes to draw.”

“Yes. The drawing is the easy bit. The hard bit is knowing that this is the level you need to draw at. Most teams in your situation try to jump straight to C2, they start sketching containers for the integration, and they spend an hour arguing about whether an OMX adapter goes inside the Subscription container or outside it. And the reason they’re arguing is that they don’t have C0 first. They don’t have the frame that says your system and their system are both systems, and the integration is a relationship between systems.”

Priya, who has been reading the diagram, says the quiet thing. “The dashed line is the whole agenda.”

“Yes.”

“If we can get agreement on what’s in the dashed line, that’s the integration plan.”

“Yes. Everything else is detail. The detail matters, but the frame comes first.”

Tom asks the sceptical question

Tom, who has been in enough meetings to know the pattern where a diagram gets treated as The Answer and then the meeting ignores it, asks the pushback.

“What if they don’t use C4?”

Charlotte nods like she was expecting the question.

“They won’t. Their deck is in a format I haven’t seen a name for. It looks like a mix of TOGAF-style boxes, some UML deployment shapes, and a lot of custom iconography. Not wrong, just their own. That’s fine. We’re not going to insist they adopt C4. We’re going to show them the C0 diagram, say here’s how we see the landscape, and ask them to point out what’s wrong with our picture. They will. They’ll tell us we’ve missed three systems, got the name of OMX slightly wrong, and conflated two things that are actually separate. And we’ll update the diagram in front of them, and by the end of the fifteen minutes we’ll have a picture that both sides recognise. That’s the thing we’re buying with this diagram. Not a framework. A shared picture.”

Priya writes that down word for word. Not a framework. A shared picture.

“And then,” Charlotte continues, “we use the shared picture to run the actual agenda. Which is: what flows across the dashed line, in which direction, with what guarantees, and on what timeline?”

Tom says: “And before today we had no way to structure that conversation because we had no picture that included both sides.”

“Exactly.”

The meeting

They go upstairs at 9:55. Henrik Larsen meets them at reception, he’s in his late forties, tall, Danish, wearing the kind of smart-casual that is one grade smarter than Tom’s smart-casual. He shakes hands firmly and introduces them to two other people: Aisha Pillai, Integration Architect, and Joe Ng, Senior Engineer. Fulfilment Platform.

Aisha has brought her own notebook. Joe has a laptop with three tabs open before they’ve sat down: one showing the OMX schema, one showing an API documentation portal, and one showing what looks like a Kanban board with Greenbox integration as a column header.

The meeting room is bigger than it needs to be. There’s a large screen at one end. Coffee and a plate of pastries. Henrik thanks them for coming. Aisha smiles in a friendly but professionally neutral way. Joe does a small wave.

Tom takes a breath.

“Before we get into the detail, I wanted to share how we’ve been thinking about the landscape. Just to check whether your picture and ours line up. Charlotte and I sketched this in the lobby this morning.”

He puts Charlotte’s notepad down on the table, turns it to face Henrik and the others, and walks them through it. The left box. The right box. The users around the outside. The dashed line in the middle.

He is not polished. He is not confident. He is sweating slightly through his shirt. But he gets to the end.

“So,” he says, “is that roughly how you see it?”

Henrik looks at the diagram for a moment. Aisha looks at it for longer. Joe takes a photograph of it on his phone.

Henrik’s answer is slow and careful. “I appreciate the simplicity. That is. I think that is actually very useful. Our deck is more detailed than this. It is more detailed because we have to explain our landscape to a lot of different audiences, and the detailed version answers more questions. But for the purpose of this meeting, yours is better. Because the question we need to answer today is the dashed line, and your diagram shows exactly where the dashed line is.”

He points at the dashed line on the notepad.

“Also, and I want to be honest, nobody on our side has drawn this diagram. We have drawn our system. You have drawn your system. Neither of us has drawn the thing that has both systems in it. I am slightly embarrassed that you drew it in four minutes and we have been working on this partnership for three months.”

Tom, Priya, and Charlotte all try not to react to that. Priya does not entirely succeed; there is a small twitch at the corner of her mouth that is the closest she comes to public delight.

Aisha says: “Can I add some things to your diagram?”

“Please.”

Aisha picks up Charlotte’s pen. She draws three things.

First, she adds a small box on the Hartland side and labels it SAP Ariba. “We procure inbound produce through Ariba. When Greenbox produce arrives at one of our cold rooms, there is a receipt against a purchase order in Ariba. This is going to matter for you because it affects how we pay for the produce you bring us.”

Second, she draws a new external actor and labels it FoodSafe regulator. “In New South Wales, our cold chain operations are audited by FoodSafe. Anything we store in a cold room has to be logged in a way that satisfies their audit requirements. This is relevant to the integration because Greenbox produce stored in our warehouses becomes subject to that regime.”

Third, she crosses out the note inside the Hartland box that said “WMS-Core, WMS-Cold, OMX, CFX, … 13 others” and rewrites it: “OMX (fulfilment orchestration), WMS-Cold (cold-chain warehouse), CFX (customer channel), plus 14 others not relevant to this integration.”

“Fourteen,” she says. “Not thirteen. And the fourteen others do not matter for what we’re discussing today. I know the deck was confusing on this. I wrote part of it.”

Tom laughs, mostly from relief. “Thank you.”

“And actually, to go back to your question from last Friday, which I saw when Henrik forwarded it, the answer to ‘where does a Greenbox subscription order go’ is: through OMX. And the answer to ‘who owns subscriber identity’ is: you do. We don’t. We don’t want to. Our customers are different, they’re retail shoppers and grocery account holders. Your subscribers are yours. If we ever have to contact a Greenbox subscriber about a delivery issue, we contact Greenbox, and you contact them. That is a principle we should write down now because it is going to come up again.”

Charlotte, very quietly, writes P1 in her notebook. She uses P for Principle.

Joe adds his own. “And stock availability for produce in our cold rooms should be a view, not a source of truth. The source of truth is Greenbox’s supply matching system. We hold the stock, but Greenbox decides how it’s allocated. Otherwise we end up fighting over who knows where the beetroot is.”

Charlotte writes P2.

What the diagram turns into

Over the next forty minutes, the one-page C0 diagram gets marked up, erased, redrawn on a fresh sheet of paper, photographed three times, and eventually copied onto a whiteboard at the far end of the meeting room. By the time the meeting is halfway done, the diagram shows:

• Greenbox and Hartland as peer software systems, each with their internal systems summarised but not detailed
• Six categories of user / actor: Greenbox subscribers, Greenbox farm partners, Hartland drivers, Hartland retail shoppers, FoodSafe regulator, SAP Ariba (as an external dependency of Hartland’s)
• A set of labelled arrows across the dashed line, now no longer dashed:

Six labelled relationships. Each one has two people in the room who know what it means. Each one is going to become a real contract, written in OpenAPI or AsyncAPI, owned by a specific person on each side, and tested.

Charlotte watches all of this with the particular satisfaction of someone whose diagram has done its job. A good diagram, she has told Tom before, is one the room stops paying attention to. Not because it’s ignored, but because it’s been internalised. People stop pointing at it and start acting from it, arguing about the arrows in the air above the whiteboard, reaching over each other to redraw a label, referring to “the OMX arrow” as shorthand for an entire category of commercial consequences. The diagram has become a shared reference frame. The rest of the meeting lives inside it.

The things the C0 diagram couldn’t resolve

By the end of the meeting, the group has agreed on the six arrows, the two principles Charlotte wrote down (subscriber identity stays with Greenbox; Greenbox is the source of truth for produce allocation), and a rough timeline: pilot the OMX integration within eight weeks, go live with one flow by end of Q3, expand.

They also have a list of things the C0 view couldn’t resolve. Charlotte calls these hotspots, the word borrowed from Event Storming, but the idea is the same. Places where two people in the room still disagreed, or where the diagram didn’t have enough detail to answer a question, or where the correct answer depends on information that isn’t available yet.

Hotspots from this meeting:

1. What happens if an order is in flight when OMX has an outage? Do Greenbox retries respect an idempotency key? Does OMX hold orders in a queue? Neither side has a definitive answer.
2. Who owns the FoodSafe audit trail? Greenbox sends produce. Hartland stores it. The regulator wants a single record. One of them has to be the primary author of that record. Probably Hartland, but it needs to be written down.
3. How do inventory discrepancies get resolved? If Greenbox thinks there are 200 kg of beetroot in a cold room and Hartland’s WMS-Cold says there are 180 kg, who wins the argument, and how does the losing side find out?
4. Authentication between systems. Mutual TLS? API keys? OAuth2 with JWT bearer tokens? Everyone has an opinion; nobody has a decision.
5. Error semantics. When Hartland’s OMX rejects a Greenbox order, what happens next? Does Greenbox retry automatically? Does it surface the error to a human? To Sam? To Maya?

Five hotspots. Each one becomes a follow-up conversation with a specific owner, a time-box, and a date by which the conversation needs to happen. Aisha owns the authentication conversation. Joe owns the inventory discrepancy conversation. Priya owns the error semantics conversation. Charlotte writes them in her notebook next to P1 and P2. She calls these H1 through H5.

Henrik’s request

At the end of the meeting, Henrik asks for something specific.

“This diagram you drew,” he says, pointing at the marked-up notepad. “Can we have a copy of it? I would like to bring it to our next internal planning session. I have been trying to explain the Greenbox integration to my leadership for three weeks, and the deck I sent you was my attempt. But this is better. This is the picture I need to show them.”

Tom tears the page out of Charlotte’s notebook. He writes For Henrik, 26 Nov 2026 at the top and hands it over. Charlotte watches him do it without protest. She knows he wanted to keep the original. She also knows that the diagram being in Henrik’s hands at Hartland is worth more than the diagram being in Tom’s hands at Greenbox, because the whole point of a System Landscape view is that it lives in the place where two systems have to agree on reality, and tomorrow morning that place is Henrik’s desk.

Priya, on the flight back to Melbourne that afternoon, writes a shadow copy of the diagram in the Structurizr DSL on her laptop. The DSL supports landscape views too, she has never used that feature either. By the time the plane lands she has the first working version of greenbox-hartland.dsl checked into a new repository called integration-docs, with Henrik and Aisha added as external collaborators. The rendered diagram is in the repo. The hotspots are in the README. The principles are in a file called principles.md.

Before she closes her laptop on the tarmac at Melbourne airport, she adds one more line to the README:

Before you can integrate two systems, you need one diagram that shows both. This is that diagram. Keep it current. When one side changes, update the other. When the relationship changes, update both sides. If this diagram and reality disagree, it is the diagram that is wrong, and fixing it is part of the work.

What Charlotte reflects on over the second espresso

Charlotte stays in Sydney for another day. She has a dinner that night with an old friend and a meeting the next morning with a different client, one of the startups she advises, not Greenbox. But in between, she sits in a cafe on George Street with a long black and her notebook, and she writes down something she has been thinking about all through the meeting.

Every integration I have ever seen fail has failed at the C0 level. Not at the C2 level. Not at the API schema. At the level above the API schema, the level where the two sides had different mental models of what the systems were and how they fit together, and nobody ever drew the picture that forced the models to agree.

Every integration I have ever seen succeed has had, somewhere early on, a version of the meeting I just watched. A meeting where someone put a simple diagram on the table and said “is this what it looks like to you?” and the other side said “almost, but let me fix three things.” And the fix landed on the diagram in real time, and the meeting proceeded from there.

The diagram isn’t a deliverable. It’s a negotiation tool. It’s the thing you point at when you disagree. It’s the thing you update when you learn something. It’s the thing that makes the space above the code big enough to hold two teams at once.

She underlines the last sentence. Big enough to hold two teams at once.

That’s the thing she’s been trying to say for fifteen years of scaling advisory, and she’s only just found the words for it today. That’s the reason she keeps doing this work. Not the frameworks. The words that let two teams agree on what they’re looking at.

She closes the notebook and pays for her coffee and walks back to her hotel.

What Tom tells Maya on the phone

Tom calls Maya from the car on the way to Sydney airport. Maya picks up on the second ring, because she’s been waiting for the call.

“How did it go?”

“Good. Better than I expected. They’re real engineers. They have real problems. The deck they sent me was too dense because they were trying to explain too much, and in the meeting they admitted it. We built a diagram together that both sides understood. We got agreement on six integration points and two principles. We have five open questions that I have a list of.”

“Did you use C4?”

“We used the C4 level that C4 doesn’t officially have a number for. Charlotte calls it C0. System Landscape. It’s the one above C1. The one with more than one system on it.”

“And?”

“And Henrik, their principal engineer, asked to keep the hand-drawn version. He said it was better than the deck they’d been using internally. Maya, I watched an experienced engineer at a big company ask for Charlotte’s napkin drawing because it was clearer than his own forty-three slide deck.”

Maya is quiet for a moment.

“That’s a good sentence.”

“It’s a true sentence.”

“Okay. Good. Come home safely. We’ll debrief on Thursday.”

Tom hangs up. The taxi driver is listening to ABC News on the radio. The sun is setting somewhere behind the Sydney Harbour Bridge. Tom leans his head against the window and thinks about the diagram Charlotte drew in the lobby this morning, which now exists in three places, on a sheet of paper at Hartland’s head office, in a repository called integration-docs that Priya set up on the plane, and on a photograph on Joe Ng’s phone that Joe has probably already forwarded to someone else.

Before you can integrate two systems, Tom thinks, you need one diagram that shows both.

He takes out his phone and sends that sentence to Priya. She replies thirty seconds later with: “Already in the README.”

Related

For the workshop pattern behind this kind of session, including running C4 modelling as a tool for cross-team integration conversations, see The Workshop: C4 Modelling. For the earlier C4 posts in this series, see Drawing the System: From Event Storm to C4, When a Container Earns Its Own Zoom, and One Diagram, Two Countries, Three Regions.