Customer 360 Enterprise Data Platform — Denodo on Azure  ·  View 11 of 39  ·  Structure

Integration Surface

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

Editable source SVG draw.io All views
Consumers that call us Power BI 1,100 users Agent Desktop 60 rps peak AI Assistant tool calls Notebooks 35 users Partner Portal 4 partners Microsoft Purview nightly scan Denodo Virtual DataPort Customer 360 Logical Layer one access contract Sources we call Salesforce CRM on demand SAP S/4HANA on demand Oracle Billing cached 30 min ServiceNow CSM cached 15 min Marketing Cloud cached 1 hour Databricks SQL gold tables only Delta and ADLS MPP scan ECID Crosswalk never cached ODBC REST MCP JDBC APIM meta REST JDBC JDBC REST REST JDBC Parquet JDBC Integration Surface — Every Interface In and Out External / third party Security / platform Application we own Data store synchronous batch Fourteen interfaces, one contract. No consumer holds a credential for a source, and no source is reachable except through a layer 2 view. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • Fourteen interfaces, one contract. No consumer holds a source credential, and no source is reachable except through an integration view.
  • The crosswalk interface is marked never cached, which is a functional requirement rather than a performance note — see view 07.
  • Purview pulls lineage from Denodo rather than Denodo pushing to Purview, so the enterprise catalogue cannot go stale silently when a pipeline fails.

Ownership

  • We own every left-hand interface and the contract on it. We own none of the right-hand ones, which is why capability limits, quotas and vendor SLAs are on view 12 rather than assumed away.
  • Salesforce and ServiceNow API call limits are the binding constraint on federated concurrency, not Denodo throughput.

Risks

  • SaaS vendors version their APIs on their own schedule. Schema drift is a named failure mode on view 39 and is caught by CI, not at runtime.