Open Data Infrastructure
Open Data Infrastructure for Customer 360
Customer 360 fails when it becomes a closed application promise instead of governed, portable customer context.
Customer 360 is usually sold as a complete view of the customer. The hard part is proving who should see that view, where it came from, and whether it can leave the product that assembled it.
The practical problem
Customer data lives across product events, billing systems, support tools, CRM records, marketing platforms, contracts, identity systems, and operational workflows. A closed Customer 360 application can make that look unified while quietly creating another control boundary.
ODI changes the frame. The goal is not one more place to view a profile. The goal is governed, portable customer context that approved systems can use without rebuilding identity, consent, lineage, and policy from scratch.
Core idea: Customer 360 should be an infrastructure contract around customer context, not a product silo with a prettier profile page.
The ODI boundary
The Customer 360 boundary includes identity resolution, source provenance, consent and privacy constraints, data quality, lineage, semantic definitions, and access policy. The profile is only the surface.
That boundary becomes more important with AI. A sales assistant, support agent, retention workflow, or personalization system may all want customer context. They should not each rebuild the meaning of "active customer," "contract owner," "open case," or "eligible offer."
Patterns that work
Separate identity from activation. Identity resolution should produce a governed customer graph with confidence, source, and survivorship rules. Activation systems should consume approved views of that graph for specific purposes.
Attach policy to attributes. Customer status, product usage, support history, payment details, health information, or location data may have different privacy and access rules. A single profile permission is too blunt.
Expose customer context through contracts. Approved tables, APIs, semantic models, and context-graph nodes should carry lineage, freshness, ownership, and use constraints. That gives dashboards and agents the same governed basis for action.
Failure modes
The first failure is profile theater. Everyone sees a beautiful profile, but nobody can explain which source won a conflict or why the record changed.
The second failure is consent drift. A downstream workflow uses customer data for a purpose the original policy did not cover because the policy did not travel with the attribute.
The third failure is lock-in by enrichment. The customer record becomes more valuable inside the application than in the platform, so every new use case pays rent to the profile vendor.
Questions to ask
- Which customer identifiers are canonical, and how are conflicts handled?
- Can each customer attribute carry source, freshness, confidence, and policy status?
- Can approved systems access governed customer context without copying everything?
- Can agents see which customer facts are safe to use for which tasks?
- Can the organization leave a Customer 360 product without losing the context model?
For related architecture, read Context Graph vs Knowledge Graph, Designing Data Access for AI Agents, and Governed Data Sharing With Open Table Formats.
Sources to start with
Start with the primary docs. They are the contracts you can test against, not commentary about the contracts.