Customer 360 Enterprise Data Platform — Denodo on Azure

Who uses the Customer 360, what it reads, and what it deliberately does not touch.

The shape of the platform in one picture: federate by default, materialise by exception.

Which responsibilities Denodo takes, and which it must be prevented from taking.

Who the platform is for, in their own words, and what each of them gets to do with it.

What happens to an agent in the first forty seconds, and the moment where the platform lets them down.

How a report author finds, understands and is blocked by a dataset that was certified all along.

The one journey where the failure is a wrong answer rather than a slow one.

What depends on what, and why no consumer can reach a source structure directly.

The deployable units, the technology in each, and what talks to what.

The four modelling layers, the naming standard, and where each kind of logic is allowed to live.

Every way the platform touches another system, with protocol, cadence and who owns it.

For each class of source: the connector, how it authenticates, what it can be asked to do, and what follows from that.

How five source identifiers become one enterprise customer, and why none of it happens in a view.

What is copied, what is only read, and the cadence on every arrow.

Who owns each byte, what would have to be restored, and what could simply be rebuilt.

The entities a consumer sees, the one key they all join on, and where the source keys survive.

Which attribute groups are federated, cached or materialised — and the rule that decides, rather than the author.

What can answer a query, how each store is kept fresh, and where the platform refuses to help.

How a defect is detected, what it does to the record, and who is expected to fix it.

What actually happens between a report refreshing and rows arriving, across five systems.

The stages between a statement and a plan, and which of them do the real work.

One REST call from the agent desktop, including the part where a source does not answer.

The one genuinely streaming path, and why Denodo does not read the stream.

How a grounded answer is produced, and why the model needed no security design of its own.

The degradation path, drawn across all four parties, from healthy through to recovery.

Finding every copy of one person across six systems, and who is allowed to delete them.

From a steward's approval to every consumer agreeing, and what happens if the notification is missed.

What runs where, what survives a zone, and what a region failure actually costs.

Three classes with different latency contracts, and the one resource they still share.

How a view change reaches production, and the three gates that stop a bad one.

Every signal from emission to the person or control that acts on it.

How the platform decides what to materialise next, and why that is a governed change.

What drives spend, what it scales with, and the four levers that actually move it.

Where the boundaries are, what crosses each one, and where an attacker actually arrives.

From a sign-in to a filtered, masked result set — and the one trade-off in the chain.

One policy set per role, and every channel inheriting it without restating it.

Five classes of sensitive data, classified once and enforced everywhere above it.

From a business definition to a column-level trace, and the loop that keeps ownership honest.

Every named way this breaks, what absorbs it, and the one class with no technical answer.