Try to manage a large-scale Enterprise Architecture with a single team working at a single level of detail, and it will eventually break down. Different organizational units have different needs, multiple architecture teams need to work in parallel, and deliverables need to be modular enough to be reused across the landscape. TOGAF® addresses exactly this problem through the concept of Architecture Partitioning. This article walks through the purpose of partitioning, the ADM phase where it should be addressed, when it should be revisited, and a practical example drawn from a global SAP S/4HANA rollout — quoting directly from the TOGAF® Standard throughout.
Why Architecture Partitioning Exists
The TOGAF® Standard defines the purpose of partitioning as follows:
“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.”
(The Open Group, TOGAF Standard — Applying the ADM, Chapter 4)
Two points stand out here. First, partitioning exists to simplify development and management — it is not a classification exercise, but a foundation for governance. Second, the standard explicitly states that partitioning is a different concept from “levels” (Strategic/Segment/Capability) and the Architecture Continuum. In practice these two ideas get conflated, but levels classify architecture by granularity, while partitioning defines team-level ownership and governance boundaries.
The standard lists three reasons architectures need to be partitioned:
- Organizational unit architectures conflict with one another
- Different teams need to work on different elements of architecture at the same time
- Effective architecture re-use requires modular architecture segments
It also notes that “it is impractical to present a definitive partitioning model for architecture” and that “each enterprise needs to adopt a partitioning model that reflects its own operating model” — a reminder that partitioning should be designed around your organization’s actual structure, not applied as a generic template.
Which ADM Phase Should Address It
The standard is explicit about which phase owns partitioning: 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.”
(The Open Group, TOGAF Standard — Applying the ADM, Chapter 4)
In other words, partitioning is a decision to make before Architecture Vision (Phase A) even starts — it belongs to the moment the organization stands up its Architecture Capability. The standard breaks the Preliminary Phase work into three steps:
- Determine the organization structure for architecture: identify the standing teams that will create architecture, and establish their governance bodies, membership, and reporting lines
- Determine the responsibilities for each standing architecture team: define the subject matter areas, level of detail, time periods, and stakeholders covered by each team, ensuring the entire enterprise scope is assigned to a single owning team per architecture
- Determine the relationships between architectures: formalize governance relationships and clarify where artifacts from one partition are expected to be reused in another, including overlap points and compliance requirements
The standard also addresses temporary project teams: they should operate under the governance of a standing architecture team, and their own ADM cycle should include a process for establishing appropriate partitioning. In practice, this distinction between standing and temporary teams is easy to blur. On a global SAP program, for example, if the program-dedicated team ends up owning the entire global template with no standing team behind it, there is no permanent owner left to govern that template once the program closes — and standardization erodes quickly. Deciding, during the Preliminary Phase, who owns each area on a permanent basis is the practical crux of partitioning design.
Don’t Confuse Partitioning with “Levels”
TOGAF® also defines three architecture “levels” — Strategic Architecture, Segment Architecture, and Capability Architecture — but this is a different axis from partitioning. Levels classify architecture by granularity: Strategic Architecture sets direction at the executive level, Segment Architecture supports roadmap development at the program or portfolio level, and Capability Architecture supports the realization of capability increments. Partitioning, by contrast, answers “who owns and governs this area” — a team-level boundary. In practice, a single level (say, Segment Architecture) can contain multiple partitions (regional teams, for example), and a single partition can span multiple levels of deliverable. Treating the two as the same thing tends to create confusion: either ownership is clear but detail standards vary wildly, or detail is consistent but ownership is ambiguous.
When Should It Be Revisited
The chapter that defines partitioning does not prescribe a fixed review cycle — there is no mention of an annual review, for instance. The “Applying Iteration to the ADM” chapter, however, is explicit about the triggers for re-establishing or adjusting the Architecture Capability that partitioning is part of:
“Projects may require a new iteration of the Preliminary Phase to (re-)establish aspects of the Architecture Capability identified in Phase A to address a Request for Architecture Work[, or to] adjust the organization’s Architecture Capability as a result of identifying new or changed requirements for Architecture Capability as a result of a Change Request in Phase H.”
(The Open Group, TOGAF Standard — Applying the ADM, Chapter 2)
That gives two explicit triggers:
- Triggered from Phase A: a new Request for Architecture Work surfaces a scope that the current partition structure cannot cleanly accommodate
- Triggered from Phase H: a Change Request arising from Architecture Change Management identifies new or changed requirements for the Architecture Capability itself
The Architecture Governance iteration description reinforces this: “Results of a Change Request may trigger another phase to be revisited; for example, feeding back a new requirement to the Preliminary Phase to improve the Architecture Capability.” The standard is not asking for periodic reviews on a calendar — it is asking you to re-iterate the Preliminary Phase whenever a genuine need for change has been identified.
A Practical Example: Global SAP S/4HANA Rollout
The following is a practical application built on the standard’s own classification criteria (Subject Matter/Breadth, Time, Maturity/Volatility, and Depth), applied to a Tier 1 automotive supplier rolling out a global SAP S/4HANA template.
Partitioning by Subject Matter (Breadth)
A core team owns the common global template (FI/CO, master data governance via MDG), while separate teams own regional and divisional local extensions — North American dealer management, European intercompany logistics, and so on. This maps directly onto the standard’s own examples of partition units: “applications, departments, divisions, products, services, service centers, sites.”
Partitioning by Depth
Strategic Architecture, covering investment decisions and the overall roadmap for executive stakeholders, is partitioned separately from implementation-level architecture — detailed design work such as WRICEF specifications — which requires a different level of detail and a different audience.
Partitioning by Time and Maturity/Volatility
Mature core finance and accounting areas, which change infrequently, are managed under a standard governance cadence, while highly volatile new areas — AI agent adoption, data fabric initiatives — are managed with shorter, more frequent iteration cycles.
Questions to Ask Before You Start Designing Partitions
When you actually design partitions during the Preliminary Phase, it helps to translate the standard’s own definition criteria — subject matter, level of detail, time period, stakeholders — into concrete questions:
- Subject matter: Which SAP modules, business processes, or organizational units does this partition cover? Where exactly is the line between the global template and local extensions?
- Level of detail: Does this team stop at the conceptual level, go as far as logical design, or drill down into configuration-level detail?
- Time period: Is this architecture scoped to a single rollout wave, or to the entire multi-year roadmap?
- Stakeholders: Who approves this deliverable, and who can request changes to it? Between a regional CIO and the global Center of Excellence, where does final sign-off authority sit?
- Relationships: Where do this partition’s outputs get reused or connected within other partitions — security architecture, technology architecture, and so on?
If any area cannot be answered cleanly, that is a signal that partitioning is incomplete. As the standard warns, having more than one team’s responsibility overlap on a single architecture tends to create governance friction — and it is worth resolving early.
Key Takeaways
Architecture Partitioning defines who owns which scope, at what level of detail, over what time horizon — the foundation that makes Architecture Governance actually work. It belongs in the Preliminary Phase, and it should be revisited when one of two explicit triggers occurs: a new Request for Architecture Work surfaced in Phase A, or a Change Request from Phase H. It is a distinct concept from the Strategic/Segment/Capability levels, and designing a partitioning model that fits your own operating model — rather than importing someone else’s — is a precondition for successfully running large-scale programs like a global ERP rollout.
References
- The Open Group, “TOGAF Standard — Applying the ADM, Chapter 4: Architecture Partitioning” https://pubs.opengroup.org/togaf-standard/applying-the-adm/chap04.html
- The Open Group, “TOGAF Standard — Applying the ADM, Chapter 2: Applying Iteration to the ADM” https://pubs.opengroup.org/togaf-standard/applying-the-adm/chap02.html
- The Open Group, “TOGAF Standard — Applying the ADM, Chapter 3: Applying the ADM Across the Architecture Landscape” https://pubs.opengroup.org/togaf-standard/applying-the-adm/chap03.html
Disclaimer
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Leave a Reply