Keywords

1 Introduction

As companies must develop agile mechanisms to adapt to ever-changing conditions within their business ecosystem, business ecosystem models (BEM) have gained relevance [1]. Applying BEM can support enterprises to model themselves within their business ecosystems and thus applying an outside-in approach of enterprise modeling.

In addition to suppliers, customers, business partners, and competitors, a business ecosystem comprises innovative start-ups and companies for potential future collaboration as well. To model a company’s ecosystem, it is thus important to continuously analyze the market by scanning news feeds, social media, start-up databases, companies web pages, etc. Besides the variety of data sources, the business ecosystem affects various stakeholders of different business units (e.g. the legal, market analysis, customer department, etc.). Thus, modeling business ecosystem requires the collaboration between different stakeholders through a data-intensive process. Overall, as knowledge gained from the business ecosystem modeling affects the strategic development of an enterprise, the modeling process must conclude by providing relevant information to decision-makers creating an added value.

To address these challenges, visual decision support and visual analytic systems and approaches have been proposed and evaluated (cf., [2,3,4,5]), ensuring that visualizing BEM supports stakeholders and decision-makers applying the “wide lens” [6] and making informed decisions. However, these approaches don’t address new challenges that have emerged in the domain of information systems to reduce the time to execute the business ecosystem modeling process. First, empowering end-users (i.e., users without programming skills) to adapt not only the BEM but also the visualizations [7]. Second, reducing the complexity of the User Interface (UI) for such systems, which requires UIs with a minimal feature-set and an optimal layout based on the roles of the system [8]. In this paper, we address these challenges by introducing a tool consisting of multiple UIs tailoring different stakeholders’ needs to understand the business ecosystems. We refer to such a visual analytic system as a “Business Ecosystem Explorer” (BEEx). For the development of the BEEx, we followed Hevner’s Design Science approach [9].

The here presented prototype is applied to the context of connected mobility (CM). CM describes the interconnectedness between means of transportation, especially cars, traffic systems and infrastructure [10] due to advancing digitization of mobility, and exhibits a currently emerging business ecosystem as actors with technology-related business models, such as Google and Apple, challenge the established players [11, 12].

The main contribution of this paper is adapting a data science approach to address variety and velocity of BEM’s data, through the implementation of a prototype tool, in the context of the project TUM Living Lab Connected Mobility (TUM LLCM)Footnote 1, which empowers end-users to manage BEM by providing role-based UIs.

2 The Hybrid Wiki Approach

The development of an information system that provides a collaborative environment supporting the evolution of data models (e.g., BEM and visualizations) at runtime by different end-users (i.e., users without programming knowledge or skills) was addressed in [21] by introducing the Hybrid Wiki approach. This approach has been used in different use cases and domains such as Enterprise Architecture Management [13] and Collaborative Product Development [14]. To instantiate the BEM we used the updated Hybrid Wiki metamodel as presented in [15].

The Hybrid Wiki metamodel contains the following model building blocks: Workspace, Entity, EntityType, Attribute, and AttributeDefinition. These concepts structure the model inside a Workspace and capture its current snapshot in a data-driven process (i.e., bottom-up process). An entity contains a collection of attributes, and the attributes are stored as a key-value pair. The attributes have a name and can store multiple values of different types, for example, strings or references to other Entities. The user can create an attribute at run-time to capture structured information about an entity. An EntityType allows users to refer to a collection of similar entities, e.g., organizations, persons, etc. The EntityType consists of multiple AttributeDefinitions, which in turn contain multiple data validators.

3 Modeling the Connected Mobility Bussines Ecosystems

For modeling the connected mobility business ecosystem, we adapted the four step data science approach proposed in [16] and encoded the data in each step using the Hybrid Wiki metamodel. The connected mobility BEM is comprised of three EntityTypes: organizations, relations, and visualizations, which are enhanced with data in the process:

First, the industry structure is determined using trade publications. Categories, of both companies and their interrelations, are identified and each stored as one AttributeType. For companies, these are automotive OEMS, parts supplier, public transportation, technology companies, platform and connectivity provider, new competitors of affected industries, and public institution. As relation types, we identified cooperation, (partially) ownership, funding, negotiation, and supply. In the next step, relevant companies, describing attributes and their relations to other entities of the ecosystem are collected. AttributeDefinitions such as company name, abbreviation, logo, URL, short description, headquarter, CEO, category, and legal form are gathered for each identified company using companies’ web pages, newsfeed, social media, etc. Third, the BEM is represented using an explicit visual model language. Each visualization has two elements: the first element is the link between the data model and the visualizations, stored in an AttributedDefintion for each visualization. The second element is the specification of the visualizations, which is described using the visual encodings of the visual grammar VegaFootnote 2, as presented and described in [17].

Finally, the collected information are visualized, analyzed, and interpreted. Figure 1 shows the visualizations implemented in the connected mobility BEEx. The visualizations can support stakeholders analyzing the ecosystem. For example, the modified ego-network can be used to understand which types of companies are necessary to provide a mobility service, by visualizing the mobility services in the center and the mobility service providers – offering the mobility service solutions with a variety of different relations – on the outside circle. Additionally, this visualization allows the interpretation which companies already address the growing demand for mobility as a service providing mobility services, thereby acting innovatively.

