BI Architecture: services, data and dependencies

The core decision

Architecture should show which decision each component supports, which data it exchanges, who owns the interface and what happens when it changes or fails. An application diagram alone is insufficient. For this task, the initial evidence is “master data changes without an owner”, and the decision boundary concerns sources and transformations.

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 measures and thresholds.

Applied analysis: BI Architecture: services, data and dependencies

The question “BI Architecture: services, data and dependencies” first requires agreement on the meaning of data marts and semantic models. Different definitions produce different data, requirements and outcome assessments even when one system is used.

Diagnostic evidence for “errors are corrected only manually” must be reproducible. Another participant should use the same source and agreed rule to reach a comparable conclusion.

Acceptance uses evidence for measures and thresholds. Method, period and source of actuals remain comparable with the baseline; exceptions are recorded separately.

• Working object: Sources and transformations.
• Diagnostic signal: Master data changes without an owner.
• Response action: Map applications and data.
• Controlled risk: Treating an anomaly as a proven fact.

Objects under management

The subject model starts with two reference objects: sources and transformations and data marts and semantic models. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “identify critical dependencies”.

The primary boundary is sources and transformations. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Object 1: Master data and classifications. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: One measure has multiple values.
• Subject area 2: Sources and transformations. Verification basis: system of record, owner authority and the signal “users cannot see where a number came from”.
• Record 3. Object: Data marts and semantic models. Required details: identifier, lineage, quality rule and update event. Signal: Master data changes without an owner.

Integration contract

Describe data exchange as a contract between owners. For data marts and semantic models, 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 “master data changes without an owner” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Boundary 5. Object: Errors, corrections and the quality log. Define the source, frequency, permitted transformations and response to “errors are corrected only manually”.
• Control record 4. Object: Measures and thresholds. Observable signal: A dashboard does not lead to action. Accountability: semantic owner and quality owner.
• Record 3. Object: Data marts and semantic models. Required details: identifier, lineage, quality rule and update event. Signal: Master data changes without an owner.

Services and critical dependencies

For data marts and semantic models, the sequence begins with “map applications and data”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for data marts and semantic models. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Decision 1: describe business services. The basis for the next step is master data and classifications.
• Step 2. Map applications and data. Output: sources and transformations.
• Record interfaces and owners is the action at stage 3. The output documents data marts and semantic models.
• At position 4, the action is “identify critical dependencies”; its result is measures and thresholds.

From signal to decision

State the decision before compiling requirements. It identifies measures and thresholds, 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 “master data changes without an owner” and the risk “treating an anomaly as a proven fact” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “map applications and data” connects them in a testable scenario.

• Decision 1: object — master data and classifications; signal — users cannot see where a number came from; action — map applications and data.
• Decision 2: object — sources and transformations; signal — master data changes without an owner; action — record interfaces and owners.
• Decision 3: object — data marts and semantic models; signal — a dashboard does not lead to action; action — identify critical dependencies.

Diagnosis before solution selection

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

Review the signal “errors are corrected only manually” 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.

• Diagnosis records “one measure has multiple values”, its recurrence and its impact on master data and classifications.
• Observation 2: Users cannot see where a number came from. Required fields: frequency, source and consequence for sources and transformations.
• Signal: Master data changes without an owner. Evidence includes an example, frequency and consequence for data marts and semantic models.

Authority and escalation

For measures and thresholds, the role model determines more than screen access. In the action “map applications and data”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For measures and thresholds, this separation is especially important because of the risk “one data mart without shared meaning”.

• In the decision matrix, business owner connects master data and classifications with the action “map applications and data”.
• Architect: decision area — sources and transformations; control action — record interfaces and owners.
• Data owner is accountable for data marts and semantic models and confirms the action “identify critical dependencies”.
• Role: Project manager. Decision object: measures and thresholds; verified step: design target transitions.

End-to-end outcome test

The acceptance criterion for measures and thresholds 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 “errors are corrected only manually”, passes through an authorised decision and “identify critical dependencies”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1. Object: Master data and classifications. Test fields: baseline, target change, source and owner. Signal: Master data changes without an owner.
• 2. Acceptance object: sources and transformations; compare the baseline sample, expected change and confirmed actuals. Test signal: A dashboard does not lead to action.
• Evidence item 3 describes data marts and semantic models, comparable test conditions and the person accountable for interpretation. Signal: Errors are corrected only manually.
• Test 4 concerns measures and thresholds. The method, interpretation owner and outcome source are documented. Signal: One measure has multiple values.

Constraints and risk control

For the risk “treating an anomaly as a proven fact”, 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 data marts and semantic models 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 review starts with the condition “one data mart without shared meaning”. The decision uses the action “describe business services” and data about data marts and semantic models.
• Risk record 2. Condition: Measuring quality without a correction process. Control action: Map applications and data. Evidence source: Measures and thresholds.
• Risk: Self-service without a metric catalogue. Control: record interfaces and owners. Evidence: errors, corrections and the quality log.
• Risk condition 4: Treating an anomaly as a proven fact. Response: Identify critical dependencies. Testable evidence: Master data and classifications.

First working session

The first working session on sources and transformations uses real material: a transaction example, report or plan, systems diagram, role list and the variance “master data changes without an owner”. Participants select one scenario, identify data gaps and perform the action “map applications and data”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “treating an anomaly as a proven fact” helps determine the next format: a pilot, architecture discovery, competitive selection or process correction without a new system.

• Decision 1: describe business services. The basis for the next step is master data and classifications.
• Step 2. Map applications and data. Output: sources and transformations.
• Test 4 concerns measures and thresholds. The method, interpretation owner and outcome source are documented. Signal: One measure has multiple values.
• Control record 5: Errors, corrections and the quality log; data version, calculation rule, expected change and actual outcome. Signal: Users cannot see where a number came from.