BQL: Querying the Enterprise
as a Single Living Model
Ask a large organisation a simple question - which of our infrastructure exists to serve this strategic goal? - and watch what happens. The goal lives in a strategy deck. The capability that realises it lives in an ArchiMate model somebody last opened in March. The processes live in a workflow engine. The integrations live in a broker's config. The infrastructure lives in Terraform. The delivery plan lives in a pipeline definition.
Six artefacts, six tools, six owners, and no mechanical relationship between any of them. The answer takes a week and is out of date by the time it is written, which is why nobody asks. Not because the question is unimportant - it is one of the most important questions in the business - but because asking it costs more than the answer appears to be worth.
BQL is a query language built on the premise that this is an artificial problem. Those six artefacts describe one system. The reason they cannot be queried together is that they are stored apart, and that is a choice.
Contents
1. Alignment is a query, not an audit
"Strategic alignment" is normally a review: a working group, a spreadsheet, a period of interviewing people about what their system is for, and a slide saying that alignment is now at 72%. It happens quarterly at best, and its output is a snapshot of an opinion.
The reason it is a review rather than a measurement is that the evidence is scattered. If the goal, the capability, the process, the endpoint and the node were all elements in one model with typed relationships between them, "is this goal realised by anything?" would be a graph query returning a list in milliseconds, and it would be as current as the model.
That is the entire premise of BQL. Not a better modelling notation - we use the published standards unchanged - but the observation that once every layer's model is in one queryable store, a class of expensive organisational questions becomes cheap.
2. Every format belongs to a layer
The key structural insight is unglamorous and load-bearing: the ~20 modelling and automation formats a large organisation actually uses are not interchangeable. Each one belongs at a specific altitude, and the format someone reached for tells you which layer they were working at.
| Layer | Question | Formats found there |
|---|---|---|
| Motivation / Strategy | Why do we change? What do we intend? | ArchiMate |
| Business | What does the enterprise do? | BPMN, DMN, CMMN |
| Application | How does software support it? | IFML, Camel, n8n, Node-RED, Temporal, Airflow, Step Functions, Logic Apps |
| Technology | What runs it? | Kubernetes, Docker Compose, Terraform, Ansible |
| Implementation | When does it ship? | GitHub Actions, Jenkins, Argo |
Once the mapping is explicit, two things become possible that are not possible when each format lives in its own tool.
The first is validation: a Kubernetes manifest describing business intent is a smell, and so is an ArchiMate element that exists only to mirror a deployment. Layer violations are detectable rather than a matter of taste.
The second is traversal. If a Terraform node and an ArchiMate goal are elements in one graph with realisation relationships between them, the path from one to the other is walkable. That path is the answer to the question this article opened with.
3. Tracing a goal down to infrastructure
BQL's syntax is deliberately SQL-shaped, because the audience for these questions includes people who write SQL and do not write Cypher.
-- what actually realises this goal, all the way down?
TRACE ALIGNMENT OF :goal:digital_services
FROM strategy TO technology;
-- push an intent down through the layers and see where it lands
PROPAGATE INTENT :goal:customer_experience
FROM strategy TO technology
STRATEGY transform;A trace walks realisation relationships downward and returns the chain: goal, the capabilities that realise it, the services that provide those, the processes that implement the services, the endpoints and interfaces that expose them, and the nodes underneath. Every hop is a typed relationship somebody declared, so the chain is evidence rather than inference.
Read the same chain upward and it answers the question that makes budget conversations tractable: why does this node exist? Walk from the node up through the services it supports to the capability and the goal, and you either arrive at a stated business intent or you do not. Both outcomes are useful. Arriving nowhere is the more interesting one.
4. Gap analysis: what is missing, not what is wrong
Most model validation checks that what exists is well-formed. The more valuable check is for what does not exist at all, and it is exactly the check a single-layer tool cannot perform, because the missing thing lives in the layer the tool cannot see.
FIND ALIGNMENT GAPS BETWEEN business AND application;
CHECK DIGITAL TWIN ALIGNMENT WITH REPORT;Each gap is a pattern of the form "an element of this type with no incoming relationship of that type from that layer". A representative set:
| Gap | Spans | What it means in practice |
|---|---|---|
| Unrealised goal | Motivation → Business | Something the organisation committed to that no capability delivers |
| Orphan process | Business | A process that realises no declared service - work nobody asked for |
| Unassigned capability | Strategy → Business | A capability claimed in the strategy and owned by nobody |
| Violated constraint | Motivation × execution | A stated constraint that live executions are getting past |
| Unused service | Business × Application | A service exposed and never consumed |
| Service without endpoint | Business × integration | A service the business offers that nothing can actually reach |
| Orphan endpoint | Integration × Business | An endpoint serving no declared service - usually a forgotten integration |
| Untriggered process | Business × {integration ∪ UI} | A process nothing can start |
| View without interface | UI × Application | A screen backed by nothing |
Look at that list as a set of findings rather than as a feature table. "A service the business offers that nothing can reach" and "an endpoint serving no declared service" are the two halves of the same organisational failure, and both are invisible from inside either tool alone. The architecture tool sees a well-formed service. The integration tool sees a well-formed endpoint. Only the join sees that they were supposed to be connected.
5. Two layers of definition
BQL defines things at two altitudes, and keeping them distinct is what stops the language from becoming either a toy or an assembler.
The architectural level is where you declare goals, capabilities, services, components and nodes, with the relationships the ArchiMate specification defines. This is the level an architect works at, and it is entirely in domain vocabulary.
The executable level is the net semantics those elements compile to - states, transitions, arcs. This is the level the engine works at, and it is where questions about deadlock, liveness and reachability are decidable rather than debatable.
You can drop from one to the other when you need to, and most people never do. The point of exposing both is that the properties worth having live at the lower level while the vocabulary worth using lives at the upper one, and a language that only offers one of the two forces you to choose between talking about the business and being able to prove anything.
6. Queries that simulate
Because the model compiles to executable semantics, a BQL query is not restricted to asking what is currently true. It can ask what would happen.
Simulate a value stream with realistic service times and read off the distribution of completion times. Change the arrival rate and see which stage saturates first. Remove a node from the technology layer and see which business services lose their realisation - before removing it in reality. Add a work package to the migration layer and get a probability of hitting the target plateau date, rather than a date somebody committed to in a steering committee.
This is the payoff of insisting the model be executable rather than descriptive. A descriptive model can be inspected. An executable one can be interrogated about situations that have not happened yet, which is the category of question that actually precedes an expensive decision.
7. DIKW and Cynefin as first-class attributes
Every element can carry two classifications that are unusual to find in a modelling tool, and both earn their place.
DIKW - data, information, knowledge, wisdom - records what altitude of meaning an element operates at. It sounds academic until you use it to catch a specific and very common failure: a dashboard presented as knowledge that is in fact raw data with a chart on it, or a decision justified by information that was never actually elevated into knowledge by anyone.
Cynefin - clear, complicated, complex, chaotic - records what kind of problem an element addresses, and this one has direct operational consequences. Clear and complicated domains are where automation belongs: the relationship between cause and effect is knowable, so a process or a decision table is the right instrument. Complex domains are where cause and effect are only clear in hindsight, and a rigid process is actively harmful - that is what case management exists for. Chaotic domains need response, not modelling.
Tagging elements with their domain makes a design error queryable: a complex-domain problem being handled by a rigid BPMN process is a finding you can search for, rather than a realisation someone eventually has after the process has been fought for a year. It is the same move as the gap analysis - taking a judgement that normally requires an experienced human to notice, and turning it into something the model can surface.
8. The honest limits
- Import fidelity is the hard part. Bringing twenty formats into one model means twenty importers, each with its own edge cases. What a Terraform module "means" architecturally is a judgement call, and the import encodes a judgement. Treat imported elements as a starting point an architect corrects, not as ground truth.
- The model is only as good as the relationships declared. Gap analysis finds missing relationships, which means it also reports gaps that are really just undeclared relationships. Early on, a gap report is mostly a to-do list for modelling rather than a list of organisational failures. That is normal, and it is worth saying before someone runs their first report and concludes their enterprise is broken.
- Simulation results are as good as the service times you supply. A value stream simulation with invented durations produces confident nonsense. The numbers have to come from execution history, which means the simulation is only trustworthy once the processes have actually been running.
- None of this is on the public API surface today. BQL runs inside the product. Read this as the architecture and the reasoning, not as endpoints you can call this afternoon.
Conclusion
The organisational questions that matter most - what is this for, what realises it, what is missing, what happens if we change it - are expensive not because they are deep but because the evidence is scattered across tools that cannot see each other.
BQL is what those questions look like once the evidence is in one place:
- Alignment becomes a query that runs continuously, rather than a review that happens quarterly.
- Layer mapping makes format choice checkable, so working at the wrong altitude is detectable.
- Gap analysis finds what is absent, which is the class of problem no single-layer tool can see.
- Executable semantics let a query simulate, so the model answers questions about decisions not yet made.
For how the layers compile to executable semantics in the first place, see ArchiMate Layers as Executable Architecture. For the store underneath, see The Beam and the Dark Space. For the reasoning engine that runs these alignment queries continuously and tells you about the results in plain language, see A Reasoning Engine That Refuses to Guess.