Deep Battle Cards G–L
G — Optimistic vs Pessimistic Loading
Optimistic: continue with controlled provisional/unknown dimension member, then reconcile later.
Pessimistic: reject/recycle until required dependency is valid, then reload.
Purpose: manage sequencing exceptions such as fact-before-dimension.
Deciding clue: is controlled temporary inconsistency acceptable?
Contrast: create temporary Customer member → optimistic. Hold fact until Customer arrives → pessimistic.
Trap: optimistic does not mean ignore the exception; audit/reconciliation remain required.
Hook: Proceed and reconcile vs pause and reload.
Source: pp. 377–379.
H — Operational Reporting vs Strategic/Analytical BI
Operational: current workflow/status, shorter horizon, operational/ODS data often relevant.
Strategic/analytical: historical integrated trends, performance, planning, longer horizon.
Users: front-line/operational managers vs analysts/executives/planners.
Deciding clue: current workflow decision vs analysis across history.
Contrast: “Which orders are stuck now?” → operational. “How did delays change over three years?” → analytical.
Trap: report format alone does not determine the category.
Hook: Operational runs today; strategic BI learns across time.
Source: pp. 366–368, 379–384.
I — Governed Self-Service vs Unmanaged Analysis vs Managed Reporting
Governed self-service: authorized users create/explore on trusted reusable data with shared semantics, Metadata, lineage, permissions, and support.
Unmanaged: uncontrolled copies, definitions, access, outputs.
Managed reporting: centrally designed/predefined outputs with less creation freedom.
Deciding distinction: who creates the analysis and whether the underlying data/meaning/access remain governed.
Contrast: certified dataset + shared net-revenue definition + user-built dashboard → self-service. CSV downloads + individual formulas → unmanaged.
Trap: tool freedom without semantic/security guardrails is not successful self-service.
Hook: Freedom inside guardrails.
Source: pp. 379–386, 389–392.
J — Dictionary/Metadata vs Lineage vs Impact Analysis
Dictionary/Metadata: what does it mean, how is it structured/governed?
Lineage: where did it come from, how did it change, where did it go?
Impact: what would a proposed change affect?
Inputs: definitions/models, mappings, transformations, dependencies.
Outputs: glossary entries, lineage paths, dependency/impact reports.
Contrast: trace dashboard Revenue to ERP → lineage. Ask what reports break if Product hierarchy changes → impact.
Trap: a definition does not prove provenance; lineage enables but is not identical to impact analysis.
Hook: Metadata tells; lineage traces; impact predicts.
Source: pp. 363–364, 381–391.
K — Iteration vs Release vs Pilot/Sandbox vs Production
Iteration: development cycle/increment.
Release: coordinated package delivered to users/production.
Pilot/Sandbox: exploratory or limited validation.
Production: supported live service with practical business/IT controls.
Inputs to production: tested models/code/mappings/config, business acceptance, security/governance, monitoring/support readiness.
Deciding clue: being built vs packaged/deployed vs being proven vs officially supported.
Contrast: prototype works but monitoring/security/support absent → pilot, not production-ready.
Hook: Iterate → package → prove → operate.
Source: pp. 380–392.
L — Usage vs Coverage vs Performance vs Satisfaction
Usage: actual adoption/activity.
Coverage: breadth of intended analytical subjects/sources/departments represented/used.
Performance: load/query/refresh service behavior against expected windows.
Satisfaction: user perception, trust, usefulness, support experience.
Inputs: activity logs, lineage/source inventories, monitoring/SLAs, surveys/feedback.
Deciding clue: use it? cover it? run it? value it?
Contrasts: 500 licenses/45 active → usage; only Sales/Finance loaded → coverage; 90-sec query vs 10-sec target → performance.
Trap: one metric family cannot prove total program value.
Source: pp. 391–393.