Worked example — launch the ecommerce channel

Every page so far taught one layer, or one link between two. This page does the thing an enterprise-architecture practice actually exists to do: take a single business decision and walk it top to bottom through the whole model, so a reader can see how a boardroom sentence turns, step by step, into cloud infrastructure and a funded plan.

The decision is the one Cadence Cycles is really facing: launch a direct-to- consumer ecommerce channel and make it work with the stores rather than against them. We will trace that one thread down through motivation → strategy → business → application → technology, reusing the exact diagrams the earlier pages built, and then turn the heat map into the roadmap Cadence would actually fund.

The question the architecture answers

Foot-traffic is falling and D2C-native brands are winning customers online. The Board wants to know: if we spend to go omnichannel, where does the money go, in what order, and how will we know it worked? A pile of slides can assert an answer. An architecture can trace one — from the goal that justifies the spend to the systems that deliver it and the work packages that build them — and that traceability is the entire point of what follows.

1 · Motivation — why we are doing this at all

Start where every sound decision starts: the why. The motivation view records the forces, the judgement, and the intent behind omnichannel — not as opinion, but as named model elements a stakeholder can point at and argue with.

The motivation view (an authentic Archi export). Purple is the Motivation layer: stakeholders, drivers, assessments, goals, and the requirements that realise them.

Read the chain that drives this example:

• The drivers — Declining store foot-traffic and Online competition (D2C brands) — are the external pressure. They are not the architecture's to fix; they are the weather it must sail in.
• The assessment Stores strong on fitting/service, weak online is the honest judgement: Cadence's advantage is real but stranded in the shop. That finding influences the goal.
• The goal Grow D2C online revenue to 30% is the decision made measurable — the sentence the whole rest of this page serves. Its owners are the VP Ecommerce (accountable for the number) and the Board (accountable for the bet).
• Three requirements make the goal concrete: Real-time inventory visibility, Online order → store fulfilment (BOPIS), and Unified customer profile. These are what a solution must actually do — and, crucially, they are shaped by the principle Buy-anywhere / fulfil-anywhere and bounded by the constraint ERP replacement out of scope this cycle.

So what — the decision this layer drives

Motivation is where you decide whether to invest and against what number. Everything downstream is justified by tracing back to Grow D2C online revenue to 30%; anything that cannot be traced back to a goal here is, by definition, gold-plating. The constraint matters just as much as the goal: "no ERP replacement" is what keeps the programme fundable.

2 · Strategy — which capabilities the goal needs

A goal is not a plan. The strategy layer answers what must Cadence be able to do to hit the number — in capabilities, the abilities the enterprise has (or lacks), independent of the org chart or any one system.

The capability map (authentic Archi export). Tan is the Strategy layer. The omnichannel goal leans almost entirely on the Sell & Serve tier.

The goal reaches down into four capabilities in the Sell & Serve (Omnichannel) area — Ecommerce, Omnichannel Retail, Inventory Management, and Order Fulfilment — and is enacted by the course of action Stand up D2C ecommerce, which realises the goal in the model. This is the pivot from "what we want" to "what we must be able to do": the course of action is the strategy-level initiative; the capabilities are the abilities it configures. Note what is not here — no system names yet. That discipline is deliberate: capabilities outlive the software that implements them, so the plan is anchored to abilities, not vendors.

3 · Business — the value the customer actually receives

Capabilities become real in the business layer, as the value stream a customer lives through and the process and roles that deliver it.

The "Fulfil an online order" value stream (authentic Archi export). Yellow is the Business layer; the chevrons are the stages the customer moves through.

The value stream Fulfil an online order — Browse → Order → Pay → Pick → Ship / Collect — is the customer's side of the goal. Behind it, the business service Online Purchase realises the goal directly, and the Place Order process (performed by the Buyer role an Online Shopper plays) realises the service. Each stage is served by the capability that makes it possible — Order and Pay by Ecommerce, Pick by Order Fulfilment — which is the hinge back to the strategy layer: name a stumbling stage, and the capability to fix is one edge away.

4 · Application — the software that serves the business

Now, and only now, do systems appear. The application layer shows which software serves each business service — the honest map of "what runs the promise".

The application-usage view (authentic Archi export). Cyan is the Application layer; the arrows show application services serving the business services above them.

