Stage 4 summary. Information Systems Architecture

Phase C is the ADM phase where information architecture and application architecture are developed as one coordinated domain. C220 Part 1 gives it two canonical objectives. Develop the target Information Systems (Data and Application) Architecture in a way that enables the Business Architecture and the Architecture Vision, and identify candidate Architecture Roadmap components from the gaps between baseline and target. The standard works through those objectives twice, once for data and once for applications, as two parallel sequences that share the same seven-step shape, from target architecture through ABB identification and development, stakeholder review, gap analysis, and principle alignment to formal documentation.

The pairing exists because the decisions are mutually dependent. Information authority decisions constrain application boundaries, and application responsibilities determine how information governance is enforced. Run the two as separate workstreams and each side produces a strong target-state document whose authority assignments contradict the other, a conflict nobody discovers until a governance review asks who is authoritative after go-live. Phase C also never starts from a blank page. It inherits capabilities and value stages, business gaps, stakeholder concerns, architecture principles, and business scenarios from the Stage 3 business architecture, and weak inputs should be flagged before work proceeds.

Opening the phase with product or platform evaluation starts too low in the stack, because products belong after the enterprise has named its information responsibilities and application boundaries. Five Series Guides turn the generic method into a working toolkit for the stage, G190 for information mapping, G21B for customer master data, G234 for metadata, G238 for analytics, and G248 for selecting building blocks, and the first-pass pack they support should be readable by non-technical stakeholders.

An information map groups the enterprise's information into business-relevant domains, each with named ownership, stewardship, and consumer relationships. It is broader than any schema and more structured than a loose glossary, and each domain is a unit of business information responsibility that survives even when the underlying systems are replaced. The London map names customer, connection, planning, asset, network, telemetry, and publication domains, groupings a business sponsor can recognise without a data-dictionary lookup.

The practical technique has five steps. Start from the business capabilities and value stages identified in Stage 3, name each domain in enterprise language, identify the major consumers and their decision needs, record the key relationships between domains, and note where the current estate aligns or conflicts with the domain structure. The failure mode is the relabelled inventory, a map whose domain names contain system names and whose boundaries mirror the current applications, which inherits the accidents of the existing estate and ages with it.

This course uses four data architecture patterns to reason about how each domain is implemented, centralised, federated, replicated, and hybrid. They are a practical industry vocabulary rather than a taxonomy from any single TOGAF document, and the pattern choice for each domain carries different governance, latency, consistency, and cost consequences, so it should be recorded and justified in the Phase C pack.

The slogan that every entity must have exactly one source of truth sounds disciplined but hides how enterprises actually work. Authority is usually attribute-specific or lifecycle-specific, and four kinds recur. Attribute authority, where the asset register owns asset specification data while the GIS owns spatial location. Lifecycle authority, where the system that creates a record is not the one that validates it for publication. Stewardship authority, where a governance role owns the rules without producing the data. And publication authority, the last-mile designation of which representation external consumers are expected to rely on.

The information authority ownership model records that distributed reality in five layers. Entity and domain identification, attribute decomposition, authority assignment, stewardship assignment, and publication designation. Documented as a matrix rather than a single-system declaration, it gives governance boards something they can review, challenge, and use to resolve disputes, which makes it more honest and more governable than the slogan.

A single-source claim can still be valid when it is bounded. State which entity and attributes it covers, which consumer purpose the authority serves, and how conflicts with other systems are resolved, and the claim becomes testable. Leave any of those out and it is too vague to govern anything.

Customer master data management is a set of architecture decisions, not a box to be bought and switched on. G21B identifies six decisions that must be settled before platform selection. Entity definition, shared-attribute identification, authority assignment, matching rules, stewardship, and the decision use case the whole effort serves. Programmes that promise one master system as a one-time clean-up skip exactly the identity logic and authority boundaries that make the result trustworthy.

Golden-record language earns its place only when the underlying choices are explicit. A golden record becomes an architecture artefact when it specifies what it contains, how conflicts between sources are resolved, and who is responsible for it. Tied to specific high-value decisions and authority problems, master data thinking controls customer information without flattening the genuine differences across the enterprise.

