Public UBS Knowledge Graph – Building a Connected Data Catalog

UBS is building a connected data catalog at massive scale by shifting from tool-centric data management to a capability-driven model: catalog data assets, map them to a shared enterprise data model, and then federate the work through small, reusable “data services” that translate each application’s data into a common semantic format. The payoff is a curated data layer where tens of thousands of employees can find, understand, trust, and legally reuse data—without forcing every application to change its underlying systems.

The scale is the central problem. UBS runs roughly 5,000 business applications across a global workforce of about 70,000 employees. Each application typically comes with its own budget, team, database, and data structure—privacy compartmentalization included, which matters under Swiss banking rules. Integration becomes manageable when connecting a few systems, but it turns into a “major headache” when the number of applications balloons. UBS’s goal is to provide a consistent, well-described data layer for all employees: discover the right datasets, interpret them despite thousands of structures and languages, verify quality and timeliness, and ensure licensing and usage rights.

The approach relies on four steps that have been stable for about a decade—catalog assets, build a conceptual enterprise data model, and map application data to that conceptual layer. What changed after years of trying “one big catalog” is the recognition that multiple catalogs and schemas already exist, often scattered across spreadsheets and local descriptions. Instead of centralizing governance and cataloging into a single monolithic team, UBS federates the work.

At the technical core is a “data service,” described as the smallest unit of work: a Kubernetes-based virtual machine that reads from a source system and transforms the output into JSON-LD (linked data). That transformation is driven by configuration mappings, letting developers expose data without rewriting their systems. UBS then pipes the resulting linked data through Kafka, with roughly 80 source systems feeding the pipeline. The semantic layer is anchored in an internal schema aligned with schema.org-style structured data.

UBS connects not just application data but also the metadata needed to understand it end-to-end. Application registries describe business applications and their environments; infrastructure systems describe servers, networks, ports, and connectivity; scanners identify data assets such as buckets and relational databases; and asset-structure metadata is integrated from other systems. At the top sits business glossaries, including separate glossaries per line of business. All of this is carried through Kafka as JSON-LD and written into both a graph database and a data lake. The graph database supports connected, pre-linked exploration, while the data lake supports time-based analysis over large file sets.

The model is built around capabilities—find, understand, trust, use, and reuse—supported by open standards. UBS cites DCAT for dataset description and DQV for data quality and DQV for lineage. Lessons learned emphasize business value first (including separating data registration from data governance), using open standards to reduce adoption friction, and aligning team topology with the federated architecture. The rollout is described as a long game: about three years to reach the current state, with additional years expected to mature and expand scanning and onboarding. In follow-up Q&A, UBS frames “small wins” as cost savings (like identifying and archiving archive tables) to keep funding moving while the broader revenue potential is deferred to later stages.