Architecture landscape and partitioning

The architecture landscape is the total set of architectures that the enterprise maintains and governs at any point in time. It includes baseline architectures (current state), target architectures (desired future state), and transition architectures (intentionally designed interim states). The landscape exists at multiple levels of detail and covers all four architecture domains.

The landscape is not a single document. It is the enterprise's architectural knowledge base, maintained in the Architecture Repository and governed through the architecture governance framework. C220 Part 5 describes the landscape as the context within which all architecture work takes place.

The Enterprise Continuum provides the classification framework for the landscape. It ranges from generic foundation architectures (applicable across industries) through common-systems architectures (applicable within an industry) to organisation-specific architectures. The landscape lives at the organisation-specific end of the continuum, but it draws on and references assets from the generic and industry-common levels.

C220 Part 5 defines three levels at which architecture work can be conducted. Each level serves a different audience, addresses a different scope, and produces outputs at a different level of detail. Understanding the levels matters because it prevents teams from either drowning in detail at the strategic level or making implementation decisions without strategic context.

Strategic architecture

A strategic architecture provides a long-term, enterprise-wide view that guides investment and direction. It defines the principles, major capability targets, and cross-enterprise constraints that all lower-level architectures must respect. Its audience is enterprise leadership and the Architecture Board. Its outputs include architecture principles, capability targets, technology direction, and enterprise-wide standards.

A strategic architecture should not describe implementation detail. Its purpose is to set direction, not to design solutions. If a strategic architecture specifies which platform to use, it has dropped to the wrong level.

Segment architecture

A segment architecture provides more detail for a major division, business area, or capability group of the enterprise. It bridges the strategic view and the solution view. Its audience is divisional leadership and programme architects. Its outputs include detailed capability models, information models, application portfolios, and technology standards for the segment.

A segment architecture must be consistent with the strategic architecture above it. If the segment architecture defines principles or standards that conflict with the enterprise-wide view, the conflict must be resolved through governance, not hidden.

Capability architecture (solution level)

A capability or solution architecture provides the detail needed to guide implementation of a specific solution or capability. Its audience is delivery teams and solution architects. Its outputs include detailed design, component specifications, integration patterns, and deployment models.

A capability architecture must be consistent with the segment architecture that contains it and, through the segment, with the strategic architecture. The chain of consistency from strategic through segment to capability is what gives the enterprise architectural coherence across levels.

Partitioning is the act of dividing the architecture landscape into manageable portions that can be owned, developed, and governed by different teams. C220 Part 5 describes several criteria by which the enterprise can partition its architecture work.

By architecture domain. Separate business, information, application, and technology architecture into distinct partitions. This aligns with the ADM's phase structure but creates risk at the domain boundaries. Cross-domain dependencies (such as the relationship between data authority and technology platform choice) can be missed.

By organisational unit. Partition by division, department, or business unit. This aligns with ownership and accountability but can orphan cross-unit concerns like shared data models, common platforms, and enterprise-wide standards.

By geography. Partition by region, country, or site. This is appropriate when regulatory, cultural, or infrastructure differences make a single architecture impractical. It creates risk when geographically partitioned architectures need to share services or data.

By time horizon. Partition by strategic (long-term), tactical (medium-term), and operational (short-term) horizons. This aligns with the three architecture levels but creates risk when short-term decisions are made without reference to long-term direction.

By subject matter. Partition by topic such as security, data, integration, or user experience. This creates deep expertise within each partition but can fragment the enterprise view if the partitions do not communicate.

By capability or value stream. Partition by business capability or value stream. This aligns architecture work with business outcomes but requires strong cross-capability governance to prevent divergence on shared infrastructure and standards.

Partitioning without governance creates fragmentation. C220 Part 5 describes several governance mechanisms that keep partitions coherent.

Architecture Board oversight. The Architecture Board is responsible for the overall landscape, including the coherence across partitions. Partition-level architecture teams may govern their own scope, but the Architecture Board governs the joins.

Cross-partition dependency maps. The enterprise must maintain a visible map of dependencies that cross partition boundaries. This map is a governance tool, not a diagramming exercise. When a partition-level team changes something that affects another partition, the dependency map is what makes the impact visible.

Shared standards and principles. Enterprise-wide principles and standards apply across all partitions unless a governed exception has been granted. This prevents partitions from diverging on fundamental decisions like identity models, data formats, or integration patterns.

Repository discipline. All partitions publish their outputs to the same Architecture Repository. This makes the landscape visible as a whole, even when the work is distributed. A partition that maintains its own separate repository is effectively hidden from enterprise governance.

Interface contracts. When partitions share services, data, or infrastructure, the interfaces should be formally defined and governed. Interface contracts prevent one partition from making changes that break another partition's assumptions.

The London case needs partitioning because connections, publication, resilience, and governance work progress at different levels and rhythms. At the same time, the repository has to show the joins among them or the architecture quickly becomes misleading.

London architecture levels

