# Customer 360 Enterprise Data Platform — Denodo on Azure

**Solution Architecture v1.0 · Data & AI Global Practice · 2026-09 · 39 views · Denodo Platform, Microsoft Azure and open source**

One governed, semantic, secured view of a customer, assembled at query time from Salesforce, SAP S/4HANA, Oracle Billing, ServiceNow, Marketing Cloud, an Azure lakehouse and a digital event stream. Denodo is the enterprise logical data layer; the requirement's illustrative stack named Snowflake, AWS S3, Apigee, Okta, Reltio and Informatica, and this set answers it on Azure and open source instead — Databricks with Delta Lake on ADLS Gen2 for the lakehouse, Azure Event Hubs on the Kafka protocol for streaming, Azure API Management for the gateway, Microsoft Entra ID for identity, Zingg on Spark plus a PostgreSQL crosswalk in place of a commercial MDM, Soda Core for quality rules, Denodo's Presto-based Embedded MPP for lake acceleration, Microsoft Purview federating the Denodo catalogue, and Azure Monitor with Prometheus, Grafana and Sentinel for observability.

One decision carries the whole design: **Denodo owns access, never truth.** The logical layer holds no authoritative customer fact. Identity is mastered outside it by a dedicated resolution service, history and model output live in the lakehouse, streaming stays in Event Hubs, and every source system keeps writing its own records. Deleting the entire Denodo estate would slow every consumer down and lose no record. That boundary is why the identity crosswalk is the one join the platform is forbidden to cache, why the freshness contract in view 17 is architecture rather than tuning, why a partial answer carries a status per domain, and why the AI assistant in view 24 needed no security design of its own.

---

## What is here

| Path | Contents |
|---|---|
| `diagrams/index.html` | The view index — 39 views grouped into seven acts, every format linked |
| `diagrams/*.html` | One self-contained page per view: the inlined diagram plus the reasoning it deliberately omits, with copy / PNG / PDF export |
| `diagrams/svg/*.svg` | The same 39 views as SVG with the diagram XML embedded — re-opens in diagrams.net fully editable |
| `diagrams/drawio/*.drawio` | draw.io native source |
| `specs/views.json` | Diagram specifications — the source of truth for every view (assembled from `part-a..g.json`) |
| `specs/manifest.json` | Acts, page titles, subtitles and the decision / assumption / risk cards (assembled from `manifest-a..b.json`) |
| `scripts/build.sh` | Rebuilds every deliverable from the specs |
| `scripts/pin-icons.mjs` | Pins one mark per component so the same box carries the same icon on every page |
| `ask.md` | The original requirement |

784 icons are embedded in the files, so the deliverable renders identically anywhere with no network request. Each view page links to its own SVG and draw.io source, back to the index, and to the previous and next view.

To rebuild after editing a spec:

```bash
node scripts/pin-icons.mjs     # only after adding new component labels
bash scripts/build.sh          # Node 20+ and nothing else
```

Edit `specs/part-a.json` … `part-g.json` and `specs/manifest-a.json` / `manifest-b.json`; the build script assembles `views.json` and `manifest.json` from them and fails if the two lists disagree, if a view names a section that does not exist, or if the two orders diverge.

---

## The seven acts

| Act | What it lands | Views |
|---|---|---|
| 1 · Context and scope | The boundary, what is only read, and the principle everything else follows from | 01–03 |
| 2 · People and journeys | Who the 360 is for, and the three journeys whose worst moments the rest of the set answers | 04–07 |
| 3 · Structure | The layering rule, the deployable units, every interface, and how five source ids become one customer | 08–13 |
| 4 · Data | What is copied and what is only read, who owns each byte, the model consumers see, the freshness contract | 14–19 |
| 5 · Runtime | A query, an API call, a stream, an AI answer, a source outage, a subject access request and a merge | 20–27 |
| 6 · Operations | Where it runs, how it survives a zone and a region, how a view ships, what is watched, what it costs | 28–33 |
| 7 · Assurance | Trust zones, identity, one policy set for every channel, sensitive data, governance, every failure mode | 34–39 |

---

## The requirement's questions, answered

The requirement poses twenty-four questions across six categories. The set commits to all of them; these are the ones where the answer is a design decision rather than a product fact.

