=Paper=
{{Paper
|id=Vol-2574/short5
|storemode=property
|title=e-GPS - The Need for an Enterprise Navigation System (short paper)
|pdfUrl=https://ceur-ws.org/Vol-2574/short5.pdf
|volume=Vol-2574
|authors=Hans-Jürgen Scheruhn,Mark von Rosing
|dblpUrl=https://dblp.org/rec/conf/vmbo/ScheruhnR20
}}
==e-GPS - The Need for an Enterprise Navigation System (short paper)==
https://ceur-ws.org/Vol-2574/short5.pdf
e-GPS - The need for an Enterprise Navigation System
Hans-Jürgen Scheruhn, Hochschule Harz, Forschungszentrum der SAP, SAP Next Gen Chapter,
Wernigerode, Germany
Mark von Rosing, Global University Alliance, Chateau Du Grand Perray, France
Key Words:
Enterprise Navigation, Enterprise GPS, eGPS, Navigation ontology, Modelling Navigation,
Architecture Navigation, Task Ontology.
Abstract
This paper discussed the need and proposes a layout for an enterprise navigation tool. It discusses how
organizations around the world define their direction based on strategies, but how they until now
haven’t used any navigation tools. Consequently, this paper focuses on the missing concepts
exemplifying the need for an Enterprise Navigation ontology with a detailed Enterprise Navigation
taxonomy, clearly defined layers, levels, decomposition and composition principles of object class
types, stereotypes and subtypes, as well as clear semantic relationships among the objects as well as
with the artefacts. It does so by firstly defining the requirements in terms of the scope, objective as
well as which challenges, issues and problems should the Enterprise GPS ontology as a Task
Ontology address. Secondly, we describe the integration and relationship between the Enterprise GPS
ontology with domain, core and foundational enterprise ontologies. Followed by the description of the
design components of the Enterprise GPS tool, this includes its layers, levels, objects, class types,
descriptors, shapes i.e. notations, attributes, and relations. Benefits of using an enterprise navigation
are being discussed. Which is followed by examples of artefact usage within the navigation tool
‘Enterprise GPS’. A holistic usage from different angles and different levels and layers of abstraction
are being illustrated. The authors describe the result of their work as a standard recognized by the
enterprise standard body LEADing Practice. The paper concludes with a discussion on the world wide
usage of the Enterprise GPS standard. We than conclude by discussing lessons learned by applying
and thereby testing the navigation tool in practice.
The need for an Enterprise Navigation System
The importance of using navigation concepts are not a new phenomenon, ocean/see maps and land
cards have been used for centuries. In the new digital age, navigation concepts are used nearly
everywhere from the plan, ship, automobile, smartphone to libraries, museums and government
buildings. They are used everywhere where manual mapping could be automated, direction-finding is
needed or even triangulation and course-plotting could be applied. Even though organizations in terms
of companies, societies and associations are among some of the most complex things that exist, the
concept of a navigation system has not been applied yet. Many companies still believe they can
navigate their direction and development without any navigation tools. With so many changing
aspects, from external forces, drivers and customers, to industrial and technology changes there is
now a greater need to provide a meaningful and well-described overview of the direction, provide
orientation, enable direction-finding, support course-plotting and/or define the innovation and/or
54
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0).
transformation route. Also, within the extended enterprise, which is the collaboration with its partners,
service suppliers, the wholesalers, retailers etc., and the attendant complexity, the need for well-
described navigation tool is apparent. Therefore, it is of critical importance for our frameworks,
methods, approaches and practices to incorporate a practical enterprise navigation tool. The discussed
mentioned gap of the need of an enterprise navigation system was firstly identified and recognized in
2010. The global development, which consisted of a team of practitioners and academics was led by
the Prof. Dr. Hans Juergen Scheruhn (Funk et al., 2010). When the gap was identified, the team
worked on various enterprise modelling, engineering and architecture concepts
Requirements to the Enterprise Navigation Ontology
Approaches to developing and engineering ontologies begins with defining an ontology's purpose and
requirements; this is in the form of questions that an ontology must be able to answer. We call this the
competency of the ontology. The competency questions are the basis for a rigorous characterization of
the information that the ontology is able to provide to the task (Gruninger and Fox 1994). Tasks such
as these can serve to drive the development of new ontologies and also to justify and characterize the
capabilities of existing ontologies (Gruninger, 1997). After the requirements have been identified,
both in terms of the scope, objective as well as which challenges, issues and problems should the
ontology address. The next phase in the development of an ontology, is to outline its objects, types of
objects, descriptors, shapes i.e. notations, attributes, and relations. Followed by testing the ontology in
practice. This is done by applying the enterprise navigation ontology in a real-world engineering,
modelling and or architecture situations. In this section, we will discuss the requirements in terms of
scope & objectives, issues and views the enterprise navigation ontology should address in its
completeness. In order to elaborate on the scope and focus of the enterprise navigation ontology, we
will describe the various concepts of the navigation scheme in terms of layers and levels used and
then specify how they are used in the context of the enterprise navigation ontology. This permits the
reader to comprehend the explicit scope and focus explanation.
Enterprise Navigation Scope and Objectives
The idea of Prof. Dr. Scheruhn was that an Enterprise Navigator concepts, like a traditional
navigation/GPS, should allow for multiple zoom factors, from the various enterprise layers to the
enterprise levels i.e. the corporate level, the department levels, workplace levels to the data or
document level (Scheruhn et al., 2015). An Enterprise navigation concepts should also combine
different needed perspectives that are needed to run a business successfully. As an analogy to a car
navigation system, a google map navigation combines more than traditional car navigation views, for
example, also the train, aircraft, ship, train connections etc., and how they could interact is reflected.
As in most navigation systems we need a horizontal and vertical triangulation, direction-finding
course-plotting and routing system. Von Rosing and Laurier (2015), have identified that independent
of size or industry organizations have a common underlying structure. And as the structures and
context in the organizations should be considered as a whole (Rosing, Urquhart, Zachman, 2015) the
following enterprise layers have been identified to exist:
• Business
• Information
• Technology
The organisation thus has to align its way of thinking with its way of working within and across all
these perspectives. These Layers are a part of the enterprise ontology (von Rosing, Laurier 2015) The
mentioned enterprise ontology is the central and essential component, which sets the standard of how
to work with the business, information and technology layers as well as how these are related to level
concepts.
55
Navigation Scheme used within the Enterprise Navigation Ontology
The enterprise ontology has identified a standard classification scheme which is used as the basis in
the Core Reference Ontology, it divides any organization into three broad categories or layers. This
research shows that a robust and meaningful distinction of the components of an enterprise is needed
to separate the concerns of the business between those of the enabling software and those of the
underlying technology (von Scheel & von Rosing, 2016).
Contains the business objects needed to capture and describe the nature,
Business Layer form, and relationships of the business. This layer contains roles related
Ontology to business aspects such as purpose and goal (value) competencies,
services, as well as processes.
Contains the objects used to describe the structure and behaviour of
major software systems and how these objects interact with each other,
Information Layer both within the Information Layer Ontology and across the Business
Ontology Layer Ontology and the Technology Layer Ontology. The Information
Layer Ontology contains roles related to applications and date, and their
related behaviour.
Contains the objects used to describe the structure and connections of
the enabling technology of the software applications, and how these
Technology Layer objects interact with each other, both within the Technology Layer
Ontology Ontology and across the information and the Business Layer
Ontologies. In this layer, we find roles related to technology, i.e.
platform and infrastructure.
Figure 1 – Overview of the Core Reference Ontology structures
The top layer, the Business Layer Ontology, establishes the connections of the enterprise to the
environment through the identification of objects that describe the purpose and goal, and therefore
points both to the source of value and to concerns about the trade-offs necessary to optimize the
ability to pursue this value. It further identifies the competencies needed to execute the functions,
processes, service etc., within the environment. These are then used, in conjunction with business
functions and other primitives, to organize and aid in the decomposition and organization of the
logical view and physical implementation of the business and of its work. At the core of the Business
Layer Ontology are two other groups containing the objects related to business services, and
processes.
Within the Information Layer Ontology, we see the objects that comprise the description of either the
application structure and behaviour or those related to the structure of the data, which exist to enable
the work identified within the Business Layer Ontology.
Finally, within the Technology Layer Ontology there exists two other groups of objects, one of which
contains the objects that comprise the platform centric objects and the other related to the
infrastructure that hosts the application components and provides the resources necessary for them to
function in the manner needed by the business.
56
What makes the enterprise ontology concept different from other, more traditional enterprise
frameworks, methods and approaches, is the fact that it does not only work in domains or a specific
subject, but in layers. The ability to work within and across the layers, and thus simultaneously work
within multiple domains and subjects effortlessly, integrates semantically the right objects across the
different silos, thereby both enabling enterprise modelling, engineering and architecture principles.
(Zachman, 2011; von Rosing, Zachman, von
Scheel, 2015) The advantage of distinguishing
between layers and groups, over the vertical
domains that are typically applied to understand or
describe an enterprise, is that this allows for the
separation of concerns within the total system.
This then makes it practical to work across the
layers, based on the semantic relationships defined
the foundational ontology. It furthermore as
defined as a systems architecture requirement in
ISO 42010, distinguishes the concerns of the
stakeholders that are involved with the specific
objects, the creation of value, the organization and
execution of work, and the identification of the
resources needed to perform that work. The most
common identified structures and context in the
organizations are as illustrated in figure 2 spread
across the business, information and technology layers. Figure 2: Overview of
the enterprise layers
The mentioned enterprise layers and sublayers are an abstraction that represents and considers the
enterprise as a whole (Rosing, Urquhart, Zachman, 2015). For example, a policy, act, regulation or
even a strategy is a part of the business layer, while the application systems and data aspects is a part
of the Information layer. Each of the subjects can now be broken down i.e. decomposed into various
levels of depth. Depending on the level of insight needed. The layered concept can both be used for
enterprise architecture, as well as enterprise engineering and modelling concept. In Enterprise
engineering and modelling the decomposition levels are done by levels (Polovina, Etzel, von Rosing,
2019). For example, as illustrated in table 1, if we were to decompose i.e. break down the Business
Process levels, we would find the following level types Process Area (level 1), Process Group (level
2), Business Process (level 3), Process Step (level 4) and Process Activity (level 5).
Process Decomposition
Levels Name of Level Description of level
Process Area
Level 1 The highest level of an abstract categorization of processes.
(categorization)
Process Group
Level 2 A categorization and collection of processes into common groups.
(categorization)
A set of structured activities or tasks with logical behaviour that produce a specific service or
Level 3 Business Process
product.
A conceptual set of behaviours bound by the scope of a process which - each time it is
executed - leads to a single change of inputs (form or state) into a single specified output.
Level 4 Process Step Each process step is a unit of work normally performed within the constraints of a set of rules
by one or more actors in a role that is engaged in changing the state of one or more
resources or enterprise objects to create a single desired output.
A part of the actual physical work system which specifies how to complete the change in the
form or state of an input, oversee or even achieve the completion of an interaction with other
Level 5 Process Activity
actors which results in the making of a decision based on knowledge, judgment, experience,
and instinct.
Table 1: Example of. Enterprise Engineering and Modelling levels: Business Process levels
57
It is not only in business process that the decomposition root is by levels, this is also so in other
enterprise modelling concepts the same, such as in value, competency, service, information
systems/applications, data, platform or infrastructure the same case. While in enterprise engineering
and systems engineering the principles are a bit more advanced. The decomposition levels are the
same, they however are based on classification principles (assemble by order). In engineering
should/could be based on
• Modularity: Process of dividing a system into modules of a relatively uniform size
• Modules simplify system design
• Coupling: Subsystems that are dependent upon each other are coupled
• Cohesion: Extent to which a subsystem performs a single function
These could be after need be called a system (level 1), sub-system (level 2), sub-sub system (level 3),
etc. But as illustrated in figure 4, the principle remains the same.
Figure 3: Overview with example of the most common enterprise modelling and engineering levels.
The Enterprise Navigation Scheme for Enterprise Engineering, Modelling and Architecture
From the before mentioned enterprise navigation scheme in terms of layers and levels, we can
therefore conclude that a suggested enterprise engineering and modelling navigation system for
horizontal and vertical triangulation, direction-finding course-plotting and routing system could be as
suggested in figure 4 the enterprise layers and the levels.
Class Type Stereotype Type Sub-Type
Categorization
Fig. 4. The Enterprise Navigation System with the relevant Layers and Levels
58
The process of breaking down a system into various levels (Decomposition/Composition) has the
benefit of joining and combining a subject/system together into bigger/smaller grouped components.
It allows the practitioner to:
• Focus on one subject, system or area at a time
• Break a system into small, manageable subsystems (decomposition)
• Combine a system together into bigger grouped components (Composition)
• Concentrate on component pertinent to one group of users
• Build different components at independent times
While enterprise architecture also uses the above decomposition and composition concept, in
enterprise architecture (Polovina, von Rosing, 2018) they also have ‘architectural levels’ which are
based on views: these would be the contextual, conceptual, logical and physical levels and thereby
views. We can therefore conclude that a suggested enterprise architecture navigation system for
horizontal and vertical triangulation, direction-finding course-plotting and routing system for
enterprise architecture could be as suggested in figure 5 the architectural layers and the architectural
levels/views.
Fig. 5. The Enterprise Architecture Navigation System with the architectural relevant Layers and
Levels
The SAP Enterprise Global Positioning System (eGPS)
The implementation of the enterprise navigation system referring Peffers et al., (2008) into a specific
SAP explicit solution is called the SAP Global Positioning System (eGPS) and today supports 1000 of
users around the world complements the described existing teaching materials (Scheruhn et al., 2019).
The eGPS is the basis for horizontal or vertical navigation between different information views
(layers) of a company and the hierarchical levels of the information models or information objects
contained in the information system. eGPS is based on existing enterprise ontology (von Rosing,
Laurier, 2015) standards and tools for information object modeling as well as for the automated
import and export of these information objects into standard enterprise software. After nine years of
development work, eGPS now has a considerable spread in academic and school teaching and the first
industrial projects show its applicability also in that context. Practitioners can profit from EGPS
because it is fully integrated with and extends important IT management software products such as
SAP Solution Manager. This software supports the phases of process execution as well as process
implementation and process monitoring. Please note that in Enterprise GPS, they are put on the
59
vertical perspective as SAP level decomposition is in focus. As illustrated in figure 6, the eGPS levels
of are increasing from top to bottom. The first level are the organizational perspectives, whereas the
second level are the departmental aspects. Level three forms the logical workplace level (Scheruhn et
al., 2015). The fourth level works with the physical level. In fact, the fourth level should contain the
attribute structure of all media or documents involved (such as measurement protocols, certificates,
contracts, and general business documents), which regulate the data input/output process.
Figure 6 EGPS Framework Map
For the definition of the layers, the enterprise ontology (Rosing et al., 2015) was used. Accordingly,
the Enterprise GPS Framework consists of eight different layers. Each of the eight layers is always
assigned exactly four identical levels. All information object types defined in the framework are
always assigned to a combination of these. The model types that comprise the information object
types can also be assigned to several combinations (several levels). This is referred to as a location in
the EGPS Map (figure 6). This means that the layer and the level of the model types must always be
the same as that of the object types contained. The object types are connected to each other by vertical
(level) or horizontal (layer) relations. These relations are the basis for the so-called horizontal or
vertical navigation between different model types. A so-called vertical navigation takes place between
the model types at different levels. You can branch to several lower-level model types or aggregate
them into several higher-level model types. Both are always process-oriented in eGPS. In this case,
the object types are subordinate or superior to other object types (or the same object types) at different
levels via relations (object types from different levels or layers can be equated). Vertical navigation is
required whenever the vertical relationships between object types extend beyond a model. The same
applies to the horizontal relationship between the object types. These can also be mapped in one or
more model types and can be reached by the user through horizontal navigation between different
layers.
The eGPS Content for GBI/SAP currently describes a large part of the SAP University Alliance case
studies for SAP ERP (incl. SAP S/4 HANA) based on the model company GBI with the focus on the
instantiation of model and object types. By adapting the GBI organizational structure to the EGPS
competency layer, an automated transfer of the remaining views to already mentioned demo
companies such as IDES or others is possible.
The eGPS Navigator enables the user to automatically move from one model (type) to another in
order to illustrate the relations between the contained objects (types). Essential components are an
instantiation of the eGPS navigation (right grey dotted-line frame) and the EGPS Map (left grey
dotted-line frame).
60
Conclusions
This paper focuses on the missing concepts exemplifying the need for an enterprise navigation
ontology, with clearly defined enterprise layers and levels. It did so by firstly defining the
requirements in terms of the scope, objective as well as which challenges, issues and problems should
the enterprise navigation ontology as a Task ontology address. Secondly we describe the enterprise
modelling and engineering navigation system as well as enterprise architecture navigation system
ontology. Followed by the description of the layered and level components of the SAP eGPS
navigation tool. We did this all in introducing a fully integrated enterprise navigation set relevant for
various modelling, engineering, architecture as well as ERP (SAP) systems. Therefore, while this
paper should be seen and used as a overview description of how an enterprise navigation system could
eb structured, it does provide the foundational setup and a relationship to the enterprise ontology. This
paper therefore attempts to build a basis of a structured way of thinking. This paper endeavoured to
provide a standardized terminology, build common understanding, and make available the enterprise
navigation concept as well as illustrate the right contextual categorization and classification. It helps
to reduce and/or, if needed, enhance complexity of enterprise modelling, engineering and architecture
principles.
References
Funk, B., Niemeyer, P., Papenfuß, D., Scheruhn, H.-J., Weidner, S.(2010): Modellierung und
Implementierung eines Vertriebsprozesses in verteilten Systemen, Verlag Dr. Kovac
Hamburg
M. Gruninger, Integrated Ontologies for Enterprise Modelling (1997), Enterprise Engineering and
Integration, Part of the series Research Reports Esprit pp 368-377, Springer, October 1997
Polovina, S., Scheruhn, H.-J., Weidner, S. and Rosing, M. von (2016). "Highlighting the Gaps in
Enterprise Systems Models by Interoperating CGs and FCA", In: Proceedings of the Fifth
Conceptual Structures Tools & Interoperability Workshop (CSTIW). Annecy, France, pp. 46–
54.
Polovina, S., von Rosing, M., (2018). Enhancing the Practice of Enterprise Architecture Modelling
through Layers. Springer
Polovina, S., von Rosing, M., Etzel, E., (2019) Enhancing Layered Enterprise Architecture,
Development through Conceptual Structures, Springer
Scheruhn, H.-J., Rosing, M. von and Fallon, R.L. (2015). Information Modeling and Process
Modeling, In: The Complete Business Process Handbook: Body of Knowledge from Process
Modeling to BPM. Ed. by M. von Rosing, A.-W. Scheer, and H. von Scheel. pp. 511–550.
Scheruhn, Hans-Jürgen; Hintsch, Johannes; Bayramli, Elnur (2019). Der aktuelle Stand von
Enterprise GPS. In Karin Gräslund, Karin; Kilian, Dietmar; Redlein, Alexander. Proceedings
SAP Academic User Group Meeting 2019
http://repositum.tuwien.ac.at/obvutwoa/nav/classification/4371032
von Rosing, M., & Laurier, W. (2015). An Introduction to the Business Ontology, International
Journal of Conceptual Structures and Smart Applications (IJCSSA), 3(1), 20-41
von Rosing, M., & von Scheel, H. (2016) Using the Business Ontology to develop Enterprise
Standards, International Journal of Conceptual Structures and Smart Applications, 4(1), 48
von Rosing, M., Urquhart, B., & Zachman, J. A. (2015). Using a Business Ontology for Structuring
Artefacts: Example - Northern Health. International Journal of Conceptual Structures and
Smart Applications (IJCSSA), 3(1), 42-85. doi: 10.4018/ijcssa.2015010103
Wieringa, R., de Jonge, W., Spruit, P. (1995) Using dynamic classes and role classes to model object
migration, Theory and Practice of Object Systems 1(1) 61-83
Zachman, J.P. (2011). The Zachman Framework Evolution. Technical Report
https://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution.
Zachman International, Inc.
61