UDA Addendum: Frequently Asked Questions

Jeff Uren ★ 2026-08-15

This is a follow-up addendum to the UDA article series on this site, which you can find here:

The ideas described throughout this series naturally raise a lot of questions, especially around complexity, practicality, governance, and whether this is simply reinventing capabilities that already exist elsewhere. Those are exactly the kinds of questions we should be asking.

This FAQ attempts to answer some of the more common, and sometimes deliberately challenging, questions we've encountered while developing the UDA. The intention isn't to claim we've solved every problem, but to explain the reasoning behind the architectural decisions, the trade-offs we've made, and where we believe this approach provides genuine long-term value for Wellcome. YMMV.

Philosophy

Isn't this just another metadata catalogue?

No

A metadata catalogue describes where data lives. The UDA describes what the data means. More importantly, the UDA is operational. Applications, query engines, generated APIs, projections, governance, lineage, and permissions are built from it. If you remove the UDA, software stops working. If you remove a metadata catalogue, it's just documentation disappearing.

Isn't this just an ontology?

Technically yes, Practically no.

The ontology is just the representation that we chose because it's good at modeling concepts and relationships. The value comes from what sites on top of. The executable mappings, generated projections, semantic query planning, and operational systems.

Why not just improve our data model?

Because a data model describes storage, the UDA is designed to describe the organisation. Our storage can change, and will, rapidly at times, but the meaning changes much more slowly. Building around meaning gives us a far more stable foundation for other work to build on top of.

Why not start with the warehouse?

Warehouses answer today's questions, but the UDA is designed essentially to answer tomorrows. A warehouse is an "output", they're really just a single projection of the organisational meaning, but their not the only one available to us.

Engineering

Doesn't this duplicate information already stored in our data lake?

No. The data lake remains the source of recorded value, the UDA just stores the meaning, and those are two very different things.

Won't we have to model everything before we can use it?

Not necessarily, the ontology can grow incrementally one concept at a time, with all the trimmings falling in line as the meaning gets fleshed out. As the coverage increases, the platform will directly become more useful and actionable.

Isn't this just another layer of abstraction?

It absolutely is, 100%. On Purpose. It's not about whether the abstraction represents something stable, storage is super unstable, but organisational concepts, by comparison, are extremely stable, they rarely change. An abstraction is worthwhile when it provides stability.

Why not just use GraphQL?

GraphQL solves API composition, but it doesn't solve organisational meaning, GraphQL is something we generate from the ontology, not the other way around.

Why not use a data catalogue like DataHub, Collibra, or Alation?

Those are products that solve discovery and governance, but they generally don't become the runtime for your application themselves. The UDA is designed to drive the platform itself, they're complementary rather than mutually exclusive.

Isn't this over-engineering?

If all you needed was reporting, absolutely. If you're building a long-lived platform serving a wide, and varied set of domains, changing source systems constantly, as well as applications, the complexity already exists.

All the UDA is trying to do is simply centralize that complexity instead of rediscovering it over and over.

Integration

Why not integrate systems directly?

Those systems will change, but the business concepts rarely do. Replacing Oracle shouldn't precipitate every downstream application to change. Mappings absorb those changes.

Why not just build another API?

You'll end up with hundreds of APIs, the actual difficult part here isn't exposing the data, it's ensuring every API means the same thing. We can build an API in minutes.

How does this help migration?

Instead of asking "What tables changed?" we can ask "What concepts changed?" and the mappings isolate physical implementation from the conceptual meaning.

Performance

Won't querying through an ontology be slow?

The ontology isn't queried instead of the data lake, it's used to plan queries against the lakehouse itself and our operational systems. The performance comes from the underlying storage engine, just the meaning comes from the ontology.

Isn't graph technology slow?

Graphs are really, really good at relationships, warehouses are good at aggregations, lakehouses are good at storage. Nothing we're doing here replaces those things, or shifts the performance burden onto the ontology, it just orchestrates the operations across them using the right tool for the right job.

Governance

Why not keep governance in our IAM platform?

So an IAM identity system is good at answering "Who are you?", but the UDA is designed for something different: "What does this data represent?". Together, they allow permissions to follow meaning instead of table names and storage.

What happens if two teams disagree on a definition?

Excellent, the disagreement already exists, the ontology and UDA just forces it out into the open. The goal here isn't to eliminate disagreements, it's to make the disagreements explicit, and trigger those hard questions about what something actually means.

Who owns the ontology

No one really, and technically everybody. Engineering owns the platform, Domains own the concepts, Governance owns policy, the organisation owns the meaning.

AI

Can't AI infer all of this automatically?

In simple cases, sure, but more often than not, the cases are more complex, contain nuances, and complexities which can't be codified into a database or simple model.

The problem isn't necessarily that AI can guess, it's whether we want important decisions to be based on guesses.

Does AI make ontologies obsolete?

Total opposite, the more capable AI becomes, the more important grounding becomes. Explicit semantics reduce all the ambiguity.

Business

What's the ROI?

And just as importantly, it compounds.

Why invest in this instead of another dashboard?

Dashboards answer existing questions only, the UDA enables entirely new systems, and those are very different investments.

How do you know this isn't just architecture for architecture's sake?

There's a simple test for that, if we removed the UDA and it didn't affect anything, then we've more or less failed.

If removing it breaks query generation, projections, APIs, governance, lineage, and applications, then it's infrastructure rather than just documentation and diagrams.

Difficult questions

X doesn't do this. Why should we?

X doesn't solve Wellcome's problems, neither does Google, Bosch, NASA, JPL, or JP Morgan. But we do learn from them, we don't directly copy.

Every organisation has different constraints, and the goal isn't to parrot the choices of organisations that we admire, it's to learn from them and make the best choice for us.

Isn't this just Enterprise Architecture dressed up differently?

Traditional Enterprise Architecture produce documents, we're actually trying to produce software, and that's a very different objective because we're focused on tools that enable, not just describe.

What happens if the ontology is wrong?

Exactly the same thing that happens when your schema is wrong, you update it.

The difference is that the UDA makes those assumptions explicit instead of burying them inside of dozens of applications and storage systems.

Doesn't this become another central bottleneck?

Only if engineering owns all the meaning, which it shouldn't.

Domains should evolve their concepts independently within a shared semantic framework.

Isn't this too academic?

RDF, OWL, and ontologies certainly originated in academia, but so did HTTP ,and TCP/IP. Also relational databases.

Academic ideas become engineering when they solve practical problems.

Why hasn't everyone already done this?

The truth is a lot of them have, just not usually end-to-end, and not everyone publicizes these things. But there are plenty of instances of this out in the wild:

Most organisations have built pieces of the puzzle, but the opportunity is combining them together into a coherent operational platform.

Why not just buy this?

We absolutely should buy capabilities where it makes sense. We already use excellent open source and commercial components for storage, orchestration, query execution, graph databases, identity, visualization, and metadata. What we can't buy is Wellcome's understanding of Wellcome.

The UDA is that understanding made executable. It's a connective tissue between those products, not a replacement for them.