5.1 Phase C Data Architecture Objectives, Approach, and Data Principles
Key Takeaways
Phase C (Information Systems Architectures) addresses both Data Architecture and Application Architecture, establishing how enterprise information assets and software systems realize the Phase B Business Architecture.
The ADM provides complete flexibility in sequencing Phase C: architects may address Data before Application Architecture, Application before Data Architecture, or model both concurrently and iteratively.
Business Architecture directly drives Data Architecture: business functions, capabilities, and value streams define what data entities are required, their operational definitions, and business ownership.
Data architecture principles must follow the standard TOGAF principle template (Name, Statement, Rationale, Implications), establishing core mandates such as 'Data is an Asset', 'Data is Shared', 'Common Vocabulary', and 'Data Trustee'.
Data governance enforces clear separation of duties across Data Owners (executive business accountability), Data Trustees/Stewards (operational definitions, data quality, and access policy custody), and Technical Custodians (physical storage, infrastructure, and backup management).
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles
Phase C of the TOGAF Architecture Development Method (ADM) addresses Information Systems Architectures, encompassing two distinct yet interdependent domains: Data Architecture and Application Architecture. While both domains can be documented in a single combined phase or split into separate iterative sub-phases, understanding their boundaries, sequencing trade-offs, and governance foundations is critical for the TOGAF Enterprise Architecture Practitioner examination.
Core Objectives of Phase C Data Architecture
The primary objective of Data Architecture within Phase C is to define the major types and sources of data necessary to support the enterprise in a manner that is understandable to business stakeholders, complete, consistent, and stable across technology lifecycles. Rather than designing physical database tables or writing query schemas, the enterprise data architect structures the enterprise's logical and physical information assets to realize the business capabilities modeled in Phase B.
TOGAF states two objectives for the data part of Phase C: develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns; and identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Data Architectures. In practice this involves:
- Develop the Target Data Architecture: Formulate target models that address the business requirements articulated in the Architecture Vision (Phase A) and Business Architecture (Phase B), directly responding to stakeholder concerns and the Request for Architecture Work.
- Identify Candidate Architecture Building Blocks (ABBs): Define reusable, logical building blocks for data management, governance, security, and data exchange.
- Analyze Gaps Between Baseline and Target: Systematically identify discrepancies between existing data assets and target needs, documenting missing data entities, redundant data stores, and governance deficiencies.
- Formulate Candidate Roadmap Components: Feed data-related transition components and work packages into Phase E (Opportunities and Solutions) and Phase F (Migration Planning).
Key Considerations for Data Architecture
TOGAF highlights three considerations when developing the Data Architecture:
- Data management: how data entities are used by business functions, processes, and services; which data is master or reference data; and how data is created, stored, transported, and reported across the enterprise.
- Data migration: when the target replaces existing systems, data must be extracted, transformed, cleansed, and loaded, and the target should define the standard data definitions that migration is measured against.
- Data governance: the structure, management system, and people needed to manage data change and data quality.
How Business Architecture Drives Data Architecture
A fundamental tenet of the TOGAF Standard is that data does not exist in isolation; it derives its purpose, meaning, and governance from the business context. Business Architecture (Phase B) serves as the primary driver for Data Architecture:
- Business Capabilities to Data Entities: Every business capability requires specific information to function. For example, a Claims Adjudication capability requires data entities such as Policyholder, Coverage Terms, Incident Report, and Claim Dossier.
- Information Mapping: In the TOGAF Series Guides for Business Architecture, Information Mapping identifies high-level business information concepts from a business perspective. In Phase C, data architects translate these business concepts into formal Data Entities and canonical models.
- Value Streams and Information Flow: Value streams illustrate the end-to-end flow of value to a stakeholder. Data Architecture defines the information created, enriched, and consumed at each stage of the value stream.
Attempting to build a data architecture strictly from a technical standpoint—such as organizing data around database vendor features—results in fragmented architectures detached from business outcomes.
The Sequencing Dilemma: Data First vs. Application First vs. Concurrent
A recurring scenario on the practitioner exam challenges candidates to determine whether Data Architecture should precede Application Architecture, or vice versa. The TOGAF Standard does not mandate a rigid order; instead, it explicitly supports three sequencing strategies:
1. Data Architecture First
- When to Use: When the enterprise transformation is driven by data exploitation, such as enterprise business intelligence, artificial intelligence/machine learning initiatives, master data consolidation, or regulatory reporting programs.
- Architectural Rationale: Applications have relatively short lifecycles—they are frequently replaced, upgraded, or refactored every 5 to 7 years. In contrast, core business data entities (such as Customer, Product, and Financial Ledger) outlive individual software applications by decades. Designing the data architecture first creates a stable, application-neutral information baseline that incoming software packages must conform to.
2. Application Architecture First
- When to Use: When the enterprise has committed to acquiring commercial off-the-shelf (COTS) enterprise systems (such as a major ERP or CRM suite), or when the primary driver is the rapid automation of specific operational workflows.
- Architectural Rationale: COTS software packages come with predefined, proprietary internal data models. Attempting to design an abstract canonical data model before selecting the software package often leads to extensive rework, as the enterprise must ultimately adapt to the vendor's data structures.
3. Concurrent and Iterative Development
- When to Use: Modern agile digital transformations, microservice implementations, and cloud-native application modernization.
- Architectural Rationale: Data models and application service boundaries (such as REST APIs or event contracts) are deeply coupled at the domain level. Architects iterate between data entity definition and application service design across continuous ADM delivery sprints.
Formulating Data Principles Using the TOGAF Template
Architecture principles govern the design and evolution of systems across the enterprise. In accordance with the TOGAF Standard, every data principle must be formulated using the standardized four-part structure:
| Principle Element | Purpose and Definition |
|---|---|
| Name | A concise, memorable phrase that captures the essence of the rule. Must not be ambiguous. |
| Statement | A definitive, prescriptive directive stating unambiguously what should or should not happen. |
| Rationale | The business benefit, financial value, or risk mitigation that justifies the principle. |
| Implications | The concrete operational, financial, and organizational impacts, costs, and behavioral changes required to comply. |
Core TOGAF Data Principles Deep Dive
Practitioners must be familiar with the classic enterprise data principles and their architectural implications:
Principle 1: Data is an Asset
- Statement: Data is an enterprise asset that has quantifiable business value and must be managed systematically throughout its lifecycle.
- Rationale: Accurate, timely data is essential for informed decision-making and operational execution. Treating data as an ad-hoc byproduct of software applications results in inconsistent, low-quality information and missed business opportunities.
- Implications: The enterprise must allocate capital and operational funding for data management; data ownership and stewardship roles must be formally assigned; data quality metrics must be measured and reported to executive leadership.
Principle 2: Data is Shared
- Statement: Users and applications across the enterprise have access to the data necessary to perform their duties, subject to security and regulatory constraints.
- Rationale: Data hoarded within organizational silos duplicates operational costs, impedes cross-functional collaboration, and prevents a single unified view of enterprise operations.
- Implications: Systems must expose data via standardized, open interfaces and APIs rather than proprietary protocols; historical boundaries between departments must yield to shared data access; data security policies must govern access without creating unnecessary operational friction.
Principle 3: Common Vocabulary and Data Definitions
- Statement: Data entities and attributes are defined consistently across the enterprise and documented in a shared Enterprise Business Glossary.
- Rationale: Discrepant terminology leads to communication failures, reporting inaccuracies, and costly system integration efforts (e.g., when the Sales division defines Customer differently from the Finance division).
- Implications: Business units must collaborate to establish authoritative definitions; software development projects must conform to the shared data dictionary; legacy systems must map their internal terms to the canonical enterprise vocabulary.
Principle 4: Data Trustee and Stewardship
- Statement: Each enterprise data entity has an assigned Data Trustee accountable for its definition, data quality rules, and access policies.
- Rationale: Without designated trustees, no single party accepts accountability for resolving data defects, leading to neglected data assets and compliance breaches.
- Implications: Data stewardship responsibilities must be incorporated into formal job descriptions and performance evaluations; trustees must actively review and approve data access requests and schema modifications.
Data Stewardship and Governance Roles
Establishing governance mechanisms is essential to prevent data architecture models from becoming theoretical shelfware. TOGAF's example principle Data Trustee states that each data element has a trustee accountable for data quality. Common data governance practice spreads accountability across three roles:
- Data Owner (Executive Accountability): A senior business leader (such as a Vice President of Sales or Chief Financial Officer) who has formal operational ownership of a specific business data domain. The Data Owner is accountable for data classification, funding data remediation projects, and approving cross-domain data sharing agreements.
- Data Trustee / Data Steward (Operational Custody): A designated business and domain expert acting on behalf of the Data Owner. The Data Trustee defines operational business glossaries, establishes data validation rules, monitors data quality scorecards, and evaluates access requests.
- Data Custodian / Technical Custodian (Infrastructure & Engineering): An IT or engineering professional (such as a Lead Database Administrator or Cloud Data Engineer) responsible for the physical storage, server hosting, encryption key management, network transport, backup/recovery, and disaster recovery of data assets.
Exam Practitioner Scenario: Sequencing in Practice
Scenario: Global Logistics Corp is embarking on a multi-year digital transformation. The organization operates 14 regional logistics centers, each running a disparate legacy dispatch application. Executive leadership has set two primary strategic goals:
- Achieve unified real-time visibility into global container tracking and inventory analytics to optimize fleet logistics.
- Procure and deploy an off-the-shelf Commercial Off-The-Shelf (COTS) Fleet Management Suite within 18 months.
Architectural Analysis: The enterprise architect must decide how to sequence Phase C.
- Wrong Approach: Developing a complete, rigid logical data model for all fleet operations before beginning software vendor evaluations. This delays procurement and creates models that will inevitably clash with the COTS package's internal data schema.
- Wrong Approach: Postponing all data architecture until after the COTS package is implemented. This abandons the real-time global tracking and analytics objective, allowing disparate legacy data definitions to persist.
- Optimal Approach (Gradient 5-Point Response): Sequence Phase C using a concurrent, partitioned strategy. For the real-time visibility objective, develop a Target Data Architecture first—specifically defining a Canonical Data Model and Data Dissemination Architecture for container tracking. For the fleet dispatch operations, conduct Application Architecture first to evaluate COTS software packages, followed by mapping the selected COTS data entities into the enterprise canonical tracking model.
Common Exam Traps & Pitfalls
- Trap 1: The 'Data Architecture Always Precedes Application Architecture' Myth: Exam questions often tempt candidates with absolute statements claiming TOGAF mandates Data Architecture first. The standard explicitly grants architects the flexibility to do Data first, Application first, or both concurrently.
- Trap 2: Confusing Data Owner with Data Custodian: Questions frequently ask who is accountable for authorizing data access policies versus who implements encryption. Remember: the Data Owner (business) holds accountability for policy, while the Data Custodian (IT) implements technical controls.
- Trap 3: Writing Principles Without Implications: A distracter option on principle formulation will present a statement and rationale but omit implications. In TOGAF, an architecture principle without implications is incomplete because it fails to define the operational cost of compliance.
Regarding the execution sequence between Data Architecture and Application Architecture in Phase C, what guidance does the TOGAF Standard provide?
Data Architecture must strictly precede Application Architecture, so that database structures are fully normalized before any software procurement begins
The architect may do Data before Application, Application before Data, or both together iteratively, depending on the enterprise context
Application Architecture must always come first, because business data entities cannot be defined until the underlying software vendor is identified
The two domains cannot be developed in the same ADM cycle and must be handled in separate sequential iterations of the architecture work
When formulating enterprise architecture principles using the standardized TOGAF template, which component describes the concrete operational impacts, costs, and behavioral changes required to comply with the principle?
Principle Statement
Principle Rationale
Architecture Vision statement
Principle Implications
In enterprise data governance, which role is operationally responsible for defining business data terms, maintaining the business glossary, setting data quality criteria, and assessing day-to-day data access requests?
Data Trustee (or Data Steward)
Database Administrator (Technical Custodian)
Chief Information Security Officer (CISO)
Lead Solution Architect
Sections you finish are checked off in the contents.