Utility customer data needs the retail model adapted before any platform implements it. Relationships are connection-based, defined by a physical connection point rather than a purchase, and the same entity can be a connection applicant, a service consumer, a metering-point holder, and a complaints correspondent across a lifecycle spanning decades, with regulatory reporting obligations attached. The working test of the architecture is trust. Shadow copies of customer data are a symptom of low trust, and if the architecture is working the need for them should decrease.

For an asset-heavy operator, five information groupings carry the architectural weight. Asset, network, planning and scenario, telemetry and operational, and publication information. The same data feeds planning, safety, resilience, and regulatory evidence, which makes model authority and data quality architecture concerns rather than technical housekeeping. The stage's cautionary case is a GIS and an asset register disagreeing about a cable route, with a planning estimate coming out materially wrong because no architecture governed the relationship between systems holding different aspects of the same physical reality.

The Common Information Model, standardised as IEC 61968 and IEC 61970, is a shared semantic vocabulary for power-systems information, not a mandatory schema. Alignment does not mean every system uses CIM natively. It means the enterprise knows the mapping between its internal structures and the CIM, governs that mapping at the boundaries where information crosses to external or publication formats, and records where alignment is maintained and where it is deliberately omitted, with rationale, in the Phase C pack.

The trap is letting operational-system boundaries dictate the enterprise information architecture. A system can be excellent at running a function and still be a poor organising principle for publication, analytics, and governance, so asset and network data are treated as enterprise domains in their own right.

Metadata supplies the context that raw data cannot carry on its own, and G234 sets six minimum concerns every published or shared information asset should answer. Meaning, provenance, stewardship, lifecycle, classification and access, and quality and confidence. Technically accurate substation capacity figures with no scenario, model-run date, or authority context are practically misleading, and without metadata the enterprise quietly outsources interpretation risk to every downstream user. Retrofitting it later costs more, because the original knowledge holders have moved on, the asset count has grown, and consumers have already built their own interpretations. Publication raises the burden further, since external consumers cannot ask the data team for context, and the decisions about who may see and receive which figures sit alongside the metadata as design choices, with the paired baseline-to-target data view stating how each domain moves to the target without loss or duplication.

Analytics is a decision-support chain, and G238 structures it in four layers. Source information with its authority and quality constraints, the semantic layer of shared definitions and calculation logic, the analytical product the consumer sees, and the decision use that gives the chain its purpose. The semantic layer is the most common failure point because it is the least visible and the most easily skipped. When fourteen dashboards, or a dashboard and a regulatory submission, disagree on the same concept, the cause is almost always an ungoverned semantic layer.

Trustworthy analytics is therefore built from the foundations up. G238 describes four patterns, centralised, federated, self-service, and embedded, suited to different decision needs, and refresh frequency must match the decision cadence the product serves. A dashboard is an output of the architecture, not the architecture, 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 architecture building block is a logical description of a needed capability, and C220 Part 4 makes it technology-aware but product-neutral. It captures functional and non-functional requirements, defines interfaces to other ABBs, guides and constrains the selection of solution building blocks, and is reusable across contexts. A solution building block is the product-specific implementation that realises one or more ABBs and is constrained by their specifications. Naming a vendor platform as the ABB means the logical layer has been skipped and the vendor's pitch has become the de facto requirement.

The content metamodel, renamed the Enterprise Metamodel in the 10th Edition, is what stops the application view floating free. It keeps application components traceable to the data entities they create, read, update, or delete, the business functions and capabilities they support, the technology services that will host them, and the mapping from logical to physical component that ties every product choice back to an enterprise need.

The London ABB catalogue shows the discipline in use. Planning-evidence preparation, publication management, telemetry ingestion, customer-data stewardship, network-model management, and governance reporting are named as enterprise responsibilities first, so candidate products can be weighed against a stable logical requirement instead of procurement pressure standing in for architecture reasoning.

Integration is an architecture concern because coupling decisions drive failure propagation, change cost, and accountability. The stage's two cautionary numbers make the point. A synchronous, tightly coupled telemetry pipeline lost ninety minutes of sensor readings when the receiving system went offline, and an estate of seventy-two independently designed point-to-point integrations made a single system replacement touch thirty-one of them. One badly chosen pattern is harmless. Dozens create a fragile web that makes every change programme expensive.

