Connected vs. Integrated: The Distinction That Matters

"Connected planning" is the most overused phrase in apparel software marketing. Every vendor claims it. Almost none of them mean the same thing by it. The distinction is not pedantic — it shows up at the three moments where mid-market apparel teams lose the most margin.

The two architectures

There are two architectures that get called "connected planning" in the market.

Integrated planning is what most enterprise platforms ship. OTB, assortment, buy plan, and allocation are separate modules — sometimes from different acquisitions, sometimes built in-house — connected by APIs and a shared data layer. From the buyer's perspective, the connection is real: data flows from one module to the next, reports roll up across them, and a sufficiently determined integration team can keep them in sync.

Connected planning, properly defined, is one model. Not multiple modules that share data — one model where OTB, assortment, buy plan, and allocation are different views into the same underlying object. When a style depth changes, the OTB position updates because it is the same data, not because an integration job propagates the change.

The two architectures look identical in a vendor demo. They diverge sharply in production.

Where the distinction shows up

Reconciliation under pressure

In an integrated architecture, reconciliation is a process — periodic, batched, and almost always behind the team's actual decisions. The integration job runs nightly, or hourly, or on-demand. Between runs, the modules are out of sync. In the buying week, the cost of being out of sync is 1–3 points of IMU per event.

In a connected architecture, reconciliation is not a process — it is a property. There is no out-of-sync state, because there are not multiple states. The reconciliation cost during the buying window goes from "managed" to "absent."

In-season change propagation

In an integrated architecture, when a style is cut mid-season, the change has to propagate from the assortment view to the buy plan to the OTB to the allocation profile to the reports. The propagation is reliable in the steady state and unreliable under exception conditions — which is exactly when the team needs it most. The team learns to manually verify the change in each downstream view, which means the integration provides much less leverage than its description implies.

In a connected architecture, the change is the assortment, the buy plan, the OTB, and the allocation profile. There is nothing to propagate. The unreliability under exception conditions disappears because there is no propagation step.

Policy enforcement and audit

This is where the distinction matters most for executive teams.

In an integrated architecture, governance — approval thresholds, decision logs, policy enforcement — has to be applied at each module. A buy commitment threshold exists in the buying module; an OTB exception threshold exists in the planning module; an allocation override threshold exists in the allocation module. They can all be configured. They are not the same control. A buyer who exceeds OTB at the assortment-build stage does not trip the buy-commitment threshold, because the threshold lives one module downstream.

In a connected architecture, the threshold attaches to the decision, not the module. A commitment that exceeds OTB triggers the same approval flow whether it originates in the assortment build, the buy plan, or the post-PO change. This is what auditors actually want to see when they ask about decision authorization.

Why the market accepts integrated as connected

The market accepts integrated planning as connected planning for a structural reason: most enterprise vendors built their platforms by acquiring point solutions and integrating them. The architecture is what it is. Calling it "connected" is true at the experience layer for the steady state and false at the exception layer where the value is.

The mid-market gap exists because the integrated architecture's overhead — implementation time, configuration depth, ongoing data engineering — is a fit for enterprise economics and a poor fit for $20M–$500M apparel brands. The platform that solves the mid-market opportunity is not "enterprise lite." It is a different architecture, designed for the segment.

What to ask in evaluation

For procurement teams trying to distinguish connected from integrated in a vendor evaluation, three questions reliably separate them:

1. →

   "When a style's depth changes, what updates and when?" A connected platform answers "all dependent views, immediately." An integrated platform answers with a description of the propagation path.

2. →

   "What happens to OTB enforcement when a buyer overrides a depth target?" A connected platform applies the OTB threshold to the override at the moment of override. An integrated platform applies it at the next module-level check, which may be hours or days later.

3. →

   "Can I see the full audit trail of a single style across the season?" A connected platform produces this in a single query. An integrated platform produces it from multiple module-level logs that have to be correlated by timestamp.

The honest answer to each of these questions reveals the architecture. The vendor's marketing language does not.

Why this matters for mid-market

Connected vs. integrated is an architecture conversation, but the consequences are operational. Mid-market apparel teams do not have the engineering capacity to keep an integrated stack synchronized through the buying window — that is the work that gets pushed to the spreadsheet stack, which is how they ended up with the spreadsheet stack in the first place.

The platform that displaces the spreadsheet stack in mid-market apparel is not a smaller version of the enterprise model. It is the connected architecture, built for the segment that cannot afford to maintain integration as a function. That is the thesis behind RetailNorthstar, and it is why the distinction between connected and integrated is the most important one in this category right now.

See the connected architecture in a 30-minute demo.