Modeling SAP ERP 6.0

Learn key approaches for modeling SAP ERP 6.0, including product versions, software components, technical components, and interfaces, as well as modeling system instances, such as local customizations.


SAP ERP is the traditional suite of enterprise software applications developed by SAP to help businesses manage their key processes, such as finance, human resources, procurement, supply chain, and more. SAP ERP 6.0 is a major SAP ERP suite that will be supported until 2030.

SAP ERP is built on the classic R/3 architecture, where "R/3" stands for Real-Time, Three-Tier Architecture. It typically uses a relational database management system (RDBMS) for its backend, such as Microsoft SQL Server, Oracle, or IBM Db2. The suite is primarily deployed on-premise, though some cloud deployment options exist.

This guide focuses on modeling the "old" SAP ERP solutions to support best practices modeling for ERP/ S/4HANA transformation use cases (check the ERP Transformation use case guide for details). Follow the general instructions from the Modeling SAP Cloud Solutions guide while modeling the SAP ERP 6.0 in LeanIX since most of the best practices apply for SAP ERP 6.0 as well.

General Guidelines for Modeling SAP ERP 6.0

  • Like other SAP applications, SAP ERP 6.0 should be modeled as a level 1 application, with underlying modules, such as SAP MM and SAP FI, as level 2 applications.
  • Model SAP product versions, enhancement packages, add-ons, and industry solutions as IT components.

Business Perspective

LeanIX Modeling Best Practice for SAP ERP 6.0

Our general recommendation is to focus on the business perspective. This aligns with LeanIX’s application-centric view and the core objective of LeanIX Enterprise Architecture: to bring IT and business together to support strategic planning and decision-making. Bring all instances of an SAP application with business impact into LeanIX, as this reflects the LeanIX concept of an application.

In some scenarios, organizations may opt for a technical perspective following the logic of SAP System ID (SID) (unique identifier for an SAP system within the landscape, typically encompassing a database and multiple application servers) and Client (Mandant (logical partition or container within an SAP system, addressing a specific user group and containing its own data). For instance, if an organization frequently acquires new companies and prefers to keep SAP clients separate, it's better to model SIDs as level 1 applications, SAP Clients as level 2 applications, and individual SAP applications as level 3 applications in LeanIX. This approach maintains a logical structure while accommodating specific business needs.

Technical Perspective

Technical modeling approach

Modeling SAP Product Versions, Software Components, Technical Components, and Interfaces

This section provides guidance on modeling the technical details of the SAP ERP 6.0 application landscape. To do so effectively, it's essential to understand the SAP product structure, which is illustrated below:

SAP Product Model

SAP Product Model

As previously mentioned, SAP applications and modules are modeled as applications in LeanIX. However, an SAP ERP 6.0 application often uses multiple product versions and various software components. The best practice is to map SAP product versions, enhancement packages, add-ons, and industry solutions to IT components in LeanIX. Additionally, specific SAP software components are represented using IT components:

Modeling Product Versions, Enhanced Packages, Add-ons, and Industry Solutions to IT Components

Modeling Product Versions, Enhanced Packages, Add-ons, and Industry Solutions to IT Components

Use the tech category fact sheet if you want to categorize and structure different types of product versions:

Using Tech Category to Model Different Types of Product Versions

Using Tech Category to Model Different Types of Product Versions

You can also use the tech category to map technical objects and systems, such as application servers, databases, operating systems, etc., to IT components:

Use Tech Category to Map Technical Objects

Using Tech Category to Map Technical Objects

You can determine the level of detail for your model—for example, whether you want to model interfaces on level 1 or level 2 of applications. Typically, at this level, you would also consider modeling data objects to understand how data flows between applications. This is an important insight for ERP transformation use cases, as it helps visualize data movement and identify potential dependencies or bottlenecks in the system.

The following diagram shows an example of how to model SAP interfaces in LeanIX:

Data Objects and Interfaces

Example for Modeling ERP 6.0 including Data Objects and Interfaces

It is also possible to map your SAP company codes and providers to LeanIX. We recommend mapping them to the organization and provider fact sheet types.

Modeling Instances of Systems ( e.g., Local Customizations)

While many companies aim to consolidate to a single ERP system, multinational corporations often have multiple ERP systems, typically using SAP ERP 6.0 but with different configurations for different organizations, interfaces, or integrations with other systems. If it is beneficial for your organization to represent these differences create separate application fact sheets in LeanIX (as mentioned in the guide Modeling SAP Cloud Solutions). For example:

  • for different countries: SAP FI France, SAP FI Germany, etc.
  • for different business units: SAP FI BU1, SAP FI BU2


Import Template

To kick-start your SAP ERP modeling in LeanIX, use our SAP ERP Import Templates.