Phase C of the TOGAF Architecture Development Method (ADM) is often considered the "engine room" of enterprise architecture. While Phase B defines what the business does, Phase C defines how information systems support those activities. It is split into two distinct but interconnected domains: Data Architecture and Application Architecture.
In TOGAF 10, the deliverables produced in Phase C are critical because they bridge the gap between business strategy and technical implementation. This guide zooms in exclusively on the four key deliverables of Phase C, providing a comprehensive breakdown of their purpose, structure, and real-world application.
The Architecture Definition Document (ADD) is the core descriptive artifact of the ADM. In Phase C, it specifically details the Baseline (current state) and Target (future state) for both Data and Application architectures. It is not just a collection of diagrams; it is a structured narrative that explains the logical structure of the enterprise’s information systems.
Data Architecture Section:
Data Entities: What data objects exist (e.g., Customer, Product, Transaction)?
Data Relationships: How do entities relate (e.g., One Customer has many Accounts)?
Data Distribution: Where does data reside (on-premise, cloud, edge)?
Application Architecture Section:
Application Portfolio: Inventory of current applications.
Application Interactions: How do apps communicate (APIs, message queues, batch files)?
Functional Decomposition: Breakdown of capabilities into specific software modules.
Use ArchiMate Views: Include standard ArchiMate diagrams for Application Cooperation and Data Structure.
Gap Analysis: Clearly highlight what exists today vs. what is needed tomorrow. Use a "Red/Amber/Green" status for each component.
Traceability: Link every application component back to a Business Capability defined in Phase B.
Over-Engineering: Including too much technical detail (e.g., database schema definitions) that belongs in Solution Architecture, not Enterprise Architecture.
Ignoring Legacy: Failing to document the baseline accurately, leading to unrealistic migration plans.
The Architecture Requirements Specification (ARS) translates business needs into specific, measurable requirements for data and applications. While the Business ARS (Phase B) focuses on processes, the Phase C ARS focuses on information integrity, availability, and system functionality.
Functional Requirements:
"The system must allow real-time synchronization of customer addresses across all channels."
"The application must support multi-currency transactions with automatic exchange rate updates."
Non-Functional Requirements (Quality Attributes):
Performance: "API response time must be <200ms for 95% of requests."
Scalability: "Data lake must handle 10TB of new data daily."
Security: "All personally identifiable information (PII) must be encrypted at rest using AES-256."
Interoperability: "Applications must expose RESTful APIs compliant with OpenAPI 3.0 standards."
MoSCoW Prioritization: Categorize requirements as Must have, Should have, Could have, or Won’t have.
SMART Criteria: Ensure every requirement is Specific, Measurable, Achievable, Relevant, and Time-bound.
Constraint Mapping: Explicitly list technical constraints (e.g., "Must use existing Oracle license").
Collaborate with Security Architects: Ensure security requirements are embedded early, not added as an afterthought.
Validate with Developers: Review technical feasibility with lead engineers before finalizing.
The Architecture Roadmap in Phase C provides the transition plan for moving from the Baseline to the Target Data and Application architectures. It identifies the sequence of projects, dependencies, and milestones required to evolve the information systems landscape.
Work Packages: Grouping related changes into manageable units (e.g., "Customer Data Migration Project," "Legacy CRM Decommissioning").
Transition Architectures: Defining intermediate states. For example:
State 1: Legacy CRM still active, but new Mobile App reads from a new API layer.
State 2: Legacy CRM read-only, new Cloud CRM active for writes.
State 3: Legacy CRM decommissioned.
Dependency Mapping: Identifying which data migrations must happen before certain applications can be retired.
Align with Business Cycles: Schedule major data migrations during low-volume periods (e.g., avoid end-of-month financial closing).
Risk-Based Sequencing: Tackle high-risk, high-value components first to prove value early.
Resource Leveling: Ensure that data engineering teams are not overloaded by overlapping migration projects.
Big Bang Approach: Trying to migrate all data and applications simultaneously. Instead, use iterative, incremental transitions.
Ignoring Data Quality: Assuming data can be migrated "as-is." Include data cleansing work packages in the roadmap.
Architecture Building Blocks (ABBs) are reusable components that capture specific business functionality and associated IT specifications. In Phase C, ABBs define the logical structure of data and applications, independent of specific products or vendors. They serve as the blueprint for Solution Building Blocks (SBBs) in later phases.
Data ABBs:
Example: "Unified Customer Profile" – A logical model defining what constitutes a "customer" across the enterprise, including attributes like ID, name, contact info, and preferences.
Application ABBs:
Example: "Payment Processing Service" – A logical component that defines the interface for processing payments, including inputs (amount, currency), outputs (confirmation code), and rules (fraud check).
Reusability: Can be used by multiple business capabilities (e.g., the "Customer Profile" ABB is used by Sales, Support, and Marketing).
Standardization: Defines standard interfaces and data formats.
Abstraction: Hides complexity. Users of the ABB don’t need to know how it’s implemented, only how to interact with it.
Start with Business Capabilities: Map each major business capability to one or more ABBs.
Define Interfaces Clearly: Specify inputs, outputs, and error handling for Application ABBs.
Document Data Models: For Data ABBs, provide entity-relationship diagrams and data dictionaries.
In Phase E and F, ABBs are refined into SBBs by selecting specific technologies (e.g., the "Payment Processing Service" ABB becomes an SBB implemented using Stripe API).
The four deliverables of Phase C are deeply interconnected:
The ADD describes what the data and application landscape looks like.
The ARS defines how well it must perform and what rules it must follow.
The Roadmap outlines when and in what order changes will occur.
The ABBs provide the reusable building blocks that make the architecture modular and scalable.
By mastering these deliverables, architects ensure that the information systems architecture is not just a technical exercise, but a strategic asset that enables business agility, data-driven decision-making, and efficient innovation.
