40.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 39. Enterprise Continuum).
Architectures are partitioned because:
- Organizational unit architectures conflict with one another.
- Different teams need to work on different elements of architecture at the same time and partitions allow for specific groups of architects to own and develop specific elements of the architecture.
- Effective architecture re-use requires modular architecture segments that can be taken and incorporated into broader architectures and solutions.
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.
40.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:
- Manageable complexity for each individual architecture or solution
- Defined groupings
- Defined hierarchies and navigation structures
- Appropriate processes, roles, and responsibilities attached to each grouping
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:
- Architectures used to describe the Architecture Landscape are generally not abstract.
- Solution volatility generally prevents architectures from being defined that are far in the future. Volatility also reduces the accuracy of historic architectures over time, as the organization changes and adapts to new circumstances.
Using the criteria above, architectures can be grouped into partitions.
40.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:
- Determine the organization structure for architecture within the enterprise: The various standing teams that will create the architecture should be identified. For each of these teams, appropriate boundaries should be established, including:
- Governance bodies that are applicable to the team
- Team membership
- Team reporting lines
- Determine the responsibilities for each standing architecture team: For each architecture team, the responsibilities should be identified. This step applies partitioning logic to the enterprise architecture in order to firstly identify the scope of each team and secondly to partition the architecture under the remit of a single team. Once complete, this step should have partitioned the entire scope of the enterprise and should have assigned responsibility for each partitioned architecture to a single team. Partitioning should create a definition of each architecture that includes:
- Subject matter areas being covered
- Level of detail that the team will work at
- Time periods to be covered
- Stakeholders
- Determine the relationships between architectures: Once a set of partitioned architectures has been created, the relationships between architectures should be developed. This step allows governance relationships to be formalized and also shows where artifacts from one architecture are expected to be re-used within other architectures. Areas of consideration include:
- Where do different architectures overlap/dovetail/drill-down?
- What are the compliance requirements between architectures?
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 40-1.
Figure 40-1: Allocation of Teams to Architecture Scope
40.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, 5.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, 29. 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:
- Integration across the architectural domains provides a cross-domain view of the state of a segment of the enterprise for a point in time.
- Integration across the organizational scope of the business provides a cross-segment view of the enterprise.
- The Architecture Vision provides an integrated summary of Architecture Definitions, which provide an integrated summary of Transition Architectures.
Figure 40-2 shows how architectural content can be aggregated using a variety of techniques.
Figure 40-2: Architecture Content Aggregationreturn to top of page
| <<< Previous | Home | Next >>> |