Study guide
8.3 Architecture Frameworks & Standards
DAMA Certified Data Management Professional CDMP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & DMBoK Framework
1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles
2 Chapter 2: Data Governance (Part A)
2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures
3 Chapter 2: Data Governance (Part B)
2.4 Data Stewardship 2.5 Governance Metrics & Implementation
4 Chapter 3: Data Modeling and Design (Part A)
Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization
5 Chapter 3: Data Modeling and Design (Part B)
3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices
6 Chapter 4: Data Quality (Part A)
Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle
7 Chapter 4: Data Quality (Part B)
4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting
8 Chapter 5: Metadata Management (Part A)
5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures
9 Chapter 5: Metadata Management (Part B)
5.4 Standards and Semantics 5.5 Metadata Governance & Integration
10 Chapter 6: Master and Reference Data Management
6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards
11 Chapter 7: Data Warehousing and Business Intelligence
7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses
12 Chapter 8: Data Architecture
8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards
13 Chapter 9: Document and Content Management
9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies
14 Chapter 10: Data Integration and Interoperability
Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards
15 Chapter 11: Data Security
Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards
16 Chapter 12: Data Storage and Operations
Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations
17 Chapter 13: Big Data and Data Science
13.1 Big Data V's & Technologies
18 Chapter 14: Data Ethics
14.1 DMBoK Data Ethics Framework
19 Chapter 15: Data Management Process and Maturity
15.1 Maturity Assessment Frameworks
8.3 Architecture Frameworks & Standards
Key Takeaways Explain This Topic AI
TOGAF places Data Architecture within Phase C: Information Systems Architectures, alongside Application Architecture.
Data Architecture serves as the architectural core connecting Data Governance (policy) to database systems (implementation).
The Architecture Review Board (ARB) is the governing body responsible for approving data models and enforcing standards.
ISO/IEC/IEEE 42010 defines the standard terms 'Architectural View' (the representation) and 'Architectural Viewpoint' (the schema rules).
Last updated: July 2026
TOGAF Alignment
TOGAF (The Open Group Architecture Framework) is the most widely adopted enterprise architecture framework globally. The core of TOGAF is the Architecture Development Method (ADM) , which is a cyclical process for planning, developing, implementing, and governing enterprise architectures.
The ADM cycle consists of several phases, structured as follows:
Phase A: Architecture Vision - High-level goals and stakeholders.
Phase B: Business Architecture - Business strategy, process, and organization.
Phase C: Information Systems Architectures - Divided into two sub-disciplines: Data Architecture and Application Architecture .
Phase D: Technology Architecture - Hardware, operating systems, and network infrastructure.
Phase E: Opportunities and Solutions - High-level implementation planning.
Phase F: Migration Planning - Transition roadmap.
Phase G: Implementation Governance - Architecture oversight of the build phase.
Phase H: Architecture Change Management - Governance of changes to the architecture.
Data Architecture in TOGAF Phase C
In Phase C, the Data Architect's primary objectives are:
Baseline Data Architecture : Document the current state of data assets, schemas, and integration points.
Target Data Architecture : Define the desired future state that supports the business requirements defined in Phase B.
Gap Analysis : Compare the Baseline and Target architectures to identify what needs to be built, migrated, or decommissioned. The output categorizes gaps into three distinct groups: New (components to be constructed), Modified (existing structures that require alteration), and Eliminated (legacy assets marked for retirement).
Data Migration Plan : Formulate strategies for migrating data from legacy formats to target repositories, focusing on data validation, transformation rules, and fallback procedures.
TOGAF emphasizes that Data Architecture must be developed in tight alignment with Application Architecture (the other half of Phase C) to ensure that applications can support the required data structures.
DAMA-DMBOK Connection
The DAMA-DMBOK2 outlines how Data Architecture interacts with all other 13 Data Management Knowledge Areas. It is the architectural spine of data management.
Data Governance : Data Governance provides the policies and standards, while Data Architecture designs the models and flows that implement these policies.
Data Quality : Data Architecture designs data models with constraints (nullability, datatypes, unique keys) that prevent bad data from entering databases.
Metadata Management : The artifacts of data architecture (data models, DFDs, lineages) are themselves metadata, which must be stored and managed in a metadata repository.
Data Security : Data architects identify sensitive data domains (e.g., PII) in their models and design the physical segregation or encryption zones.
Data Integration & Interoperability : Data architects define canonical data models, XML/JSON schemas, and payload specifications to govern system-to-system messaging formats and service-oriented architectures.
Master & Reference Data Management : Data Architecture identifies golden records, systems of record (SoR), and systems of origin (SoO) pathing that MDM systems must implement.
Architecture Steering and Governance
To prevent projects from diverging from the enterprise blueprints, organizations establish formal Architecture Steering and governance bodies, typically centered around an Architecture Review Board (ARB) or a Data Architecture Steering Committee .
Roles and Responsibilities of the ARB:
Model Review & Approval : Every new or modified logical and physical data model must be reviewed and approved by the ARB to ensure compliance with the Enterprise Data Model (EDM).
Standards Enforcement : Enforcing naming conventions, formatting, and structural standards (e.g., primary key definitions, standard audit columns like CreatedTimestamp ).
Variance and Exceptions : Reviewing requests for exceptions where a project must diverge from standards due to business or technical constraints.
Technical Debt Management : Tracking and planning the retirement of legacy databases and non-standard architectures.
Data Product Maps & Standards
Modern data architectures focus on Data Products . A data product is a curated, high-quality dataset, API, or dashboard designed to solve a specific business problem, managed as a product throughout its lifecycle. A Data Product Map visualizes these products, their owners, their source datasets, and their consumer applications.
Architects also rely on international standards to structure their work:
ISO/IEC/IEEE 42010 : This standard defines requirements for architecture descriptions of systems and software. It introduces the concepts of Architectural Views (what you see when looking at a system from a specific perspective) and Architectural Viewpoints (the conventions, rules, and templates used to construct a view). Under this standard, viewpoints are structured based on the target audience, specific concerns (e.g., security, query latency, scalability, storage footprint), and the language or notation models (like UML, ERD, or ArchiMate) used to describe them.
Worked Example: The TOGAF ADM Phase C Deliverables
The following table outlines key deliverables of Phase C (Data Architecture):
Deliverable Purpose Core Content
Data Principles Guiding rules for data management E.g., "Data is an asset", "Data is shared", "Data is secure".
Baseline Data Architecture Current state assessment Existing schemas, database inventories, current network topologies.
Target Data Architecture Desired future state blueprint Conceptual/logical models of the target state, data hub designs.
Data Architecture Gap Analysis Transition roadmap Identification of redundant systems to retire and new databases to build.
Data Migration Plan Risk-managed transition strategy ETL scripts, data profiling reports, reconciliation plans.
Exam Trap: Architectural View vs. Viewpoint
The CDMP exam often tests the distinction defined in ISO/IEC/IEEE 42010:
An Architectural Viewpoint is the template, standard, or perspective (e.g., "a security perspective" or "a database schema notation"). It specifies the rules, notations, and techniques. It is the schema template itself.
An Architectural View is the actual model, diagram, or implementation drawn for a specific system using that viewpoint (e.g., "the physical database schema for the billing system").
Think of the viewpoint as the lens and the view as the picture taken through that lens.