Customer 360 Enterprise Data Platform — Denodo on Azure · View 02 of 39 · Context and scope
Decisions
- Federation is the default and physical movement needs a justification, not the other way round. Copying five systems into a hub was rejected: it adds a pipeline, a storage bill and a staleness window to data that is already correct where it sits.
- Only three things move — digital events, deep order history, and model output — because each is either too large, too slow or not queryable at the source.
- The identity crosswalk sits between the lakehouse and Denodo, not inside either, so the mastering logic can be tested against a labelled set on Spark.
The alternative considered
- A physical customer hub in Databricks with everything landed. Cheaper per query, but every attribute inherits an ETL latency, and a profile correction takes a batch cycle to appear on an agent's screen.
- Chosen instead: federation for the operational attributes an agent reads, materialisation for the analytical ones a report aggregates.
Numbers
- Customer profile query target under 2 s, full Customer360 under 5 s, API response under 2 s at P95.
- 500 concurrent sessions, 99.9% availability, RTO 30 minutes, RPO 5 minutes on the crosswalk.
- Digital activity visible on the 360 within 60 seconds of the tap that produced it.