CASE STUDY & SCENARIOS

How architecture decisions play out in practice.

One anonymized engagement and two situations technology leaders face often, with the questions and trade-offs behind each decision.

Read the case study Download the PDF ↗

Real engagement, anonymizedScenarios clearly labelledNo invented metrics

CASE STUDY · RETAIL · POST-ACQUISITION

Two ERPs and one ordering process, six months after an acquisition

A transitional architecture that integrated two ERPs and the ordering processes within six months, and gave the business team room to run the real transformation.

IndustryGrocery retail
TriggerAcquisition by a larger retail group
TimeframeSix months from the acquisition
ScopeTwo ERPs and the ordering processes

Context

A retail network was acquired by a larger group. Each company ran its own ERP, and the ordering processes depended on them. A single ERP was the long-term goal, but a full migration could not be done safely in the time the business needed.

The challenge

The combined business needed working ordering processes across both organizations quickly, without stopping operations and without forcing a rushed migration that would lock in decisions before the new operating model was clear.

The outcome

Both ERPs and the ordering processes were integrated within six months of the acquisition. With the systems working together, the business team had room to carry out the real transformation and remodelling on its own timeline, instead of under integration pressure.

The approach: a transitional architecture

Coexistence by design. Both ERPs stayed in place for their own scope; an integration layer connected them instead of replacing either.
Clear data ownership. For each core entity (items, suppliers, stores, prices, orders) one system was the owner, with a mapping between the two coding schemes.
One ordering process. Ordering was harmonized end to end, so users worked with one process regardless of which ERP executed it.
Built to be temporary. Every transitional interface had an owner and a decommissioning path, so the intermediate state would not become permanent legacy.

What CTOs can take from it

After an acquisition, the target state does not have to be the first step. A deliberate intermediate architecture buys time for the decisions that matter: define data ownership before building interfaces, harmonize the business process before the systems, and plan the exit of every temporary component from day one.

Client name and identifying details are not published. Typical deliverables in an engagement like this: transitional architecture blueprint, data ownership matrix, interface catalogue and decommissioning roadmap.

SCENARIO 1 · ILLUSTRATIVE

Buy or build in the AI era?

A company starts building an AI capability in-house. Halfway through, vendors and foundation models ship much of the same capability as a standard feature. Should the team continue, change course or buy?

Questions to answer first

Is it a differentiator? Build only where proprietary data or processes create an advantage competitors cannot buy.
How fast is the market moving? If vendors are likely to match the capability within 12–18 months, a long build is a bet against the market.
Who owns quality over time? AI output degrades silently as data, models and usage change.
What is the full cost? Include the team that runs, evaluates and updates it, not only the one that builds it.
Can you leave? Check data portability and how hard it is to switch models or vendors.

How we would approach it

Buy when the capability is becoming standard, vendors improve it faster than you could, and you can test its quality on your own data.
Build when it depends on your data or processes, is part of what makes you different, or regulation requires full control.
Most often, compose: buy the model or platform and build the thin layer that holds your data, workflows and evaluation.
Overtaken project: review it at fixed checkpoints against what the market now offers, and judge the remaining value, not the effort already spent.
Team size: keep a small cross-functional team (product owner, one or two engineers, someone who owns evaluation, a domain expert) until value is proven, then scale.

Quality over time

Plan for quality from day one: a test set built from real cases, agreed quality measures, monitoring in production and permanent capacity for evaluation and updates. Without them, neither a bought nor a built solution can be trusted a year later.

SCENARIO 2 · ILLUSTRATIVE

State of the art, or just good enough?

Leadership wants the newest architecture (event streaming, microservices, an AI platform), but the organization has limited skills, unclear data ownership and teams already absorbing several changes.

Questions to answer first

Which business outcome needs it? Name the capability that requires this level of technology, and what it is worth.
Can the organization run it? Skills, support and on-call, monitoring and governance matter more than the design.
Is the data ready? Clear owners, quality and definitions come before advanced platforms.
How much change can teams absorb? Count the transformations already in flight.

How we would approach it

Choose the simplest architecture that meets the needs of the next two to three years, with clear extension points.
Invest in readiness first: ownership, observability, automation and skills, then adopt the more complex technology where it pays off.
Go state of the art selectively where it creates a measurable advantage, and keep the rest standard.
Measure readiness instead of guessing: a maturity assessment across architecture domains shows where the gaps are.

Check your readiness with the free assessment ↗

INTRODUCTORY DISCUSSION

Facing a similar decision?

Share the context. If there is a fit, we arrange a discussion of about 25 minutes to explore options and next steps. No obligation.

Request an introductory discussion ↗