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.

C220 Part 2 lists specific objectives for Phase C. Understanding all of them prevents the common mistake of reducing Phase C to a data-modelling or application-cataloguing exercise. Each objective protects a different aspect of the enterprise reasoning.

1. Develop the target information systems architecture that enables the business architecture and the architecture vision. This is the primary goal. Everything else in Phase C serves this.
2. Identify candidate architecture building blocks based on the business-architecture and architecture-vision work already completed. The ABBs should be logical and product-neutral at this stage.
3. Select and develop the ABBs that will form the target information systems architecture. This moves from candidate identification to deliberate selection and detailed specification.
4. Conduct a formal stakeholder review of the proposed architecture. Phase C outputs are not finished until the enterprise's key stakeholders have reviewed and accepted them.
5. Identify and resolve gaps between the baseline and target information systems architectures. Gap analysis reveals what must change, what can be retained, and what must be eliminated.
6. Confirm the architecture aligns with enterprise principles established in the Preliminary Phase. This prevents the Phase C work from drifting away from the organisation's agreed decision constraints.
7. Finalise the architecture definition document and related artefacts. Phase C produces formal deliverables, not working papers.

These objectives move from high-level framing (objective 1) through detailed design (objectives 2 and 3), stakeholder validation (objective 4), gap identification (objective 5), principle alignment (objective 6), and formal documentation (objective 7). A Phase C exercise that skips any of them is cutting corners that will show up later as governance surprises or implementation conflicts.

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 integration choices. 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 view showing 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 SBB discipline 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.

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.