8.3 Architecture Frameworks & Standards

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:

1. Baseline Data Architecture: Document the current state of data assets, schemas, and integration points.
2. Target Data Architecture: Define the desired future state that supports the business requirements defined in Phase B.
3. 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).
4. 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):

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.