The Short Version

In TOGAF (The Open Group Architecture Framework), the data architect works primarily within the Data Architecture domain - one of four core architecture domains alongside Business, Application, and Technology Architecture.

The data architect role in TOGAF is responsible for defining how an organization’s data assets support business strategy. This includes data models, data flow, data governance, and the policies that ensure data is managed as a strategic asset.

If you’re a data architect working in an enterprise that uses TOGAF, understanding how your role fits the framework helps you speak the same language as enterprise architects and align your work with broader organizational architecture.

TOGAF Architecture Domains

TOGAF defines four architecture domains:

Business Architecture

Defines business strategy, governance, organization, and key business processes.

Data Architecture

Defines the structure of an organization’s logical and physical data assets and data management resources.

This is where data architects primarily operate.

Application Architecture

Defines the individual applications, their interactions, and their relationships to core business processes.

Technology Architecture

Defines the logical software and hardware capabilities required to support business, data, and application services.

Data Architecture in TOGAF

Definition

TOGAF defines Data Architecture as:

“A description of the structure of an organization’s logical and physical data assets and the data management resources.”

This includes:

  • Logical data assets - Conceptual and logical data models
  • Physical data assets - How data is actually stored
  • Data management resources - Tools, processes, and governance

Scope

Data Architecture in TOGAF covers:

  • Data entities and relationships
  • Data lifecycle management
  • Data quality standards
  • Data governance policies
  • Data integration patterns
  • Metadata management
  • Master data management

The ADM and Data Architecture

The Architecture Development Method (ADM) is TOGAF’s process for developing enterprise architecture. Data architects engage heavily in several phases:

Preliminary Phase

Establish architecture capability:

  • Define data architecture principles
  • Identify stakeholders for data concerns
  • Establish data governance framework
  • Assess current data architecture maturity

Phase A: Architecture Vision

Create high-level vision:

  • Identify data-related business goals
  • Define data architecture scope
  • Outline target data capabilities
  • Secure stakeholder commitment

Phase B: Business Architecture

Understand business context:

  • Map business processes that generate/consume data
  • Identify business data requirements
  • Understand information flows between business functions
  • Define business data ownership

Phase C: Information Systems Architectures

This is the primary phase for data architecture work.

Data architects develop:

  • Baseline Data Architecture (current state)
  • Target Data Architecture (future state)
  • Gap analysis between baseline and target
  • Data architecture building blocks

Data Architecture Artifacts

TOGAF suggests these deliverables:

Catalogs:

  • Data Entity/Data Component catalog
  • Data Entity/Business Function matrix

Matrices:

  • Data Entity/Business Function matrix
  • Application/Data matrix

Diagrams:

  • Conceptual Data Diagram
  • Logical Data Diagram
  • Data Dissemination Diagram
  • Data Lifecycle Diagram
  • Data Security Diagram
  • Data Migration Diagram

Phase D: Technology Architecture

Support technology decisions:

  • Data storage technology requirements
  • Data integration technology needs
  • Database platform recommendations
  • Data security technology

Phase E: Opportunities and Solutions

Plan implementation:

  • Identify data architecture work packages
  • Prioritize data initiatives
  • Define transition architectures
  • Assess implementation risks

Phase F: Migration Planning

Create roadmap:

  • Data migration sequences
  • Implementation dependencies
  • Resource requirements
  • Timeline and milestones

Phase G: Implementation Governance

Guide execution:

  • Architecture compliance reviews
  • Data standard adherence
  • Quality checkpoints
  • Change management

Phase H: Architecture Change Management

Manage evolution:

  • Monitor data landscape changes
  • Assess change requests
  • Update data architecture as needed
  • Continuous improvement

Data Architecture Building Blocks

TOGAF uses the concept of Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).

Data ABBs (Architecture Building Blocks)

Abstract, reusable data architecture components:

  • Master Data Management capability
  • Data Quality Management capability
  • Metadata Management capability
  • Data Integration patterns
  • Data Governance framework

