What is headless BI, and what does it change about where metrics are defined?

## Splitting a BI tool in half A traditional BI platform bundles two very different things: a **modelling layer** (what a metric means, which tables join to which, which attributes you may slice by) and a **presentation layer** (charts, dashboards, filters, scheduling, sharing). Bundling is convenient until you have a second consumer. The data scientist in a notebook, the analyst in a spreadsheet, the customer-facing app embedding charts, the reverse-ETL job pushing metrics back into a CRM — none of them can reach into the BI tool's model, so each re-implements the metric. You are back to four definitions of revenue. **Headless BI** keeps the modelling layer and drops the built-in presentation. The metric definitions run as a service; consumers query it. ## What a consumer sends A request is expressed in the model's vocabulary rather than in table names: ```text metrics: [net_revenue, order_count] dimensions: [order_month, customer_region] filters: ["customer_region = 'EMEA'"] grain: month ``` The service resolves that to SQL against the physical tables, executes it (or delegates execution to the warehouse), and returns rows. The consumer never names `fct_order_line` and never writes an aggregation. Interfaces vary — a REST or GraphQL endpoint, or a wire-protocol-compatible SQL endpoint so existing tools can connect as if it were a database. ## What it buys **Portability of definitions.** Metrics live in your repository, in a format you control, reviewed like code. Swapping or adding a BI tool becomes a presentation decision rather than a re-modelling project. **Consistency across consumer types.** The notebook and the dashboard and the spreadsheet are the same client to the service, so they cannot disagree. This is the real payoff: metric consistency usually breaks at the *edges* of the BI tool, not inside it. **One place to govern.** Ownership, descriptions, certification status and access rules attach to the metric, and every consumer inherits them — including the ones that never open a dashboard. **Reuse beyond analytics.** Because it is an API, operational consumers can use it: an app showing a customer their own usage metrics, or a sync pushing account health scores into a sales tool, computed from the same definition finance reports on. ## What it costs **Another service to run.** Availability, latency and concurrency become your problem. A dashboard that used to hit the warehouse directly now traverses an extra hop, so caching strategy matters. **Weaker per-tool features.** A BI vendor's own modelling layer is deeply integrated with its visualisations — drill paths, custom aggregations at render time, tool-specific interactions. Going headless means you get the lowest common denominator across your consumers. **Migration cost.** Metrics already encoded in a BI tool's modelling language have to be re-expressed, and re-expressed *identically*, which is a reconciliation exercise, not a translation exercise. **A single point of failure.** When everything queries one service, its outage is everyone's outage, and a bad definition change is instantly everyone's bad number. That raises the bar on testing and review. ## When it is worth it It earns its keep when you have genuinely multiple consumer types — more than one BI tool, or serious notebook and application consumption alongside dashboards — and when metric disagreement is already costing you meetings. A single-BI-tool shop with all consumption inside that tool gets most of the benefit from that tool's own modelling layer, and should not add a service to solve a problem it does not have. A middle path is common: define metrics in the transformation layer as certified models with the metric logic baked in, and let the BI tool read those. You lose flexible slicing at query time, but you keep one definition without operating a new service. ## In an interview Define it precisely — modelling without presentation, consumed over an interface — then name the consumer types it unifies, and be honest that it is an architectural commitment, not a free upgrade. Note also that the specific modelling syntax belongs to whichever product you use; the transferable idea is that the definition stops living inside a visualisation tool.