Building an enterprise data model: objects, ownership and quality

What to do in practice

Data work starts with a model: objects, identifiers, master data, sources, quality rules and correction owners. Integration transports a record; it does not make that record unambiguous or trustworthy by itself. For this task, the initial evidence is “one measure has multiple values”, and the decision boundary concerns errors, corrections and the quality log.

The practical focus is data lineage, quality, accountability and management use. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is sources and transformations.

Authorial source and practical model

The Systems.Education article on building a data model is by Alexander Chernov. A practical enterprise sequence covers objects, identifiers, systems of record, owners and quality rules.

A data model becomes a management tool when every object is connected to a decision and control scenario. A component diagram answers “where”; the data model answers “what the record means, who owns it and how its quality is verified”.

Objects, identifiers and owners

Describe the boundary through object records rather than system names. For errors, corrections and the quality log, record meaning, identifier, source, quality owner and update event; for master data and classifications, also document the relationship rule.

Test the link between errors, corrections and the quality log and master data and classifications using an end-to-end example. The team performs “assign systems of record”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Boundary 1. Object: Master data and classifications. Define the source, frequency, permitted transformations and response to “master data changes without an owner”.
• Object 2: Sources and transformations. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A dashboard does not lead to action.
• Subject area 3: Data marts and semantic models. Verification basis: system of record, owner authority and the signal “errors are corrected only manually”.

Sources and integrations

Describe data exchange as a contract between owners. For master data and classifications, specify the triggering event, system of record, mandatory fields, pre-transfer control and the recipient's response to an error.

Choose the transport mechanism after frequency and resilience requirements are known. Check “one measure has multiple values” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Control record 5. Object: Errors, corrections and the quality log. Observable signal: Users cannot see where a number came from. Accountability: semantic owner and quality owner.
• Record 4. Object: Measures and thresholds. Required details: identifier, lineage, quality rule and update event. Signal: One measure has multiple values.
• Subject area 3: Data marts and semantic models. Verification basis: system of record, owner authority and the signal “errors are corrected only manually”.

Decision and supporting evidence

State the decision before compiling requirements. It identifies sources and transformations, the role authorised to choose, the permitted action and the evidence participants will use to accept or reject an option.

Do not combine the signal “one measure has multiple values” and the risk “measuring quality without a correction process” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “maintain lineage and versions” connects them in a testable scenario.

• Decision 1: object — master data and classifications; signal — errors are corrected only manually; action — maintain lineage and versions.
• Decision 2: object — sources and transformations; signal — one measure has multiple values; action — identify key objects.
• Decision 3: object — data marts and semantic models; signal — users cannot see where a number came from; action — assign systems of record.

Quality and correction rules

The method is a sequence of decisions rather than a universal checklist. For master data and classifications, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For errors, corrections and the quality log, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “maintain lineage and versions”.

• Stage 1: identify key objects. The working artefact describes data marts and semantic models.
• Stage gate 2 connects the action “assign systems of record” with the result “measures and thresholds”.
• 3. Action: align identifiers and master data; verifiable result: errors, corrections and the quality log.
• Decision 4: define checks and corrections. The basis for the next step is master data and classifications.

Checks before the project

Diagnosis examines a concrete episode involving errors, corrections and the quality log. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “master data changes without an owner” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Observation 1: One measure has multiple values. Required fields: frequency, source and consequence for data marts and semantic models.
• Signal: Users cannot see where a number came from. Evidence includes an example, frequency and consequence for measures and thresholds.
• Event to test: master data changes without an owner. Evidence shows timing, frequency and consequence for errors, corrections and the quality log.

Roles in the operating environment

Build the authority matrix around decisions concerning sources and transformations. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “maintain lineage and versions” concerning sources and transformations in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• Business owner decides within data marts and semantic models; the basis is prepared through “define checks and corrections”.
• For measures and thresholds, the assigned role is Architect; its control duty is to maintain lineage and versions.
• Data owner: authority is linked to errors, corrections and the quality log, and participation is tied to “identify key objects”.
• In the decision matrix, project manager connects master data and classifications with the action “assign systems of record”.

How to verify the change

The acceptance criterion for sources and transformations includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “master data changes without an owner”, passes through an authorised decision and “assign systems of record”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Test 1 concerns master data and classifications. The method, interpretation owner and outcome source are documented. Signal: Errors are corrected only manually.
• Control record 2: Sources and transformations; data version, calculation rule, expected change and actual outcome. Signal: One measure has multiple values.
• Criterion 3 uses data marts and semantic models; the result is compared with the baseline using one method. Signal: Users cannot see where a number came from.
• Criterion 4: Measures and thresholds; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Master data changes without an owner.

Decision risks

For the risk “measuring quality without a correction process”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

An assumption concerning master data and classifications remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• Risk record 1. Condition: One data mart without shared meaning. Control action: Align identifiers and master data. Evidence source: Errors, corrections and the quality log.
• Risk: Measuring quality without a correction process. Control: define checks and corrections. Evidence: master data and classifications.
• Risk condition 3: Self-service without a metric catalogue. Response: Maintain lineage and versions. Testable evidence: Sources and transformations.
• The risk scenario “treating an anomaly as a proven fact” is addressed through “identify key objects” and confirmed using data marts and semantic models.

Pack for the first decision

The first session examines one real case involving errors, corrections and the quality log. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “one measure has multiple values”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “maintain lineage and versions”; assign an additional test or stop condition to the risk “treating an anomaly as a proven fact”.

• Stage 1: identify key objects. The working artefact describes data marts and semantic models.
• Stage gate 2 connects the action “assign systems of record” with the result “measures and thresholds”.
• Criterion 4: Measures and thresholds; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Master data changes without an owner.
• Criterion 5. Object: Errors, corrections and the quality log. Test fields: baseline, target change, source and owner. Signal: A dashboard does not lead to action.