This infographic explains a seven-step process for mapping technology components to business locations and environments.
Among all Enterprise Architecture deliverables, the Environments and Locations Diagram is one of the rare artifacts that speaks to executives and operations teams with the same single picture. It belongs to Phase D: Technology Architecture of the TOGAF® ADM, and it remains a formal artifact in the 10th Edition of the standard (The Open Group, TOGAF® Standard — Architecture Content §3.6.6).
This guide walks through the purpose of the diagram, a step-by-step creation process, the practical pitfalls that derail it, and a concrete worked example based on a global ERP transformation.
The definition in the standard is refreshingly direct:
The Environments and Locations diagram depicts which locations host which applications, identifies what technologies and/or applications are used at which locations, and finally identifies the locations from which business users typically interact with the applications. This diagram should also show the existence and location of different deployment environments, including non-production environments, such as development and pre-production.
(TOGAF® Standard — Architecture Content §3.6.6)
So there are three questions it must answer:
On top of that, the standard explicitly requires you to show non-production environments such as development and pre-production. This is what separates the diagram from a generic infrastructure drawing: it treats environment multiplicity (Dev / QA / Pre-Prod / Prod) as a first-class structural concern.
On the ADM side of TOGAF® 10, the following appears as part of the Target Technology Architecture to be captured in the Architecture Definition Document:
Environments and locations — a grouping of the required technology into computing environments (e.g., development, production)
(TOGAF® Standard — ADM, Phase D §8.4)
In other words, the Architecture Definition Document is the deliverable, and this diagram is one of the artifacts that populates it. When a review board asks whether the diagram is a formal deliverable, explaining that hierarchy keeps the discussion from drifting.
TOGAF® lists a number of environment- and location-related purposes for Phase D: linking platform requirements to hosting requirements; showing how a single application may need to be physically located in several environments to support local access, development lifecycles, and hosting requirements; documenting the contents of each environment and the logical communications between components; describing the physical communications infrastructure including routers, switches, firewalls, and network links; and supporting the presentation of capacity information for both deployed infrastructure and communications infrastructure (TOGAF® Standard — ADM, Phase D).
Phase D also makes clear that service boundary design is inseparable from location and latency. Because services may interact over remote links and inter-service communication carries built-in latency, the standard advises that drawing service boundaries and setting service granularity must consider the platform and location impact of inter-service communications (TOGAF® Standard — ADM, Phase D). This diagram is the record that makes those judgments auditable later.
The TOGAF® Phase D modeling process prescribes defining a taxonomy of technology services and logical technology components including standards, identifying the relevant locations where technology is deployed, and carrying out a physical inventory of deployed technology abstracted up into the taxonomy (TOGAF® Standard — ADM, Phase D §8.3). Translated into practice, that becomes the following.
Do not start drawing. Decide whose decisions the diagram is meant to support. The typical audience includes infrastructure and operations leads, security and data-protection officers, network engineers, regional IT leads, and the PMO tracking migration cost. Because each audience needs a different level of detail, producing several versions of the same diagram is often the correct answer, not a failure of discipline. TOGAF® is explicit that artifact selection should be driven by stakeholder concerns.
The primary inputs are:
This is where you put TOGAF’s Catalog → Matrix → Diagram progression to work: catalogs and matrices are the raw material for the diagram.
“Location” shifts meaning with context, and the single most important discipline is to avoid mixing these three layers:
SAP’s guidance asks architects to explicitly name the data center provider, the data center location, and infrastructure-specific details for each landing zone (SAP Learning).
Determine how far the diagram extends across Dev, Test (QA), Pre-Prod, and Prod. Since TOGAF® explicitly calls for non-production environments such as development and pre-production, any omission should carry a written rationale. This is also the point to assess environment symmetry. A production tier spanning multiple regions while Dev sits in a single region is a legitimate design choice, but the asymmetry has direct risk and cost implications that belong in the conversation.
Assign each Solution Building Block to its deployment environments. A single application appearing across multiple environments and multiple locations is not an anomaly; it is precisely the case TOGAF® anticipates, driven by local access, development lifecycles, and hosting requirements.
Visualize the request-response and information-flow relationships between Solution Building Blocks, and derive network requirements from them (SAP Learning). At the same time, show which data traverses public lines and where VPN security capabilities are required.
TOGAF® asks that capacity information for deployed and communications infrastructure be presented per environment where available. Managing RPO/RTO targets, latency objectives, and data residency constraints alongside the diagram — as annotations or a companion table — means the alternatives comparison in Phase E can run directly off this artifact. Finally, close out all activities in the “Finalize the Technology Architecture” step and publish formally through the Architecture Definition Document (TOGAF® Standard — ADM, Phase D).
The Software Distribution Diagram is an Application Architecture artifact. The Environments and Location Diagram takes it as input and adds a substantially higher level of detail from the deployment and operational perspective (SAP Learning). A diagram that merely re-skins the former will be called out in review as a restatement of application placement.
Documenting network communication lines, VPNs, and related network detail is the job of the Network and Communications Diagram (SAP Learning). Note that in the 10th Edition, what 9.2 called the Communications Engineering Diagram has been renamed the Network and Communications Diagram (TOGAF® Standard — Architecture Content §3.6.6). A workable boundary: the Environments and Locations Diagram shows that a connection exists and what kind it is; detailed device topology goes in the companion diagram.
TOGAF® states that the level of detail depends on the scope and goals of the overall architecture effort, and that new technology building blocks introduced by the effort need to be defined in detail during Phase D. Conversely, existing building blocks carried into the target environment may need to be redefined to ensure interoperability and fit-for-purpose operation (TOGAF® Standard — ADM, Phase D).
A remarkably common failure is to map internal hosting carefully while omitting user sites and third parties — EDI counterparties, supplier portals, logistics providers. The definition explicitly includes where business users typically interact with the applications from.
Which region holds personal data or export-controlled data is something this diagram expresses more naturally than any other artifact. Running the legal and privacy review during Phase D rather than after it dramatically reduces rework.
With SaaS, the internal structure of the data center is invisible — but the contractual region, the location of the subaccount, and the connection method to the on-premises counterparties are all documentable. The answer is not “we can’t draw it because it’s SaaS.” Draw the boundary as a box, and make the nature of that boundary explicit: public line or dedicated circuit, and which authentication model applies.
SAP’s methodology states plainly that iterations occur within and across individual phases, and that the visualization is not intended to imply a waterfall-based approach (SAP Learning). TOGAF® likewise leaves it to the team, in line with established Architecture Governance, to decide whether the Baseline Description or the Target Architecture is developed first (TOGAF® Standard — ADM, Phase D).
Consider a fictional automotive Tier 1 supplier — headquartered in Tokyo, with a primary plant in Nagoya, European operations in Stuttgart, and North American operations in Detroit. Here is the target Environments and Locations Diagram expressed in text.
| Solution Building Block | Hosting | Dev | QA | Pre-Prod | Prod | Data residency constraint |
| Core ERP (S/4HANA) | Cloud DC, Tokyo region | ● | ● | ● | ● (Tokyo + Osaka DR) | Accounting data held in-country |
| Integration / extension platform (BTP-class) | Tokyo subaccount + EU subaccount | ● | ● | — | ● | EU personal data processed in EU |
| Procurement SaaS | Vendor DC, EU | — | ● | — | ● | Supplier personal data in EU |
| MES | Plant on-premises (Nagoya / Stuttgart / Detroit) | Nagoya only | Nagoya only | — | All three sites | Production data held first at site |
| Analytics / data platform | Tokyo region | ● | ● | — | ● | EU data transferred after pseudonymization |
| Identity provider (cloud identity services) | Global tenant | ● | ● | — | ● | — |
This table is the implementation of what TOGAF® means by grouping the required technology into computing environments.
The Detroit MES case is the point of the exercise: drawing the diagram is what surfaces the conclusion that synchronous integration is not viable. That is exactly why Phase D treats location and latency together.
Comparing the baseline — independent regional ERP instances with ad hoc VPNs — against the target yields Architecture Roadmap candidates such as:
These map to the Phase D output “Technology Architecture components of an Architecture Roadmap” (TOGAF® Standard — ADM, Phase D §8.4).
The Environments and Locations Diagram is a formal artifact of TOGAF® Phase D in the 10th Edition, sitting alongside the Technology Standards Catalog, Technology Portfolio Catalog, Application/Technology Matrix, Platform Decomposition Diagram, Processing Diagram, Networked Computing/Hardware Diagram, and Network and Communications Diagram (TOGAF® Standard — Architecture Content §3.6.6). The Architecture Definition Document is the deliverable; this diagram is what gives it substance.
Its real value is not visual completeness. It is the ability to make one page carry the full argument for how a placement decision propagates into latency, cost, regulatory exposure, and operability. Now that cloud and SaaS are the default rather than the exception, the architects who refuse to leave location ambiguous are the ones who produce architectures that survive implementation.
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 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…
Learn how Outputs, Deliverables, Artifacts, and Outcomes differ in Enterprise Architecture through a practical automotive…