Understanding the System Landscape

Chapter 5 of Integration Architect, Part 1: Understanding Integration (See). Previous: The Admin’s Integration Toolkit · Next: Understanding Integration Requirements.

The first four chapters were about one arrow: the call, what travels on it, and the tools that make it. This chapter steps back to see all of them at once. Before you choose a pattern, before you pick an API, before anyone writes a line of code, draw what exists: the system landscape.

It doesn’t need much. Rectangles and arrows. But a good landscape sets the scope, finds the systems nobody mentioned, shows who holds which secret, and tells you when it’s time for something in the middle.

All six modules draw Steve Trucking’s landscape, and every box keeps its place from the first call to the last module.

The ideas in this chapter

• Two boxes protect you. A user, an arrow, a blue box that says Salesforce. Put it in front of the client, and it sets the scope: anything not on it isn’t in the project. And then the memories come: “Oh, wait. I’ve got something else.”
• A box is a process boundary, and every arrow crosses one. Some Salesforce products share your org; some have their own hosting and need a connector or an integration. Anything in core does not require an integration. Check where each one runs today; don’t assume.
• On a landscape, the arrow starts at whoever opens the connection, and the label says what moves. Two conversations are two arrows. A double arrow is only for a connector, and a dashed line is trust, with no call at all. A database stores; a process calls.
• Browser or server comes down to which one is the client. In a mashup, the browser calls another site itself, and whatever the browser needs, anyone with the page can see. If it needs a secret, the server makes the call.
• Point to point grows as n × (n − 1). Every system you add talks to every system already there, until it’s a web. A hub in the middle turns the web into spokes, and gives you routing, orchestration, one vault for the credentials and transformation. It’s one basket, so it had better be a strong one, and with one or two connections it may not be worth it.
• The landscape becomes an inventory. Current state first. Then, for every arrow: who starts it, how it travels, the credential and who holds it, and who owns it. And keep it alive, down to revoking the credential when an integration retires.

The path through this chapter

Six modules, each standing on its own.

1. Two Boxes Protect You. Two boxes are enough; then the memories come, one box at a time; and draw it on the first call.
2. Boxes, Boundaries and Touch Points. A box is a process boundary; the product party, on core, near core and in its own hosting; every touch point and what’s behind it; and how much to put in a box.
3. What the Arrow Means on a Landscape. Reading every arrow; two conversations, two arrows; the connector’s double arrow and the trust line; who can start a call; and why data flows get their own diagram.
4. Where an Integration Happens: Browser or Server. The lateral call and the mashup; what the browser has to know; browser-level integration in Salesforce today; when it breaks in the browser; and browser, process and data.
5. Point to Point, or Hub and Spoke. The web, growing one system at a time, and the hub; the arithmetic; what the middle gives you; one strong basket; and when it isn’t worth it.
6. The Landscape as an Inventory. Current state first; every arrow’s four answers; the credential column; and keeping it alive.

Each idea here is a seed. Chapter 6 asks what the business needs from each arrow. Chapter 7 names the patterns. Middleware at enterprise scale is chapter 17, virtual integration and mashups chapter 18, signing in chapter 12, and watching every arrow chapter 13.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

• That the project has a landscape from the first call, current state first, and that every box the client adds is a decision: in scope or out.
• What each box is, and for every Salesforce product, whether it’s on core, near core or in its own hosting, checked against today’s sources.
• What each arrow means, who starts it and what moves, with two arrows for two conversations and a double arrow only for a connector.
• Where each integration runs, in the browser, in a process or at the data, and that no secret ever reaches a page.
• Point to point or hub and spoke, where orchestration lives, and how the hub is secured, sized and kept running.
• The inventory behind the landscape: every arrow’s starter, mechanism, credential and owner, and who keeps it current.

Beyond the exam: AI tools and agents are boxes and arrows like any other. Each one is a system on the landscape, each place it reaches your data is an arrow with a credential and an owner, and an AI widget on a page is a browser-level integration. Agents multiply arrows fast, and the same arithmetic applies: a hub in the middle gives you one place to see them and one place to stop them. Each module ends with what AI changes, and chapter 21 goes further.

Explore

• Salesforce Architects, Integration Patterns (opens in a new tab): data, process and virtual integration.
• Salesforce, Trust Status (opens in a new tab): each separately hosted service and its current status.
• In the Data Architect course, Draw the System Landscape: my layout for a Salesforce landscape, and the current state before you fix it.

Next: Understanding Integration Requirements