Operational Architecture: Why Palantir Is Enterprise Architecture That Actually Worked
I had an uncomfortable moment last week.
I was helping a client think through their platform options and pulled up Palantir Foundry as a comparison point. I had used Palantir as a reference before, but for some reason this time I really looked at it. And what I saw was unsettling.
Palantir Foundry is doing what enterprise architecture has been trying to do for thirty years. They just stopped calling it architecture, and they started wiring it into operations.
That sentence has been sitting in my head ever since. It is, I think, the single most important shift in how we should be thinking about enterprise architecture as a discipline. And the implications, once you see them, change how you build, sell, and lead architecture work.
What Palantir Actually Built
If you have not encountered Foundry, the simple version is this. It is an enterprise data operating system that does three things: it integrates every relevant data source in an enterprise into a unified layer; it overlays a semantic ontology on that data so the business can reason about customers, products, risks, shipments, and capabilities in business terms rather than database terms; and it builds operational applications on top of that ontology that drive decisions and trigger actions back into the operational systems.
Their newer product, Palantir AIP, layers large language models over the ontology so business users can chat with their enterprise data and have AI agents take action on it.
The pricing is enterprise-scale. The implementation is months. The customer base is governments, defence contractors, banks, and Fortune 500 industrials. They are not in the SA mid-market. They are not particularly interested in being.
But that is not why they matter to enterprise architects.
The Uncomfortable Realisation
Strip away the data infrastructure language and look at what Palantir’s ontology actually is. It is a semantic model of the enterprise. It defines what a customer is, what a transaction is, what a shipment is, what a regulatory exposure is. It maps how those entities relate to one another. It records the policies and rules that govern them.
That is enterprise architecture.
Specifically, it is the kind of enterprise architecture that EA practitioners have been writing white papers about for decades. Living. Operational. Wired into the business. Single source of truth for how the enterprise actually works. The thing every Chief Architect promises in their first hundred days and almost no Chief Architect actually delivers.
Palantir delivers it. Not because they are better at enterprise architecture than enterprise architects. They are not. They have likely never used the word “ArchiMate” in a sales meeting. They delivered it because they came at the problem from the data infrastructure side and never let the model decay.
That is the difference. Traditional EA built models in tools that had no operational job. Palantir built models in a tool that had nothing but operational jobs. The architecture stayed alive because the operations needed it to stay alive.
Why Enterprise Architecture Decays
I have written before about why most EA work ends up as a documentation graveyard. The short version: an architecture model that does not have a job to do every day will decay. It is not a discipline problem. It is a structural one.
Capability heatmaps go into PowerPoint. ArchiMate models go into Visio or Sparx EA. Application portfolios go into Excel. The artefacts get produced for a strategic planning cycle, then they get put down. The business changes. The artefacts do not. Within eighteen months the architecture is fiction.
Architects know this. They produce update plans. They schedule annual refreshes. They lobby for governance. None of it works at scale, because none of it changes the underlying problem: the model has no operational reason to be correct on any given day.
Compare this to what happens inside Palantir Foundry. The ontology is not an artefact. It is the substrate that operational decisions run on. If the ontology is wrong, the decisions are wrong, and the wrong decisions surface immediately because they are connected to the operational reality. The model stays correct because the operations refuse to let it be incorrect.
This is the structural insight, and it is bigger than Palantir. The architecture lives when it has a job to do. The architecture dies when it does not.
What This Means for the Discipline
If you accept that framing, a lot of conventional EA practice looks structurally doomed. Producing capability models for a strategic planning cycle. Maintaining an architecture repository that no one queries. Writing target-state documents that the business will never look at. Standing up an EA function whose deliverables are read by other architects.
None of that is architecturally wrong. It is just operationally inert. It produces beautiful models that have no daily reason to be correct, and so they are not correct after the first major business change.
The implication is uncomfortable: most EA functions are not under-resourced. They are mis-resourced. They are spending their hours on artefacts that decay because the artefacts have no operational role. They should be spending their hours on architecture that is wired into the operational decisions and operational systems where the architecture’s correctness matters.
This is not a call to throw out enterprise architecture. It is a call to do it operationally rather than descriptively. Build models that have a job. Wire them into the systems that depend on the model’s correctness. Make the architecture the substrate, not the documentation.
What I Have Been Building, Without Quite Realising
I have been building toward this insight for a while without seeing it clearly. Looking at my own platforms with this lens is clarifying.
SoaringWings Pro, my native platform for capability modelling and ACMF maturity assessment, is built around a knowledge graph that the AI agents reason across. The model is not an artefact. It is queryable, it is operational, and the agents do real work against it. The graph is the substrate; the assessments and recommendations are the operational outputs.
StrategyMapper Pro applies the same idea to strategic analysis and Wardley mapping. The map is not a slide. It is a structured graph of components, dependencies, and evolutionary states that the platform can reason about. Strategic recommendations come out of the model because the model has the operational job of producing them.
Both platforms are, in their own scale and their own vertical, doing the thing Palantir does at the data infrastructure layer. They are operational architecture, not descriptive architecture. I just did not have the language for it until I really looked at Foundry.
The Move for Architects
If you are a Chief Architect, Head of EA, or transformation leader sitting with this article, the practical move is this. Stop asking “are we producing the right architectural artefacts?” and start asking “what operational job is each architectural artefact doing?”
If the answer is “it informs the next strategic planning cycle,” that is a weak operational job. It is so weak that the artefact will decay before the next planning cycle, and the next planning cycle will be done from scratch anyway.
If the answer is “it is wired into the investment governance process and capital allocation has to reference it,” that is a strong operational job. The artefact will stay correct because investment decisions cannot be made if it is wrong.
If the answer is “it is wired into the regulatory reporting cycle and any deviation triggers an automated alert,” that is a very strong operational job. The artefact stays correct because the regulator will notice if it does not.
The pattern is straightforward. Architecture lives when it is operational. Architecture dies when it is not. The discipline of enterprise architecture has spent thirty years producing artefacts in the second category. Palantir spent twenty years producing artefacts in the first.
The lesson is not that we should all become Palantir. The lesson is that the next thirty years of enterprise architecture have to be built on the same operational substrate, even if the scale, vertical, and form factor are completely different.
The Honest Self-Assessment
Look at your own EA function. Pick three artefacts you produced in the last twelve months. For each one, ask the question: what would happen tomorrow if this artefact disappeared?
If the honest answer is “nothing immediate,” the artefact is descriptive, not operational. It will decay. It is decaying right now.
If the honest answer is “an operational decision would be wrong, a regulatory submission would fail, a capital allocation would be miscalculated, a programme would lose its dependency view,” the artefact is operational. It will stay alive because the operations cannot afford for it to decay.
The ratio between those two categories tells you what kind of EA function you are running. Most EA functions, in my experience, run somewhere between 80/20 and 95/5 in favour of descriptive artefacts. That is the structural reason most EA functions struggle for credibility. They produce a lot, and almost none of it is doing operational work.
Palantir’s existence at scale is the proof that this can be inverted. The question is not whether operational architecture is possible. The question is whether you are building toward it or away from it.
I know which side I am on. The work I am doing now, both in client engagements and in the platforms I am building, is squarely on the operational side. After looking at Foundry properly, I do not see another defensible side to be on.
The architecture lives when it has a job. Make sure yours does.