20.1 Overview

In a typical enterprise, many architectures will be described in the Architecture Landscape at any point in time. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a big picture. To address this complexity TOGAF uses the concepts of levels and the Enterprise Continuum to provide a conceptual framework for organizing the Architecture Landscape. These concepts are tightly linked with organizing actual content in the Architecture Repository and any architecture partitions discussed in Part V.

20.2 Architecture Landscape

Levels provide a framework for dividing the Architecture Landscape into three levels of granularity:

1. Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
2. Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
3. Capability Architecture provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.

Figure 20-1 shows a summary of the classification model for Architecture Landscapes.

The Architecture Continuum provides a method of dividing each level of the Architecture Landscape (see 39.4.1 Architecture Continuum) by abstraction. It offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships. The Architecture Continuum shows the relationships from foundation elements to organization-specific architecture, as shown in Figure 20-2.

The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary redundancy.

Levels and the Architecture Continuum provide a comprehensive mechanism to describe and classify the Architecture Landscape. These concepts can be used to organize the Architecture Landscape into a set of related architectures with:

• Manageable complexity for each individual architecture or solution
• Defined groupings
• Defined hierarchies and navigation structures
• Appropriate processes, roles, and responsibilities attached to each grouping

There is no definitive organizing model for architecture, as each enterprise should adopt a model that reflects its own operating model.

20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise

The following characteristics are typically used to organize the Architecture Landscape:

• Breadth: The breadth (subject matter) area is generally the primary organizing characteristic for describing an Architecture Landscape. Architectures are functionally decomposed into a hierarchy of specific subject areas or segments.
• Depth: With broader subject areas, less detail is needed to ensure that the architecture has a manageable size and complexity. More specific subject matter areas will generally permit (and require) more detailed architectures.
• Time: For a specific breadth and depth an enterprise can create a Baseline Architecture and a set of Target Architectures that stretch into the future. Broader and less detailed architectures will generally be valid for longer periods of time and can provide a vision for the enterprise that stretches further into the future.
• Recency: Finally, each architecture view will progress through a development cycle where it increases in accuracy until finally approved. After approval, an architecture will begin to decrease in accuracy if not actively maintained. In some cases recency may be used as an organizing factor for historic architectures.

Using the criteria above, architectures can be grouped into Strategic, Segment, and Capability Architecture levels, as described in Figure 20-1.

20.4 Developing Architectures at Different Levels

The previous sections have identified that different types of architecture are required to address different stakeholder needs at different levels of the organization. Each architecture typically does not exist in isolation and must therefore sit within a governance hierarchy. Broad, summary architectures set the direction for narrow and detailed architectures.

A number of techniques can be employed to use the ADM as a process that supports such hierarchies of architectures. Essentially there are two strategies that can be applied:

1. Architectures at different levels can be developed through iterations within a single cycle of the ADM process.
2. Architectures at different levels can be developed through a hierarchy of ADM processes, executed concurrently.

At the extreme ends of the scale, either of these two options can be fully adopted. In practice, an architect is likely to need to blend elements of each to fit the exact requirements of their Request for Architecture Work. Each of these approaches is described in 19. Applying Iteration to the ADM.

return to top of page