Stop Designing Integrations Around Systems. Start Designing Around Streams.

Integration strategies can fail long before a line of code is written.

Not because the tools are wrong, or the engineers are not capable.

But because teams start with the wrong mental model.

Too often, integrations are designed around systems such as Shopify, NetSuite, Microsoft Business Central, or a WMS, instead of around the streams of data that actually define how a business operates.

The issues usually show up as:

• Orders that cannot be explained when something goes wrong

• Inventory numbers no one fully trusts

• Finance teams manually rebuilding reality in spreadsheets

• Engineers afraid to change anything because every change breaks something else

At HighCohesion, we think about integrations differently. We think in streams, not systems.

This is not about one approach being right and the other wrong. They are fundamentally different ways of understanding the same reality. One is anchored in systems. The other is anchored in the flow of data over time.

Systems Answer: “Where Does This Live?”

Streams Answer: “What Happened and What Happens Next?”

Most teams default to a system-centric view of integrations, described in terms of connections such as Shopify to NetSuite or Microsoft BC to Peoplevox.

The focus ends up being on keeping systems aligned rather than understanding how the data actually flows through the business.

System-centric thinking is good at answering questions like:

• Where does this data live?

• Which system is the source of truth?

• How do we keep records in sync?

But those are not the questions that cause problems at scale.

Stream-centric thinking starts somewhere else entirely. It asks:

• What happened?

• In what order did it happen?

• What needs to happen next?

An order is not as simple as a record sitting in an ecommerce platform. It is a stream of events that starts when an order is created and continues as it is paid, edited, fulfilled, returned, refunded, and settled. That difference, static records versus evolving flows, changes how decisions get made. Rather than treating downstream consequences as an afterthought, it makes them a priority.

Consider this example:

In a system-first model, you end up having to pick an arbitrary cutoff point for when an order is “real” enough to push into the next system. Send it to the WMS too early, and stock gets locked against a version of the order that is about to change. Send it too late and fulfilment slows down, while finance and reporting start drifting because different systems are looking at different snapshots.

In a streams model, that decision becomes explicit. The order is treated as a timeline of events: order created → paid → edited → items swapped → address updated → partially fulfilled → remainder fulfilled. Downstream systems do not have to guess what changed, or when. The WMS can reserve and release stock based on specific events, not a single “current state” row. Finance and reporting can reconcile against the sequence, so when Shopify no longer reflects the full picture, the business still can.

System-centric integration design works early on when businesses are small, because change is infrequent, and ownership is usually centralised. But as soon as growth introduces complexity, the problems begin.

For example, small changes like adding a new shipping method or payment option, or allowing exchanges instead of refunds, can spell big trouble.

Yes, systems make those changes feel easy, but that doesn’t mean they will work through the entire stack.

Let’s take a closer look at how system thinking can impact operations.

When orders are treated as “Shopify data”, downstream logic starts making dangerous assumptions:

• That the current state reflects everything that has happened

• That edits elsewhere do not matter

• That timing and intent can be inferred later

Those assumptions break as soon as something happens out of order, which is exactly how real businesses operate.

In a stream-based model, an order is a time-ordered sequence of events, including creation, payment, edits, fulfilment, returns, refunds, and settlement.

No single system observes or controls an order through that entire lifecycle. For that reason alone, no single system can own the truth.

Sales, holds, allocations, returns, and adjustments all affect inventory. These events often occur out of order, across different systems, and compete for the same inventory pool.

When inventory logic is scattered across systems, each system can be locally correct while the overall picture is wrong, meaning out-of-stock items, overselling, and painful reconciliation become inevitable.

Streams force inventory to be treated as what it actually is: a flow of competing claims over time, not a number that can simply be synchronised.

Products are rarely as static as systems assume.

Think pricing changes, availability shifts, bundles, and recategorisation. These types of simple product edits can unexpectedly break fulfilment, pricing, or reporting because downstream systems assumed products were stable.

Treating products as a stream of truth allows teams to change product data where it makes sense while ensuring those changes flow predictably to every system that depends on them.

Returns are sometimes bolted on as an afterthought and modelled as reversals instead of processes. That carries risk.

A returns stream makes visible what systems often collapse into a single state:

• Request

• Approval

• Transit

• Receipt

• Refund

Without that flow, teams lose timing, accountability, and the ability to see or explain what actually happened.

Financial data almost never maps cleanly to a single system.

Fees, holds, chargebacks, adjustments, and settlements are applied at different times by different actors. When teams assume one system owns financial truth, they end up with balances that look right but cannot be explained, audited, or reconstructed.

The problem usually only becomes visible when something goes wrong. At that point, the story of how the numbers were produced has already been lost.

Streams-based thinking handles complexity like a breeze.

For example, when businesses replatform, streams allow the flow to stay constant while implementations change. When new tools are added, teams can mould the tools to the business rather than forcing the business to fit the tools. When companies expand internationally, variations in tax, currency, and fulfilment become interpretations of the same flow instead of forks in logic.

Thinking in data flows instead of individual systems brings the implications of change to the surface earlier, so fewer assumptions slip through, and there are fewer surprises later.

Honestly? Streams do not make things faster. But they do make them safer.

The hardest part of streams thinking is letting go of the idea that there is a single, simple source of truth.

Small changes require more upfront analysis because the whole picture must be considered. But ultimately, that means the cost is paid once instead of repeatedly through breakage and reconciliation.

Streams force teams to accept that downstream always matters.

Streams do not remove complexity, but they do make it visible, traceable, and survivable.

For teams growing fast or operating at scale, that difference is everything.

If you want integrations that survive change, perform under pressure and scale without constant reconciliation, start with what happened, not where it lives.

Everything else becomes clearer from there.

At HighCohesion, we design integrations that can be replayed, explained, and changed without rewriting business logic every time something evolves.

When orders are treated as “Shopify data”, downstream logic starts making dangerous assumptions:

• That the current state reflects everything that has happened

• That edits elsewhere do not matter

• That timing and intent can be inferred later

Those assumptions break as soon as something happens out of order, which is exactly how real businesses operate.

In a stream-based model, an order is a time-ordered sequence of events, including creation, payment, edits, fulfilment, returns, refunds, and settlement.

No single system observes or controls an order through that entire lifecycle. For that reason alone, no single system can own the truth.