Designing SAP as Enterprise Architecture—not merely selecting products

When manufacturing companies implement SAP S/4HANA, discussions often become overly focused on selecting products and functions.

Typical questions include:

• Which product should connect SAP S/4HANA and the manufacturing execution system?
• Should the company adopt SAP Integration Suite?
• Which service should be used for identity management?
• Should SAP Datasphere become the enterprise data platform?
• Should SAP Cloud ALM be used as the monitoring tool?

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:

• Which technology services are required at the enterprise level?
• Which systems provide information?
• Who consumes that information?
• Which shared capabilities should mediate between providers and consumers?

Two TOGAF reference models can support this analysis:

• TOGAF® Technical Reference Model (TRM)
• Integrated Information Infrastructure Reference Model (III-RM)

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.

---

1. Why Reference Models Matter in an SAP Implementation

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:

• SAP S/4HANA
• SAP Integrated Business Planning
• SAP Extended Warehouse Management
• SAP Digital Manufacturing
• Manufacturing execution systems
• Product lifecycle management systems
• Customer relationship management systems
• Data warehouses
• Electronic data interchange platforms
• Supplier portals
• API management platforms
• Identity management platforms
• Networks
• Security monitoring solutions
• Master data management systems
• Analytics and visualization platforms

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:

• An increasing number of point-to-point integrations
• Different interface specifications across plants and regions
• Fragmented authentication and authorization management
• Duplicate implementation of the same capabilities in multiple products
• Unclear boundaries between global standards and local requirements
• Difficulty identifying the impact of SAP upgrades
• Inability to maintain a Clean Core
• Lengthy deployment cycles for new plants or legal entities

TRM and III-RM help prevent these problems by organizing the architecture around required capabilities, roles, and services rather than around individual products.

---

2. The Difference Between TOGAF® TRM and III-RM

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.

---

3. How to Use III-RM in an SAP Implementation

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:

1. Information Consumer Applications
2. Information Provider Applications
3. Brokering Applications

3.1 Information Consumer Applications

Information Consumer Applications are applications that consume and present information.

In a manufacturing SAP implementation, examples include:

• Executive dashboards
• Production progress dashboards for plant managers
• Order and inventory inquiry applications for sales teams
• Supplier performance dashboards for procurement teams
• Quality management dashboards
• Supplier portals
• Customer portals
• Mobile approval applications
• SAP Analytics Cloud
• SAP Fiori applications

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.

3.2 Information Provider Applications

Information Provider Applications are business systems that store, generate, and provide information.

In a manufacturing company implementing SAP, typical providers include:

• SAP S/4HANA: Sales, procurement, inventory, production, costing, and finance
• SAP IBP: Demand planning, supply planning, and inventory planning
• SAP EWM: Warehouse inventory, inbound and outbound processing, and warehouse execution results
• SAP Digital Manufacturing or MES: Production results, equipment performance, and quality results
• PLM: Materials, drawings, engineering bills of material, and engineering change information
• CRM: Customers, opportunities, and sales activities
• SAP Master Data Governance: Master data
• External EDI platforms: Forecasts, firm orders, delivery instructions, advance shipping notices, and invoice information
• Quality management systems: Inspection results, defects, and corrective actions
• Enterprise asset management systems: Equipment failures, maintenance history, and equipment condition

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.

3.3 Brokering Applications

Brokering Applications mediate between information consumers and information providers.

In an SAP implementation, possible brokering capabilities and products include:

• SAP Integration Suite
• API Management
• SAP Event Mesh
• SAP Master Data Governance
• SAP Datasphere
• Data lakes or enterprise data platforms
• Enterprise search
• Identity and access management
• Workflow platforms
• EDI transformation platforms
• Messaging platforms
• Data virtualization
• Code conversion and data transformation services

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:

• Locating information sources
• Identifying connection endpoints
• Transforming data formats
• Converting code structures
• Performing authentication and authorization
• Routing messages
• Integrating information
• Publishing APIs
• Distributing events
• Controlling workflows
• Auditing information usage

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.

---

4. How to Apply III-RM in TOGAF® ADM Phase C

III-RM is primarily applied in TOGAF® ADM Phase C, particularly within Application Architecture.

The following approach is effective for manufacturing companies implementing SAP.

Step 1: Identify Information Consumers

First, identify who needs which information.

Examples include:

