Quality, Security & Governance
Part 5: Running It Like a Platform
The two groups before this one made sure the platform runs — pipelines scheduled and versioned, lineage traceable end to end — but running reliably says nothing about whether the data flowing through that platform is correct, unambiguous, or safe for the person querying it to see. This group is the trust layer on top of the operational one. Data quality and data contracts make correctness an engineered, tested property instead of a hope; master data management makes sure the entities every team argues about — customer, product, account — resolve to one trustworthy golden record instead of five conflicting ones; and security and governance make sure access to all of it is controlled, auditable, and defensible to a regulator, not just convenient for whoever asks first. The next two topics step back from mechanism to institution: data strategy and roadmaps is how an architect turns an executive mandate into a sequenced, defensible plan, and the governance operating model is who is actually accountable for all of the above once the policy engine is built — a person, not a product, has to own the answer when something goes wrong. Privacy and industry regulation is where all of the above stops being a best practice and becomes a legal obligation with a specific, named architecture requirement attached — and the group closes by applying that same obligation somewhere it’s easy to forget it applies: test data management carries every one of those controls into dev, QA, and staging, where a prod snapshot and a careless refresh job can undo everything the rest of the group built. Together, these seven topics are what turns “the pipeline ran” into “you can build a decision, a model, or a compliance filing on what it produced — and defend, to a board or a regulator, who decided that and why, and exactly which law required it, in every environment the data ever touches.”
mindmap
root((Quality, Security & Governance))
Data Quality & Data Contracts
Shift-left testing
Producer/consumer contracts
Master Data Management
Match/merge & survivorship
Golden record & stewardship
Security & Governance
RBAC vs ABAC vs RLS
Policy as code
Compliance by design
Data Strategy & Roadmaps
Maturity assessment
Current vs target state
Governance Operating Model
Owner, steward, custodian
Governance council
Privacy & Industry Regulation
GDPR vs CCPA consent models
HIPAA minimum necessary
BFSI: Basel, PCI DSS, AML/KYC, SOX
Test Data Management
Masking vs tokenization
Subsetting & synthetic data
See also: Dimensional Modeling for the Cloud Era — a master data management golden record is the upstream source a conformed dim_customer is built from, and the same Slowly Changing Dimension decisions apply once that golden record starts changing over time. The Architect’s Decision Framework — a data strategy roadmap is that framework’s build-vs-buy-vs-compose judgment applied at the scale of a multi-year plan instead of a single decision.
Topics
| ← Previous: Metadata, Lineage & the Data Catalog | Next: Data Quality & Data Contracts: How Much Quality Is Enough? → | |:—|—:|
Table of contents
- Data Quality & Data Contracts: How Much Quality Is Enough?
- Master Data Management: Golden Records, Matching & Stewardship
- Security & Governance: Access Control, Federated Governance & Compliance by Design
- Data Strategy & Roadmaps: Maturity Assessment, Gap Analysis & Business Alignment
- The Governance Operating Model: Owners, Stewards, Custodians & the Council
- Privacy & Industry Regulation: GDPR, CCPA, HIPAA & BFSI Compliance (Basel, PCI DSS, AML/KYC, SOX)
- Test Data Management: Masking, Tokenization, Subsetting & Synthetic Data for Lower Environments