Part 6: The Organisation as a Graph
Jeff Uren ★ 2026-07-06
This is the sixth article in a series about building a shared understanding of data, ontologies, and data architecture (UDA) in a large organisation that struggles with meaning.
There comes a certain point where you stop thinking about databases, not because SQL kind of stops being useful. It never will.
Databases start to be a bit meaningless because something more interesting starts to emerge, the organisation itself starts to become the thing you navigate.
For decades we've interacted with data through the lens of storage.
- Which database?
- Which schema?
- Which table?
- Which dashboard?
- Which report?
We've become so accustomed to translating our questions into the language of databases that we've forgotten something pretty blatantly obvious.
No one actually thinks in tables.
The wrong interface
Imagine walking into a library, and you ask a librarian for a book on Arctic exploration.
Instead of taking you through the history section, they hand you a floor plan of the building, then explain the shelving system, Dewey Decimal classifications, shelf identifiers, storage density, and all the structural engineering behind the building.
Eventually they point you in the direction of the right aisle.
You'd absolutely think they were completely insane, the storage system exists to help the library operate, it isn't supposed to become the interface. But that's exactly what we've done with data.
We've taught generations of analysts, engineers, and increasingly business users that understanding the organisation means understanding where the data happens to be stored.
It never did.
Navigating meaning
Imagine asking a question like this:
Show me every funded grant related to antimicrobial resistance, administered by organisations in East Africa, together with the applications that produced those grants, the people involved, the payments that have been made so far, and programmes they contribute towards.
That's not an unusual organisational question, but what is really weird is how we answer it.
Traditionally the first thing someone does is start looking for tables, keys, working out joins, and generally reverse engineering years of accumulated assumptions.
The storage is the problem here, so what if the interface was us making the organisation navigable?
Instead of joining tables you traverse relationships, rather than hunting through metadata you explore concepts, and instead of discovering structure you follow meaning.
The question stays exactly as the person asked it, but the platform works everything else out for you.
The Graph of Wellcome
This is where the UDA quietly disappears into the background.
Once concepts, relationships, mappings, and projections become operational, something way bigger begins to appear.
It ends up not just being a graph of concepts, it's a graph of the organisation itself and a Funded Grant isn't an isolated record anymore, it's something you can actually explore. You can move to the Application which it came from, the organisation that's administering it, the people involved, internally and externally, the quality rules that validate it, the pipelines that surface it, and the governance policies that protect them.
None of those connections needs to be invented, it's all there already, the graph just makes them visible.
Time becomes another dimension
One of the more interesting consequences of treating the organisation as a graph is that it doesn't have to represent only today.
Organisations change constantly, and Wellcome especially, departments can change rapidly, funding priorities evolve, projects begin and end, and people move.
Traditional reporting usually flattens all of that into whatever happens to be true now, but organisations aren't static, they're living systems, and Wellcome is can at times be a extreme case of that volatility based on current affairs, focuses, global-scale issues.
So if the underlying concepts are versioned, the graph becomes something you can explore through time as well as structure.
So it's not simply:
Show me our grants.
But:
Show me how our understanding of grants changed between 2020 and 2026.
Or:
Show me the organisation as it existed before this programme was created.
History magically stops being something buried in old backups that we have to plumb and create transformations and mappings for, and it becomes explorable.
AI finally has something to stand on
People have asked multiple times how AI fits into all this, and the honest answer is that AI isn't really the interesting part at all.
AI provides ready shortcuts in a lot of instances, you can skip over a lot of hard work, but it doesn't actually solve fundamental problems in and of themselves. If you believe that, you're either extremely naive, or your problem domain is extremely simple or well-trodden.
Making AI the center-point of everything, making it the axial point that everything spins around, is a mistake. It will always be a tool, and it will always be a tool that's only as good as the context it has to work with. You still need to put the work in if you want something meaningful and operational.
Grounding is the interesting part, if you do that well enough, tools like AI just sort of fall in line.
Without context, an AI model sees tables, column names, sample values, and statistical patterns, but it has no way to infer what everything actually means.
It'll get it right sometimes, just enough to make you feel overly confident in its answers, but it won't be able to explain why, and it won't be able to tell you when it's wrong.
If the organisation has an explicit model of its concepts, relationships, language, governance, then the conversation changes and the AI doesn't have to invent meaning anymore because it can just ask for it.
So the ontology doesn't really make the model intelligent, just like a human being interrogating our organisation, it give everyone a reliable place to begin.
Dashboards aren't the destination
For years we've treated dashboards as the natural endpoint of analytics.
Dashboards are incredibly useful, they're also fundamentally answers to questions someone already knew to ask.
True self-lead discovery doesn't really work like that, it starts with curiosity.
- "I wonder why..."
- "I wonder what connects..."
- "I wonder what changes..."
These are exploratory questions, and I suspect the interfaces we build over the next decade will look much less like collections of charts and much more like conversations with an organisation.
Those conversations could be visual, textual, assisted by AI, graphs, and maybe something we haven't invented yet.
The important part though is the interface is grounded in the same shared understanding of meaning.
Building a memory
There's another consequence that's easy to overlook.
Organisations have a tendency to forget. People leave, teams are reorganized, systems are replaced, consultants arrive and depart, projects finish.
The reasons behind decisions across all that time, are summarily lost and disappear.
Eventually nobody remembers why two reports disagree, why three systems define "Application" differently, or why one field has behaved strangely for the last eight years.
Meaning evaporates, and we usually call that institutional knowledge, but it's more like organisational memory. Most organisations store enormous amounts of data, but very few out there store their actual understanding. And those aren't even remotely the same things.
The UDA isn't just modelling today's organisation, it's preserving how the organisation understands itself.
Foundations
So what's the end goal here? A semantic warehouse? Generated APIs? GraphQL? AI? Governance? Lineage?
Those are all pretty useful things, but they're also just by-products in our world now, the real goal we're chasing is actually a lot simpler.
Build foundations strong enough that people stop thinking about infrastructure altogether.
Just like how we don't think about TCP protocols when we browse the web, or filesystems when we edit a document, I'd like us to reach a point where nobody needs to think about schemas before they can understand the organisation.
They just ask questions, explore, learn, build, challenge assumptions.
The machinery on the backend will do the rest for them, because that's the job of good infrastructure, you shouldn't see it, and it should make lots of other things possible.
When I started this series I said that data isn't really reality. It's representation.
All this gumpf that followed that is really just an attempt to answer one important question.
If data represents the organisation, how should the organisation represent itself?
Honestly, it feels like we're beginning to figure that out, and personally, that's a really interesting and exciting change than having just another unmaintainable catalog.