The Landscape as an Inventory

Module 6 of 6 in the chapter Understanding the System Landscape, chapter 5 of the Integration Architect course. Each module stands on its own. Previous: Point to Point, or Hub and Spoke · Next: the chapter overview, Understanding the System Landscape

The question this module answers: Once the landscape is drawn, how do you turn it into something you can run, secure and change?

We’ve drawn the boxes, the boundaries and the touch points. We’ve decided what each arrow means, where each integration happens, and whether there’s a hub in the middle. Now the landscape has one more job. It becomes the list you manage the estate from: the integration inventory.

Current State First

Before you draw where you’re going, draw where they are. What building is on the ground? What is there? What’s the layout? What are their current systems? Do they have Salesforce already, or is this a new installation? What are they going to keep, and what are they going to get rid of?

The current state is usually messier than anyone wants to admit: data rekeyed by hand from one system into another, a spreadsheet that moves the numbers to finance once a month, a message that goes out with no link because nobody connected the systems. Draw it anyway, honestly, and label it as the current state, so nobody mistakes it for the design. The Data Architect course draws Steve Trucking’s current state, and why you draw it before you fix it, in Draw the System Landscape.

Then the target landscape, the one we’ve been drawing in this chapter, is a set of decisions: which arrows stay, which change, which are new, and which go away.

Every Arrow Gets Four Answers

A landscape shows that two systems talk. An inventory says what it takes. In chapter 1, Everything Is Knowable zoomed in on one arrow and asked who calls whom, how much, how often, and what happens when it fails. The inventory adds the answers you need to run it, for every arrow:

1. Who starts it. The client, the one that opens the connection, as in module 3. That’s who holds the address and does the retrying.
2. How it travels. The mechanism: REST calls, a webhook, a file over SFTP, an event, EDI through a network. Two arrows between the same two systems usually have two different answers.
3. The credential, and who holds it. What it signs in with, where that’s kept, and who can see it. An External Client App and its own integration user for a system calling in; a named credential for a call out; a key for a file drop.
4. Who owns it. A team, with a name you can call. And, when the other end is a partner, their contact too.

Here’s the start of Steve Trucking’s inventory, one row for each arrow with a partner or a provider on the other end.

Click to enlarge

Every arrow, four answers: the table behind the landscape.

Add how much and how often from chapter 1, and you have most of what an operations team, a security review or a new architect needs to know about the estate, in one place.

The Credential Column

Look at the column in amber. It’s the one that gets forgotten.

Every arrow needs something to sign in with. In module 5, we counted them: point to point, five systems can mean twenty sets of credentials. And if one of those systems is breached, you need to reset its credentials and go talk to every system that calls it. You can only do that if you know which ones they are.

So for every credential, the inventory says where it’s kept, who can see it, when it expires or changes, and what to revoke if something goes wrong. The integration that never made it into the inventory is the dangerous one: the test integration from two years ago whose credential still works, the partner app nobody remembers approving. Chapter 12 is about protecting credentials; chapter 13 is about watching them.

Keep It Alive

An inventory that’s right on the day of go-live and wrong six months later is worse than none, because people trust it. So the landscape and the inventory change together:

• A new integration gets its row before it goes live, not after.
• A changed one gets its row updated with the change: a new mechanism, a rotated secret, a new owner.
• A retired one gets its arrow taken off the landscape, and then the work that’s easy to skip: revoke its credential, deactivate its integration user, remove its External Client App or named credential. Chapter 23 makes that a step in every review.

And look ahead. Don’t just ask what today is. I like a three-year horizon. Records will grow, traffic will grow, users will grow, complexity will grow. The inventory is where you see it coming: which arrows carry the volume, and which ones will need a different mechanism before the three years are up.

What an Architect Decides Here

• That the project starts with a current-state landscape, labelled as such.
• For every arrow on the target landscape: who starts it, how it travels, the credential and who holds it, and who owns it.
• Where the inventory lives, who keeps it current, and how often it’s reviewed.
• What happens to an integration when it retires, step by step, down to its credential and its user.
• Which arrows will need to change in the next three years, and why.

Beyond the exam: what AI changes. AI can draft an inventory fast: give it what’s in Setup (the External Client Apps, the named credentials, the integration users) and it will list them and guess what each one is for. That’s a useful start. But it can’t know who owns an arrow, or that the app called “Test 2” still feeds the warehouse. A person has to confirm every row. And every AI agent and AI tool that connects in or calls out gets its own row, like any other integration: who starts it, how it travels, its credential and its owner.

Explore

• In the Data Architect course, Draw the System Landscape: drawing the current state before you fix it.
• Chapter 1, Everything Is Knowable and The Building Nobody Described: one arrow’s four questions, what’s on the ground, and the three-year horizon.
• Chapter 4, Named and External Credentials and Who’s Calling In: the credentials behind each row.