Stage 4. Information Systems Architecture: phase summary

TOGAF treats information architecture and application architecture as one Phase C domain because the decisions are mutually dependent: information authority decisions constrain application boundaries, and application responsibilities determine how information governance is enforced. Running them as separate workstreams almost always produces conflict at the boundaries, where each side has a strong target-state document but the authority assignments contradict each other. Phase C never starts from a blank page, because its objective links back to the business architecture and the architecture vision. Opening with product or platform evaluation starts too low in the stack; products belong after the enterprise has named its information responsibilities and application boundaries.

An information map is a structured enterprise view that classifies the key information concepts into domains, each with named ownership, stewardship, and consumer relationships. Domains should be named for what the enterprise needs, not for the systems that currently store the data, so the vocabulary survives system change. The G234 patterns (centralised, federated, replicated, hybrid) help choose a structural approach per domain. Source of truth is a useful idea only when it is bounded by entity, attribute, consumer, and purpose: authority is frequently distributed across attributes, lifecycle stages, stewardship roles, and publication channels. The five-layer authority ownership model (entity identification, attribute decomposition, authority assignment, stewardship assignment, publication designation) records that distributed reality, which is more governable than a slogan that implies one system owns the truth of everything.

Customer MDM begins with identity, shared attributes, authority, matching rules, stewardship, and the decision use case, not with selecting a platform and letting the vendor lead. A golden record becomes an architecture artefact only when it specifies what it contains, how conflicts are resolved, and who is responsible. Utility customer data is connection-based and multi-role, so a retail purchaser model has to be adapted before any platform implements it. For asset and network data, the architecture must govern the relationship between systems that hold different aspects of the same physical reality, as when a GIS and an asset register disagree about a cable route and a planning estimate comes out materially wrong. The Common Information Model is a shared semantic vocabulary, not a mandatory schema: alignment means documented, governed mappings at the boundaries where information crosses to external or publication formats, and the enterprise should record where alignment is kept and where it is deliberately omitted.

Metadata supplies the meaning, provenance, stewardship, lifecycle, classification, and quality context (the six minimum concerns in G234) that consumers need to interpret information, so technically accurate substation capacity figures with no scenario, model-run date, or authority context are practically misleading. Without metadata the enterprise outsources interpretation risk to every downstream user, and retrofitting it costs more because the original knowledge holders have moved on. Analytics is a decision-support chain (source, semantic, product, decision use), and the semantic layer is the most common failure point because it is the least visible: when fourteen dashboards or a dashboard and a regulatory submission disagree on the same concept, the cause is almost always an ungoverned semantic layer. Refresh frequency must match the decision cadence, and an analytical product with no named decision use is an output without a customer.

Application architecture describes the responsibilities the enterprise needs, not the products it happens to own: an ABB is technology-aware but product-neutral, while an SBB is product-specific and constrained by the ABB. Naming a vendor platform as the ABB means the logical layer has been skipped and the vendor's pitch becomes the de facto requirement; the content metamodel keeps application components traceable to data entities and business functions. Integration is an architecture concern because coupling decisions drive failure propagation, change cost, and accountability: a synchronous, tightly coupled telemetry pipeline lost ninety minutes of sensor readings when the receiver went offline, and seventy-two independently designed point-to-point integrations made a single system replacement touch thirty-one of them. C220 Part 3's four interoperability levels (operational, semantic, syntactic, organisational) must be specified per flow. The London walkthrough proves the test that ties it together: can a governance board trace any published figure back to its authoritative source through every Phase C layer, and the ABBs defined here become the responsibilities Phase D must find technology services to host.

• Opening Phase C with product, platform, or integration-tool evaluation before naming information domains, authority, and application responsibilities.
• Declaring a single source of truth for a whole entity when different attributes, lifecycle stages, or publication views are mastered by different systems and roles.
• Naming information domains or ABBs after the systems and vendor platforms that currently hold the data, locking the architecture to the existing estate.
• Treating LTDS-style publication, metadata, or integration as add-ons rather than upstream Phase C layers, producing disconnected documents instead of one governable pack.