![](bg6.png)
graphical user interface, the so called SAPGui. This forms our first service on the root
service map. We then continue to identify service which lay also on the root map.
After this identification is completed we dive deeper into our system which actually
means we start identifying the service from the first network layer. The next layer is
the first application layer. It contains the so called ABAP dispatcher, which is
responsible for distributing the work over all available work processes in the SAP
system. These mentioned work processes form our second application layer. As a
matter of course, these two application layers must contain all parts of the application
server of the SAP system. After these two application layers, we face a network layer
again. Afterwards we have two different database layers. The first one contains
something like user kernel tasks and the second on contains buffers / caches. In the
last layer we consider the database storage.
Why the use of such a comprehensive architecture model is advantageous can be
shown by a simple example. Operating numerous ERP systems in an operating centre
is difficult and sometimes tricky. Especially when end-users face performance
problems there are several different starting points to search for a bottleneck as there
are several different layers in an ERP system. Because of this complexity, identifying
the bottleneck can be very time-consuming. The problem stems not only from the
complexity of the ERP system, it also stems from the huge number of different,
interconnected, internal layers (and therefore services) in the ERP system. So, if
facing a performance problem it is possible that the bottleneck is not inside the ERP
system but in the database storage or in the network interface controller. Using the
architecture model allows us to identify all related services. Of course knowing each
service does not mean to simulate each service.
After we built up the main service maps we will reveal the interdependencies by
building up a more complex ERP system service map containing not only the services
but also the interdependencies between them. Revealing and describing the internal
dependencies is inevitable for simulating the complete system. Reviewing the first
figure 2 we see that service B is linked to nearly all remaining services included in the
example. We want to know what type of interdependencies exist between the services
and in which way the impact will cause side-effects when changing the service to B’.
To specify the impact and side-effects, we need to identify metric and indicators,
describing the current system status. These indicators have to be measured and
compared after the change. The properties of the indicators and the metric depend on
the type of dependencies. In complex ERP systems there are several different types of
dependencies possible. In this paper we will focus on the impact of the dependencies
to the performance of the overall system. The task to determine the overall system
performance is commonly known as collecting benchmarks [4]. Comparing
benchmarks of the systems before and after changing single services will enable us to
investigate the internal dependencies of the system [5].
Hence, it is necessary to determine all appropriate performance factors of the ERP
system. We will approach this task with a theoretical performance measurement
framework. This framework will contain important performance factors which derive
from the type of ERP system and its architecture as well as from the insights provided
by the service map. The performance factors derive from the type of ERP system, the
underlying hardware, underlying operating system and network type [6]. The
framework will provide for a guideline for testing and monitoring [7]. Moreover, it
165