Information mapping and information domains

Teams often know they have data problems long before they can describe them well. Information mapping provides the first disciplined enterprise view. It groups information into meaningful domains, shows the relationships among those domains, and gives the architecture a vocabulary that is not trapped by the current software estate.

That makes the information map a bridge between business architecture and more detailed data or application work. The map is broad enough for non-technical stakeholders to understand, but structured enough to guide later decisions about authority, stewardship, and integration.

G190 (Information Mapping) provides the TOGAF method for building this view. The guide teaches the team to think in enterprise terms first and technical terms second. That ordering matters because it prevents the current system landscape from defining the enterprise vocabulary. Systems change. Enterprise information needs persist.

The information map is not a data model. A data model specifies entities, attributes, relationships, and constraints at a level suitable for database design. An information map operates one level above that. It answers the question: what information does the enterprise care about, how is it grouped, who depends on it, and who governs it? The data model follows later, informed by the map.

An information domain is a business-relevant grouping of information that shares meaning, responsibility, and relationships with other enterprise information. A well-defined domain can be explained without naming a specific product or database first.

A domain is useful when it clarifies which enterprise conversations belong together. Customer information, for instance, includes identity, relationship, service history, and lifecycle state. Those elements share governance needs and consumer expectations, which is why they belong in one domain even if they currently sit across five different systems.

Three related concepts help complete the picture. A consumer is a person, process, team, or system that relies on the domain to make a decision, perform work, or publish information. A producer is the role, process, or system that creates or materially updates the domain's information. Stewardship is the governance responsibility that protects meaning, quality, and appropriate use even when several systems participate in producing or consuming the domain's information.

These three roles, consumer, producer, and steward, are essential to every domain. If the team cannot name at least one of each for a proposed domain, the domain boundary may be wrong. A domain without a consumer has no purpose. A domain without a producer has no source. A domain without a steward has no governance.

Four questions help the team judge whether a proposed domain boundary is doing real work.

• Can the domain be explained without naming a specific product or database first?
• Can the team name its major consumers and the decisions they depend on?
• Does the domain have relationships with other domains that matter to the enterprise story?
• Would the domain still make sense if the current application estate changed in two years?

A domain called "SAP Plant Maintenance Data" fails the first test because it is named after a product. A domain called "Asset Condition and Maintenance Information" passes because it describes what the enterprise cares about regardless of which system delivers it. The second framing makes ownership, reuse, and governance conversations possible. The first framing locks those conversations to a vendor boundary.

A domain called "Miscellaneous Operational Data" fails the second test because it is too vague to have identifiable consumers. If nobody can name a decision that depends on the domain, the domain needs splitting or renaming until it becomes specific enough to govern.

G234 describes several data architecture patterns that help the team reason about how information domains are implemented in practice. Understanding these patterns prevents the team from defaulting to a single approach for every domain.

Centralised pattern. All instances of a domain's information are managed in one system. This pattern works well when a single team owns creation, validation, and publication, and when the information lifecycle is straightforward. Customer billing records in a utility might suit this pattern if one system genuinely owns the whole lifecycle.

Federated pattern. Multiple systems hold parts of the domain's information, but a governance layer ensures consistency across them. This pattern suits enterprises where different business units legitimately create and manage different aspects of the same information domain. Asset information in a large utility often fits this pattern: engineering, maintenance, and planning teams each manage different attributes.

Replicated pattern. A master copy exists in one system, and governed copies are distributed to consumers. This pattern is common when multiple downstream systems need the same information but should not be allowed to change it. Published network capacity data might follow this pattern: the planning system is authoritative, and read-only copies are distributed to the publication layer and to internal dashboards.

Hybrid pattern. Different parts of the same domain follow different patterns. This is the most common real-world situation. Customer identity might be centralised, while customer service history is federated across regional operations, and customer publication views are replicated to the external portal.

The pattern choice is an architecture decision, not a technical default. Each pattern carries different governance, latency, consistency, and cost consequences. The information map should record which pattern applies to each domain, and the architecture should explain why that pattern was chosen.

An information map becomes weak when it is simply a relabelled inventory of current systems. That approach inherits all the accidents of the existing estate and presents them as if they were the natural structure of the enterprise.

The better move is to map information in terms the business can recognise first, then ask how the current estate supports or distorts that structure. The map should be the lens through which the team evaluates the current estate, not the other way round.

Three warning signs suggest the map has fallen into inventory mode. First, every domain name contains a system or product name. Second, the boundaries between domains exactly mirror the boundaries between current applications. Third, the team cannot explain what any domain means without first describing which system holds it. If any of these signs appear, the map needs reworking from the business side.

A practical information-mapping exercise follows a repeatable five-step sequence. Each step builds on the previous one and produces a testable output.

1. Start from business capabilities and value stages. The domains should reflect the information that business architecture has already identified as important. This prevents the map from drifting into technical territory before the enterprise context is established. For London, the starting point is the capabilities identified in Stage 3: planning, connecting, operating, maintaining, and publishing.
2. Name each domain in enterprise language. Use terms that a business sponsor would recognise without a data-dictionary lookup. "Asset Condition and Maintenance Information" is enterprise language. "MAXIMO_WORK_ORDER_TABLE" is not. The naming discipline forces the team to think about meaning rather than storage.
3. Identify the major consumers and their decision needs. This is what gives the domain its purpose and helps set stewardship expectations. For each domain, the team should be able to say: "The planning team uses this domain to make investment decisions" or "The regulatory team uses this domain to produce compliance evidence."
4. Record the key relationships between domains. These relationships expose integration needs, authority overlaps, and governance questions that the architecture must resolve. In London, the customer domain connects to the connection domain, which connects to the planning and network domains. Those connections have governance consequences that only become visible when the relationships are mapped.
5. Note where the current estate aligns or conflicts with the domain structure. This is where the map becomes a diagnostic tool rather than just a classification exercise. The team can see where current systems match the enterprise need and where they create gaps, overlaps, or governance blind spots.

The output of this technique is a map that serves three audiences. Non-technical stakeholders can read it as an enterprise information landscape. Technical teams can use it as the starting point for detailed data modelling. Governance boards can use it to assign ownership and stewardship. A good information map works for all three.

The London information map needs to distinguish domains such as customer, connection, planning, asset, network, telemetry, and publication information. Those are business-relevant groupings with different consumers, controls, and stewardship pressures.

Each London domain has its own pattern implications. Customer identity might suit a centralised pattern because one team should own the definition. Asset information likely needs a federated pattern because engineering, maintenance, and planning teams each manage different attributes. Published network development data should follow a replicated pattern: planning is authoritative, and read-only copies are distributed to the LTDS publication layer.

Once those domains are visible, the London case becomes much easier to reason about. The team can ask which domains need tighter authority rules, which ones drive publication obligations, and which relationships must stay coherent across multiple systems and delivery teams.

• The London information-domain map should be understandable before any detailed schema work exists.
• Its job is to expose enterprise structure, not to mirror database design.
• The customer domain connects to the connection domain, which connects to the planning and network domains. Those relationships have governance consequences that only become visible when the domains are mapped in enterprise terms.
• The pattern choice for each domain should be recorded and justified in the Phase C pack.