Digital business ecosystems (DBEs) have attracted significant scientific research in the field of business models. In this context, the need to better integrate the emerging diferent levels of DBE business models was observed. Obvious connections between DBE-level and company-level are easy to discover, for example between value proposition on DBE-level and value creation on company-level, but other equally important connections require better explication. For such connections, modeling the business models of all DBE participants in a formalized modeling language would be useful, as the resulting machine-readable models could be used for detecting and visualizing such connections. This research introduces a metamodel designed to support an integrated view of business models, addressing some of the complexities and ambiguities in current frameworks. The implementation of this metamodel in Ado.xx is a step to prove the practicability and validity.
Digital business ecosystems (DBEs) have attracted significant scientific research over the past years. DBE
are dynamic networks of organizations, people, and digital technologies that collaborate and compete
through shared platforms to create and exchange value [
While the research on platform-based business models has clear links to business model research in general, we observed a need to better integrate the emerging diferent levels of business models. On the DBE level, several techniques have been proposed for identifying relevant ecosystem roles, their cooperation, value proposition, and value delivery approaches. Similarly, on the layer of the individual ecosystem participants, i.e., on the company level, approaches for modeling the individual business models exist. The obvious connections between DBE-level and company-level are easy to discover and document. That the value creation model on company level is interconnected with with value proposition required on DBE-level is one example of an obvious connection. However, many equally important connections, like the dependency of several DBE participants on the same supplier or partner outside the DBE, are not obvious. For such connections, modeling the business models of all DBE participants in a formalized modeling language would be useful, as the resulting machine-readable models could be used for detecting and visualizing such connections.
Using a DBE from the maritime sector as motivation and example, the aim of this paper is to contribute to research in this field by establishing the need for linking business model levels in DBE, proposing a metamodel to formalize modeling of business models, and applying this metamodel in an application ifeld. The paper is structured as follows: Section 2 summarizes relevant background and related work from DBE and business model research. Section 3 briefly presents the research method applied. Section 4 presents the case study motivating our research. Section 5 proposes the metamodel to formalize modeling of business models. In section 5.2 the proposed metamodel is applied in the case study. Section 6 summarizes the work and identifies required future research.
The research question for this paper is: "In the context of modeling business models, how can the approach of Wirtz be translated into a metamodel suitable for implementing a modeling tool?"
There are diferent streams of research regarding platforms, ecosystems and business models. The most
important issues are laid out by de Reuver et al. [
A DBE can be denfied as "a socio-technical environment of individuals, organisations and digital
technologies with collaborative and competitive relationships to co-create value through shared digital
platforms." [
Research on digital business ecosystems (DBEs) is multidisciplinary, combining insights from
information systems, strategic management, innovation, and economics. It has evolved rapidly over the past
two decades, reflecting the growing importance of platform-based and digitally interconnected business
models. Much work focused on defining DBEs and understanding their structure. Some research
streams examined how digital platforms enable collaboration, competition, and co-innovation among
diverse stakeholders, including firms, developers, users, and regulators [
Technological enablers like cloud computing, IoT, AI, and blockchain have received increasing attention for their role in facilitating scalability, connectivity, and trust within ecosystems. More recently, scholars have investigated the challenges DBEs pose, including platform monopolies, data ownership, resilience to disruption, and regulatory concerns. Research continues to expand, with growing interest in sustainability, digital transformation, and ecosystem evolution, reflecting the central role DBEs play in the modern digital economy.
Business model research recently showed two larger groups of scholars: one stream of literature focuses
on the activities that are performed in a business to support value, for example Gordijn[
The incorporation of the strategic layer is, in essence, what leads to the ”integrated” view of business models. In that context it makes sense to follow the definition of a business model of Wirtz: ”A business model is a simplified and aggregated representation of the relevant activities of a company. It describes how marketable information, products and/or services are generated by means of a company’s value-added component. In addition to the architecture of value creation, strategic as well as customer and market components are considered in order to realize the overriding objective of generating and preserving a competitive advantage.”[12](p.81).
The strategy model defines the strategic business areas of the company and the long-term and medium-term goals in the business areas, including the activities to achieve them. The resource model identifies core assets and competences, which are important for value creation. Core assets are companyspecific, are dificult for competitors to develop or imitate and are of great importance for the value creation process. Similarly, core competences are company-specific, central to the value proposition and dificult for competitors to acquire or develop. The network model defines the most important strategic partners of the company. The market ofer model structures the existing market and competitive situation, defines the company’s focus and identifies potentially competing business models. The customer model defines which value propositions (i.e. products, services or combinations thereof) are ofered to which combinations are ofered to which customer groups in which market segments. This also includes diferentiation criteria and utilisation scenarios for the products and/or services ofered. The revenue model structures the cash flows and defines their significance. It shows how the value creation for the company can be monetised. The value creation model defines how the input factors (e.g. goods or services) are combined and transformed into value oferings (e.g. products and/or services) of the company.
Furthermore, the work of Schallmo on business model levels is relevant for our research. Schallmo proposes two diferent levels with in total five sub-levels [ 13]: the two levels are the generic and the specific level. The generic level can be divided into the sub-levels abstract level, which is relevant for business models independent of a specific industry, and the industry level, which is tailored to a defined industry. The generic level is not meant for companies; companies can apply the specific level. It separates into three sub-levels: the corporate level, the business unit level, and the product and service level. Relevant for our work is the general concept of thinking in diferent levels and the relation between industry and company level.
Following the logic of Szopinski et al. [14] the approaches of Wirtz and Schallmo for their respective business models would be ”map based” in contrast to the more popular ”network-based” logic that for example Gordjin encorporates. The map-based approach however is not suficient enough to model an ecosystem from multiple perspectives: The relationships between the diferent actors are not visible here. The research of Szopinski et al. points to another gap in research: There are not many ”hybrid” models that include a map based approach as well as a network approach. One idea to connect these views can be seen in section 5.
This paper is part of a research project aiming at developing new business models for data-driven services in the context of DBE, and for implementing these business models in organizations, including the required adaptations of organization structures, business processes and IT infrastructures. The project follows the paradigm of design science research (DSR) [15], and this paper concerns the design of the envisioned artefact, methodical/technical support for implementing new business models in organizations. In previous work, we explicated the problem, we developed a FAIR data value chain and a value matrix as methodical support to identify new business opportunities and value creation options within a DBE. This paper aims at preparing technical support for applying this methodical support by establishing a metamodel for a modeling tool that can model company-level business models and capture dependencies between company-level models on DBE-level. It is therefore the second iteration of the DSR cycle and and should improve the already existing artefacts.
More concretely, in this paper we focus on a metamodel to operationalize Wirtz’s business model perspectives introduced in Section 2 in a metamodel that is suitable for implementing a modeling tool in the ADO.XX metamodeling platform. We plan to equip this modeling tool with the functionality to capture relationships between diferent business models that express dependencies of elements of one business model to other business models. These interbusiness-model relationships can later be used to visualize the dependencies of the actors (= companies) in a DBE. The research approach used is a combination of a descriptive case study and argumentative-deductive work. Starting from the research question, we use a case study (see section 4) to clarify the requirements and necessary constituents of the metamodel. The motivation for the case study is that we need to explore the nature and phenomenon of interlinking business models in DBE in real-world environments, which is possible in case studies. With the results from the case study, we start to develop the metamodel, which constitutes the argumentative-deductive part (see Section 5).
Regarding the steps in the DSR-Approach: The challenges in building ecosystem modelling tools to build an ecosystem from the start are clear: Successful cases should not only be investigated ex-post. The failure to build an ecosystem should be much more common than the success and survivorship bias of successful leaders could skew the research outcomes. Based on these main problems the requirements of a solution are explored in section 5. The next logical step is the development of a prototype to explore the feasability of a modelling tool that incorporates a connection between business models of multiple actors.
The case study that motivates our research originates from the Marispace-X project [16], which is part of the Gaia-X Initiative. Gaia-X is a European initiative to build a federated and secure data infrastructure that promotes digital sovereignty and interoperability. It aims to create a digital ecosystem where data and services can be shared securely and with trust, fostering innovation, and creating added value in the data economy.
Marispace-X applies the GAIA-X infrastructure in the maritime sector and is aimed at creating a digital maritime data space that allows industry, science, public administration, and NGOs to manage, share, and analyze data from the oceans in a secure, sovereign, and eficient manner. The resulting DBE provides opportunities for new business models, for example, in the areas of power generation in ofshore wind parks, aquaculture, logistics, or the mining of resources [ 17]. However, the amount of available data is huge, while no best practices or established data value chains exist, and the diversity in sensors and sensor formats also increases. Possible solutions for these problems would also lead to better value creation processes. The strategic value proposition of Marispace-X is to increase eficiency and reduce costs through data-driven processes; to enable cross-industry bundling of data availability and facilitate shared use; to establish scalable cloud technology infrastructures and services across applications and sectors in the maritime sector; and to develop new federated services establishing FAIR data use.
The project partnership in Marispace-X encompasses ten diferent partners (start-ups, SMEs, research institutes, universities, and large companies). For structuring the Marispace-X DBE, the roles proposed by the project “incentives and economics of data sharing” (IEDS) can be used: Service Provider, Cloud Platform Provider, Data-Infrastructure Provider, and Data Provider roles can be assigned to Marispace-X partners[18]. The role of the ecosystem orchestrator will probably be defined on GAIA-X level. The Marispace-X value creation process can generally be described along the FAIR data value chain proposed by [19], where the singular steps add value to the input data, up to the point of a new product or a new service. The finance model describes the sources of capital required for value creation and the associated supporting business activities. The procurement model defines which production factors are provided by which supplier.
We modeled the business models of the overall Marispace-X DBE and the individual companies in their above-mentioned BDE-related roles following the recommendations of Wirtz (see section 2). This recommendation includes a visualisation for the diferent partial models, which resembles a conceptual model, but does not follow a defined modeling language, i.e., it is actually only a drawing. To the best of our knowledge, there is no metamodel for the integrated business model view of Wirtz[20]. For brevity reasons, we only include the model of the service provider’s business model in Fig. 1. The models for the data provider and the Marispace-X DBE are included in [21]. It is not possible to capture the relation between the diferent business models, for example, as indicated by the role of the company in the DBE, with such drawings.
Motivated by the case study presented in the previous section, this section addresses the goal stated in the research method section: develop a metamodel for a modeling tool that can (a) model companylevel business models and (b) capture dependencies between company-level models and the DBE-level. Diferent principal approaches are possible to address this goal: use the same modeling language for company-level and DBE-level; combine a modeling language for DBE-level with a modeling language for company-level; extend a modeling language for DBE-level to also cover company-level; and extend a modeling language for company-level to also cover DBE-level. Based on our previous experience that it is possible to use the approach by Wirtz for modeling DBE-level as well as company-level (see [21]), we selected the first option, i.e., to use Wirtz’s approach for both levels. Thus, the intention of the metamodeling activity discussed in this section is to define a metamodel for the missing modeling language for Wirtz’s approach and for the inter-relations between the business models of diferent roles in the DBE. metamodels simply describe, what can be expressed in the underlying model[22]. In addition, it ”enables control over the structure and validy of models”[22]. The requirements to the metamodel are therefore the following: • Support company management in the design of their business models • Support an integrated business model view of DBE and company-level • Support identifying inter-company dependencies not visible in the DBE-level model
While modelling in the ”real-world” in the Marispace-X project would have been preferable, interviews to capture the diferent relationships between the project-partners could not be conducted due to time constraints. We therefore switched to a simpler, more general case to gather information about the practicability of an approach that connects business models of diferent actors with each other.
In order to fulfill the requirements, we begin by designing a metamodel for the integrated business model of Wirtz (see also section 2). Afterwards, the metamodel is Ado.xx tool to generate a corresponding modeling tool.
The strategic model in Wirtz’s approach ofers a clear and structured way to corporate management. The model begins with the definition of the organization’s vision. These visions serve as long-term guiding principles that describe the fundamental direction and desired state of the company. Based on these visions, the company develops its strategy. This strategy includes concrete measures and ways to realize the vision and remain competitive. Ultimately, the strategic model aims to maximize added value for the company. This added value is seen as the result of strategic decisions made by the company’s management. By aligning all activities with the overarching vision and carefully planning and implementing the strategy, the company creates sustainable success and long-term value enhancement[23]. The individual business models must be subordinated to the overarching corporate goals and visions and linked to them in order to achieve appropriate value creation in all areas. The strategic metamodel consists of three main classes: "Vision", "Strategy" and "Value Proposition". A vision or mission of the company forms the root node of the graph. A vision can associate 1 or more strategies by means of a relation. A strategy can be linked to a value proposition by means of a relation. All relationships follow the linear path described above and cannot be reversed. The classes were extracted from [23] and mapped accordingly (see Figure 2).
The resource model introduced by Wirtz focuses on presenting the core resources and core competencies as well as their subordinate elements that are relevant for value creation. It is therefore a summary of all relevant tangible and intangible input factors of the business model. Both internal and external resources and competencies are presented in this process. These resources include specific management knowledge, technical know-how, corporate image and the ability to learn. These resources can form the basis for a lasting competitive advantage. The analysis and mapping of resources and competencies that are relevant for value creation are mainly tasks of top management. As a result, various strategies can be used to ensure a sustainable competitive advantage through the available resources in the business model By influencing key resources, a company can, for example, try to keep potential competitors out of the market by pursuing a defensive blockade strategy and creating high barriers to market entry. This can be achieved through exclusive contracts with key suppliers or patents, among other things. However, there is a risk that a competitor could break through the barrier or reshape the market through a significant innovation. [23].
The resource model consists of the abstract class Resource Competence Component, which inherits its attributes from the classes Competence and Resource. The Resource Competence Component, as well as its child classes, can be associated with no or several competitive advantages by means of a directed relation. All relationships follow the linear path described above and cannot be reversed. The resulting metamodel is shown in figure 2.
The third model in the strategic component is the network model: The network model provides a comprehensive framework for understanding the collaborative dynamics of value creation and the interplay between diferent business models. It is a tool for top management to monitor and control the distribution of value among the partners involved in collective value creation. By analyzing both tangible and intangible flows of information and goods, the network model identifies and classifies the diferent shares of value creation and their interconnected relationships. In the context of a network model, a node represents a connection point within the network where value creation takes place. Each node can be a single company, a department or a specific unit within a company. These nodes are interconnected and form a value constellation that jointly contributes to value creation. Actors within the network model include all units involved in value creation, such as companies, management units and interest groups. These actors work together on the basis of a shared vision and mutual market objectives, and their interactions are governed by the inter-organizational coordination of strategic processes. The network model outlines the relationships and dependencies between these actors and illustrates how they contribute to and influence the value constellation. The network model consists of the classes: "Management Unit", "Actor", "Network Node". The "Management Unit" and "Actors" classes can have one or more relations to a network node via directed edges. This association follows the linear path described above and cannot be reversed. The resulting metamodel is shown in figure 2.
The metamodel for the value creation model is shown in Figure 3 with links to other metamodels. As Wirtz emphasizes, this model aims to transform low-value goods into high-value goods. This transformation is supported by administrative resources and production components, with administrative resources influencing the production components. This relationship is represented by the VCMRelation class. The production components include production factors, performance factors and production types. Production factors describe the goods to be processed and are categorized into potential factors (e.g. renewable resources, knowledge capital, reusable resources) and recurring factors (e.g. raw materials, consumables). This categorization takes place via the category attribute of the ProductionFactor class, which distinguishes between PotentialFactor and RepeatingFactor. Production factors can influence other production factors, and this influence is modeled by the ProductionRelation class.
Performance factors create additional value for the product and include diferent types, such as ServiceObject, Manpower, IntangibleRequirement and TangibleRequirement. The relationship between service factors and other components is also represented by ProductionRelation.
The production types are represented by the ProductionType class, which includes diferent types of production (e.g. individual production, mass production) and forms of mass customization (e.g. standardization, individualization). These classes are linked together to represent the various influencing relationships: VCMRelationProdType links performance factors to production types, and VCMRelationValueItem links production types to value items. A value item (ValueAddedItem) is created after the form of production has been defined and can in turn serve as input for the value creation model by being included as a production factor. This cyclical feature of the model enables continuous further processing and optimization of value creation. Through this comprehensive modelling, the entire value chain of a company is mapped in a structured manner, which supports the planning and optimization of resource utilization and production processes.
The metamodel for the procurement model is also shown in Figure 3. The model aims to structure and optimize the procurement process for raw materials, goods and services. In the initiation phase, the procurement process is initiated by determining demand and searching for potential sources of supply. This phase is linked to the Demand class via the PMDemandRelation class, which describes the specific demand. The fulfillment phase (represented by the Arrangement class) comprises the selection of the product and the source of supply as well as the placement of the order. The transition from initiation to processing is described by the PMRelationInitToArr class. In the transaction phase (represented by the Transaction class), the order, delivery and payment are processed. The Transaction class is linked to Arrangement via PMRelationArrToTrans and also contains the TransactionType attribute, which specifies the type of transaction. The Demand class describes the demand with attributes such as name, description, Amount, ABCAnalysis and Typology, whereby ABCAnalysis and Typology support the classification of goods. Demand is related to ProcurementPartner via PMPartnerDemandRelation. The ProcurementPartner class represents the suppliers and partners involved in the procurement process and is linked to Transaction via PMPartnerRelation and to Demand via PMPartnerDemandRelation. The arrow directions describe the process flow in the three phases. The arrows from supplier and demand describe the relationship that suppliers can cover the demand. The arrows from the demand to the initiation and execution phases describe that this demand is relevant for these phases. The arrows from the transaction to the suppliers model the conclusion of the transaction with the supplier.
The metamodel for the finance model is also shown in Figure 3. The capital model, represented by the CapitalModel class, enables planning using equity and debt capital and distinguishes between these two types of capital using the CapitalType attribute. The CapitalModel class inherits from the abstract FMComponent class, which contains the name and amount attributes and describes the basic ifnancial resources. The cost structure is mapped by the CostStructure class, which links cost centers with value-added activities and distinguishes between income and costs using the CostType attribute. CostStructure is also a specialization of FMComponent. The flows of financial resources are represented by the FMFlowRelation class, which links FMComponent and FMSource in both directions in order to map both the inflow and outflow of financial resources. FMSource represents the sources of financial resources and contains the name attribute.
The relationships between the individual partial models of the value-creation component can be described using five relations. The relations can be interpreted as follows: • PMtoVCMRelation: This relation describes the supply of production factors for the value creation model. • PMtoFMRelation: This relation models the cash flow in the transaction for the financing model.
This relation is relevant if, for example, the item to be procured is capital that is to be borrowed within the capital model of the financing model. • FMtoPMRelation: • The cash flow to the suppliers in the procurement model can be described using this relation.
FMtoVCMRelation: This relation can be used to represent the cash flows in the value creation processes.
• VCMtoFMRelation: This relation is used to model the revenue from the sale of goods.
The models presented in the previous section were the basis for implementing a modeling tool with the metamodeling platform Ado.xx. Thus, we were able to test the validity of the metamodels through applying them for selected cases. We started with an example from Wirtz’s publications, the automotive industry[24]. The strategic model for that example developed in this context is shown in figure 4 and the value creation model with related procurement and finance models is presented in Figure 5.
The usage of the metamodel and tool as a whole showed no major problems, but we detected potentials for improvement in some parts of the model. For example, it is not exactly clear what role suppliers and key accounts play in the networks. In this model, suppliers were assigned to all networks except innovation, as a supplier can be in contact with all other networks. Key accounts have points of contact with all networks. As the central organizational unit, Volkswagen is in contact with all networks. A missing link here could be the actor and organizational unit relationship. The necessity of this became apparent when carrying out the modeling. It should therefore be re-evaluated whether this relationship should be implemented in the metamodel. As these issues persisted, we chose to omit the customer and marketing component for the moment to focus on the aspects of clarity and missing links.
When considering the Marispace-X DBE and the company-level business models, it becomes clear that it is possible to capture the dependencies between diferent company-level models and between DBE-level and company-level models. However, the result is not an integrated model with two levels but rather a network of business models where the DBE-level model does not represent the coordinating and integrative upper level. The main reason seems to be that the same way of representing DBE and company-level creates a very tangled network of models rather than the required hierarchy between the model levels. As this is not the intention, future work will have to consider one of the other principal approaches mentioned in the introduction of this section.
Based on the a motivational case study from the maritime area and exisitng work on modeling business models, this paper aimed at devloping a metamodel for a modeling tool that can (a) model company-level business models and (b) capture dependencies between company-level models and the DBE-level. The developed metamodel for Wirtz’s business model approach proved to be applicable in practice and a starting point for metamodels in integrated business models. During the research process we realized the need to also investigate other strategies for achieving a two level modeling approach of business model due to the missing possibility of expressing hierarchies between DBE and company-level. The provided modularity of the components on the other hand has to be preserved, while maintaining an overview over the important aspects in a business. These results are therefore not final and rather a starting point for further investigations. If the metamodel is extended accordingly, the implementation into a tool for business modeling forms a promising avenue to demonstrate (and in the next steps evaluate) multi-level business models for DBE.
The author(s) have not employed any Generative AI tools.