KGC 2022: 'UBS Knowledge Graph — Connecting The Banks Data' by Gregor Wobbe

UBS’s knowledge graph push grew out of a simple executive question—how many CRM applications exist—and exposed a deeper problem: data was trapped behind thousands of “walled garden” systems, with unclear definitions and costly integration. The initiative’s core finding is that a next-generation data platform needs both a shared, unambiguous data model and a scalable way to connect many legacy domains without forcing every application to be rebuilt.

The starting point was a counting exercise in the CRM space. Teams tried to pull numbers from central stores and source-system ETL jobs, but the effort stalled in interpretation disputes and organizational misalignment. Even once a number was produced, the follow-up question about cost landed in a different warehouse, reinforcing that “one interpretation” was impossible with the existing landscape. UBS then defined a “nirvana state”: an analytical layer with a well-described data layer that a motivated non-technical person could understand quickly, plus an environment where data scientists spend less time hunting and massaging data and more time generating insights.

Reality looked different. Over decades, UBS accumulated roughly 5,000 applications, each guarded by application owners who had little incentive to expose data. Access required navigating gatekeepers and cross-border constraints, while integration work consumed the majority of effort. UBS estimates that when a new application is stood up, about 60% of costs go to enterprise integration. More integrations meant more code, which translated into higher maintenance burden and growing technical debt.

To change that trajectory, UBS reframed the platform as two connected moves: use graph technology to represent data consistently, and move away from “build one thing to rule them all” toward a decentralized approach. Graphs were chosen because they can represent both tabular relationships and other data forms in a common structure; UBS also settled on RDF for a single, extensible data model, despite internal debates. The platform’s other pillar is a custom “data service,” treated like a reusable cell: each application gets its own data service that can “hoover up” source data into connected data and/or expose it through a UI.

This design aims to scale across domains and data lakes by enabling “double-hop” questions—like counting CRM systems and estimating cost—to be answered without bespoke, one-off integrations. In practice, UBS runs publishers and consumers through data services deployed on Kubernetes, allowing the system to scale with cloud capacity.

A flagship “lighthouse” prototype, “bank on a page,” gives an interactive bird’s-eye view of the application estate. Users can apply lenses to filter by business capability (e.g., CRM), identify end-of-life software, or surface security exposure such as Log4j vulnerabilities—pulled from multiple vulnerability management systems. UBS also learned that not everything belongs in a graph: high-volume trading data is streamed via Kafka, with JSON Schema annotations linked to an internal schema.org so data remains explainable without forcing graph modeling.

The rollout strategy emphasized incremental delivery: demonstrate small, single-domain wins every two weeks; invest heavily in a visual anchor and UX (including a dedicated UX developer); and limit technical jargon when selling to stakeholders. Follow-up Q&A highlighted governance challenges around reconciling shared concepts (like currency) and the plan to incentivize data sharing through “data as a product” rewards. Legacy systems are not being discarded; they’re being used as sources while the platform acts as glue across the enterprise.