Everything Is Knowable

Module 1 of 6 in the chapter Think Like an Integration Architect, chapter 1 of the Integration Architect course. Each module stands on its own. Next: You’re Already Doing Integration

The question this module answers: How do you learn the architecture domain with the most pieces, without it overwhelming you?

Integration is my favorite class to teach. I’ll admit it. And it’s also the one people walk into most nervous, because of all the architecture domains, integration has the most material. There are more protocols, more APIs, more acronyms, more ways for two systems to talk and more ways for them to stop talking.

So here’s the first thing I tell every class, and the idea this whole course is built on: if you just keep breaking things down into smaller pieces, everything is knowable. There is nothing in integration you can’t know if you go down into the detail. The challenge is only that the details add up, and you have to keep track of them.

It’s Like Building With Lego

Think about building with Lego. You can build a little car from a handful of bricks. Then one of my kids gets one of the big sets, a space station with thousands of pieces, and you think: how could anyone build that?

But you already know the answer. You build it one brick at a time, and every single brick is simple. You can hold it, turn it over, see exactly how it connects to the next one.

Integration is the same. Open any enterprise diagram and you’re looking at a very complicated system of flows: a dozen systems, arrows going everywhere, some of them in both directions, half of them labelled with acronyms. But if you look down at each individual arrow, it’s just a Lego building block. And we’re going to learn the Lego building block.

There are simply more bricks in this domain than in the others. That’s why the course is longer. It’s not because any one piece is beyond you. There’s no point in this course that’s beyond you. There’s just a fair number of bricks.

Start at 30,000 Feet, Then Land

If you’re flying a plane, you start at 30,000 feet. From up there you see the whole landscape: the cities, the roads between them, the rivers. You can’t see a single house, and you don’t need to. Then you come down, and the detail appears.

That’s how we’ll work, in every chapter. First the whole system landscape, every system in its place and every arrow drawn between them. Then we pick one arrow, and zoom in on it until it’s just two systems and one conversation between them. When we’ve understood that one, we zoom back out and see how it fits.

Click to enlarge

Thirty thousand feet: the Steve Trucking landscape we’ll build through this course. One arrow is picked out in amber.

The zoom-in is where the bricks are. Every arrow, however tangled the diagram around it, can be asked the same short questions: who calls whom, how much, how often, and what happens when it fails. Because errors will happen. So for every arrow I want to know: where do I log it, what do I tell the user, and how do I retry? You’ll hear me ask those questions all the way through this course. By the end, you’ll ask them before I do.

Click to enlarge

The amber arrow, zoomed in: two systems, one conversation, four questions.

Learning the Language

The other thing that makes integration feel bigger than it is: the vocabulary. We techies love speaking in three-letter acronyms. We even have an acronym for them: a TLA is a three-letter acronym. TCP, TLS, SSL, API, CDC, and when we run out, four-letter ones.

Every acronym in this course is a brick with a label on it. We’ll take each one, say what it stands for in plain words, and show what it does. That matters for more than the exam. A big part of an integration architect’s job is to give everyone on the project the same words for the same thing: the business, the Salesforce team, the team that owns the other system, the middleware team. When I say “fire and forget” to a development team, they should know exactly what I want them to build. A common vocabulary that works across your team and across the industry is one of the most useful things you’ll take away.

How This Course Climbs

The course climbs in three levels, the same three every course I teach uses: See, Design, Direct.

• See (Part 1) is how systems talk: thinking like an integration architect, the client and the server, what an API and a contract are, the tools admins already use, the landscape around Salesforce, the requirements, and the patterns. The first four chapters are written for admins, so if you’ve run a data load or set up an integration user, you’re already on the first step.
• Design (Part 2) is every way in and out of Salesforce, moving data at scale, events, trust and identity, reliability, orchestration, and how to choose and defend a design.
• Direct (Part 3) is the connected enterprise: where integration came from, the enterprise estate, data across boundaries and across orgs, agents and the tools they call, and reviewing designs. It ends with a capstone where we architect a whole company’s integrations together.

I teach it two ways at once. Some of you want the Platform Integration Architect certification, and the course covers the exam guide’s six areas, from evaluating the current system landscape to maintaining the integration. Others just want to be a good integration architect. You’ll get both. Where something is likely to be on the exam, I’ll say so; nothing here is only for the exam.

And here’s what I want you to be able to do at the end. When you start a project and there’s more than one system involved, which today is almost every project, you’ll be able to start asking the right questions from day one, and carry that project all the way through. That works for a small project, a little single-engine plane, and it works for a project the size of a massive airliner. The bricks are the same. There are just more of them.

What an Architect Decides Here

• Whether you’ve seen the whole landscape before you start designing any single arrow.
• Which arrow to zoom in on first: usually the one with the most volume, the most risk or the most unanswered questions.
• Which of the simple questions each arrow still can’t answer: who starts it, how much, how often, and what happens when it fails.
• Which words your project will use for each pattern and mechanism, so every team means the same thing.
• What you don’t know yet, and where to find it out. Everything is knowable; not everything is known on day one.

Beyond the exam: what AI changes. AI can now write a callout, a mapping or a whole integration class in seconds. When I first tried it, it wrote me beautiful code with the endpoint URLs typed straight into it, so I asked it to use a named credential instead, and it did. That’s the point: you need to know where you’re going, and you need to recognize good code and bad code. It can save you a lot of typing, but someone still has to know every brick it’s using.

Explore

• Salesforce Help, Salesforce Certified Platform Integration Architect Exam Guide (opens in a new tab) (article 005298980), the six exam areas and their weightings; aligned to Summer ‘23, checked 2026-11-01.
• The next module, You’re Already Doing Integration: the integration work admins already do.