• Executives: Revenue, profit, inventory, cash, and demand fluctuations
• Sales teams: Inventory, delivery dates, pricing, and customer-specific performance
• Production planners: Demand, sales orders, production plans, capacity, and inventory
• Plant personnel: Production orders, work instructions, and quality standards
• Procurement teams: Requirements, purchase orders, delivery dates, and supplier capacity
• Engineering teams: Engineering BOMs, engineering changes, and component attributes
• Quality teams: Inspection results, defect causes, and traceability information

Step 2: Identify Information Provider Systems

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

Step 3: Identify Gaps Between Consumers and Providers

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:

• Data collection
• Currency conversion
• Unit-of-measure conversion
• Material code harmonization
• Standardization of company and plant hierarchies
• Data quality validation
• Access control
• KPI calculation

Step 4: Define Application Building Blocks

Before selecting products, define the logical application capabilities required.

Examples include:

• Enterprise Integration Service
• API Management Service
• Master Data Governance Service
• Event Distribution Service
• Enterprise Analytics Service
• Identity Federation Service
• Manufacturing Data Collection Service
• Supplier Collaboration Service

Once these Architecture Building Blocks have been defined, SAP and non-SAP products can be assigned as Solution Building Blocks.

---

5. How to Use TRM in an SAP Implementation

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.

5.1 Data Management Services

Data Management Services support the storage, retrieval, modification, consistency, and transactional management of data.

Examples in an SAP environment include:

• SAP HANA
• Database administration
• Transaction control
• Backup and restore
• Data archiving
• Data retention
• Data replication
• Data lifecycle management

5.2 Data Interchange Services

Data Interchange Services enable data exchange between systems.

Examples include:

• APIs
• IDocs
• OData
• SOAP
• REST
• EDI
• XML
• JSON
• CSV
• File transfer
• Message queues
• Event-based integration

These services are particularly important in manufacturing for supplier and customer EDI, plant equipment integration, and the exchange of production results with MES.

5.3 Security Services

Security Services provide authentication, authorization, encryption, auditing, and access control.

Examples include:

• Single Sign-On
• Multi-Factor Authentication
• Identity Federation
• Role Management
• Privileged Access Management
• Communication encryption
• Audit logging
• SAP GRC
• SAP Cloud Identity Services
• Enterprise identity platforms such as Microsoft Entra ID

5.4 System and Network Management Services

These services support system operations, monitoring, incident management, performance management, and configuration management.

Examples include:

• SAP Cloud ALM
• Job monitoring
• Interface monitoring
• Availability monitoring
• Performance monitoring
• Log management
• Alert management
• Incident management
• Capacity management

5.5 Network Services

Network Services connect SAP cloud environments, data centers, factories, and international locations.

Examples include:

• WAN
• SD-WAN
• VPN
• Cloud connectivity
• Proxy services
• DNS
• Load balancers
• Firewalls
• Zero Trust networking
• Segmentation between enterprise IT and plant operational technology networks

5.6 Location and Directory Services

These services identify and locate users, systems, services, and connection endpoints.

Examples include:

• User directories
• Organizational information
• Service directories
• API catalogs
• Endpoint management
• Certificate management
• System identifier management

5.7 International Operations Services

Global deployment requires support for multiple languages, currencies, time zones, character sets, and regional formats.

Examples include:

• Languages
• Currencies
• Exchange rates
• Units of measure
• Date formats
• Time zones
• Character encoding
• Country-specific localization

---

6. How to Apply TRM in TOGAF® ADM Phase D

TRM is primarily used in TOGAF® ADM Phase D: Technology Architecture.

Step 1: Translate Phase C Requirements into Technology Services

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:

• API Gateway
• Messaging
• Data transformation
• Connection management
• Certificate management
• Monitoring
• Logging
• Authentication
• Error handling
• Retry control

Step 2: Classify Technology Services

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.

Step 3: Compare the Baseline and Target Architectures

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

Step 4: Define Technology Building Blocks

Technology capabilities should be defined as reusable building blocks rather than as product names.

Examples include:

• Enterprise Identity Service
• Secure Network Connectivity
• Integration Runtime
• Central Monitoring Service
• Enterprise Logging Service
• Certificate Management Service
• Data Backup and Recovery Service
• API Security Service
• Global Directory Service

Step 5: Map the Building Blocks to SAP and Non-SAP Products

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.

