Phase C orientation: data and applications together

Phase C is often misunderstood as two separate streams that happen to sit beside one another in the ADM. In practice they are tightly linked. Information architecture asks what information the enterprise needs, how it is grouped, where authority sits, and how trust is preserved. Application architecture asks which application responsibilities, services, and interactions support that information landscape.

If the team splits those discussions too early, it tends to produce application boundaries that duplicate or blur information authority, or information models that ignore the real responsibilities of the systems and teams that have to make them work. The water utility story at the top of this module is a textbook example: the application team chose a consolidation path that contradicted the authority model the information team had designed. Nobody noticed because the two workstreams never shared a common viewpoint.

TOGAF's reasoning is straightforward. If the enterprise defines information responsibilities without understanding which applications will enforce them, the information model remains a paper exercise. If the enterprise defines application boundaries without understanding the information authority rules those applications must respect, the application model becomes a product-selection exercise disconnected from enterprise meaning.

The standard therefore treats Phase C as a single coordinated domain. The information side and the application side are two perspectives on the same enterprise problem. The architecture team may divide labour between them, but the outputs must be cross-referenced, governed together, and presented as one coherent pack.

TOGAF names the Data and Application domains inside the Phase C objective itself: the target is the Information Systems (Data and Application) Architecture that enables the business architecture and the architecture vision, addressed to the approved statement of work and stakeholder concerns. That parenthetical is not decoration. It is the standard's own signal that Phase C carries two named domains rather than one undifferentiated body of work, even while both domains sit inside a single phase and answer to a single set of stakeholder concerns.

C220 Part 1 states two canonical objectives for Phase C: (1) develop the target Information Systems (Data and Application) Architecture in a way that enables the Business Architecture and the Architecture Vision; and (2) identify candidate Architecture Roadmap components from the gaps between baseline and target. TOGAF then works through those two objectives twice: once for data architecture, once for application architecture, as two parallel step sequences rather than one generic checklist. The eight steps below are the shared shape of both sequences. Understanding that shape, and that it runs twice, prevents the common mistake of treating Phase C as a single undifferentiated to-do list.

1. Develop the baseline architecture description for the domain in hand, data or application, so the target is defined against a real starting point rather than in the abstract. For data, this is how information authority and source of truth actually sit today. For applications, this is the current portfolio and how its components interact now.
2. Develop the target architecture description for the domain in hand, data or application, that enables the business architecture and the architecture vision. For data, this is the target information-domain and source-of-truth picture. For applications, this is the target portfolio and logical component picture.
3. Identify candidate architecture building blocks for that domain, based on the business-architecture and architecture-vision work already completed. The ABBs should be logical and product-neutral at this stage.
4. Select and develop the ABBsthat will form the domain's target architecture. This moves from candidate identification to deliberate selection and detailed specification.
5. Conduct a formal stakeholder review of the proposed architecture. Neither domain's outputs are finished until the enterprise's key stakeholders have reviewed and accepted them.
6. Identify and resolve gaps between that domain's baseline and target architecture. Gap analysis reveals what must change, what can be retained, and what must be eliminated.
7. Confirm the architecture aligns with enterprise principles established in the Preliminary Phase. This prevents either domain's work from drifting away from the organisation's agreed decision constraints.
8. Finalise the domain's section of the architecture definition document and related artefacts. Data architecture finalises entity and component catalogues, logical and physical data models, and data lineage. Application architecture finalises the application portfolio catalogue, logical component and interaction views. Both feed the same architecture definition document rather than two separate ones.

Data and application architecture can run this sequence in either order, or concurrently, because TOGAF does not mandate one over the other; the course keeps them side by side in the figure below because their outputs must be cross-referenced before either is signed off. A Phase C exercise that treats the eight steps as running once, for a single merged domain, tends to lose exactly the distinction that step 1 depends on: whether the deliverable in hand is a data artefact or an application artefact.

The discipline of Phase C becomes clearer when the team keeps two distinct but connected questions visible throughout.

The information architecture question. What information matters to the enterprise, how is it grouped into information domains, where does authority sit, and what publication, stewardship, or reuse obligations follow from that? This side of Phase C is anchored by metadata discipline, authority mapping, and information-domain structuring.

The application architecture question. Which application responsibilities and interactions are needed to support the enterprise information model and the business capabilities it serves? This side is anchored by the ABB and SBB discipline that keeps enterprise judgement independent of vendor choice.

The shared enterprise question. How do these two views fit together so that the business architecture can be governed, implemented, and changed without losing trust or coherence? This is the question that makes Phase C one domain rather than two projects.

Consider a planning function in a London distribution network that needs to publish network development forecasts externally. The information question asks what data feeds the forecast, who is authoritative for input assumptions, and what metadata the published output must carry. The application question asks which systems prepare the forecast, which systems validate inputs, and how the published view reaches external consumers. The shared question asks whether the authority model and the application responsibility model are consistent, and whether the published output can be traced back through both. Neither question can be answered well without the other.

Phase C does not start from a blank page. It should receive clear inputs from the business architecture work completed in Stage 3. The quality of those inputs directly affects the quality of the information and application architecture that follows.

