Define Business Processes, Bus Matrix, Grain, Facts, Dimensions, Metrics, Source Contracts, SLAs, and Security Requirements

Learning outcomes

1. Problem frame: “production-ready” is a decision, not a screenshot

AtlasMart leadership wants one trusted sales view for finance, merchandising, marketing, and operations. A team can demonstrate tables, dashboards, indexes, and a successful DAG, yet still leave the business exposed if nobody has declared the grain, metric filters, history policy, service objective, source-deletion semantics, access boundary, or incident owner. The capstone therefore starts with a data-product contract: a versioned statement of what the warehouse means, where it comes from, who can use it, how quickly it should become trustworthy, how changes are validated, and how failure is handled.

The capstone is intentionally evidence-driven. Every later implementation choice must trace back to a business process and a consumer need; every claimed guarantee must have a test, measurement, policy record, or explicit non-guarantee.

2. Business processes first: the bus matrix is the scope boundary

A business process is a repeatable business activity that creates analytical events or state. A bus matrix maps those processes to reusable conformed dimensions. It prevents one giant “warehouse table” from mixing incompatible grains while also preventing independent marts from redefining Date, Product, Customer, or Geography differently.

The capstone implementation focuses deeply on Sales while retaining Inventory and Fulfillment in the matrix. That is incremental warehouse delivery: one process can be production-grade without pretending every process shares the same fact grain.

3. Declare grain before columns, metrics, or performance work

AtlasMart Sales uses the sentence: one row in fact_sales represents one paid order line identified by (order_id, line_no) at its event timestamp. That sentence determines uniqueness tests, additive measures, CDC keys, reconciliation, and safe joins. Customer segment is resolved historically through a dimension version; it is not copied into the fact as an ungoverned current attribute.

4. Facts, dimensions, history, and semantic metrics are different contracts

A measure is a fact-level numeric value. A metric adds aggregation, filters, time semantics, units, ownership, and versioning. A column named revenue_usd does not by itself prevent a dashboard from excluding a channel or shifting timezone boundaries. Chapter 20’s semantic contract therefore remains part of the capstone.

5. Source contract: define identity, ordering, late data, deletes, and replay

The source contract for the local fixture represents an ERP sales feed. Required fields are order_id, line_no, order_ts, customer_id, product_id, channel, status, qty, revenue_usd, and cost_usd. Timestamps are UTC. CDC uses a stable event_id plus monotonic source_seq; explicit delete events are tombstones; the accepted waterline is 208. A transaction commits target changes, seen-event identity, and watermark together.

{  "source": "AtlasMart ERP sales",  "waterline": 208,  "timezone": "UTC",  "grain_key": ["order_id", "line_no"],  "duplicate_identity": "stable event_id + source_seq",  "delete_semantics": "explicit CDC tombstone",  "required_fields": ["order_id","line_no","order_ts","customer_id",                      "product_id","channel","status","qty",                      "revenue_usd","cost_usd"]}

This is stronger than “read rows newer than yesterday.” A timestamp-only cursor can miss late updates, and an append-only target cannot represent deletes or corrections. The capstone retains the exact ordering/retry semantics already tested in Chapter 15.

6. Service objectives and ownership make reliability testable

For this teaching fixture, AtlasMart retains the earlier operational objective that once the source-ready signal exists, the certified analytical product should be complete and available within 30 minutes. Completeness is 100% against the source manifest for the certified scope. This is a fixture policy—not a universal warehouse target. Production teams must choose targets from consumer impact, source readiness, operating hours, and cost.

An owner is not decorative metadata. It is the accountable decision point for definition changes, failed tests, waivers, deprecations, incidents, and retirement.

7. Security requirements: least privilege from raw data to BI export

