Reference architecture / Analytics engineering

Governed Analytics for BI and AI

A reference architecture for making business metrics usable across dashboards, applications, and conversational analytics.

Status: Reference design, informed by my Reporting Agent work. The architecture and rollout below describe a proposed extension, not a separate production implementation or measured deployment.

Start with the decision

When someone asks how the business is performing, the answer should make its assumptions clear. Which customers are included? What period are we comparing? How fresh is the data? Who owns the definition?

Those questions matter whether the answer appears in a dashboard or comes from an AI assistant. A polished response can still lead to a poor decision when its underlying definitions are ambiguous.

My Reporting Agent work connected a governance committee, documented metrics with explicit grains and segments, a semantic layer, and a Claude plugin using reusable skills and a custom MCP interface. Continuous testing helped keep metric implementations aligned with their definitions.

This design extends that approach into a broader operating model: establish ownership, make changes reviewable, and give every consumer enough context to use the result responsibly.

Architecture: make each boundary explicit

The proposed flow has four boundaries:

1. Source to modeled data. Capture source changes, preserve enough history to investigate discrepancies, and establish expectations for schema, freshness, and ownership. Failed checks should identify the affected downstream products rather than disappear into a pipeline log.

2. Modeled data to business metrics. Build reusable entities before defining metrics. Each metric needs a grain, calculation, supported dimensions, time convention, exclusions, and accountable business owner. A definition should explain what the number means and when it should not be used.

3. Metrics to consumers. Dashboards and assistant tools should resolve approved metrics through the same definitions. The interface should return relevant context alongside values, including filters, reporting period, freshness, and definition version.

4. Consumer to decision. The experience should make uncertainty visible. An unsupported comparison, stale dataset, or ambiguous question needs an explanation or clarification instead of a confident answer.

These are logical boundaries. They do not require four new products or a replacement warehouse.

Governance that engineers can ship

I would make the data contract part of delivery: named owners, expected fields, compatibility rules, freshness expectations, and the consumers affected by change.

Testing would cover more than whether a pipeline completed. Structural checks would validate keys, relationships, and accepted values. Metric tests would exercise known examples and boundary conditions. Reconciliation would compare important totals with their agreed reference. Consumer tests would check that dashboard and assistant requests resolve to equivalent definitions.

A semantic layer would not replace authorization. The serving path would enforce the requester’s permitted access, with the same restrictions applied to assistant tools. Logging would support investigation without unnecessarily retaining sensitive query contents.

For breaking changes, the design would require an impact review, a migration window, and an explicit retirement decision.

Operating model: clear ownership, room to execute

I have built data engineering organizations and managed resources. For this design, I would connect technical ownership to how the team plans and delivers work.

Business owners would resolve meaning and accept the metric. Producing teams would own source behavior and communicate changes. Analytics engineers would own reusable models, semantic implementations, and tests. Platform owners would provide reliable execution and access controls.

A lead engineer would own each delivery slice, with a clear outcome and definition of done. Leadership would prioritize the roadmap and resource tradeoffs. Routine implementation decisions should stay with the people closest to the work; cross-domain definition disputes need a clear escalation path.

Roll out narrowly and prove reuse

I would begin with one recurring business decision, a small metric set, one dashboard, and one assistant workflow.

The first release would test whether both experiences produce consistent answers under the same filters and permissions. It would also test failure behavior: stale inputs, unsupported segments, denied access, and a definition change.

There are tradeoffs. Stronger contracts add coordination. A shared semantic layer can constrain unusual analysis. Faster refresh adds cost and operational complexity. Exploratory work still needs space, clearly distinguished from certified reporting.

I would measure definition-related rework, time to deliver a supported metric, adoption across consumers, reliability against agreed expectations, and the effort required to change a definition safely.

The intended value is practical: less repeated reconciliation, clearer accountability, and a foundation that makes the next use case easier to deliver.

Related work: Reporting Agent