The challenge
A large manufacturer was building customer-facing commerce alongside its existing ERP estate, serving both consumer and business users. The design had to be concrete enough to procure infrastructure against, explicit about which systems were in scope versus merely adjacent, and resilient enough to run as more than one instance. Later, the same estate needed a modern CX architecture for the sales side — which meant an architecture that could still be reasoned about years after it was drawn.
Approach
- Produced a dual-instance deployment architecture with per-node sizing — cores and memory for every tier, not an abstract topology.
- Marked scope explicitly on the architecture itself: sized and planned, not planned and not sized, and out of scope.
- Separated frontend and backend node groups behind a load balancer, each with its own search cluster and clustering strategy.
- Reviewed sizing against the business's own volumes, and revised it as the programme moved.
- Extended the work later into a modern CX architecture and technical blueprint for the sales side, reusing rather than replacing the existing view.
Innovation
- Put scope status on the architecture diagram itself. A deployment view that distinguishes sized-and-planned from out-of-scope prevents an entire class of late surprises.
- Kept one architecture alive across several years and multiple programmes, rather than redrawing it per initiative.
Outcome
- Deployment architecture and node-level sizing delivered and used for infrastructure planning.
- Sizing reviewed and revised across the programme as volumes firmed up.
- Integration design agreed across commerce, order management and ERP.
- Modern CX architecture and technical blueprint delivered for the later sales-side phase.
Recommendations
- Size at node level. 'Small, medium, large' cannot be procured against and cannot be tested.
- Put scope status on the diagram. If the architecture does not distinguish planned from out-of-scope, someone will assume the wrong one.
- Revise sizing as volumes firm up. A sizing done once at the start is a guess that nobody revisits.
- Design for more than one instance if the business will ever need it — retrofitting a second instance is far harder than planning one.
Architecture
Technology
- SAP Commerce (hybris)
- Order Management
- SAP Data Hub
- SAP Process Orchestration
- Apache SOLR
- SAP Sales Cloud