Pick the integration pattern before you pick the middleware

Integration projects begin with a tool comparison because a tool comparison feels like progress. It has a shortlist, vendors who return calls, a spreadsheet with weighted columns, and a decision at the end that somebody can announce. Pattern selection has none of that. It produces a short paragraph per interface and nothing to announce.

So the order gets inverted, almost every time. A platform is selected, then each interface is designed in whatever shape that platform makes easiest to build. The people doing it are not careless. It is simply the wrong way round, and the bill arrives long after the project that caused it has closed.

The claim here is narrow and strong. Every mainstream integration platform can implement every pattern, so the tool almost never determines whether an integration works. The pattern does, and in most programmes the pattern is not chosen at all: it is inherited from the first callout written in the first sprint, then copied, because copying was faster than deciding.

What each pattern is and what rules it out belongs in a reference, and we keep one: a working catalogue of Salesforce integration patterns. This is the argument for reaching for that reference before anyone opens a vendor comparison.

#Why the tool gets picked first

The reasons are good ones. That is what makes this hard to fix by telling people they have it backwards.

Procurement needs something to buy. A capital request needs a line item with a supplier against it. Integration architecture is not a line item. A platform licence is, and it can be approved, budgeted, contracted and reported on. The finance calendar rewards naming a product early, before anyone could reasonably know what the interfaces require. Nobody there is behaving foolishly. They are answering the question they were asked, which was how much and from whom.

A licence already exists. Somebody bought the platform for a previous programme, or it arrived inside a bundle nobody has fully inventoried. The marginal cost of using it presents as nothing, and using what the organisation already owns is ordinarily good discipline. The error is not using it. The error is letting "we already own it" stand as the answer to a question it cannot answer, which is how any particular interface should behave.

A vendor relationship is already working. The partner who delivered the last programme knows the estate, and starting again with an unknown supplier carries real risk. But every delivery organisation has a house pattern, the one its people are fastest and safest at, and that pattern will be proposed for interfaces it does not suit without anybody being dishonest about it. Familiarity is a genuine delivery advantage. It is not an architectural argument.

There is a fourth reason, less often said aloud. The tool decision is the only one in the room with an obvious owner. Nobody in particular owns pattern selection: it falls between an architect not funded to survey every interface, an analyst documenting requirements rather than behaviour, and a developer who will resolve it by writing something. Decisions with an owner get made. Decisions without one get defaulted, and a default is what you are looking at when every interface in an estate shares a pattern.

Each reason answers a real question. None answers the question that actually decides an interface, which is what should happen when the system on the other side is unavailable.

#What the wrong order actually costs

The costs are specific, and they do not look like integration failures when they arrive.

The estate that inherited one pattern. The platform chosen first was fastest at scheduled record movement, so that is what got built, including for the interface where a service agent needs to see whether a customer is entitled to a repair. The data is there each morning and stale by afternoon. Agents work this out and open the other system in a second tab, and the second tab becomes the process. No defect is ever raised, because nothing failed. The integration reports green for years while the workaround it created is absorbed into how long every call takes.

The callout that ended up in a save path. The first developer's tool made a synchronous call the easiest thing to build, so that is what shipped, inside a save. The availability of the org is now the availability of the system it calls. It surfaces during the far side's maintenance window, as users unable to save records, reported as a Salesforce incident, escalated to the Salesforce team, for a system that team does not own and cannot restore. The tool comparison had no column for that.

The platform bought for a single interface. One nightly extract from one system, no second consumer in prospect, on a runtime that now needs patching, monitoring, a deployment pipeline and somebody keeping the skill current. The licence is the visible cost and the smaller one. The standing operational obligation is the real cost, and it was never estimated, because the question asked was which platform rather than whether a platform.

Two projects, two tools, one field. Where the tool is chosen per project instead of the pattern per interface, two teams can write the same field from opposite directions on different schedules. Neither is wrong inside its own scope. The record alternates, support cannot reproduce it because the result depends on which job ran last, and the ownership question that would have prevented it was never asked, because no tool evaluation surfaces it.

None of the four fails on the day it ships. Each passes user acceptance testing comfortably, because acceptance testing exercises the happy path with both systems up. The cost lands afterwards: in an operations budget, in escalation volume, in a workaround nobody wrote down, and in a business that stops asking the integration team for anything.

#The questions that settle the pattern

Ask these per interface, never once for the programme. A single project routinely produces interfaces with opposite answers to all four, and answering once for the whole programme is how a pattern ends up applied where it should have been ruled out.

1. How stale may this data be? Answer in units the business recognises, and be sceptical of the phrase real time. Most requirements described that way turn out to mean within a few minutes, held by a sponsor nobody has asked what the number is for.
2. What is the volume at peak? Not the average. The Monday morning load, the end-of-month reconciliation, the seasonal spike. A pattern comfortable at average that meets a hard boundary at peak has not been chosen, it has been postponed.
3. Which direction, and who owns each field? For every field that moves, exactly one system is the source of truth. If two systems can write the same field and no precedence rule is written down, the design is not finished.
4. What must happen when the other side is down? Fail the save, queue and retry, drop it silently, or wake somebody. This eliminates most bad designs on the spot, and it is the question a tool evaluation never asks.

