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 Roles and Responsibilities
Most TOGAF course material lists six or seven architect roles. The framework itself defines four architecture domains. Both are true, and the gap between them is where the confusion starts.
| Role | Domain they own | What they are accountable for | Heaviest ADM phases |
|---|---|---|---|
| Enterprise architect | All four, plus the method | The architecture as a whole, the ADM cycle, the Architecture Repository, arbitrating between domains | Preliminary, A, E, G, H |
| Business architect | Business Architecture | Capabilities, value streams, business processes, organizational structure, business drivers | A, B |
| Data architect | Data Architecture | Data entities and relationships, logical and physical models, data flow, ownership, quality and governance policy | B, C, D |
| Application architect | Application Architecture | Application portfolio, application interactions, how applications support business processes | C, D |
| Technology architect | Technology Architecture | Compute, storage, network, platform services, the infrastructure the other three depend on | D, E |
| Security architect | Cross-cutting, not a domain | Classification, access control, encryption, audit, regulatory constraints on every other domain | Preliminary, B, C, D, G |
| Infrastructure architect | Sits inside Technology Architecture | Physical and cloud infrastructure, capacity, availability, disaster recovery | D, E, F |
Two of those rows need a caveat, because slide decks and search results routinely get this wrong.
Security architect and infrastructure architect are not TOGAF architecture domains. TOGAF has four: Business, Data, Application, Technology. Security is a concern that cuts across all four, and the TOGAF Series Guide on security architecture treats it that way. Infrastructure is a subset of Technology Architecture. The job titles are real and common. The domains are not. If you’re answering an exam question, the answer is four domains. If you’re staffing a real programme, you’ll probably hire all seven.
The data architect and the application architect share Phase C. Phase C is Information Systems Architectures, which covers Data and Application together. TOGAF suggests doing Data first and Application second, though it allows the reverse when the applications are fixed and the data has to fit them. In practice this is the phase where the two roles either collaborate or collide.
Who Does What in Phase A
Phase A is Architecture Vision, the scoping phase that runs before any domain architecture gets built. Every architect contributes, and the contributions are small and specific.
- Enterprise architect - owns the phase. Secures the Request for Architecture Work, drafts the Statement of Architecture Work, defines scope and constraints, gets sponsor approval.
- Business architect - identifies the business goals and drivers the architecture has to serve, and maps the stakeholders whose concerns will shape it.
- Data architect - states the high-level data requirements and the data constraints that come with them: residency, retention, regulatory. Flags where current data capability won’t carry the vision. No models yet. Those are Phase C.
- Application architect - sketches the candidate application landscape at the level of “what systems are in scope”, not design.
- Technology architect - identifies platform constraints and any technology the organization is already committed to.
- Security architect - surfaces the regulatory and risk constraints early, while they’re still cheap to design around.
- Infrastructure architect - usually contributes through the technology architect at this stage rather than separately.
What everyone signs at the end is the Architecture Vision document and the Statement of Architecture Work. Nothing in Phase A is detailed. Its job is agreeing what’s in scope and who cares.
TOGAF Architecture Domains
The four domains in more detail, since the role table above compresses them:
Business Architecture
Business strategy, governance, organization, and the key business processes.
Data Architecture
The structure of an organization’s logical and physical data assets, and the resources that manage them. This is where data architects primarily operate.
Application Architecture
The individual applications, how they interact, and how they relate to core business processes.
Technology Architecture
The logical software and hardware capabilities required to support the business, data, and application services.
TOGAF Data Architecture
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:
- Learn the vocabulary - Speak the same language as enterprise architects
- Align deliverables - Map your work to TOGAF artifacts
- Follow the ADM - Participate in architecture development cycles
- Create building blocks - Document reusable data architecture patterns
- 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
What are the TOGAF architect roles?
What are the architect responsibilities in TOGAF Phase A?
Is security architect a TOGAF role?
What is the data architect's role in TOGAF?
What is TOGAF data architecture?
When does data architecture happen in the TOGAF ADM?
Should data architects get TOGAF certified?
What TOGAF artifacts do data architects create?
Related Reading
- What Is TOGAF? - Overview of the enterprise architecture framework
- What Is a Data Architect? - The role in detail
- What Is Data Architecture? - The broader discipline
- Database Architect vs Data Architect - How roles differ
- What Is Data Governance? - Key area in TOGAF Data Architecture
Last updated: 15 September 2026
Fractional Data Architect helping startups and scaleups build data platforms that scale.
More about Thomas Nys →