SAP ERP Modeling Best Practices

With the impending expiration of support for ERP software stacks by 2030, organizations are actively engaged in reviewing or undergoing migration from SAP ERP to SAP S/4HANA, the modern successor. Both SAP ERP and S/4HANA represent comprehensive suites of integrated business applications tailored to support enterprise resource planning (ERP) and other critical business processes.

This modeling guideline provides best practices for modeling both the "old world" with SAP ERP 6.0 and the new systems, such as SAP S/4HANA with Fiori and SAP BTP. It focuses on Applications, related Business Capabilities, and technical elements (IT Components, Tech Category). Check out the use case section to learn more about how to model SAP systems, e.g., in the context of a S/4HANA transformation.

Relevance, Typical Modeling Challenges, and Scope of This Guide

For enterprise architects navigating this landscape, modeling SAP ERP systems presents specific challenges due to the complexity and depth of the SAP landscape, involving a multitude of modules, components, and dependencies. Enterprise architects must navigate this complexity to create accurate and meaningful models. Moreover, the transition from SAP ERP 6.0 to S/4HANA involves significant architectural changes. It is crucial for enterprise architects to model the current state and the to-be architecture in an accurate and efficient way to support a smooth transformation in time and budget.

Our guidelines represent a lean approach to modeling SAP ERP systems from a business perspective to help you assess your SAP ERP portfolio, and potential risks, as well as transform efficiently and securely into the modern S/4HANA landscape. They focus on the most critical modeling parts for SAP ERP systems on the Application & Data Architecture and the Technology Architecture layer of the LeanIX Meta Model while the Business and Strategy Architecture layer are mostly covered in our use case documentation linked below.

Choose Modeling Approach Depending on Your Use Case

To keep your architecture and modeling work lean, you should only model what you need (Fact Sheet types in LeanIX, number of hierarchy levels, attributes on Fact Sheet types) to get desired architectural insights. Here are some recommendations for the typical SAP ERP-related use cases on a high level (follow the use case links to learn more):

Use Case Insights You Get From the LeanIX Best Practice Model Approach

Application Portfolio Assessment: Capture the SAP part of an existing Application Portfolio as standardized and efficient as possible:

  • Model SAP systems as Applications on level 1 and 2
  • Link them to Business Capabilities and Organization
  • Capture TIME attributes to assess your portfolio and identify application rationalization candidates (also helpful as an exercise in the context of an ERP transformation)

.

ERP Transformation: Capture the as-is SAP ERP architecture, model the to-be architecture and support an entire S4/HANA transformation

  • Provide more business-relevant information by modeling as well Objectives, Business Context, Platform
  • Add IT Components, Interfaces, Data Objects to understand your integration architecture
  • Model Initiatives (with transformations and impacts) to create roadmaps, plan scenarios and execute on the aligned roll-out plan and architectural changes

The LeanIX Architecture and Road Map Planning (Previously known as BTM module) provides enriched capabilities for future-state architecture and scenario planning. Learn more about Architecture and Road Map Planning here.

.

.

Technology Risk Management: Manage obsolescence, standards, etc. for your organization’s SAP assets.

You can use the Obsolescence Risk view to prioritize for which SAP Applications you want to analyze and evaluate risks first. You can trigger surveys to Application Owners to validate data and let them decide if they accept certain risks (on IT Component level) or if a transformation action is needed.

Model SAP ERP 6.0

SAP ERP refers to 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 refers to a major release of SAP’s ERP Suite (supported until 2030).

SAP ERP has been based on the traditional R/3 architecture, where R/3 stands for Real-Time, Three-Tier Architecture. It often uses a relational database management system (RDBMS) as its backend, like Microsoft SQL Server, Oracle, or IBM Db2. It is primarily deployed on-premise, with some cloud options.

SAP ERP 6.0 Application Structure and Modeling Guidelines

There are two perspectives to understand and structure the SAP ERP application landscape: focusing on the application structure (business perspective), or focusing on the system landscape (technical perspective):

  1. Application Structure:
  • Level 1 Applications (SAP System): Represents the highest level of the application hierarchy, often corresponding to a specific SAP system. An SAP client contains one or multiple SAP applications that are typically known to the business.
  • Level 2 Applications (Modules): Represents the underlying modules or components of the SAP system, such as SAP MM (Materials Management) or SAP FI (Financial Accounting) or SAP HR (Human Resources).
  1. System Landscape:
  • SAP System ID (SID): Represents a unique identifier for an SAP system within the landscape, captures typically a database and different application servers)
  • Client (“Mandat”): Refers to a logical partition or container within an SAP system, addressing a defined user group and holding its own data. Different clients may be used for development, testing, and production. An SID can contain multiple clients.