---

7. Connecting TRM and III-RM in an SAP Implementation

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.

Architecture Analysis Using III-RM

Consumers

• Executive dashboard
• Plant management dashboard
• SAP Analytics Cloud

Providers

• SAP Digital Manufacturing
• MES
• SAP S/4HANA
• Quality management system

Brokers

• SAP Integration Suite
• SAP Datasphere
• API Management
• Master data integration
• Authentication and authorization services

Technology Analysis Using TRM

To support this structure, the following technology services are required:

• Data Interchange Services
• Data Management Services
• Security Services
• Directory Services
• Network Services
• System Management Services
• Logging and Audit Services
• International Operations Services

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.

---

8. Benefits of Using TRM and III-RM in Manufacturing SAP Programs

Applying TOGAF® TRM and III-RM can deliver several benefits in an SAP implementation.

8.1 Reducing Point-to-Point Integration

Separating consumers, providers, and brokers reduces the need to connect individual systems directly to one another.

8.2 Supporting SAP Clean Core

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.

8.3 Improving Reusability for Global Rollouts

Integration, identity, monitoring, and master data capabilities can be defined as shared Building Blocks and reused when deploying SAP to new companies or plants.

8.4 Increasing Transparency in Product Selection

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.

8.5 Clarifying the Roles of SAP and Non-SAP Systems

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.

8.6 Strengthening Technology Standards Governance

Authentication, APIs, logging, monitoring, networks, certificates, and data exchange formats can be managed through a Technology Standards Catalog.

8.7 Supporting Mergers, Acquisitions, and Business Restructuring

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.

---

9. Architecture Deliverables That Enterprise Architects Should Create

When applying TRM and III-RM in an SAP implementation, Enterprise Architects should consider creating the following deliverables.

Phase C Deliverables

• Application Portfolio Catalog
• Interface Catalog
• Application Communication Diagram
• System/Data Matrix
• Data Entity/Business Function Matrix
• Consumer/Provider Matrix
• Integration Service Catalog
• Application Building Block Inventory

Phase D Deliverables

• Technology Service Catalog
• Technology Standards Catalog
• Technology Portfolio Catalog
• Technology/Application Matrix
• Platform Decomposition Diagram
• Environment and Location Diagram
• Technology Building Block Inventory
• Security Service Model
• Monitoring and Operations Model

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

---

10. Practical Considerations

TRM and III-RM should not be used directly as product selection matrices.

Several practical considerations are important.

10.1 Tailor the Reference Models to the Organization

TOGAF® reference models are generic.

Organizations should extend them to include capabilities such as:

• Cloud platforms
• APIs
• Event-driven architecture
• Enterprise data platforms
• Zero Trust security
• Operational technology security

The result should be an organization-specific reference model.

10.2 Avoid Fixing Product Decisions Too Early

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.

10.3 Do Not Separate Phase C from Phase D

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.

10.4 Distinguish Logical Models from Implementation Models

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.

10.5 Do Not Use Reference Models to Reject the Existing Landscape

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.

---

11. Conclusion: Using TOGAF® TRM and III-RM to Design SAP as Enterprise Architecture

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:

• Who consumes information?
• Which systems provide information?
• What mediates between consumers and providers?
• Which information-sharing capabilities should be standardized?

TRM helps answer a different set of questions:

• Which technology services are required to support the applications?
• How should security, networks, monitoring, and data management be standardized?
• Which technology capabilities should become shared global platforms?
• Which products should be adopted as Solution Building Blocks?

Within the TOGAF® ADM:

• III-RM is primarily applied in Phase C
• TRM is primarily applied in Phase D

A practical implementation flow is as follows:

1. Define the business information requirements.
2. Use III-RM to identify consumers, providers, and brokers.
3. Define Application Building Blocks.
4. Use TRM to decompose them into the required Technology Services.
5. Define Technology Building Blocks and standards.
6. Map the Building Blocks to SAP and non-SAP products.
7. Develop solution options, migration plans, and implementation governance from Phase E onward.

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.

---

Reference Links

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.

1. The TOGAF Standard and Reference Models

• The TOGAF Standard – The Open Group
  The official entry point for the TOGAF Standard. It provides an overview of TOGAF as an Enterprise Architecture method and framework and links to related publications.
