Integrated Capstone — The Fragmented BI Estate
Situation
A retailer has: - five marts built independently; - inconsistent Customer and Date dimensions; - nightly full loads even where better change evidence may exist; - a separate near-real-time service dashboard; - weak lineage; - duplicate reports; - declining user trust.
Design a Chapter 11 response without solving everything by purchasing a new tool.
1. Primary problem
Fragmented analytical architecture and operating model. Tooling is only one component.
2. Leading Knowledge Area
Data Warehousing & Business Intelligence.
Supporting: Data Architecture, Modeling, Integration, Reference/Master Data, Metadata, Data Quality, Governance, Security, Storage/Operations, product/release management.
3. Roles
Sponsor/product owner; Enterprise/Data Architect; Modelers; integration/DW team; BI CoE; Stewards; Security/Governance; business SMEs.
4. Architecture decision
Choose a deliberate enterprise integration target or transition path: - converge on enterprise DW integration where that is the intended design; - or coordinate dimensional business-process increments with conformed Customer/Date dimensions and the DW bus; - or use an explicit hybrid/transition plan rather than accidental coexistence.
The correct answer is not “Inmon always” or “Kimball always.” State the integration mechanism and why it fits.
5. Latency separation
Ask whether the service dashboard is an operational current-data need. If so, preserve it in an ODS or justified low-latency feed rather than destabilizing the historical warehouse simply to make everything real-time.
6. Population
Profile source capabilities. Replace unnecessary full loads with source-supported CDC—timestamp, change table, transaction log or message delta as justified. Retain controlled rejects/recycles, load sequencing, audit, restart/recovery and service windows.
7. Shared semantics and trust
Govern Customer/Date definitions and conformance. Create/repair: - source-to-target mappings; - business/transformation rules; - DQ feedback/remediation; - business/technical Metadata; - end-to-end lineage; - logical/physical model synchronization.
8. BI delivery
Segment users and rationalize duplicate reports/tools. Preserve governed self-service for users who need exploration while keeping certified semantic definitions and publication/security controls.
9. Product operations
Establish: Backlog → planned releases → pilot/sandbox → business+IT readiness → production → monitor/tune → next backlog.
Use configuration management and a support model rather than ticket-only maintenance.
10. Evidence
Track a balanced set: - actual connected/query usage; - subject-area/business coverage; - load-window/service attainment; - query/refresh performance; - customer satisfaction/trust.
Why the tool-first answer loses
A new platform cannot by itself fix inconsistent dimensions, weak lineage, unsuitable load patterns, duplicate reports, missing governance, missing release discipline, or low trust.
Changed-fact logic
If one layer becomes solved—e.g. Customer/Date semantics are already conformed—do not rebuild it. Shift attention to the remaining leading constraint such as load efficiency, lineage, BI rationalization, or product operations.
Self-score
- 2: correct distinction + reason + source-aligned next action.
- 1: right area but vague or mixed responsibilities.
- 0: tool-first, architecture confusion, or missing critical gate.
Source anchor: pp. 361–393.