A comprehensive roadmap illustrating TOGAF domains and phases for ERP transformation planning and execution.
When you apply Enterprise Architecture (EA) in an ERP implementation, the TOGAF® Architecture Domain is far more than a simple classification scheme. It becomes a structuring concept for project scope, stakeholder alignment, gap analysis, roadmap design, and governance baselines. TOGAF® states that a complete Enterprise Architecture description should cover four domains—Business, Data, Application, and Technology—and warns that omitting any of them increases the risk of inconsistency and integration issues.
In other words, the Architecture Domain is both the structural unit of EA and a management axis for defining and controlling project scope. In ERP projects, designing only the Application Domain without looking at Business, or advancing only Technology without aligning the other domains, almost always results in rework during integration and design review.
ERP implementation is not just a system replacement; it is an enterprise‑level transformation. If you look only at processes, only at applications, or only at infrastructure, misalignments between domains tend to surface late in the project, when they are most expensive to fix.
TOGAF’s practical guidance explicitly states that EA is developed to enable “effective change” in the enterprise. For large‑scale transformations such as ERP, using Architecture Domains to structure what is being changed is essential. They provide a rigorous way to answer “what exactly are we transforming?” across business capabilities, information assets, applications, and technology platforms.
In TOGAF®, an Architecture Domain is a fundamental partition used to describe the Enterprise Architecture. The core ideas are:
Taken together, these statements position Architecture Domains as both the structural building blocks of EA and a practical axis for defining project scope. In ERP implementations, ignoring the Business Domain and designing only the Application Domain, or pushing ahead with Technology decisions in isolation, is a direct path toward integration overhead and late design changes.
The table below maps TOGAF’s four core Architecture Domains to typical ERP implementation artefacts, especially in SAP S/4HANA and related systems.
| Domain | Meaning in TOGAF | Typical ERP Implementation Focus |
| Business | Definition of business capabilities, value streams, organization, processes. | Future‑state processes for order management, production planning, procurement, inventory, costing, quality, shipping, and period‑end closing. |
| Data | Structure and flow of information assets that support the business. | Harmonization of materials, BOMs, routings, business partners, cost elements, inventory, and accounting master data. |
| Application | Application functions and their interactions that support the business. | Role allocation and integration design for SAP S/4HANA, PLM, MES, WMS, EDI, BI, and related systems. |
| Technology | Technical platform that supports applications. | Cloud platforms, networks, identity and access management, monitoring, security controls, and operational model. |
For the project manager, separating discussions by these four domains reduces blind spots and missing decision points. For the Enterprise Architect, visualizing dependencies across the domains significantly improves the quality of the roadmap and governance model.
In the TOGAF® ADM, Architecture Domains are explicitly embedded in Phases B, C, and D. Practitioners typically:
TOGAF® describes the standard steps within Phases B, C, and D as: select reference models, viewpoints, and tools; develop Baseline Architecture Description; develop Target Architecture Description; and perform gap analysis. It also clearly states that Phase A is the mandatory starting point for any EA development cycle, and that completing Phase A outputs requires exploring all domains at least at a high level.
Applied to ERP, Phase A is where you articulate why you are implementing ERP and which transformation items are in scope for this program. You then design future business processes in the Business Domain, master data and information flows in the Data Domain, system responsibilities in the Application Domain, and the execution platform in the Technology Domain, comparing Baseline and Target in each domain to derive gaps and executable work packages.
For the PM, Architecture Domains are not just a way to structure the WBS; they are a framing mechanism for decisions and stakeholder alignment. TOGAF’s practitioner guidance emphasizes that Phase A must clarify scope, stakeholders, concerns, and requirements before detailed architecture work begins.
In ERP implementations, PMs should use the domains mainly in three situations:
For instance, if you prioritize infrastructure modernization for an S/4HANA migration without validating assumptions in the Business Domain, you will likely revisit application configuration and data structures later. PMs should therefore consciously distinguish between domains that will be deeply explored and domains that will be “understood but not fully redesigned” and manage them explicitly.
For Enterprise Architects, the critical point is not to treat each domain as an isolated optimization box. TOGAF® acknowledges the existence of partial architectures but stresses that these are not complete EA descriptions and that architects have an obligation to manage and explain the associated integration risks.
In an ERP program, key responsibilities for the Enterprise Architect include:
In ERP, if decisions on adopting standard application functionality are taken purely within the Application Domain, you will miss important assumptions about Business variance and master data design. The Enterprise Architect must therefore deliver not only domain‑specific artefacts, but also cross‑domain trade‑off views that support informed decision‑making.
When deploying an ERP template across multiple sites, you define the scope of business standardization in the Business Domain, common master data in the Data Domain, responsibilities and integration patterns with local systems in the Application Domain, and connectivity and operational platforms in the Technology Domain.
If one site decides to minimize Business changes, you still need to make visible how that decision affects the other domains—especially data harmonization and template reuse. Without that transparency, the global template rapidly fragments and loses its value.
When integrating an acquired company into an existing ERP, there is often pressure to focus on Application integration first. TOGAF’s perspective is clear: without understanding Business and Data, you cannot achieve a complete and sustainable integration.
In practice, you should analyze process differences, customer and material master differences, accounting master structures, system integration options, and operational constraints across all four domains. Doing so significantly improves the realism of the integration roadmap and the probability of successful execution.
TOGAF® acknowledges that when the primary goal is technology selection, and business processes are not direct change targets, a fully elaborated Business Architecture may not be necessary. However, it also states that the other domains depend on at least a sufficient level of Business Architecture understanding.
The correct interpretation in ERP is not “we can ignore Business,” but rather “we can adjust the depth of Business modelling to match the project objectives.” Even in a technology‑led S/4HANA migration, you need a minimal Business view to avoid misaligned data and application decisions.
TOGAF’s practitioner guidance warns architects against collecting more information than necessary and strongly recommends stopping at a level of detail that is “fit for purpose.” In ERP implementations, you do not need to design all four domains to the same level of granularity, but you do need to explicitly state which domains are being treated more lightly and what risks you accept as a consequence.
Equally important is not skipping Phase A. If the main stakeholders have not agreed on the target state, business value, and scale of required change in Phase A, the detailed work in Phases B–D will produce sophisticated designs without real consensus, leading to governance and approval issues later.
The following matrix summarizes key questions for PMs and Enterprise Architects when using Architecture Domains in ERP programs.
| Perspective | PM: Questions to Confirm | EA: Questions to Confirm |
| Scope | Which domains are explicit change targets in this project? | What assumptions do we make about domains we will not deeply explore? |
| Dependency | How will decisions in early‑moving domains impact the others? | How do we translate cross‑domain gaps into specific work packages? |
| Governance | Who approves the risks associated with out‑of‑scope domains? | How do we document requirements, constraints, and compliance checks? |
| Roadmap | In what sequence should we execute to minimize rework? | How many Transition Architectures do we need, and what does each represent? |
In ERP implementation projects, TOGAF’s Architecture Domains are both a way to separate four design areas and a practical framework for scope definition, dependency analysis, migration planning, and governance. Project managers can use the domains to clarify project boundaries and risk exposure, while Enterprise Architects maintain cross‑domain consistency, design the Target Architecture, and construct a realistic roadmap. Doing so allows organizations to manage ERP implementation not as a mere system rollout but as a true enterprise‑level transformation.
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.
Of all the artifacts in TOGAF ADM Phase B, the Business Footprint Diagram is the…
The Environments and Locations Diagram is a formal TOGAF Phase D artifact that answers which…
The most common failure in early Enterprise Architecture work is misreading the business strategy. This…
Manufacturing integration must balance the rapid harmonization of management reporting with the safe migration of…
A TOGAF-based framework for identifying, evaluating, and mitigating SAP implementation risks in Tier 1 automotive…
Learn how Enterprise Architects can apply TOGAF Initial Risk Assessment, mitigation, and Residual Risk Assessment…