콘텐츠로 이동
SteveTechArcSteveTechArc Courses

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

Section titled “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

Section titled “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.

Thirty thousand feet: the whole landscape The Steve Trucking landscape from 30,000 feet: people on the left, one Salesforce org in the middle with the Retail Partner portal and the tracking page, the identity provider above, the integration layer to the right, and arrows connecting Salesforce with Snowflake, FleetLink, the finance ERP, photo storage, the SMS and email provider and three Retail Partners. One path is picked out in amber: Redrock's manifests come in through the integration layer and into Salesforce. Underneath: from 30,000 feet, a dozen systems and a tangle of arrows; pick one arrow, and it's a single building block. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.54.0", "built": "2026-10-30", "id": "DGM-INT-TL-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape 0.13.0", "theme": "stevetecharc 1.4.0"} ABOVE: IDENTITY, APPEXCHANGE, WEB PEOPLE RIGHT: INTERNAL SYSTEMS BELOW: CUSTOMER CHANNELS BOTTOM RIGHT: PARTNERS AND PROVIDERS Dispatch coordinators 45, inside 9 partner DCs Delivery crews ~700 on 330 trucks Care and office staff 100: service, ops, finance Retail Partner users ~300 at 3 partners Recipients ~1 million a year Corporate IdP SSO for office staff only Retail Partner portal Tracking page INTEGRATION Snowflake status history, analytics FleetLink raw GPS stays here Finance ERP invoices partners, pays crews Photo storage 4–5 million a year, off core RouteDesk archive retired; 8 years of history Phone care agents Email email-to-case SMS and email provider day-before message, with a link Redrock REST API, webhooks Keystone CSV over SFTP Brightwave EDI through a third-party network Salesforce Field Service, one US org a link, no login office staff only calls cases in manifests in status out manifests in status out manifests in status out upserts, partner key status events status events latest position only delivery counts delivery counts photos, from the crews' app day-before, with a link Salesforce a community people identity, apps, web an internal system a customer channel the integration layer starts at the system that opens the connection; the label says what moves a shared certificate: trust, no direct call the arrow we zoom in on From 30,000 feet: a dozen systems and a tangle of arrows. Pick one arrow, and it's a single building block. © 2026 Twinshark LLC · stevetecharc.com
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.

One arrow, four questions One arrow from the landscape, zoomed in. On the left, Redrock, a Retail Partner with a REST API; on the right, Salesforce, with the integration layer in front; an arrow labelled "manifests in" runs from Redrock to Salesforce. Below, four questions with an answer for each side. Who calls whom? Redrock calls in and is the client; Salesforce answers and can't fetch a manifest nobody sent. How much? About 1,100 deliveries a day; about 350,000 a year, growing 30% a year. How often? A set per distribution centre each evening, then single revisions; a coordinator must see a change before the truck leaves. What happens when it fails? Redrock needs an answer so it knows what to send again; on the Salesforce side: where do I log it, what do I tell the user, and how do I retry? Underneath: one arrow, zoomed in: two systems, one conversation, four questions. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.48.0", "built": "2026-10-28", "id": "DGM-INT-TL-02", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape/connection 0.13.0", "theme": "stevetecharc 1.4.0"} manifests in CLIENT Redrock SERVER Salesforce Retail Partner, REST API Integration layer in front REDROCK'S SIDE SALESFORCE'S SIDE Who calls whom? Redrock calls in. Redrock is the client. Salesforce answers. It can't fetch a manifest nobody sent. How much? About 1,100 deliveries a day. About 350,000 a year, growing 30% a year. How often? A set per DC each evening, then single revisions. A coordinator must see a change before the truck leaves. What happens when it fails? Redrock needs an answer, so it knows what to send again. Where do I log it, what do I tell the user, and how do I retry? One arrow, zoomed in: two systems, one conversation, four questions. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

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

Learning the Language

Section titled “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

Section titled “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

Section titled “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

Section titled “Explore”