The question this module answers: Why do you draw a system landscape before you design anything, even when it has only two boxes?
Before you choose a pattern, before you pick an API, before anyone writes a line of code, draw what exists. That drawing is the system landscape: a picture of the systems, the applications and the data flows, and how they connect and interact.
It doesn’t need much. Rectangles and arrows. The rectangles are the systems; I call them process boundaries, and module 2 explains why. The arrows are where one system talks to another, and every arrow crosses a boundary.
You all will need to learn to draw system landscapes. And the first one is the smallest.
I’ve done system landscapes where it’s only Salesforce. A user in a browser on the left, one arrow, a blue box in the middle that says Salesforce. That’s the whole landscape. And that is great.
Why is that a valid system landscape? Put it in the technical requirements document, the TRD, and ask yourself: what does it save me from?
It sets the scope. The landscape says what’s in the project, so it also says what isn’t. Months later, the client says, “Hey, wait a minute. Where’s my mobile app?” And you can say, “That wasn’t in the diagram.” Where’s the push of my orders? Where’s my this? Where’s my that? None of them were on the landscape everyone agreed to. They’re new work, and new work is a conversation about time and cost, not a surprise at go-live.
So a system landscape with these two boxes can actually protect you.
In chapter 1 we met the client who looks at a finished project and says, “Where is this?” (The Building Nobody Described). The landscape is one of the best ways to have that conversation at the start instead of the end.
Here’s the part that surprises people. Put even two boxes in front of a client, and you’d be surprised by how many memories suddenly come back.
I’ve sat there on first calls. That’s what I call the first time I talk to a client about their project. I put the landscape up, and the conversation goes like this. “Okay, you’ve got system B.” “Oh, wait. I’ve got something else.” “All right, you’ve got system C.” “Oh, I’ve got something else.” Nobody was hiding anything. They just hadn’t thought about it until they saw the picture and noticed what was missing.
That’s what happens at Steve Trucking. The first call starts with the two boxes: the office staff and Salesforce.
Then the touch points: the partners’ own users and their portal, the people receiving the deliveries with their tracking page, the phones, email, and the text messages the day before.
And then the systems behind it all: the identity provider, the analytics with every status ever sent, the GPS, finance, the photos, and the old system nobody uses anymore but whose history everyone still needs.
Frame 5 of 5: one memory at a time, the whole estate.
Every box stayed where it first appeared. That matters: when the landscape grows, people can see what’s new without having to find everything again.
This is the same landscape you saw from 30,000 feet in chapter 1. Now you’ve seen how it gets drawn: not all at once by an architect who already knows, but box by box, with the client, as they remember.
So a system landscape is critical in an integration project, even if it’s just two boxes. It protects you. And then you start to find all the other ones.
A few things I do with it:
Draw it before anything else. Don’t wait until you understand the estate. You understand the estate by drawing it.
Show it, don’t just keep it. The memories come when the client sees the picture, not when you describe it.
Every new box is a decision. In scope or out? Now or later? Write the answer next to the box, with the date and who said it.
Keep it current. The landscape grows through the project. Every box stays in its place, so people can find what changed.
Keep it simple. The landscape shows the systems and how they connect, not everything inside them. Module 2 is about how much to put in a box.
That the project has a system landscape, from the first call, even if it’s two boxes.
Where it lives (in the TRD, for example) and who agrees to it.
For every box the client adds: in scope or out, and who decided.
Who keeps the landscape current through the project, and how changes are shown.
Beyond the exam: what AI changes. AI can draft a landscape in seconds from a requirements document or the notes of a call. It can only draw what someone wrote down. The memories that come back on a first call (“Oh, wait. I’ve got something else”) still need a person looking at the picture. And AI adds boxes of its own: every AI tool or agent that connects to Salesforce is a system on the landscape, with an arrow and an owner, like any other. If it isn’t drawn, nobody is watching it.
