Owners, Boundaries and Change

Module 5 of 6 in the chapter Think Like an Integration Architect, chapter 1 of the Integration Architect course. Each module stands on its own. Previous: The Building Nobody Described · Next: Plan for Failure

The question this module answers: Why do integrations break when nothing in them changed, and what does the architect decide to prevent it?

Here’s a call every integration architect gets eventually. The integration that has run every night for a year stopped working this morning. Nobody touched it. The code is the same, the schedule is the same, the credentials are the same.

So what changed?

Almost always, the answer is: something on the other side of the arrow. A field was renamed. A password, a secret or a token was reset. The other system was upgraded. Somebody made a perfectly reasonable change to their own system, and the integration, which crosses into that system, broke.

That’s the last idea in this chapter, and it’s the one that stays with you longest: every system has an owner, every arrow crosses a boundary, and integrations break when one side changes without the other knowing.

Every Arrow Crosses a Boundary

Draw any two systems and an arrow between them. The arrow leaves one system and arrives in another. That point where it crosses is a boundary, and on each side of it is a different owner: a different team, often a different company, with its own priorities, its own release dates and its own reasons to change things.

So for every arrow, part of the architect’s job is to decide where each side’s responsibility stops. The system that answers, the server, makes itself available, checks what comes in, does its own logging and its own debugging, and when it finally releases the answer back, its responsibility stops there. The system that called, the client, is responsible for what happens on its side: tracing connection errors, authentication errors and the errors the server passes back. Chapter 2 takes that apart properly. For now, the point is that the line exists, and somebody has to draw it before something goes wrong, not after.

What Breaks When One Side Changes

Let me give you the most common way I see it happen.

An outside team, often a middleware team, needs to reach into Salesforce. There’s a decision to make, and it needs to be made in the very first week or two of the project, while you’re still in design. Do they call Salesforce’s standard API, or a custom one you build for them?

If you give them the standard API, they reach straight into your objects and fields. That works, but it means that team needs to be in your meetings. Because if you rename a field, add a picklist value or change a custom object and they don’t know about it, it’s going to break. Nothing in their integration changed. Something on your side of the boundary did.

If you build them your own contract instead, a small set of calls such as get customer and save customer, you need good Apex developers on the Salesforce side. But now you can change what’s behind the contract, the fields, the objects, the automation, and as long as you keep the contract, they’re fine. That’s a separation of responsibility.

Click to enlarge

Where you draw the boundary decides what breaks when your side changes.

Neither one is always right. A small team that sits together can live with the standard API. Separate teams, separate companies or a long-lived integration usually want the contract. Chapter 17 comes back to this decision with the whole enterprise around it. What matters here is that it’s a decision about the boundary, and it has to be made on purpose and early.

Change You Don’t Control

Some changes come from people you’ll never meet.

Credentials are the simplest example. Picture an ERP that three other systems sign in to, each with its own credentials, as they should. In older integrations that’s a username and password; today it’s more often a client ID and secret, or a token. Now one of those systems is breached and you have to reset its credentials or tokens. Either way, the reset is the same kind of work: you need to go and talk to every other system that calls it. The more systems connect directly to each other, the tighter those interconnections get, and the more one change ripples. Chapter 5 does the math on that.

And the platforms change too. Salesforce releases three times a year, and each release can bring a new API version, a retirement date or a new default. You saw one in the second module of this chapter: connected apps reaching end of support, with a date. Nothing in your integration changes on that date. The platform around it does. Somebody has to own watching for those dates, and somebody has to own the work they cause.

A change you planned for is a change. A change nobody told you about is a failure, and that’s the last module of this chapter: what happens when an arrow stops, and how it comes back.

What an Architect Decides Here

• Who owns each system on the landscape, and who to call when it changes.
• For every arrow, where each side’s responsibility stops.
• Whether an outside team calls the standard API or a contract you own, decided in the first weeks of the project.
• How changes on either side of a boundary are announced, tested and agreed before they ship.
• Who watches for platform release and retirement dates, and who owns the work they cause.

Explore

• The next module, Plan for Failure: what happens when an arrow stops, and how it comes back.
• Salesforce Help, Migrate All Connected Apps to External Client Apps (Release Update) (opens in a new tab), Winter ‘27, checked 2026-11-01: an example of a dated platform change.