Framework

The architecture fit framework: how to run discovery and strategy before platform selection

Discovery and strategy is the framework Acro runs before any platform decision. It surfaces the operational truth, maps it against architecture options, stress-tests the trade-offs with the people who will operate the stack, and produces a platform-neutral recommendation a CFO can fund and a CIO can defend. Four phases, six to eight weeks, one deliverable a build team can execute against.

Why discovery beats implementation as a starting point

Implementation starts when the architecture and platform decisions are already made. If those decisions are right, implementation goes well. If they are wrong, implementation is the most expensive correction tool the business has. The discipline of the framework is to spend a few weeks getting the decisions right rather than a few quarters correcting them.

The framework is structured because mid-market B2B operating models are complicated. Customer-specific pricing, contract terms, multi-warehouse inventory, approval chains, and account hierarchies do not yield to a workshop. They yield to a sprint that asks the right questions of the right people, writes the answers down, and tests them against the architecture options before anyone signs a contract.

The four phases below take six to eight weeks together. Shorter and the operational truth is under-investigated. Longer and the project stalls in analysis. The phases are sequential because each one feeds the next; running them in parallel collapses the discovery into a kickoff.

Step one: surface the operational truth

The first phase is structured interviews and data review. We talk to the people who run the order-to-cash flow daily: the order desk, a working sales rep, a working CSR, the ERP administrator, the buyer-experience owner, and the executive sponsor. We do not run the interviews against a generic template. We run them against the questions the architecture decision actually depends on.

The questions cover: how a quote becomes an order, how an order becomes a shipment, how a shipment becomes an invoice. How customer-specific pricing gets applied, when contract terms override list price, when a freight surcharge gets calculated and by whom. How approvals route, what triggers them, what an exception looks like. How inventory is committed, how partial shipments work, how backorders surface to the buyer.

We write down the contradictions as well as the consistencies. When three people give three different answers to the same question, that gap is operational truth waiting to be reconciled. The output of step one is a business-rule catalogue, not a slide deck. It is the artifact every later phase reads.

Step two: map business logic to architecture options

With the business-rule catalogue in hand, the second phase tests it against the three practical architecture paths: native ERP commerce, middleware-led integration, and decoupled commerce. We do not start with a platform shortlist. We start with the architectures themselves, because the platform decision flows from the architecture decision and not the other way around.

Each rule in the catalogue gets two annotations. First, where does it have to live? Real-time in the ERP, eventually consistent through middleware, or owned by the commerce platform with a write-back to the ERP. Second, what kind of integration does it imply? A synchronous call, an event subscription, a nightly batch, or no integration at all. Those two annotations produce a clear picture of how much real-time ERP exposure the architecture requires.

The picture usually points to one or two architecture paths cleanly. The other paths can be ruled out for written reasons. That written rationale is what makes the recommendation defensible when the board asks why a particular path was chosen and why the others were not.

Step three: stress-test the assumptions with stakeholders

The third phase is alignment. We bring the leadership team, the buying committee, and the people who will operate the stack post-launch into the same room with the same artifacts. The architecture path is presented with its rationale. The trade-offs are named honestly. The conversation forces conflicts that the executive offsite avoided.

The CIO wants stability, the VP of Sales wants flexibility, the COO wants efficiency. The architecture choice cannot satisfy all three completely; the discipline is to name which one wins and why. Alignment that emerges in this phase is alignment that holds through implementation. Alignment papered over here cracks during UAT, when correction is most expensive.

A useful test for whether the stress-test actually worked: at least one assumption the executive team walked in with changes. If nothing changes, the room was being polite rather than honest. Practical optimism includes the willingness to say so.

Step four: produce a platform-neutral recommendation

The fourth phase converts the architecture decision into a platform recommendation. With the architecture path chosen, the platform shortlist becomes narrow and defensible. Each shortlisted platform gets scored against the capability matrix the discovery produced. The platform that wins is the one that carries the matrix cleanly, with the integration patterns the architecture implies, at an operating cost the team can sustain.

The recommendation is written in language the CFO can fund and the CIO can defend. It names the platform, the integration partner, the major customizations the project will require, the major customizations it will not, and the operating model the team will inherit. It also names the runner-up platform and the reason it was not chosen, because runner-ups are how funding committees pressure-test a recommendation in the room.

The deliverable is not a slide. It is a written brief a build team can execute against, a CFO can fund, and a CIO can defend in a board meeting. That is what makes discovery and strategy different from a kickoff workshop and from a vendor pitch. The output is the artifact, not the meeting.

How Celeste accelerates the diagnostic

Celeste is the AI-assisted commerce diagnostic Acro uses to compress the first phase. It asks the structured questions an interviewer would ask, takes the leadership team's answers, and produces a first-pass read on the architecture options within hours rather than weeks. The output is not a recommendation. It is a starting point the human architects then pressure-test against the operational truth that interviews surface.

For a leadership team that wants an honest read before committing to a full discovery sprint, Celeste produces enough signal to decide whether to fund the sprint and what scope to give it. For a sprint already in flight, Celeste accelerates the interview cycle by surfacing the questions worth asking next. Either way, the principle holds: AI accelerates the diagnostic; the architect makes the call.

Use Celeste as the front door to this framework rather than as a substitute for it. The framework is what produces a recommendation a build team can execute against. Celeste is what gets the framework started faster.

Frequently Asked Questions

Next step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.