Modeling SAP® solutions with a platform like Ardoq offers a holistic view that helps businesses understand if their SAP solutions align with strategic objectives, as well as identify opportunities to improve efficiency, mitigate risk, and reduce cost.

Here are our suggested approaches to modeling SAP solutions with Ardoq. This includes some options and alternatives to cater to the different objectives your organization may have for modeling SAP solutions. A model that informs migration will contain different details from one that is exploring IT costs or one that analyzes business criticality of IT.

Whilst SAP ECC (SAP ERP Central Component) and the more recent SAP S/4HANA® suite have different architecture, the approach to modeling them using Ardoq is very similar. So we’ll first cover different elements of a model using SAP ECC and subsequently explain the minor differences that are required to model a S/4HANA suite.

Table of Contents

Start with modeling the SAP Application and its modules using the Application and, optionally, Application Module components, showing the modules as children of the parent SAP Application component (they are an integral part of that SAP solution deployment). We recommend this because it is very likely that you will need to add connections (called references in Ardoq) to other components to and from individual modules later on. For more in-depth information on our approach to modeling applications, read What is an Application.

For the SAP solution modules, we recommend that you use the Application component type if business users would recognize, and refer to, these modules as business systems in their own right. On the other hand, some organizations may only refer to “SAP” as a business system, and the deployed modules may be meaningful only to those who are responsible for its deployment, maintenance and support. If this is the case, you should model these underlying components with the Application Module component type. If there is a need to represent custom extensions separately, you should use the Application Module component type. Application and Application Module are functionally similar, the difference being the desire to include them in business-oriented visualizations, such as those used to present the business architecture.

Use a Data Store component to represent the supporting database as a separate component. We recommend modeling the database separately because it is not embedded within the SAP application, and is typically deployed on separate infrastructure. In contrast, the SAP modules are all part of the same SAP solution deployment, and so are better represented as child components (either of type Application or Application Module) of the parent SAP Application component.

Reference 1: Example of SAP Applications and Data Store As Components in Ardoq

The Technology Product component type is used to record details of which technologies and versions are deployed across the organization. Combined, a set of Technology Products form your organization’s technology catalog. These components represent hardware and software products and, optionally, composite entries that define approved standards (e.g. an approved standard server configuration).

Reference 2: The Technology Product Component in Practice

Model the catalog separately from deployed instances to facilitate easy maintenance of the architecture repository, as one entry in the catalog may reference many deployed instances. See the Application Hosting Use Case for more information about this aspect of your model.

For an “on premise” deployment of SAP solutions, show the Application and Data Store components supported by the Server components on which they are deployed. The Server component can be used to represent both physical and virtual servers. In the example shown in reference 3 below, the SAP solution has five installed modules, is running Windows Server on a Dell PowerServer, with the database using Oracle 19c on a separate server.

Reference 3: How to Use the Server Components When Modelling On-Premise SAP Solutions

The previous examples show how to model a SAP software environment that is deployed on premise, running on your own server. For cloud-based SAP solutions or SAP solutions that are run on your behalf by a service provider that operates their own data centers, you should focus on modeling just the SAP application and its modules. As you are not directly responsible for the servers and software infrastructure that supports your SAP solution implementation, it is unlikely that you will need to model these details within Ardoq. Instead, we recommend representing the environment in which your SAP solution implementation runs with a Technology Service component (Reference 4).

Reference 4: Representing SAP Solutions as a Service With a Technology Service Component

Following these steps and examples, you will have modeled the SAP application, the environment it is running in, and the details of products, their releases and versions, that make up the underlying technology stack.

Next we will show you how to enrich this overview with capabilities, people, and more.

Your Enterprise Architecture becomes more valuable when its knowledge graph extends to the business architecture of the organization. Here is an example of how to connect it to the people and organizational units that use SAP solutions, the capabilities that are realized with its use, and the business information involved.

In reference 5 below, we can see that Carol is the responsible owner of the SAP Application, while Anne is an expert in the FI Module, and Karl is an expert in another module. You can also show which organizational units consume each of the different SAP Software Modules, indicated in reference 5 with the Organizational Unit component. For more information on modeling people and applications, read Application Lifecycle Management Use Case.

Reference 5: Connecting SAP Application Components to People and Organizational Units

Business capability modeling provides a way of representing an organization’s capabilities independent of its structure. Applications help to realize business capabilities, along with other enterprise assets such as people and their skills, business processes and business information. In reference 6 below, you can see how to represent the relationship between SAP Software Modules and the business capabilities they help to realize. See the Business Capability Modeling Use Case for our best practice recommendations on how to model your business’ capabilities.

Reference 6: Connecting SAP Application Components to Business Capabilities