| # | Question | The answer here | View |
|---|---|---|---|
| 3 | What workloads should be virtualised versus cached? | Neither the author nor taste decides. Each attribute group declares a freshness class, and the platform assigns federation, cache, summary or lakehouse materialisation from it. Profile, contact, account status and recent orders are federated with no cache anywhere; cases and marketing are cached with published staleness; history, scores and KPIs are materialised. | 17 |
| 4 | How does Denodo handle real-time versus historical data? | Real time is federated straight to the source or to a streaming Delta table Denodo reads without holding state. Historical is materialised in Silver and Gold and reached through the Presto-based MPP tier. Nothing in the logical layer is stateful, so a streaming outage shows as staleness on one attribute rather than a broken view. | 17, 23 |
| 5–7 | How do pushdown, distributed joins and caching actually behave? | Branch pruning and column trimming run before costing, so a five-source view becomes two source calls. Delegation is decided per source by a capability check, not a global setting. MPP offload is the fallback above roughly 10 M rows scanned, not the default. | 20, 21 |
| 8 | How does it scale with concurrent users? | Three isolated Virtual DataPort pools with separate timeouts, row limits and connection budgets — interactive, data services, analytical. The analytical class is capped at 40% of any source connection pool. Isolation stops at the source, which is drawn as a risk rather than assumed away. | 29 |
| 9–12 | Lineage, definitions, ownership, discovery | Lineage is derived from the view definitions, so it cannot drift from the code. An owner is a named person, certification carries an expiry, and access requests sit on the asset page with a one working day target. Purview federates the Denodo catalogue rather than duplicating it. | 38 |
| 13–16 | IAM, row and column security, PII, audit | Entra ID group claims map to Denodo roles map to view grants. Classification is declared once at the integration layer and inherited by every view above it, so a new business view is masked the day it is created. Financial columns are never cached in any form. Every query is audited with principal, view, row count and masks applied. | 34–37 |
| 17–19 | APIs, BI tools, AI consumption | The same policy set serves JDBC, ODBC, REST, OData, GraphQL and MCP. The AI assistant carries the agent's on-behalf-of token and has no entitlements of its own — a request for an unmasked card number is refused by the same policy that would refuse the agent in Power BI. | 22, 24, 36 |
| 20 | How does Denodo coexist with a lakehouse? | As a consumer of its gold tables and as an accelerator over its Delta files. Denodo never writes to the lake and never reads bronze. | 03, 15 |
| 24 | What happens when a source is unavailable? | A partial answer is a 200 with an explicit per-domain status — never a 500 and never a silent omission. An empty panel and an unreachable source must never look the same. | 22, 25 |

---

## Where this departs from the requirement, and why

| The requirement said | This set does | Because |
|---|---|---|
| Snowflake as the warehouse | Azure Databricks with Delta Lake on ADLS Gen2, Unity Catalog for lake grants | The stack was directed to Azure and open source; Delta plus the Presto-based Embedded MPP gives Denodo a lake-acceleration path that does not depend on a second vendor's warehouse being awake. |
| Reltio / Informatica / SAP MDG for MDM | Zingg on Spark plus a PostgreSQL crosswalk, survivorship rules versioned in Git | Identity resolution genuinely must sit outside Denodo — but a commercial MDM is not required to prove that. The interface is deliberately a crosswalk table, so an MDM can be substituted behind it without one consumer changing. |
| Informatica / Collibra for data quality | Soda Core rules on Databricks, exceptions published as an entity on the 360 | The requirement is to *expose* defects, not to cleanse silently. Cleansing inside a view creates a customer record that exists nowhere else and becomes a second system of record. |
| Apigee / Kong for API management | Azure API Management | Same capability, one fewer vendor in an Azure landing zone. |
| Kafka for streaming | Azure Event Hubs on the Kafka protocol | Kafka clients and tooling unchanged, no broker estate to run. |
| Datadog / Splunk | Azure Monitor and Log Analytics, Prometheus and Grafana for Denodo JMX, Microsoft Sentinel as the SIEM | Denodo exposes JMX; the open-source exporter path is the shortest route to it, and Sentinel keeps the audit sink in a separately administered subscription. |
| "Every consuming application" | The partner portal is the only external consumer in scope | Customer-facing self-service was out of scope; the pattern extends to it but nothing here is built for it. |

---

## What still needs a decision

1. **Source delegation capability is the biggest untested assumption.** The design depends on SAP HANA and Databricks accepting delegated joins and aggregations over the Customer 360 access paths, and on Salesforce SOQL filter pushdown covering the predicates actually used. Phase 3 of the requirement's proof-of-concept exists to test exactly this; until it does, the latency targets on views 02 and 20 are targets, not commitments.
2. **SaaS API call limits under federated load.** Salesforce and ServiceNow contracted limits are the binding constraint on federated concurrency — not Denodo throughput. Exceeding one converts an architecture decision into an unplanned licence negotiation.
3. **Source reachability from the DR region.** Failing over to West Europe gains a running Denodo with nothing to read if a source is network-restricted to the primary region. This must be confirmed per source before the RTO on view 28 can be claimed.
4. **The accepted identity gap.** Sources see the platform identity, not the user, because SAP and Salesforce cannot express a region-scoped, book-scoped, column-masked entitlement. Source-side audit therefore shows a service account and the user-level record lives in Sentinel. Documented on view 35 as a trade, and it needs explicit sign-off from the CISO rather than silent acceptance.
5. **Denodo licence core sizing.** Cores are the real capacity ceiling and the largest fixed cost line. Pool sizing on view 29 is a commercial decision as much as a technical one, and the numbers there are an architecture starting point pending a workload test.