Online Purchase is served by a small, legible landscape: the Ecommerce Platform (the storefront), the Order Management System (OMS) exposing the Manage Order service, the Inventory Service behind Check Inventory and Reserve Stock, and the external Payment Gateway behind Take Payment. This is where the requirements from Motivation land as software responsibilities: real-time inventory visibility is the Inventory Service's job; BOPIS is the OMS orchestrating a store pickup; unified customer profile is CRM data the storefront reads. Because the constraint said "no ERP replacement", the OMS and Inventory Service are added around the ERP, not instead of it — an architecture decision you can read straight off the diagram.

5 · Technology — what it all runs on

Finally, the technology layer: the nodes, platforms, and networks the software lands on. This is where the promise becomes a machine — and where a run-cost and a resilience question get their answer.

The infrastructure-usage view (authentic Archi export). Green is the Technology layer; it shows which node serves each application component.

The Cloud Platform node serves the Ecommerce Platform, OMS, Inventory Service, PIM, and CRM; it hosts a Kubernetes cluster and a CDN, while the on-prem ERP server and the in-store POS terminals stay where they are. Read this layer as the outage question in reverse: if the Cloud Platform is down, the layered view (below) will trace a straight line back up to Grow D2C online revenue to 30% — which is exactly the sentence that justifies paying for its resilience.

6 · From heat map to roadmap — the decision this section was built to make

We now have an unbroken line of sight from goal to cloud. But a line of sight is not a plan. The last two diagrams turn analysis into sequence: which capabilities to invest in, and in what order.

First, the heat map scores each capability by strategic importance × maturity gap — how much it matters to omnichannel versus how far today falls short:

The capability heat map (authentic Archi export). Four capabilities run hot — Ecommerce, Omnichannel Retail, Inventory Management, Order Fulfilment — and those four are the omnichannel programme.

The heat map names where to invest. The roadmap — the pink Implementation & Migration layer, the last layer this section introduces — names when, and turns each hot capability into a funded work package:

The implementation roadmap (authentic Archi export). Pink is the Implementation & Migration layer. Two plateaus bookend the change; a gap per hot capability is closed by a work package that realises a deliverable and moves Cadence toward the target state.

Read it left to right, as time:

• Two plateaus bracket the journey — Current state (siloed channels) and Target state (omnichannel) — joined by a triggering relationship: this is the transition the programme buys.
• Each hot capability carries a gap (what today lacks). Each gap is closed by a work package: Build D2C storefront closes the Ecommerce gap, Unify inventory service closes the Inventory gap, and Roll out BOPIS closes two gaps at once — Order Fulfilment and Omnichannel Retail.
• Every work package realises a deliverable — Ecommerce Platform live, Real-time inventory service, BOPIS in 50 stores — and each deliverable in turn realises the target plateau.

So what — the roadmap Cadence would actually fund

The sequence falls out of the model, not out of a steering-committee argument. Build D2C storefront goes first: it is the ante for having an online channel at all, and it realises the goal's headline. Unify inventory service goes next, because Real-time inventory visibility is the requirement that both the storefront and BOPIS depend on — sequence it early and two later packages get easier. Roll out BOPIS lands last but earns the most: it is the one work package that closes two hot gaps, so it is where the omnichannel thesis — "buy anywhere, fulfil anywhere" — finally pays off. That is a plan you can put a number and a date against, and defend line by line back to the goal.

Reading a full line of sight

Zoom out, and the six steps above are one picture — the layered view, the section's hero diagram:

The layered view (authentic Archi export) — the same thread this page walked, drawn as one model. Every connector is a real ArchiMate relationship.

This is the pay-off of doing the work as one model rather than seven slide decks. Because each diagram above is a view onto the same elements, the line of sight is real and two-way: top-down it answers "how, concretely, do we deliver this goal, all the way to the metal?"; bottom-up it answers the question every change review asks — "if the Cloud Platform has an outage, which customer promise and which strategic goal are at risk?" — and traces it straight back to Grow D2C online revenue to 30%. The roadmap is simply that same line of sight, sequenced and costed.

The through-line, in one sentence

A driver justified a goal, which needed capabilities, delivered by a value stream, served by applications, running on technology — and the hot capabilities became work packages on a roadmap. That single sentence, every clause a traceable model element, is what an enterprise-architecture practice is for.

Where to go next

• Working in a TOGAF/ArchiMate shop — how a team actually operates the model behind this example: the repository, governance, ADM iterations, viewpoints, and the anti-patterns to avoid.
• Capability heat-maps — the scoring method behind the hot capabilities that anchor the roadmap.
• Value streams — the cross-map and the layered view this example synthesises.
• TOGAF & the ADM — where a worked example like this one lands in the architecture development method.