• The TOGAF Series Guides – The Open Group
  The official list of TOGAF Series Guides. The Integrated Information Infrastructure Reference Model is listed as a TOGAF Series Guide.
• Enterprise Continuum – Introduction – The Open Group
  This document explains that TOGAF provides two reference models for possible inclusion in an organization’s Enterprise Continuum: the TOGAF Technical Reference Model and the Integrated Information Infrastructure Reference Model.

2. TOGAF Technical Reference Model

• TRM Concepts – The Open Group
  This document describes the objective of the TRM as providing a widely accepted core taxonomy and an appropriate visual representation of that taxonomy. It supports the definition of a common technology-service classification and a Technology Service Catalog.
• TRM in Detail – The Open Group
  This document explains the detailed structure of the TRM, including Application Software, the Application Platform, Communications Infrastructure, and the platform services that support applications.
• TOGAF Frequently Asked Questions – The Open Group
  The FAQ describes the TRM as a model and taxonomy of generic platform services.
• Phase D: Technology Architecture – The Open Group
  This document identifies the TOGAF TRM as one of the reference sources that can be used when developing the Technology Architecture. It supports the use of the TRM primarily in ADM Phase D.
• Phases B, C, and D – The Architectural Model Level – The Open Group
  This document illustrates how an architecture can be checked against the TRM to identify and add technical functionality required for completeness.

3. Integrated Information Infrastructure Reference Model

• III-RM – Basic Concepts – The Open Group
  This document explains that the III-RM extends selected parts of the TRM, particularly the Business Applications and Infrastructure Applications areas, to support the design of an integrated information infrastructure and Boundaryless Information Flow.
• Integrated Information Infrastructure Reference Model – The Open Group
  This document describes the III-RM as a model of applications operating on top of an application platform. It provides a useful basis for understanding Information Consumer Applications, Information Provider Applications, and brokering capabilities.
• The TOGAF Series Guides – The Open Group
  This page provides the current location of the III-RM Series Guide within The Open Group’s TOGAF guidance portfolio.

4. SAP Integration Suite and Brokering Capabilities

• What Is SAP Integration Suite? – SAP Help Portal
  This page provides an overview of SAP Integration Suite. Its Cloud Integration, API Management, and event-driven capabilities can be mapped to selected brokering responsibilities described by the III-RM.
• Capabilities of SAP Integration Suite – SAP Help Portal
  This documentation lists capabilities including Cloud Integration, API Management, Event Mesh, Integration Advisor, Trading Partner Management, OData Provisioning, and Open Connectors.
• API Management – SAP Integration Suite – SAP Help Portal
  This page explains SAP Integration Suite’s API Management capability for API security, publication, management, and governance.
• What Is SAP Event Mesh? – SAP Help Portal
  This documentation explains how SAP Event Mesh enables applications to communicate through asynchronous events. It is relevant when mapping event-brokering capabilities to an event-driven architecture.

5. Master Data, Data Management, and Analytics

• SAP Master Data Governance – SAP Help Portal
  Official documentation for SAP Master Data Governance, including master-data creation, change control, approval processes, quality management, and governance capabilities.
• SAP Master Data Governance on SAP S/4HANA – SAP Help Portal
  This page provides an overview of SAP MDG on SAP S/4HANA, including classic mode and cloud-ready mode.
• SAP Datasphere Catalog Concepts – SAP Help Portal
  This documentation explains how the SAP Datasphere catalog supports data discovery, data publication, access management, and data-governance processes.
• SAP Analytics Cloud – SAP Help Portal
  Official documentation for SAP Analytics Cloud. Its analytics, dashboarding, and planning capabilities are relevant when considering Information Consumer Applications.

6. Technology and Application Lifecycle Management Services

• About SAP Cloud ALM – SAP Help Portal
  This page describes SAP Cloud ALM as a cloud-based application lifecycle management solution supporting the implementation and operation of cloud and hybrid business solutions. It can be considered when mapping SAP capabilities to system-management and operational services within an organization-specific TRM.
• SAP Cloud ALM for Implementation – SAP Help Portal
  This documentation explains how SAP Cloud ALM provides a central platform for implementation management using predefined process and task content.
• SAP Cloud ALM for Operations – SAP Help Portal
  This documentation covers operational monitoring capabilities for business processes, integrations, jobs, exceptions, and user experience.

---

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.

---

Back to Top