Diagram showing integration of TOGAF TRM and III-RM within SAP architecture framework.
When manufacturing companies implement SAP S/4HANA, discussions often become overly focused on selecting products and functions.
Typical questions include:
These are all important questions. From an Enterprise Architecture perspective, however, several fundamental issues should be clarified before specific products are selected.
The organization must first determine:
Two TOGAF reference models can support this analysis:
This article does not explain these models merely as academic TOGAF concepts. Instead, it presents them as practical tools for designing an SAP implementation as Enterprise Architecture in a manufacturing environment.
A large-scale SAP program cannot be designed by focusing on ERP alone.
In practice, an SAP implementation typically involves many systems and technology platforms, including:
When these components are selected independently, each system may introduce its own authentication method, interface technology, monitoring approach, data transformation logic, and master data management mechanism.
This often creates problems after go-live, such as:
TRM and III-RM help prevent these problems by organizing the architecture around required capabilities, roles, and services rather than around individual products.
Although TRM and III-RM may appear similar, they address different architectural concerns.
| Perspective | TRM | III-RM |
| Primary focus | Technology platforms and shared technology services | Application structures that provide, consume, and broker information |
| Primary question | Which technology services are required to support applications? | Who provides information, who consumes it, and how are they connected? |
| Primary ADM phase | Phase D: Technology Architecture | Phase C: Information Systems Architectures |
| Use in an SAP implementation | Organizing technology standards, infrastructure, security, operations, and networks | Defining the roles of ERP, MES, PLM, analytics, portals, and integration platforms |
| Typical outputs | Technology Service Catalog and Technology Building Blocks | Application Building Blocks, Interface Catalog, and Integration Architecture |
In simple terms:
III-RM defines the logical structure of information exchange.
TRM defines the technology foundation that supports that information exchange.
In an SAP implementation, a practical sequence is to use III-RM first to clarify business systems and information flows, and then use TRM to design the technology services required to support them.
III-RM is a reference model for designing information sharing across organizational and system boundaries.
In manufacturing, information related to sales, engineering, procurement, production, logistics, quality, and finance flows across multiple systems and organizations.
III-RM structures this environment around three primary roles:
Information Consumer Applications are applications that consume and present information.
In a manufacturing SAP implementation, examples include:
A critical principle is that information consumers do not necessarily need to operate the source systems directly.
For example, executives should not need to log in separately to SAP S/4HANA, SAP IBP, MES, and CRM to review sales, inventory, profit, and on-time delivery performance.
The consumer layer should integrate information according to user roles and present it at an appropriate level of detail.
Information Provider Applications are business systems that store, generate, and provide information.
In a manufacturing company implementing SAP, typical providers include:
Enterprise Architecture must define not only what each system provides, but also which system serves as the System of Record for each major information domain.
For example, if the authoritative systems for material master data, business partner data, equipment master data, production results, and inventory balances are unclear, adding more integrations will not ensure data consistency.
Brokering Applications mediate between information consumers and information providers.
In an SAP implementation, possible brokering capabilities and products include:
Brokering Applications should not be treated merely as interface tools.
A broker does more than move data from System A to System B. It may perform functions such as:
Even when SAP Integration Suite is adopted, it is insufficient to define it simply as a product that connects SAP and non-SAP systems.
III-RM should be used to clarify which brokering capabilities will be standardized as enterprise services and which responsibilities will remain within individual applications.
III-RM is primarily applied in TOGAF® ADM Phase C, particularly within Application Architecture.
The following approach is effective for manufacturing companies implementing SAP.
First, identify who needs which information.
Examples include:
Next, determine which systems provide the required information.
| Information | Primary Provider |
| Sales orders | SAP S/4HANA |
| Demand forecast | SAP IBP |
| Production results | SAP Digital Manufacturing or MES |
| Engineering BOM | PLM |
| Inventory | SAP S/4HANA or SAP EWM |
| Customer information | CRM or SAP S/4HANA |
| Quality results | QMS, MES, or SAP S/4HANA |
| Management KPIs | SAP Analytics Cloud or an enterprise data platform |
The information required by consumers may not be available directly from providers in the required form.
For example, global inventory information required by executives may be distributed across country-specific SAP S/4HANA systems, SAP EWM systems, and legacy ERPs.
In this case, the following broker capabilities may be required:
Before selecting products, define the logical application capabilities required.
Examples include:
Once these Architecture Building Blocks have been defined, SAP and non-SAP products can be assigned as Solution Building Blocks.
TRM classifies the technology platforms and common services required to support applications.
An SAP implementation requires more than the business functions provided by SAP S/4HANA, SAP IBP, or other applications. It also requires a broad range of supporting technology services.
The following are representative TRM service areas.
Data Management Services support the storage, retrieval, modification, consistency, and transactional management of data.
Examples in an SAP environment include:
Data Interchange Services enable data exchange between systems.
Examples include:
These services are particularly important in manufacturing for supplier and customer EDI, plant equipment integration, and the exchange of production results with MES.
Security Services provide authentication, authorization, encryption, auditing, and access control.
Examples include:
These services support system operations, monitoring, incident management, performance management, and configuration management.
Examples include:
Network Services connect SAP cloud environments, data centers, factories, and international locations.
Examples include:
These services identify and locate users, systems, services, and connection endpoints.
Examples include:
Global deployment requires support for multiple languages, currencies, time zones, character sets, and regional formats.
Examples include:
TRM is primarily used in TOGAF® ADM Phase D: Technology Architecture.
Application Building Blocks defined through III-RM should be decomposed into the technology services required to support them.
For example, an Enterprise Integration Service may require:
Use TRM categories to organize the required services systematically.
This makes it easier to identify omissions and duplication.
For example, an API integration design may specify the connection protocol but overlook monitoring, authentication, logging, failure retries, and certificate renewal.
By using TRM as a checklist, architects can verify not only the API connection itself but also the supporting technology services required for reliable operation.
Compare the current environment with the intended target environment.
| Technology Area | Baseline | Target |
| System integration | Plant-specific point-to-point integrations | Shared integration platform |
| Authentication | Separate identities for each SAP system | Federation with the enterprise identity platform |
| Monitoring | System-specific monitoring | Integrated monitoring with SAP Cloud ALM |
| EDI | Separate connections by country or company | Shared EDI service |
| API management | Individually published APIs | Governance through an API Gateway |
| Logging | Logs retained within individual systems | Centralized logging and audit platform |
| Master data | Managed separately in each system | Governance through SAP MDG |
Technology capabilities should be defined as reusable building blocks rather than as product names.
Examples include:
Finally, assign products as Solution Building Blocks.
| Technology Building Block | Potential Solution |
| Integration Runtime | SAP Integration Suite |
| API Management | SAP API Management |
| Event Distribution | SAP Event Mesh |
| Identity Federation | SAP Cloud Identity Services or Microsoft Entra ID |
| Application Monitoring | SAP Cloud ALM |
| Governance and Access Control | SAP GRC |
| Master Data Governance | SAP MDG |
| Analytics Platform | SAP Datasphere and SAP Analytics Cloud |
| Database Platform | SAP HANA |
Following this sequence enables an organization to select the best product for a required enterprise capability rather than using a product merely because it is available within the SAP portfolio.
TRM and III-RM should not be used independently. They should connect Phase C and Phase D of the TOGAF® ADM.
Consider a scenario in which production results from factories must be visualized on management dashboards.
To support this structure, the following technology services are required:
III-RM determines who uses which information, where the information comes from, and how it is mediated.
TRM determines what is required to operate that structure reliably, securely, consistently, and according to enterprise standards.
Applying TOGAF® TRM and III-RM can deliver several benefits in an SAP implementation.
Separating consumers, providers, and brokers reduces the need to connect individual systems directly to one another.
Integration logic and excessive custom functionality can be separated from SAP S/4HANA and placed in shared broker or platform services.
This makes it easier to preserve a Clean Core.
Integration, identity, monitoring, and master data capabilities can be defined as shared Building Blocks and reused when deploying SAP to new companies or plants.
Products can be evaluated against required capabilities and services rather than being selected first.
This makes the reasons behind technology decisions easier to explain and govern.
Decisions about whether to standardize on SAP or retain an existing MES or PLM solution can be based on the architectural roles of consumers, providers, and brokers rather than on product preferences.
Authentication, APIs, logging, monitoring, networks, certificates, and data exchange formats can be managed through a Technology Standards Catalog.
Systems from acquired companies and international subsidiaries can be mapped to a common model of consumers, providers, brokers, and platform services.
This makes integration strategies easier to define.
When applying TRM and III-RM in an SAP implementation, Enterprise Architects should consider creating the following deliverables.
One particularly useful deliverable is a matrix connecting business needs, consumers, providers, brokers, technology services, and products.
| Business Need | Consumer | Provider | Broker | Technology Service | Product |
| Global inventory visibility | SAP Analytics Cloud | SAP S/4HANA and SAP EWM | SAP Datasphere and SAP Integration Suite | Data Management, Security, and Network Services | SAP Datasphere and SAP Analytics Cloud |
| Engineering change integration | PLM users and plant personnel | PLM, SAP S/4HANA, and MES | SAP Integration Suite and SAP Event Mesh | Messaging, Data Interchange, and Monitoring | SAP Integration Suite |
| Supplier collaboration | Supplier Portal | SAP S/4HANA and SAP Ariba | API and EDI Broker | Security, Directory, and Data Interchange Services | SAP Ariba and SAP Integration Suite |
| Production performance visibility | Plant managers | MES and SAP Digital Manufacturing | Enterprise Data Platform | Data Management, Network, and Security Services | SAP Digital Manufacturing and SAP Analytics Cloud |
TRM and III-RM should not be used directly as product selection matrices.
Several practical considerations are important.
TOGAF® reference models are generic.
Organizations should extend them to include capabilities such as:
The result should be an organization-specific reference model.
Selecting products before defining Architecture Building Blocks causes the architecture to be constrained by the capabilities of existing products.
The organization should first define the required capabilities and services, and only then assign SAP and non-SAP products.
When Application Architecture and Technology Architecture are designed independently by different teams, application requirements and technology platforms may not align.
Traceability must therefore be maintained from III-RM to TRM.
API Management, Integration Runtime, and Event Broker are logically separate Building Blocks.
Even when a single product provides multiple capabilities, their architectural roles should be managed separately.
Reference models are not intended to justify replacing every legacy system.
They should be used to visualize the roles performed by existing MES, PLM, EDI, and data platforms, and to determine which components should be retained, integrated, consolidated, or replaced.
In an SAP implementation, TRM and III-RM are more than TOGAF study topics.
Together, they can elevate an SAP program from a product implementation initiative to an Enterprise Architecture transformation.
III-RM helps architects answer the following questions:
TRM helps answer a different set of questions:
Within the TOGAF® ADM:
A practical implementation flow is as follows:
SAP S/4HANA, SAP IBP, SAP EWM, SAP Digital Manufacturing, SAP Integration Suite, and SAP Datasphere are not the architecture itself.
They are Solution Building Blocks used to deliver the information capabilities and technology services required by the enterprise.
The role of Enterprise Architecture is not to arrange products on a diagram. It is to establish traceability from business requirements through information structures, application structures, technology services, and product selection.
TOGAF® TRM and III-RM provide a common language for building and governing that traceability.
This article is based on official publications from The Open Group concerning the TOGAF Technical Reference Model (TRM), the Integrated Information Infrastructure Reference Model (III-RM), and official SAP product documentation.
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.
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…
Learn how Outputs, Deliverables, Artifacts, and Outcomes differ in Enterprise Architecture through a practical automotive…