SAP Application Structure

SAP Application Structure

Our general LeanIX recommendation is to focus on the business perspective as this aligns with LeanIX’s application-centric view and the fundamental aim of LeanIX Enterprise Architecture, which is to bring IT and business together to support strategic planning and decision-making.

SAP ERP 6.0 (as any other SAP application) is modeled as a level 1-Application, and the underlying modules (e.g., SAP MM, SAP FI) as level-2 Applications:

Business Perspective

Business Perspective

Technical Perspective

Technical Perspective

📘

There can be situations where organizations might favor a technical perspective, e.g., if it is a frequent use case to buy new companies and a preference to keep SAP clients separated. In these cases, our recommendation is to model SAP System IDs (SIDs) as level-1 Applications, SAP Client as level-2 Applications, and SAP Applications as level-3 Applications in LeanIX.

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

This section provides guidance on how to model the technical details of the SAP application landscape. Therefore, it is helpful to understand the SAP product structure:

SAP Product Model

SAP Product Model

As already explained, SAP applications and modules are Applications in LeanIX. However, an SAP application typically uses multiple product versions of a software. It is best practice to map the SAP product versions, enhanced packages, add-ons, and industry solutions to an IT Component in LeanIX. In addition, SAP software components can also be added using IT Components in LeanIX:

Modeling product versions, enhanced packages, add-ons, and industry solutions to IT Component

Modeling product versions, enhanced packages, add-ons, and industry solutions to IT Component

You can use the Tech Category Fact Sheet to structure the 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 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

Use Tech Category to map technical objects

If you want to map the Interfaces between your SAP systems to LeanIX, use the Interface Fact Sheet type. The technology that an interface uses can be modeled as an IT Component in LeanIX. You can decide the level of detail - e.g. if you want to model Interfaces on level 1 or level 2 of Applications. Typically, at this level, you would also be interested in modeling Data Objects to understand the flow of your data between applications, which is an important view in ERP transformation use cases.

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

Data Objects and Interfaces

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/Provider Fact Sheet types.

📘

Leverage integrations with SAP FI, SAP Solution Manager and SAP SolMan to get data

  • Both the interface and the technology behind it can be partially extracted from SAP PI. Use our Integration API to automate the data exchange.
  • Company codes can be extracted from SAP FI.
  • Providers of product versions and software components can be extracted from SAP Solution Manager.
  • To maintain data and keep it up-to-date, assign a responsible person to the respective Fact Sheets.
  • To automatically synchronize your data, use our Integration API to connect to your SAP Solution Manager instance.
  • You can also use the .xls interface to export and import data between SAP SolMan and LeanIX.

For more details, please get in touch with your Customer Success Manager.

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

While many companies are trying to move to one ERP system only, we observe many cases, in which e.g., multi-national companies have several ERP systems. The software would each time be SAP ERP 6.0, but they might have very different setups (different User Groups, different Interfaces/integrations with other systems). In those cases it can make sense to show the differences by creating different Application Fact Sheets, e.g.,

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

Using the Platform Fact Sheet

The Platform Fact Sheet in LeanIX is designed to support communication with your business stakeholders and use a terminology that is broadly known, to read more, see Platform modeling guidelines. If you use the Platform Fact Sheet in the context of your SAP ERP transformation, you might want to create a Platform Fact Sheet “Old ERP” and a Fact Sheet “New ERP - S/4HANA” (for other organizations, it could be “OneERP”). Using the Platform Fact Sheet makes sense if your organization has different platforms and it is something typically understood by your business.

📘

Import Template

To kick-start your SAP ERP modeling with LeanIX, use our SAP ERP import templates.

Model SAP S/4HANA

In this section, we explain the key difference in modeling the S/4HANA stack in comparison to the classic SAP ERP stack.

SAP S/4HANA is a next-generation ERP suite built on a different technical backbone - the SAP HANA platform, which offers enhanced capabilities and a more streamlined architecture. It runs on the SAP HANA database and introduces a simplified data model and architecture compared to the complex three-tier architecture of traditional SAP ERP. S/4HANA uses the SAP Fiori interface for an intuitive user experience.

Instead of Modules, SAP S/4HANA is structured into Lines of Businesses.