---

## The 39 views

| # | View | What it answers |
|---|---|---|
| 01 | System Context | Who uses the 360, what it reads, what it deliberately does not touch |
| 02 | High-Level Architecture | The shape in one picture: federate by default, materialise by exception |
| 03 | The Governing Principle | Which responsibilities Denodo takes, and which it must be prevented from taking |
| 04 | Actors and Their Core Journeys | Who it is for, in their own words, and what each gets to do |
| 05 | Journey — Answering an Inbound Call | The agent's first forty seconds, and where the platform lets them down |
| 06 | Journey — Building a Customer Report | How a certified dataset still blocked the work for six days |
| 07 | Journey — Resolving a Duplicate Customer | The journey where the failure is a wrong answer, not a slow one |
| 08 | Layered Architecture | What depends on what, and why the layering rule is a security control |
| 09 | Container Architecture | The deployable units, their technology, and what talks to what |
| 10 | The Denodo View Hierarchy | Four modelling layers, the naming standard, where logic may live |
| 11 | Integration Surface | Every interface in and out, with protocol, cadence and owner |
| 12 | Source Connectivity | Per source class: connector, identity, what can be delegated, what follows |
| 13 | Identity Resolution | How five source ids become one customer, and why not in a view |
| 14 | Data Flow | What is copied, what is only read, and the cadence on every arrow |
| 15 | Storage Zones | Who owns each byte, what must be restored, what can be rebuilt |
| 16 | The Customer 360 Logical Model | The entities consumers see and the one key they all join on |
| 17 | The Freshness Contract | Federated, cached or materialised — and the rule that decides |
| 18 | Caching and Acceleration | What can answer a query, how it stays fresh, where the platform refuses |
| 19 | Data Quality | How a defect is detected, what it does to the record, who fixes it |
| 20 | A Customer360 Query, End to End | What happens between a refresh and rows arriving, across five systems |
| 21 | Query Optimisation | The stages between statement and plan, and which do the real work |
| 22 | A Data Service Call | One REST call, including the part where a source does not answer |
| 23 | Real-Time Digital Activity | The one streaming path, and why Denodo does not read the stream |
| 24 | The AI Assistant | How a grounded answer is produced with no credential of its own |
| 25 | When a Source Goes Down | The degradation path across all four parties, healthy to recovered |
| 26 | Subject Access and Erasure | Finding every copy of one person, and who may delete them |
| 27 | A Merge Propagates | From approval to consistency, and what happens if the event is missed |
| 28 | Deployment | What runs where, what survives a zone, what a region failure costs |
| 29 | Workload Isolation | Three latency classes, and the one resource they still share |
| 30 | Environments and Delivery | How a view change ships, and the three gates that stop a bad one |
| 31 | Observability | Every signal from emission to the person or control that acts |
| 32 | The Operating Loop | How the platform decides what to materialise next |
| 33 | Cost Model | What drives spend, what it scales with, the levers that move it |
| 34 | Trust Zones | Where the boundaries are, and where an attacker actually arrives |
| 35 | Identity and Access | Sign-in to filtered, masked rows — and the one trade-off in the chain |
| 36 | Authorisation Model | One policy set per role, inherited by every channel |
| 37 | Sensitive Data | Five classes, classified once, enforced everywhere above |
| 38 | Governance and Lineage | Business definition to column trace, and the loop keeping owners honest |
| 39 | Failure Modes | Every named way this breaks, and the one class with no technical answer |

---

## Build status

```
39 views · 784 icons embedded
validate --strict   0 errors, 0 warnings
route check         288 edges routed, 0 errors, 11 clutter warnings
link check          40 pages, 310 relative links, all resolve
```

The eleven remaining route-check warnings are clutter, not geometry: two on the context view and six on the integration catalogue, where a fan of fifteen satellites around one centre box puts short edge labels near neighbouring lines. Both were tested against cutting satellites and widening the canvas; neither reduced the count, and removing interfaces from an integration catalogue would be the worse trade. Nothing crosses a box and no label sits on one.