The capstone uses synthetic identities and an explicit matrix rather than embedded passwords. bi_reader can read governed semantic output but cannot query the atomic fact directly. etl_service can write the fact through the pipeline path but cannot consume BI output. security_admin manages policies. Privileged direct access is exceptional and auditable. A secure dashboard is not sufficient if the same analyst can query raw/staging tables and bypass masking or row policies.

Technical access controls must be aligned with organization and jurisdiction policy; this lesson does not claim one privacy/retention rule applies everywhere.

8. Architecture decision records turn tradeoffs into reviewable evidence

An architecture decision record (ADR) captures context, choice, evidence, consequences, owner, and rollback. The capstone starts with four: preserve atomic grain/metric v1; materialize a repeated daily-product workload only if benchmarks justify it; isolate interactive and ELT workloads only after queue evidence; and keep hybrid lakehouse/warehouse system-of-record/serving boundaries explicit.

ADR-30-001  Preserve one-paid-order-line grain and gross_revenue_usd.v1Evidence      control totals + golden metric testsConsequence   physical implementations may change; business meaning may notRollback      revert model/semantic releaseADR-30-002  Materialize daily-product aggregate for repeated BI workloadEvidence      equivalent results + repeatable local benchmarkNon-guarantee local timing does not prove cloud-engine speedupRollback      route query to atomic fact

9. Controlled failure: the “feature checklist” capstone

Diagnosis: the checklist proves presence of features, not correctness or operability. Nobody can distinguish a legitimate semantic change from drift, prove history after a backfill, identify consumers during an incident, or restore service after corruption.

Repair: require evidence artifacts: bus matrix, grain and metric contracts, source contract, owner matrix, SLOs, access matrix, reconciliation controls, ADRs, runbook, recovery test, benchmark assumptions, cost model, lineage, and a known-limit register. A requirement is complete only when its evidence is reviewable.

10. Local lab: generate and inspect the capstone contract pack

Run the standard-library fixture from a clean directory. The full capstone harness creates bus_matrix.json, source_contract.json, architecture_decisions.json, access_matrix.json, lineage.json, known_limits.json, runbook.md, and evidence_summary.json. The minimum contract assertions are:

baseline = (10, 8, 12, 820, 495, 325)assert grain == "one paid order line per (order_id,line_no)"assert source_contract["waterline"] == 208assert metric["name"] == "gross_revenue_usd.v1"assert metric["expected_usd"] == 820assert access["bi_reader"]["fact_sales"] == "deny"assert slo["certified_after_source_ready_minutes"] <= 30assert owners["metric"] == "finance semantic owner"

The assertion values are not universal design values. They are deterministic AtlasMart fixture contracts. Their purpose is to make silent changes fail visibly.

11. Verification checklist

• Every in-scope business process has a declared grain and conformed-dimension mapping.
• Atomic control totals and metric v1 values are frozen before implementation changes.
• Source identity, ordering, delete, late-data, retry, and watermark semantics are explicit.
• Service objectives name the measured scope and the owner.
• Access is defined from raw/staging through semantic/BI surfaces; no credential is embedded in lesson code.
• Every major architecture tradeoff has evidence, rollback, and a known non-guarantee.

12. Production judgment and bridge to Lesson 2

The capstone is now well-defined enough to implement. The deciding question is not “Does AtlasMart have all warehouse features?” but “Can each business decision trace to a declared grain, metric, source contract, service objective, access policy, owner, and verifiable evidence?” Lesson 2 turns those contracts into executable dimensional, history, CDC, quality, orchestration, and semantic state.

Knowledge check

Authoritative references

• Kimball Group — DW/BI resources for business process, grain, fact/dimension, bus architecture, and lifecycle techniques.
• Google SRE Book — Service Level Objectives for the distinction between measured reliability indicators and explicit service targets.
• NIST SP 800-53 Rev. 5 for general least-privilege and access-control concepts; organization-specific policy remains required.
• Big Data Academy — Data Warehousing and Dimensional Modeling curriculum for the course sequence and stable AtlasMart continuity.