36. Architecture Partitioning

Chapter Contents
36.1 Overview | 36.2 Applying Classification to Create Partitioned Architectures | 36.3 Integration

36.1 Overview

Partitions are used to simplify the development and management of the Enterprise Architecture.

Partitions lie at the foundation of Architecture Governance and are distinct from levels and the organizing concepts of the Architecture Continuum (see 35. Enterprise Continuum).

Architectures are partitioned because:

It is impractical to present a definitive partitioning model for architecture. Each enterprise needs to adopt a partitioning model that reflects its own operating model.

This chapter discusses the classification criteria that are generally applied to architectures and how these can be leveraged to partition the enterprise into a set of architectures with manageable complexity and effective governance.

36.2 Applying Classification to Create Partitioned Architectures

For the reasons outlined in the previous section, it is valuable to partition and organize the Enterprise Continuum into a set of related solutions and architectures with:

The following table shows how suitable classification criteria can be used to support partitioning of solutions:

Characteristic

Usage to Support Solution Partitioning

Subject Matter (Breadth)

Solutions are naturally organized into groups to support operational management and control. Examples of solution partitions according to subject matter would include applications, departments, divisions, products, services, service centers, sites, etc.

Solution decomposition by subject matter is typically the fundamental technique for structuring both solutions and the architectures that represent them.

Time

Solution lifecycles are typically organized around a timeline, which allows the impact of solution development, introduction, operation, and retirement to be managed against other business activity occurring in similar time periods.

Maturity/Volatility

The maturity and volatility of a solution will typically impact the speed of execution required for the solution lifecycle.

Additionally, volatility and maturity will shape investment priorities. Solutions existing in highly volatile environments may be better suited to rapid, agile development techniques.

The following table shows how each classification criteria can be used to support partitioning of architectures:

Characteristic

Usage to Support Architecture Partitioning

Depth

The level of detail within an architecture has a strong correlation to the stakeholder groups that will be interested in the architecture.

Typically, less detailed architectures will be of interest to executive stakeholders. As architectures increase in detail, their relevance to implementation and operational personnel will also increase.

In practical terms, architecture discipline is used to support a number of different types of architecture that are used for different objectives. The classification criteria described above can be used in different ways to support the achievement of each objective.

The following characteristics are generally not used to partition an Architecture Landscape:

Using the criteria above, architectures can be grouped into partitions.

36.2.1 Activities within the Preliminary Phase

The key objective of the Preliminary Phase is to establish the Architecture Capability for the enterprise. In practical terms this activity will require the establishment of a number of architecture partitions, providing defined boundaries, governance, and ownership.

Generally speaking, each team carrying out architecture activity within the enterprise will own one or more architecture partitions and will execute the ADM to define, govern, and realize their architectures.

If more than one team is expected to work on a single architecture, this can become problematic, as the precise responsibilities of each team are difficult to establish. For this reason, it is preferable to apply partitioning to the architecture until each architecture has one owning team.

Finally, it is worth considering the distinction between standing capabilities of the enterprise and temporary teams mobilized to support a particular change initiative. Although the remit of standing teams within the enterprise can be precisely defined, it is more difficult to anticipate and specify the responsibilities of (possibly unknown) temporary architecture teams. In the cases of these temporary teams, each team should come under the governance of a standing architecture team and there should be a process within the ADM cycle of these teams to establish appropriate architecture partitioning.

Steps within the Preliminary Phase to support architecture partitioning are as follows:

Once the Preliminary Phase is complete, the teams conducting the architecture should be understood. Each team should have a defined scope and the relationships between teams and architecture should be understood. Allocation of teams to architecture scope is illustrated in Figure 36-1 .



Figure 36-1: Allocation of Teams to Architecture Scope

36.3 Integration

Creation of partitioned architectures runs the risk of producing a fragmented and disjointed collection of architectures that cannot be integrated to form an overall big picture (see Part II, 4.6 Architecture Integration).

For large complex enterprises, federated architectures - independently developed, maintained, and managed architectures that are subsequently integrated within an integration framework - are typical. Federated architectures typically are used in governments and conglomerates, where the separate organizational units need separate architectures. Such a framework specifies the principles for interoperability, migration, and conformance. This allows specific business units to have architectures developed and governed as stand-alone architecture projects. More details and guidance on specifying the interoperability requirements for different solutions can be found in Part III, 25. Interoperability Requirements .

In order to mitigate against this risk, standards for content integration should be defined and Architecture Governance should address content integration as a condition of architectural compliance. Content frameworks, such as the TOGAF content framework (refer to Part IV: Architecture Content Framework) can be used to specify standard building blocks and artifacts that are the subject of content integration standards.

For example, a standard catalog of business processes can be agreed for an enterprise. Subsequent architectures can then ease integration by using the same process list and cross-referencing other aspects of the architecture to those standard processes.

Integration can be addressed from a number of dimensions:

Figure 36-2 shows how architectural content can be aggregated using a variety of techniques.



Figure 36-2: Architecture Content Aggregation

return to top of page