The TOGAF Standard frames interoperability by how business processes, information, and technical services are shared, and asks architects to state the degree of information exchange each interaction needs. On top of that framing this course works with four levels, operational, syntactic, semantic, and organisational, as a teaching taxonomy rather than a list from the standard, and each integration should specify which level it requires. Semantic interoperability is where most enterprise integration problems actually live, because two systems can exchange data successfully while interpreting it differently.

Coupling choices follow the enterprise context, not technical preference, weighed by failure consequence, change frequency, latency requirement, and governance accountability. A good integration decision record captures five things. The business purpose of the connection, the interoperability level required, the authority and semantic assumptions travelling across it, the chosen pattern with the alternatives considered, and the consequences for latency, failure handling, coupling, and governance, with an explanation of why the chosen pattern is the least harmful option.

The walkthrough assembles everything the stage taught into one Phase C pack, built in a six-layer sequence where each layer answers a question the next depends on. The information-domain map, the authority map, the CIM alignment decisions, the metadata and publication rules, the application responsibilities and key interactions, and the integration and governance notes. Starting with application responsibilities before the domains are clear produces platform-driven answers, which is why the order matters.

The strongest validation is end to end. A network capacity headroom figure in the LTDS publication carries metadata naming its scenario, model-run date, steward, and confidence. From there the trace runs back through the publication ABB and its SBB mapping, the CIM alignment at the publication boundary, the governed integration path with its decision record, the authority chain for planning assumptions and inputs, and finally the source domains that fed the forecast. If a governance board can follow that whole trace, the pack has done its job. If any link is missing, the pack is incomplete.

The pack then anchors everything that follows. Stage 5 selects the technology services that host the application responsibilities defined here, Stage 6 sequences change in an order that respects the authority boundaries and integration dependencies the pack records, and Stage 7 governs implementation against it as the reference architecture.

Analytics and AI are extensions of the information architecture, not a separate discipline. A model is an application built on data, so it belongs to Phase C, and the moment its output changes a decision it carries authority like any other authoritative source. The stage's opening warning is a load-forecasting model that shaped reinforcement spending for eighteen months with no owner, no recorded lineage, and no review point. The remedy is to treat the AI system, the model plus its training data, serving code, and the decision it feeds, as one architecture element with an owner, a stated purpose, a lifecycle, a repository entry, and explicit dependencies.

Governance separates into three questions that form a chain, not a menu. Data governance asks whether the input is fit to use, traced to sources with a recorded basis. Model governance asks whether the model is sound, versioned, and evaluated across the groups it affects rather than only in aggregate. Decision governance asks whether a human can review and override the live decision, whether affected people can challenge it, and whether drift is monitored with a defined rollback. Good data with an ungoverned model, or a sound model with no decision control, still fails.

Four controls carry the load, all ordinary architecture artefacts. Data lineage, a model registry, human oversight, and a risk tier that sets how heavy the other controls must be. Regulators are moving to classify AI by risk, so the risk-based shape is worth building in, but the precise legal categories, duties, and timelines must be verified against the current text with qualified advice rather than asserted from a course. London governs its load-forecasting model through the repository, so the same record that assures the model doubles as Ofgem investment evidence.

The stage closes by running its own test on London Grid Distribution, the fictional operator serving 2.3 million customers across Greater London. A capacity headroom figure published under LTDS obligations must be traceable from the consumer back to its sources. The metadata names the scenario and model-run date, the publication ABB and its platform prepared it, CIM alignment made it interpretable at the boundary, a governed integration carried it, the authority map shows planning-assumption authority sitting in the modelling tool while publication authority sits in the LTDS layer, and the domain map shows the asset, network, planning, and telemetry information that fed it. Every layer of the stage appears in that one trace.

The same discipline reaches the newest element in the estate. The AI load-forecasting model that ranks substations for reinforcement is a versioned repository entry with an owner, recorded lineage, a planner reviewing its output before money moves, and drift monitoring with a defined rollback, so the record that assures the model is the record that justifies the investment case to Ofgem. Hold the test in mind, because every stage that follows will be asked the same question under different pressure. Can you prove why what you publish deserves to be trusted?