Data SBBs (Solution Building Blocks)

Specific implementations:

  • Specific MDM tool (e.g., Informatica MDM)
  • Data quality platform (e.g., Great Expectations)
  • Data catalog implementation (e.g., Atlan, DataHub)
  • ETL/ELT tools (e.g., dbt, Fivetran)

Data Architecture Principles

TOGAF emphasizes principles as guides for decision-making. Example data principles:

Data is an Asset

Statement: “Data is an asset that has value to the enterprise and is managed accordingly.”

Implications:

  • Data has measurable business value
  • Data management is funded appropriately
  • Data quality is actively managed

Data is Shared

Statement: “Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions.”

Implications:

  • Single sources of truth are maintained
  • Data silos are eliminated where possible
  • Access controls enable appropriate sharing

Data Trustee Accountability

Statement: “Each data element has a trustee accountable for data quality.”

Implications:

  • Clear ownership for all data
  • Quality standards are enforced
  • Stewardship responsibilities are defined

Common Vocabulary

Statement: “Data is defined consistently throughout the enterprise using common vocabulary.”

Implications:

  • Shared data dictionary
  • Consistent naming conventions
  • Business glossary maintenance

Practical Application

For Enterprise Environments

If your organization uses TOGAF:

  1. Learn the vocabulary - Speak the same language as enterprise architects
  2. Align deliverables - Map your work to TOGAF artifacts
  3. Follow the ADM - Participate in architecture development cycles
  4. Create building blocks - Document reusable data architecture patterns
  5. Define principles - Establish guiding principles for data decisions

For Pragmatic Data Architects

TOGAF can be heavyweight. Practical adoption:

  • Use TOGAF concepts without full compliance
  • Focus on artifacts that add value
  • Adapt the ADM to your organization’s pace
  • Don’t let process slow down delivery

What to Take From TOGAF

Even if you don’t use TOGAF formally:

  • Baseline vs Target thinking - Document current and future state
  • Principles-based decisions - Establish guiding principles
  • Building block concept - Create reusable patterns
  • Stakeholder mapping - Identify who cares about what
  • Governance integration - Connect data architecture to broader governance

TOGAF Certification for Data Architects

Is It Worth It?

Consider certification if:

  • Your organization uses TOGAF
  • You work with enterprise architects regularly
  • Your clients/employers value the credential
  • You want to understand enterprise architecture context

Skip if:

  • Your environment doesn’t use formal EA frameworks
  • You’re in a startup or growth-stage company
  • Practical data architecture skills matter more than credentials

Certification Levels

  • TOGAF Foundation (Level 1) - Basic understanding
  • TOGAF Certified (Level 2) - Application and analysis

Data architects typically benefit most from Level 1 for vocabulary and context, with Level 2 optional.

Frequently Asked Questions

What is the data architect's role in TOGAF?
In TOGAF, the data architect works primarily in the Data Architecture domain, defining how an organization’s data assets support business strategy. This includes data models, data flow, governance policies, and ensuring data is managed as a strategic asset.
What is Data Architecture in TOGAF?
TOGAF defines Data Architecture as the structure of an organization’s logical and physical data assets and data management resources. It covers data entities, relationships, lifecycle management, quality standards, governance, and integration patterns.
When does data architecture happen in the TOGAF ADM?
Data architecture work happens primarily in Phase C (Information Systems Architectures), but data architects engage in most ADM phases - from defining principles in the Preliminary Phase through implementation governance and change management.
Should data architects get TOGAF certified?
It depends on context. TOGAF certification is valuable if your organization uses TOGAF, you work with enterprise architects, or clients value the credential. It’s less essential for startups or environments not using formal EA frameworks.
What TOGAF artifacts do data architects create?
Data architects create catalogs (Data Entity catalog), matrices (Application/Data matrix), and diagrams (Conceptual Data Diagram, Logical Data Diagram, Data Lifecycle Diagram, Data Migration Diagram, Data Security Diagram).