IT director FAQ — integrating retail decision engines
Answers for IT Directors and CIOs on integrating a retail decision platform: architecture, ERP fit, API surface, security, SLA, cloud and vendor lock-in.
A decision engine sits between the data layer and the execution systems. It reads aggregated data from the warehouse or lakehouse, computes decisions, and writes them back into the WMS, OMS, POS or ERP through REST or a queue. The execution side stays stateless and keeps the system of record intact. Most retailers run the platform as a sidecar to existing infrastructure rather than as a replacement. That keeps blast radius small and rollback cheap. See our guide to integrating decision engines for the full reference architecture and the typical wiring diagram.
Integration follows one of two patterns. Read-only, where the platform consumes ERP data and surfaces decisions in a separate UI, ships in eight to twelve weeks. Write-back, where decisions flow back into the ERP for execution, takes sixteen to twenty-four weeks. The longer timeline reflects ERP master data alignment and change-management on the SAP or Oracle side, not the platform itself. Most teams start read-only to prove value, then move to write-back once business users trust the outputs. See our intelligence layer page for how decisions flow back into the ERP.
The API surface has three categories. Inbound endpoints handle data ingestion from the warehouse, WMS and POS. Decision-query endpoints let downstream systems pull current decisions for a SKU, store or order. Feedback endpoints accept post-execution actuals so the platform can close the loop on accuracy. Everything is REST plus webhooks, fully documented in an OpenAPI specification. The contract is versioned, so an ERP integration written today keeps working when the platform ships new features. See our orchestration layer page for the full API map and the standard event flow.
Most retail decision data is aggregated and carries no PII, which simplifies the security posture significantly. Standard requirements still apply: SOC 2 Type II, ISO 27001 and EU data residency for RGPD scope. On top of that, encryption in transit and at rest, SSO via SAML or OIDC, and role-based access control. Solya runs in EU regions only with no cross-border data movement. Any platform you evaluate should publish its sub-processor list and let your CISO review a recent pen-test report. See our data sovereignty and RGPD article for the full compliance posture.
Cloud-native is the default and the cheapest path. On-prem deployment is technically possible but adds thirty to fifty percent on total cost of ownership over three years. The retailer takes on infrastructure, patching and model retraining. Private cloud, where the platform runs in your own VPC inside AWS, Azure or GCP, is the middle ground. It satisfies most regulated retailers without the on-prem overhead. The choice mostly depends on your existing cloud posture and your CISO's appetite for shared-tenant risk.
Above them, not parallel to them. The decision platform produces the optimised plan, the WMS and OMS execute it. The WMS keeps owning warehouse mechanics like slotting, picking and putaway. The OMS keeps owning order routing and fulfilment. The decision platform feeds both with smarter inputs: better allocation targets, better replenishment quantities, better order-routing priorities. This separation keeps each system in its lane and makes vendor swaps tractable. See our WMS vs decision platform article for the full responsibility split.
For a mid-size retailer with a clean data warehouse, plan for twelve to twenty weeks end-to-end. The breakdown is roughly four weeks of data integration plus four to six weeks of model calibration on your history. Add four weeks of business validation in shadow mode, then two to four weeks of phased rollout. Compressed timelines of eight to ten weeks are achievable when the data model is clean and the scope is one decision type. Multi-decision scopes or messy master data push toward the upper end of the range.
Production SLAs typically land at ninety-nine point five to ninety-nine point nine percent uptime, depending on tier. Decision freshness matters more than raw uptime for most use cases. Replenishment decisions refresh hourly, allocation refreshes daily, markdown refreshes weekly. Real-time sub-second decisioning is rarely necessary outside dynamic pricing, and forcing it inflates cost without changing P&L. Make sure the contract spells out freshness windows per decision type, not just an overall uptime number. See our decision intelligence platform architecture for the typical freshness tiers.
Lock-in is real but manageable through three contract terms. First, data portability: a written commitment that your historical data, including features and labels, is exportable on demand. Second, model portability: trained models exported in a standard format like ONNX, so a successor vendor can evaluate them. Third, a standards-based API surface using REST and OpenAPI, not a proprietary SDK. Push for all three in the master services agreement before signing. See our build vs buy article for the framework that scopes lock-in risk across the broader build-or-buy decision.
A well-designed platform is multi-tenant from day one. Each brand or region becomes a logical tenant with its own data, parameters and access controls, all served from one production deployment. That keeps operations simple and lets you add a new brand or country in weeks, not quarters. Avoid platforms that require a separate instance per tenant. They look fine at one or two brands and become unmanageable at five or more. Confirm tenant isolation, per-tenant model tuning and per-tenant audit logs during the technical evaluation.