Cross-Domain Case Studies — Resolution Key 03–04
Case 03 — Regulatory Data-Control Remediation
1. Business objective and symptoms
The objective is demonstrable, proportionate control over sensitive data while preserving legitimate business use. Symptoms include inconsistent classifications, overlapping regulations, excessive entitlements, inappropriate test copies, incomplete lineage and weak exception evidence.
2. Leading Knowledge Area
Data Security leads the control/risk response, with Data Governance co-leading policy, accountability and exception authority.
3. Supporting Knowledge Areas
Metadata/lineage; Data Quality for completeness/accuracy of classifications and control data; Integration for vendor/extract flows; Organization & Roles; Organizational Change; Storage/Operations where data copies/backups are involved.
4. Roles
Data Owner/Stewards, Security Administrator, privacy/compliance/legal SMEs, security/risk leadership, Metadata Specialist, system/database owners, governance/exception body, auditors and Change Agents/managers.
5. Governance decisions
- define accountability for sensitive domains and controls;
- assign one internal confidentiality level where applicable while retaining all applicable external regulatory categories/obligations;
- establish access, masking, sharing, retention and exception policy;
- define approval/escalation/expiry/evidence requirements for exceptions;
- define legitimate-use principles so protection is proportionate rather than indiscriminately restrictive.
6. Architecture/design decisions
- catalog sensitive assets and build field-level/source-to-consumer lineage;
- distinguish identity verification from permission and total entitlement exposure;
- design least-privilege roles/entitlements;
- use persistent masking for a stored non-production copy when underlying PII must not remain, versus dynamic masking for user-visible representation when underlying truth is retained;
- design vendor/data-sharing controls and monitoring evidence.
7. Ordered management execution
- discover/inventory sensitive data and applicable obligations;
- validate classifications and map lineage/copies/consumers;
- identify vulnerabilities/threats and perform risk assessment based on likelihood/impact/value;
- approve proportionate policies/control requirements and exception process;
- recertify authorization/entitlements—not just authentication;
- remove excess access, redesign roles and protect test/vendor copies appropriately;
- remediate uncontrolled data movements and attach approvals to assets/users with expiry;
- monitor access, exceptions, control performance and lineage completeness;
- train/communicate changed roles and legitimate-use paths so teams do not recreate shadow workarounds;
- provide auditable evidence to governance/audit/regulator.
8. Evidence and metrics
Entitlement reduction; access-review completion; unauthorized-access exceptions; classification/lineage coverage; masking coverage; exception age/expiry; vendor-sharing evidence; audit findings; control failures; legitimate-use service impacts.
9. Tempting shortcut
Encrypt everything and declare success. Encryption is one control; it does not resolve overbroad authorization/entitlements, test-copy exposure, missing lineage, unmanaged exceptions or regulatory-category/accountability gaps.
10. Changed-fact branch
If classification, lineage, policy and entitlements are already correct and the only problem is that users cannot prove identity reliably, Authentication control becomes the leading technical issue.
Sources
Case 04 — Legacy Warehouse to Modern Analytical Platform
1. Business objective and symptoms
The objective is a controlled modernization that preserves trusted historical semantics while improving scalability/latency and reducing operational risk. Symptoms include missing lineage, hidden DQ remediation, inconsistent semantics, an underspecified target, no transition state and technology-fashion decisions.
2. Leading Knowledge Area
Data Architecture leads the modernization structure because current/target/transition states, enterprise concepts, standards and roadmaps must be coherent before hundreds of jobs/schemas are redesigned.
3. Supporting Knowledge Areas
DW/BI; Integration & Interoperability; Data Modeling & Design; Metadata; Data Quality; Storage/Operations; Governance; Security; Organizational Change.
4. Roles
Data Architect, DW/BI Architect, Data Modelers, Integration Architect/Specialists, Metadata specialists, DQ Analyst/Stewards, platform/DB operations, governance/ARB, Security and Change Agents/business owners.
5. Governance decisions
- approve modernization objectives, architectural principles and decision rights;
- decide which enterprise semantics/history are non-negotiable;
- govern source-of-truth, DQ responsibilities and acceptable transformation/remediation rules;
- approve security/retention requirements and migration exception gates;
- define architecture-review/conformance process for project teams.
6. Architecture/design decisions
- document current architecture and dependencies;
- define target analytical architecture based on business/quality/latency needs—not technology fashion;
- define transition-state architecture for coexistence, synchronization and rollback;
- preserve/reconcile enterprise models before teams independently redesign schemas;
- choose ETL vs ELT by target capability, raw retention, recovery and operational requirements;
- select batch/micro-batch/event/synchronous patterns from actual freshness/transaction coupling needs;
- define staging/ODS/DW/mart roles and historical behavior;
- establish Metadata/lineage/metamodel design.
7. Ordered management execution
- inventory systems, jobs, consumers, SLAs, business semantics and historical dependencies;
- capture lineage/dependencies and profile critical data to expose hidden defects;
- validate enterprise concepts/current-state assumptions;
- define target + transition architecture and migration waves;
- separate intentional transformation from source defects that require remediation;
- rationalize mappings and orchestration; identify reusable/conformed analytical structures;
- choose ETL/ELT and latency patterns per workload—not one universal rule;
- pilot high-value bounded domains and run coexistence/reconciliation controls;
- migrate in waves with rollback/history/reproducibility evidence;
- communicate role/process changes, train users/operations and measure adoption/stability;
- retire legacy components only after evidence shows target behavior/semantics are stable.
8. Evidence and metrics
Lineage coverage; reconciliation of historical reports; DQ defect escape/recurrence; migration success/retry rates; latency SLA; job failure/recovery; performance/cost; semantic/conformance exceptions; user adoption; number of legacy dependencies retired safely.
9. Tempting shortcut
Convert all ETL to ELT and do a big-bang cutover because the target is modern. This ignores business latency differences, recovery/raw-data needs, semantic dependencies, transition architecture and people/operational adoption.
10. Changed-fact branch
If the target/transition architecture and enterprise semantics are already approved and the remaining task is converting a specific source-to-target pipeline, Integration & Interoperability / DW implementation becomes leading rather than Data Architecture.