Optimized Future-State Architecture Review

Optimized Future-State Architecture Review
An assessment of the current future-state design — identifying structural gaps, clarifying system ownership, and establishing a clear API-first, event-driven target architecture before build-out begins.
Executive Architecture Review
Slide 1 of 6
Architecture Assessment of the Supplied Future-State Design
This is in reference to the "Future State Architecture" document provided to me.
The picture shows capability coverage, but not enough integration intent. Real-time versus async patterns are not explicit. Ownership of pricing, customer data, and order truth is blurred.
1. Integration Layer Bypassed
Several flows appear to route around the integration layer, weakening governance for auth, retries, mapping, and monitoring.
2. System Ownership Blurred
Master data responsibilities overlap across Syndigo, ERP, and legacy systems with no clear authority defined.
3. Pricing Truth Unclear
CPQ, M3, commerce, and tax all influence the commercial result, but final authority is not explicitly assigned.
4. CPQ to M3 Path Missing
The design does not show the real-time contract for configuration validation, price, ATP, credit, and order creation in M3.
5. Boomi and ION Collapsed
One shared box hides which tool owns API brokering, orchestration, business events, and partner translation.
6. Legacy on the Core Path
PeopleSoft is temporary but still touches core master and ERP flows, creating migration risk and dual-write risk.
Key gap: The architecture needs a clear API strategy and an explicit CPQ-to-M3 integration model before any build-out begins.
Slide 2 of 6
Where API Calls Improve the Design
Use APIs for synchronous decisioning. Use events for downstream propagation and analytics.
Recommended split: Experience APIs and API Gateway for synchronous requests — ION for business events and workflows — Boomi only where external translation is still required.
Slide 3 of 6
What the API Layers Mean in This Architecture
Make the channel experience simple. Keep system ownership clear.
Layer 1 — Experience Channels
B2B Portal · ISP Portal · Direct Entry · Microsites · Alt Ordering / RMA. These are the surfaces users interact with — they should never call backend systems directly.
Layer 2 — Experience API / BFF
Channel-facing API shaped for the user experience. The portal calls one API that returns exactly what the channel needs — not five backend systems independently.
Layer 3 — Process / Orchestration API
Coordinates multi-step business flows. Manages quote-to-order logic, sequencing, idempotency, and orchestration across systems.
Layer 4 — System APIs
Thin, stable interfaces to each backend. Expose product, pricing, tax, ATP, order submit, and content through controlled, versioned APIs.
Layer 5 — Backend Systems
commercetools · Infor CPQ · Infor M3 · Vertex · Builder.io CMS · Syndigo · DAM. These systems are accessed only through their system APIs.
Example flow: The portal calls POST /quote/configure-price. The API layer calls CPQ for valid configuration, M3 for customer agreement, price and ATP, and Vertex for tax — then returns one clean response to the portal.
Make Ownership Explicit
CPQ owns configuration rules, option dependencies, guided selling, and visualization.
M3 owns customer agreement, final commercial price, ATP, credit, order lifecycle, inventory, and finance.
Vertex owns tax calculation.
CMS owns content.
Syndigo / DAM own product content and assets.
Sync APIs vs. Async Events
Use synchronous APIs for: price, ATP, customer context, credit check, order submit.
Use asynchronous events for: accepted order, rejected order, backorder, shipment, invoice, analytics, downstream propagation.
Do not let the portal or CPQ create direct point-to-point calls into multiple systems without an API layer.
Slide 4 of 6
Optimized Future-State Architecture
API-first for real-time decisions. Event-driven for downstream updates and analytics.
Master Data & Assets
Syndigo PIM/MDM — product, attributes, hierarchies
MediaValet DAM — product assets and renditions
Experience Channels
B2B · Microsites · ISP · Direct Entry · Alt Ordering / RMA
Content
Builder.io CMS — structured content, pages, and merchandising
Legacy / Sunset
PeopleSoft bridge — phase 1 only. Isolated behind a dedicated transition boundary. Not on the target-state core path.
Commerce & Configuration
commercetools — catalog, cart, quote, checkout
Infor CPQ + Threedium — guided selling, configuration, pricing assistance, visualization
Vertex — tax
Integration Layer
API Gateway / Experience APIs — channel-facing contracts
Process / Orchestration APIs — multi-step business flows
ION events / workflow — business events and async downstream
Boomi — external translation only
Analytics
Data Lake / Lakehouse — events and CDC from M3 and commerce layer
Infor M3 — System of Record
Customer · Contracts · Pricing · ATP · Orders · Inventory · Finance · Manufacturing
Execution & Partner Edge
EDI · AP Automation · Fulfillment
Architecture Callouts
M3 is the ERP system of record for all transactional outcomes.
Boomi is external only — not used for internal API routing.
PeopleSoft bridge is temporary — phase 1 isolation only.
Channels call the API layer — not every backend system directly.
Legend: Solid arrow = sync API call. Dashed arrow = async event.
Slide 5 of 6
CPQ to M3 Target API Contract
Rule: CPQ owns option logic and user experience. M3 owns transactional truth.
Keep in CPQ
Rulesets and option dependencies
Guided selling and rendered outputs
Provisional quote experience and visualization
Share Through the API Layer
Customer context and contract lookup
Real-time price and ATP decisions
Idempotent order submit and status events
Keep in M3
Customer and commercial master
Booked price and credit
Order lifecycle, inventory, ATP, finance, and execution
Do not do this: Direct database writes into M3 · CSV or email as the order interface · Two final pricing engines · Uncontrolled point-to-point integrations
CPQ improves the sales and configuration experience. M3 remains the final authority for commercial and transactional outcomes.
Slide 6 of 6
Decision Summary
What should be locked before build-out
Architecture Decisions
01
M3 is the transactional system of truth.
02
CPQ is the configuration engine, not the final order authority.
03
Every channel uses an experience API or BFF.
04
Process orchestration is separated from system APIs.
05
ION handles business events and workflow.
06
Boomi is limited to external translation and edge cases.
07
Legacy is isolated behind a temporary bridge and removed from the target-state core path.
Immediate Next Steps
01
Define the CPQ-to-M3 real-time API contract.
02
Define idempotency and correlation IDs for quote-to-order.
03
Publish system ownership for customer, product, pricing, ATP, and order lifecycle.
04
Separate API gateway, orchestration, and event responsibilities in the integration design.
05
Remove dual-write paths and unmanaged direct integrations.
06
Confirm which status updates will be event-driven.
07
Create a measurable retirement plan for PeopleSoft.
The optimized architecture is simpler, more governable, and clearer on system ownership. It reduces channel complexity and keeps M3 authoritative while still allowing CPQ and commerce to deliver a modern buying experience.