Fig. 1.
figure 1

BEEx Visualizations used in the connected mobility BEM

Full size image

4 The Connected Mobility Business Ecosystem Explorer

The development and maintaining of an information system that provides a collaborative environment supporting the evolution of both the model and its instances at runtime by stakeholders and ecosystem experts (i.e., the Hybrid Wiki approach) can be considered a difficult task. This process involves nontrivial design decisions and a reference architecture of the connected mobility BEEx.

4.1 Design Considerations

Four main requirements drive the design considerations. First, the BEEx must support semi-structured and non-structured data (i.e., data variety). Second, the end-users should be able to modify the BEM and visualizations at run-time (i.e., without the need to recompile the system). Third, the BEEx must provide role-based UIs. Finally, the BEEx must be supported by WEB-based technologies. In this paper, we describe the decisions we made regarding the following concerns: development process, architecture style, and visualizations technology

We followed a model-driven development (MDD) process, which is used on the Hybrid Wiki approach. This decision ensures that the system can handle different types of data, thereby the CM BEEx can address the data variety challenge in the associated scenario. However, this approach increases the complexity of the system [15]. Therefore, we select the resource-oriented architecture (ROA) as architecture style. The ROA enables the communication between the different components using defined resources encoded in JSON format, which increases the performance in the communication of WEB-based systems (i.e. using the HTTP protocol) [18]. Thereby, the complexity of the system that supports the Hybrid Wiki approach can be encapsulated. Hence, each component in the system utilizes the optimal resources/features that guarantee the role-based UI.

The visualizations technology selected was based on the visual grammar Vega. Instead of using an imperative approach (e.g. D3JSFootnote 3), we select a declarative approach, which guarantees the description of the visualization using a common visual grammar. This decision ensures that end-users can create visualizations, and bind them to the current BEM at run-time. Additionally, this approach addresses the data velocity challenge since it allows the end-users to continuously adapt the BEM and the visualizations.

4.2 Architecture

The BEEx architecture is shown in Fig. 2. The BEEx architecture ensures a clear separation between execution and development environments, and it is composed of four main components. The first component is the BEEx Modeler, which is the core component of the modeling environment, allowing the BE Modeler to create/update/delete the BEM and the visualizations. The next component is the BEEx Client, which is the core component of the execution environment, and it allows the BE User to interact with all the visualizations, providing only read access to the Models Repository through the Query Service. The Model Repository component stores the BEM and the visualizations in JSON format, which are exposes using a RESTful service. Finally, the Query Service component is responsible for extracting the information from the Models Repository, which is required in each environment using the stated security constraints.

Fig. 2.
figure 2

BEEx architecture with main components.

Full size image

4.3 First Evaluation of the BEEx Prototype

For the evaluation process, the BEEx is hosted in a TUM University server under the following addresses, the execution environment https://ecosystem-explorer.in.tum.de, and the modeling environment https://vmmatthes17.in.tum.de.

Initially, we conducted nine interviews in semi-structured form with nine different companies within two months, following [19]. We aimed at a balance between receiving some quantifiable evaluation but also enabling interviewees to vary the depth of answer depending on own capability and willingness [20]. The focus of these interviews was to receive feedback regarding the CM BEM. A sample of attributes was presented, as well as some types of relations and a visualization of the combination of entities through relations in the form of a force-directed layout. All interviewees stated that the BEM supported them in mastering ecosystem related tasks and that their knowledge of the connected mobility ecosystem was increased. Some suggested immediately additional scenarios, for example, the patent management in the pharmaceutical industry.

We used the interviews’ results to update the connected mobility BEEx. As a next step, we conducted three in-depth interviews with additional three companies. To obtain a wider range of opinions, we selected three companies of different fields of activity. Namely, an automotive OEM, a publicly funded non-research institution and a software company with main business area addressing connected mobility, all actively modeling their business ecosystem. All stated their perceived limitations with the current in use tools. Additionally, two companies confirmed that different stakeholders within in the enterprise have different viewpoints towards the enterprise’s business ecosystem. As a limiting factor, it should be noticed that the presented BEEx prototype required further developed within the conduction of these in-depth interviews. Nevertheless, all companies agreed that the prototype foster the understanding of the connected mobility ecosystem and two continued that it would be interesting to use such a tool within in their enterprise to collaboratively manage the business ecosystem evolution.

5 Conclusions

In this paper, we adapted an existing data-science approach and introduced a tool for supporting the BEM process. The design decisions and the architecture ensure that end-users can address variety and velocity of BEM’s data in the context of the connected mobility business ecosystem. The BEEx provides role-based UIs, which empowering end-users to manage the BEMs. The first BEEx evaluation indicates that the proposed approach and tool conforms to the enterprise tasks for BEM. However, further evaluation is required to evaluate the potential of the BEEx on supporting different stakeholders in completing different BEM related tasks.