SAP S/4HANA Application Structure and Modeling Guidelines

First of all, there is no major difference in modeling SAP S/4HANA in comparison to SAP ERP 6.0. Level 1 applications are used to model the respective SAP system (S/4HANA or S/4HANA Cloud), and Level 2 applications model the Line of Businesses (Finance, Sourcing and Procurement, Marketing, etc.), which is very similar to the modeling of SAP Modules as Level 2 applications. With the introduction of S/4HANA another business layer has been introduced, Fiori apps. We recommend modeling only Custom Fiori applications and adding them as Level 3 applications to LeanIX (see the section below for more information). Depending on the level of granularity that you want to model, you can either go for one, two, or three application levels. Our recommendation is to model your SAP landscape with at least two levels:

Modeling SAP S/4HANA Applications

Modeling SAP S/4HANA Applications

Since S/4HANA uses a different technical backbone than ERP 6.0 (the database HANA is used; in addition, S44HANA environments are also often cloud-based), the IT Components look different:

S/4HANA IT Components

S/4HANA IT Components

Please find in the following SAP S/4HANA import templates which can serve as a starting point for your own modeling. Our import templates focus on On-Premise, Cloud and Hybrid SAP S/4HANA deployments. The following diagrams represent a simplification of the import templates and are intended to provide you some best practices on how to model the different deployment models.

On-Premise Deployment:

S/4HANA On-premise deployment

S/4HANA On-premise deployment

Cloud Deployment:

S/4HANA Cloud deployment

S/4HANA Cloud deployment

Hybrid Deployment:

S/4HANA hybrid deployment

S/4HANA hybrid deployment

📘

Import Template

To kick-start your SAP S/4HANA modeling with LeanIX, use our SAP S/4HANA hybrid deployment import templates.

Model Fiori Applications as Part of the S4/HANA Tech Stack

With the introduction of SAP S/4HANA, Fiori applications are a crucial part of the SAP landscape. There is a set of SAP standard Fiori Apps, which can be customized according to your organization’s requirements. Additionally, you can create your own Fiori applications (called 'apps’ below) using different programming models from SAP (RAP or CAP).

In general, Fiori applications can be divided into two groups:

  • Standard Fiori apps that are used completely or essentially as SAP delivers them. These apps are being used more like components in SAP S/4HANA and support standard processes and functionality.
  • Custom Fiori apps, which are either developed in-house or are customized SAP Fiori apps. These apps provide a decisive added value, produce custom output, create documents, or have a high significance for the differentiation of your organization.

Our best practice is to only module custom Fiori apps in LeanIX and do so as level-3 Applications under the SAP Line of Business Application (as explained above). We don’t see significant added value in modeling a large amount of standard Fiori Apps which will blow up your application repository.

Model SAP BTP

The SAP Business Technology Platform (BTP) is playing an increasingly important role in SAP landscapes. It is SAP’s technology platform supporting intelligent enterprise solutions. Due to SAP's Clean Core and Fit2Standard concept, enhancements are implemented in the SAP BTP rather than in the SAP S/4HANA core. Since this is an open platform (as opposed to a rather closed SAP core system), it is very important to develop the SAP BTP strategically and to maintain an "overview" of the various solutions that are implemented and operated in the SAP BTP.

Depending on your perspective, you can see BTP as a Platform, Application, or IT Component. We are currently working on detailing our modeling approach for BTP and will be shared here as soon as possible.

Model SAP Interfaces and External Partners

Interfaces (i.e., internal or external system dependencies) play a significant role in an ERP transformation or operations and should, therefore, be modeled in LeanIX and always kept up-to-date. Data maintenance can be done collaboratively or through automated solutions, such as the Automation or Survey features. The Interface Circle Map can help visualize dependencies during the implementation.

We recommend modeling ‘business’ interfaces in LeanIX, which are also understood by key users, linking technical information in the Resource tab, such as Diagrams or other technical documentation. Important attributes can be responsibilities, technology dependencies, or security information.

Visualizing dependencies with Circlre Map

Visualizing dependencies with Circlre Map

For the modeling of external partners, there are different options:

  • Create one or more Application Fact Sheets that cluster external partner dependencies and add IT Components and Providers as needed. In this case, the same Data Objects and Interfaces can be used. This approach is best used when the dependencies are of low strategic importance.
  • Model all external partners as separate Applications with individual interfaces. This approach can be used if the dependencies are highly strategic and must be visualized individually.