Operational Data Push
Sending modelled analytical data back into operational tools, which turns a warehouse table into a production dependency with none of the guarantees.
A customer health score computed in the warehouse is more useful inside the CRM than on a dashboard. Reverse ETL does that: it reads a modelled table and writes it into an operational system through that system's API.
The architectural consequence is usually underestimated. The warehouse was built for analysis — nightly latency, best-effort availability, schema changes made by analysts — and it is now upstream of a system that sales staff use during a call. A failed pipeline is no longer a stale dashboard; it is a wrong number in front of a customer.
What the push therefore needs: an SLO on the source table with monitoring behind it, change control on the models feeding it, rate limiting and backoff against the target API, and a clear answer to what the operational system shows when the data is stale — the previous value, nothing, or an explicit staleness indicator.
The governance question is ownership. The analytics team owns the model; the operational team owns the consequence. That split needs naming before the first incident rather than during it.