Choosing the Right Integration Design

Chapter 16 of Integration Architect, Part 2: Designing Integrations That Work (Design). Previous: Integration Orchestration · Next: The Story of Integration (coming soon).

Part 1 gave every arrow a pattern. Part 2 taught the mechanisms one by one: the calls in, the calls out, the bulk loads, the events, the identities, the failure handling, the orchestration. This chapter puts them together. For each integration, which mechanism, and why? And can you say why, so that someone else could check it?

There’s rarely one right answer. There are many ways to solve a problem, and a few of them are good. This chapter is about choosing among those few, and defending the choice.

The running example is Steve Trucking, from one arrow, the day-before message, to the whole company under load in Checkpoint 2.

The ideas in this chapter

Pattern first, then mechanism. “Fire and forget” is a pattern; a platform event is one way to build it. Every pattern has several mechanisms, and the pattern narrows the choice without making it.
Read Salesforce’s decision guide well. Its advice is strong: don’t copy data you don’t need, use the integration platform you already have, no new investment in outbound messaging. Read its legend, its footnotes, its date and the guides around it, and check it against the product’s own pages.
Forces choose the mechanism. Coupling, consistency, scale, latency, security, the team’s skills and the running cost. When two pull against each other, the requirement says how far each one may go.
Choose between imperfect options. A balanced solution: optimal parts, sub-optimal parts on purpose, and no parts that only work until real volume arrives. Present both options fairly, then: “In my professional opinion…”
Combine mechanisms, and count what they cost. Copy what people search and act on; look at the rest. Do the licence math on today’s table, and ask whose API allocation every read spends.
Write the design down. One record per arrow: the data contract, plus the mechanism, the identity, the failure plan, the owner, the running cost and the date it was checked.
Check the whole, not each part. Add up the event deliveries and the API calls for the whole org, today and in three years.

The path through this chapter

Seven modules, each standing on its own.

Pattern First, Then Mechanism. Two words in one breath; the order to think in; each pattern and what carries it; one arrow, three ways to build it.
Salesforce’s Decision Guide, Read Well. A guide for “it depends”; what it says up front; primary tools and supporting ones; five habits for reading it well; what no guide can tell you.
The Forces. Forces, not a formula; seven forces; forces pull against each other.
Trade-offs, the Course’s Way. Choose between imperfect options; a balanced solution; what goes bad in a year; present both, then say what you think; the trade-off card.
Combining Mechanisms, and Licensing Them. Most designs are more than one mechanism; a hybrid; do the licence math; the limits that shape a hybrid.
Write the Design Down. A design nobody wrote down; one record, two halves; the day-before message, written down; what the record is for.
Checkpoint 2: Steve Trucking Under Load. Every arrow, its mechanism; the meter; three years out; what I’d still check.

Part 3 starts with chapter 17: where integration came from, and where it’s going.

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

For every arrow: the pattern, then the mechanism, and the reason, said out loud.
Which of Salesforce’s recommendations the design follows, where it doesn’t, and why.
Which forces matter for each arrow, and how far each may go.
For every real trade-off: both options, fairly, then your professional opinion, in one breath.
What’s copied and what’s viewed, and the licence count on today’s table.
One record per arrow, kept current the day the design changes.
The sums for the whole org, today and at year three, and what they require.

Beyond the exam: an AI assistant can draft a mechanism for every arrow, both sides of every trade-off, and a record for every integration, in minutes. That’s a real help. What it can’t do is own the call, or know which line in the record nobody actually decided. The professional opinion is still yours, and so is the sum at the bottom of the page.

Explore

Salesforce Architects, Data Integration with Salesforce (opens in a new tab): Salesforce’s own decision guide.
Salesforce Help, Salesforce Connect Adapters Included per Add-On License (opens in a new tab): the licence table.
Checkpoint 1: Steve Trucking, What I Would Architect: where Part 1 left off.

Next: The Story of Integration (coming soon)