• Capabilities and value stages that tell the team which business outcomes the information system must support. Without these, the Phase C team is designing in the abstract.
• Business gaps that reveal where trust, speed, quality, or accountability are currently breaking down. These gaps become the information and application problems that Phase C must address.
• Stakeholder concerns that shape publication, evidence, resilience, and integrationchoices. A CTO's concern about technical debt looks different from a regulator's concern about publication transparency.
• Architecture principles that already constrain reuse, interoperability, evidence quality, and governance behaviour. These principles were settled in the Preliminary Phase and must be respected throughout Phase C.
• Business scenarios that describe real enterprise problems in stakeholder language. These scenarios help Phase C stay grounded in business reality rather than drifting into abstract modelling.

If any of these inputs are missing or weak, the Phase C team should flag the gap before proceeding. Designing information and application architecture without business context is like fitting out a building before the architects have decided what the building is for.

A disciplined Phase C does not try to produce everything at once. The first pass should be readable by non-technical stakeholders and structured enough to guide later decisions.

1. A plain-language information-domain view showing the major information groupings the enterprise cares about. For a London distribution network, those might include customer, connection, planning, asset, network, telemetry, and publication domains.
2. An information-authority viewshowing where stewardship, publication, and partial authority sit. This is the view that prevents the "single source of truth" slogan from hiding real governance complexity.
3. A simple application-responsibility view that names ABBs (logical roles) before SBBs(specific products). This preserves the enterprise's ability to compare options against a stable logical requirement.
4. A short list of integrations, metadata needs, and unresolved governance questions that could distort the architecture later if left unaddressed.

The first-pass pack is not the final architecture. It is the minimum structure needed to have honest conversations about authority, boundaries, and trade-offs before the detail work begins. A governance board that reviews this pack should be able to understand the enterprise's information landscape without a technical dictionary.

The TOGAF Standard provides the core ADM method, but the detail of how to apply Phase C in specific contexts comes from the Series Guides. Stage 4 uses five Series Guides to move Phase C from a generic modelling exercise into something operationally useful. Each guide addresses a specific information or application challenge.

G190 (Information Mapping) provides the method for structuring how enterprise information is organised, related, and used. It anchors the information-domain view by teaching the team how to define domains in enterprise language rather than in system or database terms. This guide is covered in Module 27.

G21B (Customer Master Data Management) adds discipline for one of the most common information-authority challenges: customer identity, stewardship, and lifecycle governance. For a utility, customer information touches service, billing, connections, and regulatory reporting. This guide is covered in Module 29.

G234 (Metadata Management) ensures that published and shared information carries enough context for consumers to interpret and trust it. Without metadata, even technically correct data can be misleading. This guide is covered in Module 31.

G238 (Business Intelligence and Analytics) connects information architecture to the decision-support chain that planning, governance, and operational teams depend on. Dashboards are visible, but the semantic layer underneath them is what makes analytics trustworthy. This guide is covered in Module 32.

G248 (Selecting Building Blocks) provides the ABB and SBBdiscipline that stops application architecture from collapsing into a vendor shortlist. It protects the enterprise's independent reasoning about what it needs before products enter the conversation. This guide is covered in Module 33.

Together, these five guides turn Phase C from a theoretical framework into a practical set of tools that can be applied to real enterprise problems. The modules that follow will walk through each one in detail.

The idea of treating data and applications together is not just an administrative convenience. It reflects a real enterprise truth: information does not govern itself, and applications do not justify themselves.

Information needs applications to create, validate, transform, store, and publish it. Applications need information authority rules to know what they are allowed to do and what they are responsible for. When the two are designed separately, the enterprise gets information models that no system enforces and application portfolios that no information governance controls.

In TOGAF terms, this means the content metamodel shows explicit relationships between data entities and application components. An information domain should be traceable to the application responsibilities that support it. An application responsibility should be traceable to the information domains it creates, reads, updates, or governs.

When those traceability links are absent, the Phase C pack is a collection of documents rather than an architecture. When they are present, the pack becomes a coherent enterprise view that can be governed, challenged, and evolved.

TOGAF defines an architecture building block as a reusable component of enterprise capability, expressed in capability terms rather than in product or vendor terms. In Phase C, this means the application side of the architecture should describe what the enterprise needs (the ABB) before it names what the enterprise will buy or build (the SBB), and the data side should describe what information the enterprise must govern before it names the system that will hold it.

In the London case, LTDS-style publication, customer and network information authority, telemetry use, planning evidence, and governance reporting cannot be separated cleanly into independent projects. The information questions and application questions are entangled by the nature of the enterprise.

Consider just one London scenario: publishing network development information to meet LTDS transparency obligations. The information architecture must define which information domains feed the publication, who is authoritative for each input, and what metadata the published output must carry. The application architecture must define which services prepare the publication, which validate it, and how the whole chain is governed. If either side is missing, the publication cannot be trusted.

That is why Stage 4 begins by teaching Phase C as one joined-up enterprise exercise. The aim is not to produce perfect models. The aim is to make information responsibilities, application responsibilities, and enterprise trust boundaries visible enough to govern.

• The London case needs one Phase C pack, not parallel data and application slide decks.
• Every later integration or platform choice in the course depends on the quality of this Stage 4 framing.
• If the Phase C orientation is weak, Stage 5 technology choices will float free from the enterprise reasoning that should constrain them.
• The London architecture board should be able to review the Phase C pack in one session and understand where authority, responsibility, and governance accountability sit.