Decisioning architecture and solution delivery
Domain focus
This domain tests architecture decisions and delivery discipline: where decisioning runs, how real-time and batch paths coexist, and how a solution is tested, promoted, and monitored.
Core rules
- Separate layers: data ingestion, decisioning, engagement policy, and channel presentation. A clean boundary lets channels reuse the same decision logic.
- Use the Real-Time Container for synchronous inbound decisions and batch data flows for outbound campaigns. Do not put long-running batch logic inside a real-time strategy.
- Adaptive Decision Manager updates models asynchronously; design for a fallback propensity or default action when a model is unavailable.
- Cache stable reference data; keep customer and interaction data fresh enough for the decision latency budget.
- Deliver in stages: configure, unit-test strategies, simulate, pilot on a channel, then promote. Monitor decision volumes, model performance, and contact-policy suppressions.
Worked example
A bank needs outbound email and inbound web recommendations. The team builds shared strategies and proposition data, runs a nightly batch data flow for email, and exposes the same strategies through the Real-Time Container for web. Reasoning: sharing the decision layer keeps offers consistent; separate execution paths meet different latency and volume needs.
Traps
Putting batch-only logic in the real-time path; assuming ADM scores are synchronous; ignoring data latency; and launching without a fallback when a model or data flow fails.