Enterprise data architecture

Connected data.
Shared understanding.

Give each layer a model suited to its job: source structures for capture, Data Vault for integration and history, Kimball dimensional models for analysis, and semantic models for shared meaning. Pointer helps you combine them so teams can reuse each other’s work.

Fit & tradeoffs

Choose the layers you need.

When the layers help.

Multiple sources, historical change, and definitions shared across teams can justify a common integration and analytics foundation.

Account for the investment.

Each model adds engineering, storage, testing, and operational work. Weigh that cost against the need for reuse and traceability.

Use the simplest fit.

Stable sources and a focused reporting need may require fewer layers. Add integration patterns when the requirements justify them.

The big picture

From source data to useful answers.

Your business systems hold the records. Each layer makes those records easier to connect, understand, and reuse, so reporting and AI can draw on the same business meaning.

Prepare the data. Share the meaning. Put it to work.
Your starting point

Data from across the business.

  • Applications
  • Databases
  • APIs
  1. 01 / Bronze

    Keep the source.

    Capture records with their original keys and values so they can be reused and traced.

    Source records & load context
    Source data & ODS
  2. 02 / Silver

    Connect the history.

    Link business records across systems and retain changes over time.

    Business keys, relationships & history
    Data Vault
  3. 03 / Gold

    Make analysis simpler.

    Organize business events around shared dimensions such as customer, product, and date.

    Facts surrounded by shared dimensions
    Kimball star schemas
04 / Shared semantic models

Define business meaning once.

Give reports and AI the same definitions, calculations, and access rules.

Explore the model
  • Agreed measures
  • Relationships
  • Access rules
  • AI instructions

This reference uses Data Vault for Silver and Kimball for Gold. Medallion defines the progression; the models are chosen to fit your needs.

For a concrete progression through these layers, explore the survey model below.

Services across every layer

Connected lineage. Repeatable delivery.

Established models provide repeatable patterns for generation, loading, and checks. Maintaining lineage across Bronze, Silver, Gold, and Semantic connects source records to the business measures people use.

  1. BronzeSource data
  2. SilverKeys & history
  3. GoldFacts & context
  4. SemanticShared measures

Lineage & delivery capabilities across all four layers

  • Lineage

    Trace measures through transformations to source records, and inspect downstream dependencies before changes.

  • Orchestration & automation

    Reuse model-driven generation, loading, and checks to reduce manual pipeline work.

  • Quality & reconciliation

    Check keys, history, and totals before issues reach downstream reports.

  • Governance & security

    Agree model ownership and test access for each consuming path.

  • Monitoring

    Track freshness and failed loads so teams know where to investigate.

  • Version control & CI/CD

    Version models and validate dependencies to reduce release rework.

Inside the architecture

A clear job for every layer.

Bronze / source data & ODS

Capture once.
Keep the source context.

Source-aligned tables and an operational data store (ODS) preserve familiar keys and values before analytical rules are applied. Retained extracts or change records let engineers investigate and reprocess captured inputs without repeating the source extraction.

  • Reuse captured data while reducing load on source systems.
  • Preserve source context for traceability and investigation.
  • Replay retained inputs for recovery and reprocessing.
01 / Bronze / retain source meaning
IngestionExtracts, APIs, and database changesCapture at the cadence the source supports
Source structureODS tablesReuse keys, values, and current state
Retained inputsCapture historyReplay retained extracts or changes
TraceabilityLoad metadataIdentify origin and arrival time

Choose current-state and retention requirements explicitly; an ODS does not automatically preserve every historical change.

Silver / Data Vault integration

Connect the business.
Retain its history.

Data Vault separates business keys in hubs, relationships in links, and descriptive history in satellites. This makes it easier to add sources and attributes without redesigning existing structures. These well-established patterns are highly automatable, allowing generation, loading, and history checks to be reused across the model.

Raw Vault retains captured history and source metadata for auditing; Business Vault applies reusable rules while preserving that evidence. Connected lineage carries this understanding into the analytical layers.

  • Integrate changing sources with less redesign.
  • Preserve captured history and source traceability for audits.
  • Automate repeatable hub, link, and satellite builds and loads.
02 / Silver / separate keys, relationships, and history
HubCustomerCustomer business key
HubOrderOrder business key
HubProductProduct business key
Satellite / descriptive historyOrder line detailsQuantity, status, and changes over time

Define the relationship’s grain: the same product can appear on multiple order lines. Record source and load time support auditing; mappings and transformation metadata carry lineage into downstream models.

Gold / Kimball dimensional models

Make analysis consistent
across the business.

Kimball star schemas organize a business process into facts with a defined meaning for each row—the grain—and descriptive dimensions. They simplify analytical joins and make data easier to navigate. Conformed dimensions let teams compare processes using the same customer, product, or date definitions.

Established fact, dimension, and history patterns make these models highly automatable. Reusable templates apply agreed loading and validation rules, reducing custom engineering for each new mart.

  • Business-friendly facts and dimensions simplify analysis.
  • Simple star-schema joins support efficient BI queries.
  • Conformed dimensions align reporting across processes.
