Module 5 · The Systems & Data Layer · Chapter 22 of 32
Integrations and the RevTech Stack
A stack without a declared system of record produces as many truths as it has tools. Pick one owner per domain, sync in one direction, and buy the plumbing you should never build.
10 min read
The number on the board slide was total company ARR. I had pulled it from Salesforce, summed the active subscriptions, and it was low by roughly two million dollars. Not a rounding error and not a broken formula. The self-serve business, about $2M of recurring revenue, bills through Stripe and never writes a record into the CRM. Salesforce had never been the system of record for that revenue. Everyone treated it as if it were, because it was the system everyone looked at.
That gap is the whole subject of this chapter. A go-to-market stack without a declared system of record produces as many versions of the truth as it has tools, and the org discovers which one was authoritative at the worst possible moment. Module 3 argued in the Operating Model that tools and methodologies have to interoperate through one interface or they multiply into chaos. Module 5 has been making that concrete: the CRM data model turned the Bowtie into real objects, and automation architecture made the logic on top of them debuggable. This chapter is the plumbing between the tools: who owns which fact, how a change in one system reaches another, and which of those pipes you should buy instead of build.
Pick a system of record before you pick a connector
A system of record is the single place a given fact actually lives. Not the place it is most convenient to read, and not every place it happens to be stored, but the one system that owns the write. Everything else that holds a copy of that fact is a subscriber, and a subscriber reads it rather than edits it. The discipline is not “one database.” Modern stacks are federated on purpose, because Nue prices a quote better than Salesforce ever will and Vitally scores health better than a CRM report. The discipline is that each domain has exactly one owner, and the rest of the stack knows who that is.
Here is the stack this course grounds in, drawn as a hub with an ownership label on every node.
The reason a hub matters is arithmetic. Wire six systems directly to each other and you own fifteen point-to-point integrations, because n systems need n(n-1)/2 links. Every one is a place a schema change can break a sync you forgot existed. Route them through a hub, or through a middleware bus, and the count drops to six. That is the same lesson automation architecture taught about flows: proliferation is not caused by any single bad decision, it is what you get by default when nobody owns the topology.
So the first artifact this chapter asks you to produce is not a connector. It is a one-page ledger: for each domain (account, opportunity, price, order, forecast, health, billing), name the system of record and the direction data flows. In this stack, Salesforce owns the account and the opportunity, Nue owns the price and the order and writes the closed ARR back into Salesforce, Clari owns the forecast call it computes off Salesforce data, Vitally owns the health score and writes it back, Stripe owns self-serve billing, and Snowflake owns nothing operationally but is the historical record everything replicates into. Write that down and half your integration arguments end before they start.
Sync patterns, and the ways they fail
Once ownership is settled, the question is mechanical: how does a change in the owner reach its subscribers, and how do you keep that from turning into a feedback loop. The patterns are few. The failure modes are specific.
- 1
Default to one direction
Sync one way from the system of record outward. Make bidirectional the exception you can justify by name, because two-way sync is where every loop and every race condition is born. Most edges only need the owner writing and the subscriber reading.
- 2
Key every write on a stable external ID
Make the sync idempotent: replaying the same event twice must change nothing. If your upsert matches on a durable external ID rather than a fuzzy name, a re-delivered webhook is harmless instead of a duplicate.
- 3
React to events, not tables
Fire on the change (a webhook or platform event) instead of re-scanning whole objects on a timer. Batch only the sources that give you no event to listen for. Polling everything is how you hit rate limits and how you notice drift a day late.
- 4
Suppress the echo
When Vitally writes a health score back to Salesforce, that save must not re-trigger the flow that pushes Salesforce changes to Vitally. Tag system-originated writes so the reverse sync ignores them. Skip this and the account ping-pongs.
- 5
Reconcile on a schedule
Sync drifts no matter how clean the design. A nightly job that counts records per domain in the source and each subscriber, and alerts on a mismatch, catches a silent drop before a board slide does.
The failure that costs the most is the one that compounds with automation you already have. This is where the two Module 5 chapters collide.
Buy the plumbing, build the logic
The last decision on every edge is buy or build. The rule that keeps this from becoming a religious argument: buy the commodity plumbing, build only the logic that is actually yours.
| Buy the connector / iPaaS | Build it yourself | |
|---|---|---|
| Where it fits | Standard sync between two popular SaaS tools (Salesforce and Vitally, Salesforce and Clari) | A mapping no vendor sells, or logic that has to live inside your own data contract |
| Time to live | Days: configuration, field maps, no code to own | Weeks to months, and then you own it for as long as it runs |
| Who owns a break | The vendor: their SLA, their changelog, their on-call | You: every upstream schema change is your pager |
| Cost shape | A subscription that scales with seats or record volume | Engineering time up front, cheap at the margin after |
| Best used for | The 80% of edges that are undifferentiated pipe | The handful of edges that are your actual advantage |
The trap is building the commodity edges because they look easy, then having no engineering left for the edges that matter. A CRM-to-CS sync is a solved problem someone maintains for a living; buy it. The rule that decides whether Nue lets a discount through, or the routing that puts an inbound lead on the right owner in seconds, is your revenue logic, and it belongs in code you control and in the system of record it protects. Reverse-ETL out of Snowflake sits in the same frame: buy the pipe that pushes a computed segment back into Salesforce, do not hand-roll it.
Interoperability is Breakpoint 10, made physical
Revenue Architecture places interoperability at Breakpoint 10 on the growth S-curve, in the same Growth Model that gave us the twelve breakpoints. It names three elements: one standardized data model (the Bowtie), one common language (Impact), and one open interface (SPICED). The Operating Model chapter installed those three as agreements between teams. This chapter is where the agreements meet infrastructure. A system of record is the Bowtie made physical: the actual place a given stage of the lifecycle lives, so that “qualified opportunity” or “closed ARR” resolves to one system and one definition instead of a negotiation between dashboards.
The book’s claim that interoperability is the precondition for AI is not a slogan, it is literal. You cannot point an agent, or even a dependable routing rule, at a stack that stores ARR in three systems with three definitions and expect a trustworthy answer. The agent will confidently return whichever number it reached first. Everything the systems academy builds on top of this stack assumes the ownership question was answered first.
Handoff
You can now draw your stack as a hub, name the owner of every domain, wire each edge one direction with an echo guard, and split buy from build without a fight. One thing this chapter deliberately did not solve: sync is a multiplier, not a cleaner. It faithfully propagates whatever quality exists at the source. One bad account replicated to five subscribers is now five bad accounts, and a fast, well-designed pipeline just spreads the error faster. So the last stop in the systems layer is keeping the owner itself trustworthy. Next, in Data Governance and Quality, we install the stewardship and the change process that keep the system of record worth being the record.