e-GPS - The need for an Enterprise Navigation System

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 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 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 welldescribed 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.

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) .

Business Layer

Ontology

Information Layer

Ontology

Technology Layer

Ontology

Contains the business objects needed to capture and describe the nature, form, and relationships of the business. This layer contains roles related 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, both within the Information Layer Ontology and across the Business 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 objects interact with each other, both within the Technology Layer Ontology and across the information and the Business Layer Ontologies. In this layer, we find roles related to technology, i.e.

platform and infrastructure. 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. 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 Level 1 (PcraotceegsosriAzaretiaon) The highest level of an abstract categorization of processes.

Level 2 (PcraotceegsosriGzarotiuopn) A categorization and collection of processes into common groups.

Level 3 Business Process pArsoedtuocft.structured activities or tasks with logical behaviour that produce a specific service or 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 Level 5 Process Activity faocrtmorsorwsht aicteh oref saunltisnipnutth,oevmeraskeinegoorfeavednecaicshioienvbeatsheedcoonmkpnleotwiolnedogf ea,nj uindtgemraecntito,nexwpitehrioetnhceer, and instinct.

Table 1: Example of. Enterprise Engineering and Modelling levels: Business Process levels 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. 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 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. 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 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. 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). 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.