03 / Gold / choose the grain for the business question
Conformed dimensionsProduct, location, and dateConsistent definitions across analytical models
Transaction factSales activityOne row per transaction lineMeasures: quantity and sales amount
Periodic snapshot factInventory positionOne row per product, location, and dayMeasure: stock on hand

Transactions describe activity; snapshots describe a position in time. Their measures need different aggregation rules.

Semantic / shared business meaning

Define meaning once.
Use it across BI and AI.

A well-designed semantic model captures business understanding: agreed definitions, terminology, relationships, measures, and calculation rules. Reports and AI use that governed meaning, reducing duplicated formulas and conflicting interpretations.

AI instructions embedded in the model add guidance on interpreting business terms and choosing the right measures. Together with the model’s definitions, they help Power BI Copilot and configured Fabric data agents answer with more relevant business context.

  • Share consistent business definitions and measures.
  • Enable self-service analysis without rebuilding the model.
  • Guide AI with governed business context and instructions.
04 / Semantic / business understanding built into the model
Gold inputsFacts and dimensionsDeclared grain and shared keys
Shared semantic modelGoverned business contextDefinitions, relationships, measures, and AI instructions
Sales amount
Sum the defined transaction amounts.
Order count
Count distinct orders, not order lines.
Stock on hand
Use the relevant snapshot date.
Example AI instruction
For inventory questions, use Stock on hand for the requested date.

A daily stock balance should not be summed across dates. The model carries this meaning into every consuming experience.

Architecture in practice

One survey model, through every layer.

Qualtrics surveys, questions, and responses become a shared foundation for self-service BI, Copilot, and a dedicated Survey data agent. Each layer prepares data and definitions the next layer can reuse.

01 / Bronze · operational data store

Capture the source structure.

ODS tables follow the source structure, giving downstream models one reusable view of survey definitions and question-level response records.

Keep answers in context
Survey and question keys preserve the connection between an answer and its source definition.
Reuse the ingestion pattern
Capture new questionnaires through the same pipeline, reducing separate source extracts for each reporting need.
ODS tableSurvey
  • Key Survey ID
  • Survey name
  • Status
ODS tableQuestion
  • Key Survey ID / Question ID
  • Question text
  • Question type
ODS tableSurvey response
  • Key Survey / Question / Response
  • Sub-question / iteration
  • Response type

02 / Silver · Data Vault

Connect identities. Retain history.

Hubs identify entities, links capture relationships, and satellites retain changing attributes. This separates integration changes from reporting design.

Extend with repeatable patterns
Standard hub, link, and satellite patterns lend themselves to automated builds and loads as attributes and relationships are added.
Investigate changes
Retained versions help explain changed question text or choices without reconstructing prior values from reports.
Hub / identitySurvey
  • Key Survey hash key
  • Survey business key
Hub / identityQuestion
  • Key Question hash key
  • Question business key
Satellite / historySurvey details
  • Survey hash key
  • Name / status
  • Version / start date

Stable keys connect the model.
Satellites preserve source history.

Satellite / historyQuestion details
  • Question hash key
  • Text / type / choices
  • Version / start date

03 / Gold · Kimball star schemas

Organize the data for analysis.

Kimball star schemas present the integrated data as response and answer facts with familiar dimensions, simplifying joins for analysis.

Make the grain clear
Keep participation counts separate from answer counts to reduce accidental double counting.
Reuse the context
Shared Survey, Date, and Response dimensions reduce repeated mapping and align results across both stars.

Response star

DimensionSurveySurvey key
DimensionDateDate key
FactSurvey Response
  • Response count
  • Score / progress
DimensionResponseResponse key

One row per response

Answer star

DimensionSurveySurvey key
DimensionDateDate key
DimensionAnswer TypeAnswer type key
DimensionQuestionQuestion key
FactSurvey Answer
  • Answer count
  • Answer text
DimensionChoiceChoice key
DimensionResponseResponse key

04 / Semantic · shared business model

Define the meaning once.

Response Count, Answer Count, and Pct of Choice Selection carry the survey’s business understanding into each consuming tool. Definitions explain what is counted and how to interpret a percentage.

Maintain calculations once
Shared counts and percentages reduce duplicated logic in reports and self-service analysis.
Give AI explicit context
Model AI instructions can explain that choice share compares selections within a question, rather than respondents, and guide the choice of measure.

Shared Survey semantic model

DimensionSurveySurvey key / name
DimensionQuestionQuestion key / text
DimensionChoiceChoice key / label
FactSurvey Response
  • Response key
  • Survey key
FactSurvey Answer
  • Response / question / choice keys
  • Answer count
Shared measuresResponse CountAnswer CountPct of Choice Selection
Reports & self-service BICopilotDedicated Survey data agent
Survey model evolution: source tables, Data Vault, star schemas, and a shared semantic model.

Choose the right design

Which layers does
your platform need?

We can help choose the model boundaries, implement reusable patterns, and equip your team to extend them.

Plan your architecture work