Information Systems Architecture

When a retailer designs how its order data is owned, it has to settle in the same breath which application stores that data and which one publishes it. That is why this stage develops data architecture and application architecture as one effort rather than two: authority, integration, and publication choices are coupled, and a clean answer in one view is worthless if it contradicts the other. Holding them together is what keeps the architecture coherent at enterprise scale rather than locally tidy and globally broken.

It is tempting to run the data work and the application work as separate initiatives on their own timelines, since they involve different specialists and tools. The trouble is that application boundaries drawn before information ownership is clear tend to bake in duplicated or ambiguous data, and that makes integration, publication, and governance harder once the systems exist. Running the two views as a single effort is the safer order, because the boundaries you draw will commit you long after the project ends.

A hospital that wants to understand its information might name patient, clinician, appointment, billing, and outcomes as domains, each with an owner and a set of dependencies, rather than listing the databases it happens to run. That is what an information map is: a grouping of the enterprise's information into business-relevant domains, broader than any schema and more structured than a loose glossary. It gives you a unit of information responsibility that survives even when the underlying systems are replaced.

The common slip is to treat the map as an inventory of the current databases and tables, which simply mirrors the accidental shape of legacy systems. A map built that way stops being an enterprise view and becomes a technical catalogue that ages with the estate. The better approach is to define each domain as a unit of business information responsibility, independent of where it is stored today, so the map keeps describing what the enterprise needs to know rather than what its systems happen to hold.

In a bank, the onboarding system may be authoritative for a customer's verified identity while the servicing system is authoritative for their current balance, and both matter to the truth of the same customer without either being the whole truth. Authority is usually attribute-specific or lifecycle-specific, so the real architecture question is who owns which attributes and how conflicts are resolved, not which single system is declared the truth. Seeing authority this way is more honest about how enterprises actually work.

The slogan that every entity must have exactly one source of truth for all of its attributes sounds disciplined but hides this reality, and it becomes dangerous when two systems are each authoritative for different parts of one entity. A better record is an explicit authority map that states which system or role is authoritative for which attributes and lifecycle states. That map is harder to write than a one-line claim, but it tells consumers what they can actually rely on and how disagreements get settled.

An airline that wants a single view of a traveller across booking, loyalty, and service first has to agree what the customer entity even means and how duplicate records are matched, long before it claims a golden record. Customer master data management is that set of architecture decisions about identity, golden records, authority, stewardship, matching, and publication. It is a way of controlling customer information across channels, not a box to be bought and switched on.

Programmes often promise one master system as a one-time clean-up, which skips the identity logic and authority boundaries that make the result trustworthy. The work succeeds when it is tied to specific high-value decisions and authority problems, with identity, matching, and stewardship rules settled before any golden-record claim is made. Approached that way, master data thinking controls customer information without flattening the genuine differences across the enterprise.

For an asset-heavy operator such as a national railway or a telecoms network, the condition of assets, the topology of the network, and the telemetry coming off it drive planning, safety, resilience, and reporting. That makes model authority and data quality architecture concerns rather than technical housekeeping, because the same data feeds decisions that carry operational and regulatory weight. Sector reality reshapes the architecture problem here in a way generic teaching tends to miss.

The mistake is to treat asset and network data as operational details left to the systems that produce them to govern in isolation. When operational-system boundaries are allowed to dictate the enterprise information architecture, the data becomes hard to publish, analyse, or govern coherently. Treating asset and network data as enterprise domains in their own right keeps publication and analysis aligned across the whole organisation rather than trapped inside the systems that happen to generate it.

A government department publishing open statistics needs each dataset to carry its owner, its refresh date, and the definitions behind the numbers, not just the figures themselves. Metadata architecture provides exactly that: it answers meaning, stewardship, provenance, lifecycle, and the conditions under which data may be published, so a consumer can tell what the data means and whether it can be relied on. Discoverability and trust are architectural outcomes, which is why metadata belongs in this stage.

Metadata is often postponed as administrative paperwork to be added once the data is already being published. The cost shows up later, when publication and analytics turn out to be far harder without it and the consumer base has already grown. Building metadata in from the start treats trust and discoverability as design goals rather than afterthoughts, and the more consumers a dataset has, the less optional that discipline becomes.

The same publication thinking carries two further Phase C concerns that are easy to defer and costly to retrofit. A government department releasing open statistics still has to decide who may see and receive which figures and under what controls, so data security and dissemination are design decisions taken alongside the metadata, not bolted on once consumers appear. The paired baseline-to-target data view is the other: it states how each domain moves from today's stores to the target without loss or duplication, so migration is designed rather than discovered when the systems change.

A streaming service can present a polished retention chart that is still misleading if the semantics behind the metric and the logic that refreshes it have never been settled. Analytics architecture is concerned with information quality, semantic consistency, latency, access, and the decision context behind each view, which means a dashboard is an output of the architecture, not the architecture itself. The visual layer is only as sound as the foundations it sits on.

It is easy to take a well-designed dashboard as evidence that the analytics architecture beneath it is sound, but a confident chart can rest on unsettled semantics, unclear authority, and missing metadata. The safer sequence is to settle semantics, authority, metadata, and refresh logic before the visual layer is built, because trustworthy decision support depends on foundations a chart alone can never guarantee. Good analytics architecture is judged by the decisions it supports, not by how the numbers look.

A scale-up that needs a way to send transactional notifications first defines that responsibility, its interfaces, and its constraints as an architecture building block, then weighs candidate products against it. An architecture building block states a logical application responsibility; a solution building block is the concrete product chosen to satisfy it. Naming the responsibility first is where application architecture meets the marketplace of possible solutions without surrendering to it.

The failure is to treat the selected vendor product as the architecture, as though naming the product were the same as defining the responsibility. That skips the layer where capability, interfaces, and reuse should have been reasoned about. Naming the building block and its required capability and constraints before choosing a product keeps the enterprise able to reason about what it needs, and it preserves the independence that procurement pressure would otherwise erode.

When a music streaming firm keeps each domain's data owned by one team behind a defined interface, it stops any single team's system from becoming a hard dependency for everyone else. Integration choices about interoperability, coupling, latency, ownership, and failure handling shape how easily the enterprise can change, which makes them enterprise decisions rather than implementation details. The way systems connect decides how brittle or how adaptable the whole estate becomes.

Designing integration one service-to-service interface at a time feels pragmatic, but it loses sight of cross-system dependency risk and publication discipline. A better practice is to record each integration decision with its authority boundaries, latency expectations, failure consequences, and coupling, and to explain why the chosen pattern is the least harmful option. The strongest integration architectures justify not just how systems connect but why that connection style serves the enterprise best.