In Ardoq, the Enterprise Data Catalog is represented with a combination of Subject Area and Data Entity components. Reference 7 below is a a simple example of how this can be done however, by nesting components within components, Ardoq can be used to represent a very rich and comprehensive Enterprise Data Catalog. As with business capabilities, you can model its relationship with SAP Software Modules, this time using the Accesses reference type. See the Data Lineage Use Case for more information on modeling data entities.

Reference 7: Simplified Example for Modeling the Enterprise Data Catalog

The Ardoq metamodel uses the Is Connected To reference type to link Applications and Application Modules to each other. It can be useful to show where this connection is managed via a formal interface, such as an API. Reference 8 below shows how you can use the Interface component type is used to represent this. Integrations and APIs can be modeled as a child of an Application component as seen in reference 8, or an Application Module component, depending on the level at which it operates. See the Application Integration Management Use Case for more information on modeling integrations and APIs.

Reference 8: Modeling Integrations and APIs with SAP Solutions

The SAP S/4HANA suite can largely be modeled using the same component types that you’ve used to model SAP ECC. Here are the key differences between the two which you should be aware of.

The SAP S/4HANA suite has nine Lines of Business which replace SAP ECC’s ten Modules. Like the Modules, you can model the Lines of Business using either the Application or Application Module component type as shown in reference 9 below.

Reference 9: Modeling the Lines of Business for the SAP S/4HANA Suite

If you’ve adopted the SAP Fiori® design system, you may choose to represent your SAP Fiori Apps as Application components alongside the Lines of Business. Remember to only model to the level that is needed. You do not need to model each individual app, but if you want to carry information at this level, for example, about their cost or ownership, then you can represent each SAP Fiori App with its own Ardoq component.

The SAP S/4HANA suite uses the SAP HANA Database and Platform. While SAP ECC uses a stand-alone database separate from the SAP Application and its Modules, SAP HANA is an in-memory database that is an integral part of the application. So we recommend representing a SAP HANA database as a Data Store component that is a child of the parent SAP Application component as shown in reference 10 below.

This example shows a SAP S/4HANA solution running in Azure. An on-premise deployment would show the Application component supported by a Server component instead of the Technology Service.

Reference 10: Modeling the Database for SAP HANA Databases

In reference 11, you can see a Dependency Map visualization for an example deployment of SAP solutions. It includes the Modules that have been deployed, the business capabilities that they help realize, and the people who are experts in, or own, the various components of the deployment.

Reference 11: Dependency Map View of a SAP Solution Deployment

In reference 12 below, you can see a Block Diagram visualization of the same model. It shows the organizational units which are dependent on the different SAP Modules to realize their essential business capabilities. You can also see that “MyRail” is running the 2021 version of SAP S/4HANA suite in the cloud, using the Microsoft Azure Center for SAP solutions in their North Europe Region.

Reference 12: Block Diagram View of a SAP Solution Deployment

Ardoq offers you a uniquely rich and flexible modeling capability as part of its platform and this article has covered the basic approach you should adopt when modeling the environment for your SAP solutions. We encourage you to go beyond this basic approach to create the rich data source you need to drive valuable business decisions via your enterprise architecture. This may mean adding more data to the components and references we’ve used in the examples here. With Ardoq, every component type and reference type can contain data fields so you can use these to further describe or qualify each component or reference in your graph. For example, you may wish to use a field to indicate where custom code has been adopted.

You should also consider how much of this metamodel you need to adopt to achieve your objectives and deliver business value from Ardoq. If your focus is on how SAP solutions are used to support business units and deliver products and services to customers, perhaps you have no need to model how and where SAP solutions are deployed.

We recommend that you only model to the level of detail that you need to deliver value. That might also mean expanding your graph, and its metamodel, beyond the limited component types and reference types we’ve used here. You might, for example, wish to model change initiatives and their planned impact on your organization’s business capabilities. Or connect your SAP modules to the value streams and business processes that connect your business directly to its customers. In our Use Case Solutions Metamodel Guide, you can see the component types and reference types in the context of a more complete enterprise architecture metamodel which supports other Ardoq Use Cases. Our Use Case guides include our best practice approach for solving specific problems or achieving a specific business outcome. They are built to help you realize value quickly by providing pre-configured assets that can be populated with data to deliver business outcomes. These guides are valuable resources for designing your enterprise architecture to quickly solve problems and generate insights.

Reference 13 below shows all of the component types and reference types that have been used in this recommended approach to modeling SAP solutions. This metamodel is itself a subset of the Ardoq Use Case Solutions Metamodel.

Reference 13: Metamodel Diagram Showing All Components and Reference Types Recommended to Model SAP Solutions

Here are the Use Case solutions that have been referenced in this guide:

SAP®, SAP Fiori®, and SAP S/4HANA® are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.