#Who has to be in the room

The answers are not held by the people usually invited to an integration workshop.

The owner of the far system has to be there, because questions two and four are about their system rather than yours: their maintenance windows, their availability commitment, whether their system can push or must be polled, what they do when their own dependencies fail. Assumptions about a system you neither own nor control are where patterns go wrong most often, and they are cheap to test when the right person is present.

The owner of the business process answers question one and settles what happens when the data is wrong. Not the sponsor, and not an analyst relaying a requirement: the person accountable when a customer is told something incorrect.

Whoever will be paged should be there, because question four describes their future. Queue and retry silently, or fail loudly at the point of use, produce very different lives for that person, and they are the only one present with an incentive to say so.

Someone who reconciles is the least obvious attendee and often the most useful. Finance or operations, whoever would notice if records had been quietly missing since a date nobody can establish. If nobody would detect that gap, the pattern about to be chosen carries more risk than the design records.

The vendor is invited after this session rather than to it. What comes out is short: per interface, the four answers, the pattern chosen, the patterns ruled out and the clause that ruled them out, and a line naming the owner of each contested field. With that in hand, the vendor conversation is a supplier conversation rather than a design workshop run by somebody with a product to sell.

#One estate, several patterns, probably several tools

A programme searching for the integration tool has usually not yet accepted that its interfaces differ. That search is the tell, and it is worth naming when you hear it.

The correct outcome for most estates is plural on both axes: a platform where there are several systems, several consumers and interfaces that will outlive the projects building them; native capability where the interface runs between the org and one other system and always will; a scheduled job for the extract that is genuinely just an extract; and no copy at all where data is read occasionally and never edited.

That plurality is not sprawl, and the distinction matters because fear of sprawl is the usual argument for standardising on one tool prematurely. Plurality is several tools, each with a named operator, each monitored, each in a register somebody outside the original project can read. Sprawl is when nobody can list what connects to what, and the answer to how this data gets here is the name of a person who left.

Standardise the operating discipline rather than the tool: how a failure is detected, who is paged, where ownership is recorded, what naming and logging look like. Do that and running three tools costs little more than running one.

#Quick reference

#The three rules that outlive the pattern

One owner per field. Bidirectional sync where both sides can write the same field without a documented precedence rule is not an integration, it is a race condition with a schedule. Write the ownership matrix and publish it. It is the most useful artefact the project will produce and the only one still being read in three years.

Idempotency everywhere. Every retry-capable pattern will retry, so every consumer must handle the same message twice without creating a duplicate or double-counting a value. External IDs and upsert are what make that true, rather than query-then-insert, which is both slower and racier.

Observability before go-live. You need to answer, without a developer: did this record sync, when, and if not, why. If the only way to answer that is a debug log, support escalates every question to engineering forever, and that cost quietly exceeds the licence.

#When the platform is already bought

This is where most people reading this actually are. The licence exists, it was announced, and somebody's judgement is attached to it.

Concede the purchase immediately, and mean it. Arguing about whether the platform should have been bought converts an architecture conversation into a procurement one, and architecture arguments do not win those. It also makes an opponent of the person whose recommendation it was, which costs you the next ten interfaces as well as this one.

The reframe that works is a distinction rather than an objection. A platform is a delivery capability. A pattern is a property of an interface. Owning a capability tells you what you are able to build; it does not tell you which interfaces should be built that way, any more than owning a database tells you what to store in it. Nobody has to be wrong for both statements to be true, which is what makes it a conversation people can stay inside.

Then stop arguing and take one interface, ideally one already causing visible pain, and run the four questions with the owner of the far system present. The answers do the work, and they arrive from the far side rather than from you. You are proposing a way of deciding rather than a reversal, which is far easier to agree to in a room where the money is already spent.

Be prepared for the answer to favour the platform, and say so publicly when it does. That is what buys credibility for the interface where the answer goes the other way. When it does, put the case in operating terms rather than architectural ones: forcing an interface through a platform that does not suit it produces a maintenance load people will later blame on the platform itself. Keeping it out protects the investment rather than undermining it, and the framing has the advantage of being true.

The version with no clean answer is a purchase that came with a committed volume of interfaces. Then the conversation is about sequencing rather than pattern: deliver the interfaces the platform genuinely suits first, use them to establish the operating discipline, and let the rest arrive later, by which time you have evidence rather than an opinion.

#Then choose the tool

With patterns settled, tool selection becomes short and far less contentious, because you are no longer comparing platforms in the abstract. The question is concrete: does this platform support these named interfaces, at this volume, with this retry and observability story, operated by people we have or can hire. That is a two-day evaluation instead of a two-month debate, and the only version where the spreadsheet means anything, because the columns now come from your estate rather than a vendor's feature list.

Where the answer is a platform, the layering decisions that follow matter too: API-led connectivity applied to a Salesforce estate. Where it is not, the engineering that keeps a direct interface alive for years is in Salesforce API integrations that survive contact with production. More on how we approach this: MuleSoft and integration services.