Strategic level: Enterprise-wide principles for data authority, publication discipline, cyber resilience, and regulatory transparency. These principles constrain all lower-level work.

Segment level: The connections segment covers the customer connections value stream end-to-end, including case management, planning, publication, and assurance. The asset management segment covers network asset lifecycle. Each segment has its own architecture team and its own ADM cycle.

Capability level: Individual solution architectures for the case-management platform, the publication pipeline, the model tooling, and the cross-layer assurance view. Each capability architecture traces back to the segment and, through it, to the strategic principles.

London partitioning decisions

The London architecture is partitioned primarily by capability and value stream, with cross-partition governance provided by the Architecture Board and the repository. The critical cross-partition dependencies include:

• Data-authority rules (strategic) constrain every segment and capability architecture.
• The publication pipeline (connections segment) depends on the asset data model (asset management segment).
• Cyber assurance (cross-cutting) applies to every partition but is owned at the strategic level.
• The case-management platform (capability) must enforce authority rules defined at the segment level.

Each of these dependencies must be visible in the repository and governed by the Architecture Board. Without that visibility, partition teams will make local decisions that create cross-partition conflicts.

The TOGAF Series Guide G238 addresses the relationship between enterprise architecture and portfolio management. The central insight is that the architecture landscape is the primary input to portfolio decisions, and portfolio decisions are the primary output that connects architecture to enterprise investment.

What portfolio management means in an architecture context

Portfolio management in this context is the discipline of selecting, prioritising, and sequencing the enterprise's change initiatives so that they deliver the target architecture within acceptable risk, cost, and time constraints. It is not project management (which manages individual initiatives) and it is not programme management (which manages groups of related initiatives). It is the enterprise-level view of which changes to invest in, when, and in what order.

Without architecture input, portfolio decisions become political: whoever argues most persuasively gets funding. With architecture input, portfolio decisions become structural: investments are sequenced based on dependency chains, capability gaps, risk profiles, and the transition states needed to reach the target architecture.

How the architecture landscape feeds portfolio decisions

G238 describes several specific ways the architecture landscape supports portfolio management.

• Gap analysis. The gap between the baseline architecture and the target architecture identifies the changes the enterprise needs to make. Each gap is a potential portfolio item. The architecture landscape makes these gaps visible and traceable across all four domains.
• Dependency mapping. The architecture landscape shows which changes depend on other changes. A data-quality initiative that depends on a platform migration cannot start before the platform is in place. Portfolio sequencing must respect these dependencies or create delivery risk.
• Risk assessment. The architecture landscape identifies where the enterprise has concentration risk, technical debt, or compliance exposure. Portfolio decisions should prioritise changes that reduce the most consequential risks, not just the most visible ones.
• Transition-state logic. The transition architectures from Phase E and Phase F define intentional intermediate states. Portfolio management uses these transition states to sequence investment across multi-year programmes.

Strategic versus tactical portfolio decisions

G238 distinguishes between strategic and tactical portfolio decisions. Strategic portfolio decisions determine the enterprise's long-term investment direction: which major capabilities to build, which platforms to adopt, and which programmes to fund across multiple years. These decisions are informed by the strategic-level architecture.

Tactical portfolio decisions determine how to sequence and resource work within an approved programme: which work packages to deliver first, how to handle cross-team dependencies, and how to manage scope changes within a fixed budget. These decisions are informed by segment and capability-level architectures.

The risk arises when tactical decisions are made without reference to strategic architecture. A delivery team that resequences work packages to meet a local deadline may create a dependency conflict that only the strategic architecture can reveal. G238 recommends that tactical portfolio changes above a defined risk threshold are reviewed against the architecture landscape before approval.

The London transformation programme portfolio includes several major initiatives: connections reform, data publication modernisation, OT platform renewal, cyber resilience improvement, and regulatory compliance. Each initiative is a portfolio item. The architecture landscape determines how they relate to each other.

Dependency-driven sequencing. Data publication modernisation depends on data-quality improvements, which depend on OT platform telemetry accuracy. The portfolio cannot fund publication modernisation in isolation. The architecture landscape makes this dependency chain visible so that portfolio sequencing respects the structural order.

Strategic portfolio decision. Should the enterprise invest in a unified data platform or continue with domain-specific data systems? This is a strategic portfolio decision that the architecture landscape informs by showing where data authority is currently fragmented, what the integration cost is, and what risk the fragmentation creates for LTDS publication accuracy.

Tactical portfolio decision. Within the connections reform programme, should the self-service portal be delivered before or after the backend assessment engine upgrade? The architecture landscape shows that the portal depends on real-time network data from the assessment engine, so the backend upgrade should be sequenced first or the portal will need expensive temporary integrations.

Without the architecture landscape, these portfolio decisions would be made on the basis of business urgency alone. Business urgency is a valid input, but it is not sufficient. The architecture provides the structural evidence that prevents the portfolio from creating dependency conflicts, rework, and integration surprises.