Phase C of the Architecture Development Method (ADM) is where enterprise architecture transitions from business strategy to system design. While earlier phases define what the business wants to achieve, Phase C defines the information and applications required to make those goals a reality. It focuses on two tightly integrated domains: Data Architecture and Application Architecture.
This guide provides a complete, beginner-friendly walkthrough of Phase C, covering its objectives, core concepts, practical considerations, and how it fits into the broader architecture lifecycle.
Phase C has two clear, measurable goals:
Develop the Target Information Systems Architecture (covering both Data and Application domains) so that it fully enables the Business Architecture and Architecture Vision, while addressing stakeholder concerns and the approved project scope.
Identify Candidate Architecture Roadmap Components by analyzing the gaps between the current (Baseline) state and the desired (Target) state of data and applications.
Data Architecture describes the structure of an organization’s logical and physical data assets, along with the resources used to manage them. It answers:
What data is critical to the business?
Where is data created, stored, transformed, and consumed?
How does data flow between systems and processes?
How is data quality, security, and lifecycle managed?
Application Architecture provides a blueprint for the individual software applications deployed in the enterprise. It answers:
Which applications support core business processes?
How do applications interact with each other and with data stores?
What functional capabilities does each application provide?
How do applications align with business goals and stakeholder needs?
Development Sequence Flexibility: Phase C can be executed as Data → Application, Application → Data, or concurrently. TOGAF intentionally leaves this choice to the architecture team based on organizational context, project constraints, and existing expertise.
When designing or transforming data architecture, architects must address:
Systems of Record/Reference: Clearly define which applications or databases own master data (e.g., customer, product, employee data).
Enterprise-Wide Standards: Establish consistent naming conventions, data formats, and integration protocols that all applications must follow.
Business-Data Mapping: Understand how data entities are used by specific business functions, processes, and services.
Data Lifecycle Tracking: Document where and how data is created, stored, transported, and reported across the enterprise.
Transformation Complexity: Assess the effort required to convert, clean, or restructure data for new systems.
Integration Requirements: Identify necessary software for data exchange (e.g., ETL tools, data profiling utilities, API gateways).
Replacing or upgrading applications almost always requires data migration. Critical steps include:
Identifying which data sets (master, transactional, reference) must move to the new system.
Defining the level of data cleansing, weeding, and transformation required before migration.
Ensuring the target system receives high-quality, validated data upon go-live.
Establishing a common enterprise data definition to prevent silos and inconsistencies post-migration.
Data architecture is not just technical; it requires organizational readiness. Governance focuses on three dimensions:
Structure: Does the organization have the right standards bodies, data stewardship roles, and cross-functional teams to manage data during transformation?
Management System: Are there defined processes for governing data quality, security, privacy, and lifecycle from creation to retirement?
People & Skills: Does the enterprise have personnel with the right data architecture, engineering, and stewardship skills? If not, training or hiring must be planned early.
Architects should never start from scratch. Phase C heavily utilizes the Architecture Repository to accelerate design by reusing proven reference models, industry standards, and enterprise-specific assets. Common examples include:
| Industry/Domain | Reference Model / Standard |
|---|---|
| Retail | ARTS Data Model |
| Petrotechnical | Energistics Data Model |
| Telecommunications | TM Forum Application Models |
| IT Service Management | IT4IT™ Reference Architecture |
| Healthcare, Finance, Transportation | OMG Vertical Domain Models |
| Cross-Industry Integration | III-RM (Integrated Information Infrastructure Reference Model) |
Using these models reduces design time, improves interoperability, and aligns the architecture with industry best practices.
Input from Phase B: Receives the Business Architecture, Architecture Vision, and Statement of Architecture Work. Business goals dictate what data and applications are needed.
Uniform Step Pattern: Like Phases B and D, Phase C follows a consistent rhythm: document Baseline → design Target → perform Gap Analysis → identify roadmap candidates.
Output to Phase D & E: The finalized Data and Application architectures inform Technology Architecture (Phase D). Gap analysis results and candidate solutions feed directly into Opportunities & Solutions (Phase E) to build the implementation roadmap.
Requirements Management: Throughout Phase C, new data and application requirements are continuously captured, validated, and fed into the central Requirements Management process.
Scenario: A regional healthcare provider wants to unify patient records across clinics, labs, and telehealth services to improve care coordination and reduce duplicate testing.
| Step | What Happens in Phase C |
|---|---|
| Baseline State | Patient data lives in 3 separate systems: clinic EHR, lab system, telehealth app. Data formats differ. Updates are manual or batch-synced nightly. |
| Target State | A single, real-time patient data hub with standardized records. All applications read/write to the hub via secure APIs. |
| Data Architecture Focus | Define master patient index, standardize clinical data formats (e.g., HL7/FHIR), map data flows, establish data quality rules, plan migration/cleansing strategy. |
| Application Architecture Focus | Blueprint how clinic EHR, lab system, and telehealth app will interact. Identify API middleware, define integration points, retire redundant legacy modules. |
| Gap Analysis | Missing real-time integration layer, inconsistent patient identifiers, no centralized data governance team. |
| Roadmap Candidates | 1) Deploy API gateway & integration middleware 2) Cleanse & migrate historical records 3) Establish data stewardship council 4) Retire legacy batch sync jobs |
This structured approach ensures technology decisions directly support clinical outcomes and regulatory compliance.
✅ Phase C bridges business strategy and technical execution by defining what data is needed and which applications will process it.
✅ It covers Data Architecture and Application Architecture, which can be developed in any order or concurrently.
✅ Success depends on rigorous data management, careful migration planning, and strong data governance.
✅ Architects should leverage the Architecture Repository and industry reference models to avoid reinventing the wheel.
✅ Outputs from Phase C (gap analysis, target architectures, candidate solutions) directly shape the Architecture Roadmap in Phase E.
✅ Phase C is iterative and continuously aligned with the Requirements Management process to adapt to changing business needs.
By mastering Phase C, architects ensure that enterprise systems are not just technologically sound, but fundamentally aligned with business value, data integrity, and long-term operational agility.
