10.3 Architecture Partitioning
Key Takeaways
- TOGAF defines an architecture partition as a subset of architecture resulting from dividing that architecture to facilitate its development and management.
- Partitions define how Enterprise Architecture work is broken down into multiple architecture initiatives that can proceed in parallel.
- The Preliminary Phase is used to determine the desired approach to partitioning architecture teams, processes, and deliverables.
- Partitioned architectures must be integrated through shared metamodels, standards, reference material, and architecture governance.
- Architecture partitions are distinct from architecture levels, which divide the landscape by granularity.
10.3 Architecture Partitioning
The Foundation syllabus asks you to briefly explain how partitioning helps simplify the development of an Enterprise Architecture. Partitioning answers a practical problem: a single architecture that tries to describe an entire complex enterprise in full detail is too large to develop, maintain, and govern.
Definition and Rationale
The glossary defines an Architecture Partition as "a subset of architecture resulting from dividing that architecture to facilitate its development and management." The Core Concepts chapter adds that partitions define how the work is broken down into multiple architecture initiatives.
Partitioning simplifies EA development because:
| Benefit | Why it helps |
|---|---|
| Manageable scope | Each partition has a bounded subject, so the architecture team can understand and describe it properly |
| Parallel work | Separate teams can develop different partitions at the same time without waiting for one enterprise-wide model |
| Clear ownership | Each partition can have its own sponsor, stakeholders, and governance responsibilities |
| Trade-off between breadth and detail | Architectures that cover a very wide subject area tend to be simple summaries; detailed architectures need a limited scope. Partitioning lets both exist together |
| Different rates of change | Parts of the enterprise that change at different speeds can be architected on different schedules |
| Agility | Breaking work into multiple architecture initiatives allows timely response to enterprise needs |
Partitioning Is Planned in the Preliminary Phase
Depending on the scale of the enterprise and its budget for architecture, a number of approaches may be adopted to sub-divide or partition architecture teams, processes, and deliverables. The Preliminary Phase should be used to determine the desired approach to partitioning and establish the groundwork for putting it into practice. Typical Preliminary Phase activities include:
- Identifying the characteristics that will be used to divide the architecture — for example the organizational area or subject matter covered, the level of detail, and the time period
- Defining the partitioned architectures and how they relate to the Architecture Landscape levels
- Allocating teams to each architecture scope
- Setting up the governance and integration approach so partitions fit together
Integrating Partitioned Architectures
Partitioning must not create isolated silos. TOGAF addresses integration through architecture content aggregation — combining the content of partitions into a coherent whole — supported by:
- A shared metamodel and content framework, so each team uses the same entity types and work products
- The Architecture Landscape levels, so strategic and segment architectures provide context for detailed partitions
- The Standards Library and Reference Library, so partitions re-use common standards, patterns, and building blocks
- Architecture governance, including the Architecture Board, to resolve conflicts between partitions and approve boundaries
Partitions Versus Levels
| Concept | Divides architecture by | Example |
|---|---|---|
| Levels | Granularity and detail (Strategic, Segment, Capability) | A strategic enterprise view versus a detailed capability view |
| Partitions | Separate architecture initiatives, scopes, or subsets for development and management | Separate architectures for retail banking and commercial banking, each with its own team |
A partition can itself contain architectures at more than one level, and a level can be split into several partitions.
Practical Signals That Partitioning Is Needed
The standard leaves the choice of partitioning approach to each enterprise, but common signals that an architecture should be partitioned include:
| Signal | Why partitioning helps |
|---|---|
| Several business units with different sponsors and priorities | Each partition can have clear ownership and its own stakeholder engagement |
| A single architecture team cannot keep one enterprise-wide model current | Separate teams can work in parallel on bounded scopes |
| Parts of the enterprise change at very different speeds | Fast-changing areas can iterate without waiting for slower ones |
| Regulatory or geographic separation between operations | Partitions can respect legal and organizational boundaries |
| Architecture descriptions are either too shallow to act on or too large to understand | Partitions allow detail where it is needed while strategic views stay summary |
Whatever the signals, the integration mechanisms below must be designed at the same time as the partitions, or the result is a set of disconnected architectures.
Scenario: A Global Manufacturer
A manufacturer operating in 30 countries cannot describe its entire enterprise in one architecture. In the Preliminary Phase the chief architect partitions the architecture into three segments — manufacturing operations, sales and service, and corporate functions — each with its own architecture team and sponsor. A small central team maintains the strategic architecture, the enterprise metamodel, and the Standards Library. When the sales and service team proposes a customer data platform that overlaps with corporate finance's plans, the Architecture Board uses the strategic architecture and the shared standards to agree a single customer master shared by both partitions.
Common Exam Pitfalls
- Thinking partitioning creates independent architectures with no integration. Partitions must be integrated through shared content, standards, and governance.
- Confusing partitions with levels. Levels concern granularity; partitions divide architecture to make development and management easier.
- Deciding partitioning late. The Preliminary Phase determines the desired approach to partitioning.
- Ignoring team allocation. Partitioning also covers how architecture teams are assigned to scopes.
How does the TOGAF glossary define an architecture partition?
How does partitioning help simplify the development of an Enterprise Architecture?
In which ADM phase should the desired approach to partitioning architecture teams, processes, and deliverables be determined?
Which statement correctly distinguishes partitions from levels?