Introduction

The aim of modeling is to model business process flows. The model helps you to understand and then to implement the process flows or to enhance an implementation that already exists.

Although a company's software is tailor-made for the needs of that business, the fundamental business process flows do not vary that much. It is possible that there are many implementations for a process flow in a business and for the same business area but with a different focus. The data and the fundamental process flows are however often the same.

For this reason it makes sense from the beginning to introduce a level of abstraction to the modeling that is removed from the details of implementation. The same modeling object (the “process component”) is always used for the same business process flow, irrespective of how many different implementations there will be in a specific system landscape. The data for each process flow is modeled using “business objects”. The following sections deal with this in more detail.

Abstractions from Data Using Business Objects (BOs)

SAP uses BOs to describe the data of an application. The fundamental idea is that a clear distinction between the data of different business areas contributes to a good modeling of the business processes. Many questions relating to modeling can be answered by the modeling of business objects. Business objects are therefore the central point of the principles used by SAP and form the foundation for the definition of services.

To be able to use BOs effectively for multiple use cases, you must model them in such a way that you avoid overlaps with other BOs. For example, product data should not be part of an order, but rather modeled in a separate BO. In this way the BO for product data can then be used for other use cases.

Of course, the character of the data that is described by a BO also plays an important role in modeling. An important characterization is the difference between transaction data and master data:

Aside from this characterization of the BOs you can also use the BO as a template for a whole series of BOs. For example, a business partner can be either a customer or a supplier and the data, with which either the customer or the supplier is described, is the same. If you consider beforehand a “business object template” from which the customer and supplier can be projected, then you avoid an inconsistent definition of the same data.

In short, the data that needs to be accessed (and in turn, the BOs) are the central points of the modeling: services always access data, therefore the modeling of services is intrinsically linked with the modeling of business objects. A well thought-out and consistent identification of BOs leads to a good modeling of services.

Abstraction from Implementation Using Process Components

In ARIS models, SAP works with process components to identify a self-contained part of a value chain. The business relevance of a process component is not designed just for SAP, but is cross-company. This is particularly crucial for implementation later of B2B processes.

From the meeting view, a process component is a shell where data, and services for accessing this data, are contained. Since data can be modeled using business objects, one or multiple objects belong to exactly one process component and in this way determine the data of a business area. In this way process components form reusable modules of (possibly multiple) larger applications.

One difficulty with the definition of process components is the level of granularity. In other words: With regard to the data and the process to be modeled, you must decide whether to introduce one or multiple process components . Actually, the modeling of data using one or multiple BOs is closely connected to the modeling of process components. If, for example, different departments access different data of a BO, then this is a sign that the BO does not cover a self-contained business area and that actually you need two separate BOs. It therefore makes sense in such cases to spear the related process components into two process components. There can however also be cases where a process component covers two BOs where one BO describes data that complements the data of the other BO.

Accessing Process Component Data

If the level of granularity of the data and the partitioning of the value chain process that is to be modelled is clarified in process components, then you can specify the access to this data in the modeling. There are two types of access:

The accesses are modeled by service interfaces and operations that access BOs either synchronously or asynchronously.

You derive the service interfaces and operations that are necessary for access from the access type. There are some standard variations for synchronous asynchronous access that cover the majority of use cases. For each variant SAP works with an interface pattern from which service interfaces, operations and message types are directly derived in the modeling and which are always modeled in the same way: