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 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 lead by the Prof. Dr. Hans Juergen Scheruhn. When the gap was identified, the team worked on various enterprise modelling, engineering and architecture concepts.

You can download the full pdf article here.

 

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

 

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 1 the enterprise layers and the levels.

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 2 the architectural layers and the architectural levels/views.

 

Specific Enterprise Navigation solutions: The SAP eGPS

There are various practical implementation of the enterprise navigation concept, the most applied one is an SAP specific explicit solution, called the SAP Global Positioning System (eGPS). Today it already used by the SAP Competency Center within the SAP University Alliance. It supports more than 1000 of users around the world, where it complements and supports the enterprise navigation of various SAP models and concepts.

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 both business, information and data objects modelling and architecture as well as for the automated import and export of these business, information and data objects into standard enterprise software. After nine years of development work, eGPS now has a considerable spread in academic theory, industry instance testing as well as cross the globe university teaching (Scheruhn et al., 2016). According to Laurier and von Rosing (2019) it would meet the requirements for the Academia and Industry Collaboration, where it both supports the academic research method as well as the Industry Design Method.

The first ten industrial projects also show its applicability also in that context of private as well as public sector. 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 notion of both balance scorecard, reporting, KPI performance maps as well as process execution and 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 3, 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 3). 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).

 

Research Team

The Enterprise Architecture contacts are:

Research Leader:
Prof. Dr. Hans-Jürgen Scheruhn
Advisory Board Member
Head of Enterprise Navigation system Research, Global University Alliance

Research Co-Leader:
Professor Mark von Rosing
ISO 42010 Development Member
Head of the Global University Alliance

OMG Coordinators:
Fred Cummins
OMG, Business Modeling & Integration Task Force, Chairman
OMG Business Architecture Special Interest Group, Co-Chair

Prof. Antonio Margarito
University of Salento
OMG Business Architecture Special Interest Group: OMG standards that are BA relevant

Prof. Maxim Arzumanyan
Business Architecture Roles
OMG Academia & Research Working Group, Co-Chair
Global University Alliance, Co-Chair

Prof. Sjir Nijssen
PNA Group
OMG Academia & Research Working Group, member
Global University Alliance, member

Thierry Boissay
OMG Business Architecture Special Interest Group: Syntax Analysis

Henk DeMan
OMG Business Architecture Special Interest Group: Value Model
OMG VDML Chairman

Denis Gagne
OMG Business Architecture Special Interest Group: Case Modelling
OMG Case Management Model Notations, Chairman

Gagan Saxena
OMG Business Architecture Special Interest Group: Decision Model and Notation
OMG Decision Model and Notation SIG
Decision Management Solutions

NATO Coordinators:
Johan Goossens
NATO Allied Command Transformation
Branch Head, Technology & Human Factors

Krzysztof Skurzak
NATO C3 Architecture & Design

Peter Woudsma
NATO C3 Technology Innovation

UNESCO Coordinator:
Dr. Selin N. Şenocak
UNESCO Chair Holder
Cultural Diplomacy, Governance and Education
Director, Occidental Studies Applied Research Center
Political Sciences and International Relations Faculty Member

CSIR Coordinator:
Rentia Barnard
Research Institute CSIR, Enterprise Architect Research Group Leader

John A. Zachman
Inventor and Father of Enterprise Architecture, Zachman International

The team involved in this work are among others the following academics, researchers and analysts:

• • Most common Enterprise Navigaton strategies applied, Jamie Caine, Jamaica
  • Enterprise Navigaton Ontology (meta objects), Prof. Wim Laurier
  • Enterprise NavigatonSemantics (relations and rules), Prof. Simon Polovina
  • Enterprise Navigaton patterns, methods and approaches, Prof. Mark von Rosing
  • Typical Enterprise Navigaton models, Prof. Hans Scheruhn
  • Enterprise Navigaton KPIs, Georg Etzel
  • Enterprise Navigaton Measurements & Reporting, Ulrik Foldager
  • Enterprise Navigaton Roles, Maria Hove
  • Enterprise Navigaton Viewpoints, Maxim Arzumanyan