1 Introduction

Digital business ecosystem (DBE) is the concept based on Moore’s definition of business ecosystem aimed at facilitating the evolution of a complex system involving organisations and individuals of an economic community [1]. In DBE as a new kind of collaborative network—the digital counterpart of a business ecosystem, the participating organisations and individual actors cooperate for product and service exchange by means of ICT.

In contrast to traditional multi-actor business models and networked organisations, DBE possesses several unique characteristics: heterogeneity, referring to the involvement of diverse actors; symbiosis, emphasising that the actors provide and extract resources of the value to each other, coevolution, denoting that DBE’s evolvement is driven by actors’ interactions, and self-organisation, meaning that the ecosystem is independent of external entities and not hierarchically controlled [2, 3].

An illustrative DBE example can be drawn from the recycling industry, within which many companies are reinventing their traditional business models towards newer solutions for improving results and efficiency. They bring in new actors, provide new infrastructures, integrate their own and new capabilities, and thus create and deliver innovative services. In symbiosis, the end users are providing objects for recycling, being motivated by different kinds of compensations offered by the business actors seeking promotion by giving the credits for communal transport, or top-up mobile recharge, or accepting humanitarian donations, etc. The recycling company, as the backend of this self-organisation, provides the infrastructure points for recycling as well as the web portal for receiving new actors and managing existing ones.

The highly collaborative aspect of DBE is, in turn, boosting the size, complexity, and dynamics of interactions and interrelationships among the involved actors leading to difficulties related to its management [4]. The modelling approach has proven useful in dealing with complex problems in organisational settings [5]. However, the current research emphasises a lack of proposals for methodological DEB design to support its development, analysis, measurement, and runtime management [3, 6]. Our research has aimed to address this problem by proposing a holistic approach to model-based DBE design as a design science research (DSR) project [7]. According to the DSR guidelines and research process proposed by Johannesson and Perjons [7], our previous work, including a recently conducted systematic literature review [8] and an exploratory semi-structured interview study [9], contributes to the iterative activities of problem explication and requirements analysis. In [10], we have addressed the DSR activity of designing and developing artefact by presenting a foundation of the design artefact—a modelling method for DBE design. In this study, we further attend to this DSR activity based on our previous effort in [10] with the following research goals:

  • RG1: to design and document a holistic method for DBE design based on the requirements reported in [7, 10]

  • RG2: to validate the DBE design method by means of action research

In relation to RG1, we have proposed a methodological approach for designing DBE using situational method engineering (SME) [11]. The characteristics of SME of supporting modularity and different situations with the modular method building blocks are the motivations for the choice aiming to address the comprehensive perspectives. A delimitation of this study is the focus on the process aspect of the method since the product aspect should be supported by the process. Hence, in this study, we have emphasised the engineering of the method and its process which will be matched and integrated with the existing modelling method components for its product elements. To address RG2, we have chosen to use action research for the validation of the DBE design method. The validation action research cycles have been applied to a real Swedish DBE case in health care. The reason for conducting the validation through action research is because it allows the application in natural organisational settings and collaboration with stakeholders in the settings, which is considered significant as in the dynamic context of a DBE.

The proposed method is intended to support researchers and practitioners, e.g. organisations participating in DBEs or management consultants, in designing DBEs taking into account the relevant perspectives of a DBE. These perspectives encompass the crucial concepts related to a DBE based on the empirically elicited requirements in [9].

The rest of the paper is organised in the following way. Section 2 provides background and related work. Section 3 presents the research methodology concerning design science and action research. Theoretical foundation and the development of the proposed DBE design method as well as the method itself with its module maps are provided in Sect. 4. Section 5 illustrates the validation case and the application of the validation action research cycles. A discussion and concluding remarks are presented in Sect. 6 and 7, respectively.

2 Background and related work

This section provides a state of the art related to DBE design, followed by an overview of Situational Method Engineering and its suitability for use in the DBE setting.

2.1 Elements of digital business ecosystems

Actor, role, capability, relationship, and digital component, were identified as the essential elements of DBE [2]. The actors are individuals and individual organisations that take participation in a DBE by taking specific roles according to their capabilities. They engaged in the relationships with other actors of the systems, and realise these roles at the runtime by the means of different digital components such as the ecosystem digital platform and its services, smart devices, and even other.

DBE roles are of a high significance for the ecosystem’s design because they correspond to the DBE-specific responsibilities of the actual involved actors and provide thus underlying knowledge for the capabilities relevant to a DBE and the method of their use. In [12], the authors surveyed the relevant literature to identify the DBE roles leading to the following ones:

  • Driver is guiding and looking over all actors within an ecosystem, with responsibilities, such as setting up a common vision for all DBE actors, improving the overall health of a DBE, and collecting and raising end users’ events and feedback.

  • Aggregator collects and combines multiple resources in a DBE into products and services without having the responsibility of leading a whole ecosystem and its involved actors. A

  • Modular Producer has capabilities and offers resources, such as products, services, technologies, knowledge, and financial funding, in a specialised domain within a DBE.

  • Complementor develops also capabilities and creates values in a specialised domain. However, its offerings are complements, often bundled by end users that add extra value to the core resources of a DBE.

  • Customer is the beneficiary of a DBE’s efforts and the sources of revenue as they pay for resources, whereas an

  • End User consumes resources based on its specific needs and provides feedback to other DBE actors.

  • Governor governs actors within a DBE by defining and providing normative artefacts, such as standards, laws, policies, guidelines, norms, and ethics, related to the business concern of the DBE.

  • Reputation Guardian surveys and assesses DBE actors' trustworthiness, reliability, solvency, and worthiness.

2.2 Model-based design of digital business ecosystems

We have studied methods for DBE design in a systematic literature review [8], whereof 5047 papers initially retrieved and 3031 screened, 94 were included for analysis. It has been revealed that from the analysed studies, only few proposed a holistic conceptual modelling method for DBE design, i.e. consisting of a modelling language and procedures for modelling. Remarkably, the modelling procedures of the proposed methods are insufficiently rigour, in terms of guidelines for design, and incomplete due to lacking consideration of some important DBE concepts in the modelling constructs. A study [13] included the elements actor, role, capability, relationship, and digital component, but the method for their design and analysis was not elaborated. Similarly, the inclusion of the elements and the lack of elaboration on their design and analysis were observed in several other approaches, including the Methodology of Business Ecosystem Network Analysis [14]; a methodology for modelling interdependencies between partners in a DBE [4]; and an approach for modelling and analysing DBEs from the value perspective [13]. However, none of these studies presented an elaborated method that includes all relevant DBE elements, nor the methods encompassed analysis of design or re-design based on runtime analysis that is important for DBE because of its high dynamics and complexity.

When studying a complex system, multi-perspective modelling [15] is important because of its feature of being able to represent cognitive perspectives, rooted in Psychology. The cognitive perspectives denote specific professional backgrounds or mindsets corresponding to cognitive dispositions of prospective users [15]. This provides means for representing different knowledge of the system in models with different intended perspectives and purposes of the users. Multi-view modelling is also important because of the use of different types of models in various viewpoints can represent different facets of the system [16]. This provides the basis for functionalities such as visualisation, decomposition, and specialisation supported by a multi-view modelling method and tool for users with the intention of accessing excepts or different visualisations of existing models based on the various viewpoints [17]. We have so far used 4EM [5] for modelling some of the essential perspectives of DBE, such as the actor-resource model for presenting the actors, their roles in DBE, and resources that they exchange [18]. It is necessary to incorporate multi-view modelling for the further analysis of DBEs. Since there are different levels of abstraction of a DBE and different groups of users, meaning the DBE roles mentioned in Sect. 2.1, multi-view modelling can support the different information needs based on these levels and user groups by modelling and visualising an excerpt or an aggregation of existing information captured and documented in collected models.

2.3 Situational method engineering

Situational Method Engineering (SME) [11] is a framework that provides theory and guidance for the design of methods that are situation-specific and configurable. A key feature of SME is the support for method modularity—a method is constructed using method chunks as the building blocks [11, 19, 20]. A method chunk is thus an autonomous part of a method, including its process and product elements. The process defines the activity of the method chunk, whereas the product formally defines the artefacts to be used and produced by the process. In addition, the user roles and supporting tools can also be defined. The composition of method chunks for constructing a new method is done using the Map approach [11, 20]. This approach is used to present the process model of the method in terms of engineering intentions (i.e. the engineering goal) and alternative strategies for achieving these intentions. The process model follows the form of a labelled directed graph with intentions as nodes and strategies as edges between intentions (see a simple map example given in Fig. 1). For instance, a strategy in the example map (Fig. 1) is legal expert meeting, which can be used to achieve the intention I18 analyse coverage of policies and regulations on all actors. In the map, a source intention, a strategy, and a target intention form a section (i.e. a triplet < source intention, strategy, target intention >). Each section requires one or more method chunks specifying how to achieve the target intention using the selected strategy. The Map approach also provides the method extension mechanism as the adding of new strategies and new intentions leads to new method chunks [11, 20].

Fig. 1
figure 1

Example map—the policies and regulations module map (PR-map)

Full size image

The dynamics occurring in the context of a DBE can be supported by the situational support of SME by means of the use of different method chunks as the design strategies. Dynamics mean how the DBE actors behave, interact, and react to each other in different situations, such as in the different phases of the DBE life cycle or when facing opportunities, threats, or changes. For example, a dynamic issue can be a sudden exit of a crucial DBE actor, which can pose a threat to the operation or deployment of the DBE. The remaining actor could choose the appropriate method chunks with suitable strategies to re-design the DBE timely. The contexts of DBEs concern specific domains, whereas the dynamic issues in the context of a DBE are situational.

3 Research methodology

3.1 Design science

Design science as a research methodology was first proposed as seven distinct guidelines, namely design as an artefact, problem relevance, design evaluation, research contributions, research rigour, design as a search process, and communication of research, for Information Systems research by Hevner et al. [21]. In this study, we have adopted the definition of design science (DS) suggested by Johannesson & Perjons [7]. It is defined as “the scientific study and creation of artefacts as they are developed and used by people with the goal of solving practical problems of general interest” [7], which shares similarity with the understanding of DS suggested by Hevner et al. [21]. Under this definition, the researchers not only are observers of specific phenomena or problems but also take on an active role as a designer and create useful objects or artefacts for these problems. Based on this view, the authors proposed the DS research framework [7], consisting of five main activities, namely Explicate Problem, Define Requirements, Design and Develop Artefact, Demonstrate Artefact, and Evaluate Artefact. It is important to note that these activities can be conducted iteratively in the process of a design science research project.

3.1.1 Problem explication and requirements elicitation for the DSR project

The current study is a part of our design science research (DSR) [7] project which aims to develop a framework for DBE design, analysis, and management from a resilience perspective. In a systematic literature review [8], we have attained the objective of explicating the problem by concluding that there is a lack of a holistic DBE design and modelling method. Contributing to the iterative DSR activities [7], our exploratory semi-structured interview study [9] has further addressed the problem explication and requirements analysis. With the purpose of understanding DBEs and eliciting requirements for developing a DBE design method, we have interviewed industry practitioners and experts from different business domains. Concerning the design and development of the artefact, a foundation of the design artefact—a modelling method for DBE design has been presented in [10]. This study focusses on the further elaboration of the activity Design and Develop Artefact, i.e. the DBE design method, and the attempt of Demonstrate Artefact.

3.2 Action research

The practice of action research has a long history in many fields, including organisation development, business and management, education, nursing and health care, social work and community development, information systems [22, 23]. As implied by its name, action research combines actions in real organisational settings with scientific research process by integrating applied behavioural science knowledge with organisational knowledge. Because of this distinctive characteristic, action research, as a unique scientific inquiry approach, provides advantages such as addressing real issues in real organisational settings and supporting organisations in developing competencies for bring changes into organisations. Action research promotes the shift from constructing a research project on study participants to one that is conducted with the study members. Because of this shift to a collaboration between researchers and study members, the co-inquiry process of action research enables the generation of actionable scientific knowledge and useful organisational competencies at the same time.

An action research cycle consists of four phases, Constructing, Planning Action, Taking Action, Evaluating Action. Several iterations of action research cycles can consist of a project depending on the scope and the agreement between the researchers and the study members from the organisations. During the constructing phase, the context and purposes of the action research project are discussed by the researchers and the study members in order to reach consensus on issues that will be addressed in the project. The exploration of the context and purposes are collaboratively conducted during the planning action phase. Planned actions could be a first step of a series of actions tackling the critical aspect of the issues. The organisation(s) with the support of the researchers conduct and implement the planned actions in the taking action phase. Evaluations on all that have been done collaboratively in the previous phases are reflected and examined together by the researchers and the study members. These reflections feed into the iterative cycles of action research, meaning that the one cycle helps improve the next and the coming action research cycles.

3.3 Research design

The research design of this study adopted action research [22] under the design science research (DSR) framework [7]. The fusing of DSR with a more practice-oriented or intervention-oriented approach has been introduced by previous studies [24, 25]. Sein et al. [24] proposed an intervention-oriented approach to DSR as the Action Design Research (ADR), emphasising the significance of the role of organisational context shaping the design as well as the deployed artefact. Goldkuhl & Sjöström [25] investigated DSR in the field as compared to in the laboratory setting and proposed the Practice Design Research (PDR), stressing the theorising activities and evaluation activities with the use of situational design inquiry process (cf. chapter 4 in [25]). Both DSR and action research aim to change and improve human practices [7]. We observed that DSR [7, 21], which is, in essence, an iterative cycle of construct and evaluate activities (for designing artefacts), shares similarities with action research [22], which is also an iterative cycle of construct and evaluate activities (for tackling issues in real organisational settings). In fact, as stated by Hevner et al. [21], the artefacts generated by DSR may be a construct, method, model or instantiation, which can be not only technology-based, e.g. software application, but also organisation-based, e.g. organisational process design. Also, Sein et al. [24] suggested the significance of introducing action research cycles into the DSR process as a more explicit practical contribution orientation for further development of DSR. Combining DSR and action research, we have attempted to validate and improve the artefact—the proposed DBE design method and its module maps and, at the same time, support an organisation in its DBE setting in developing competencies and acquiring knowledge using the proposed method.

In order to seek a mutual understanding about the context and purpose of this action research project, several working sessions within Health Integrator, the driver of the Digital Vaccine DBE, was held for designing and conducting the action research cycles. During the sessions, the common objectives were established for improving the understanding of the implementing of the main DBE characteristics and for supporting the development of organisational competencies using the DBE design method as well as validating the method and its module maps.

As a first step, a semi-structured interview was held with the use of a priority rating list concerning the focus contexts motivated by the requirements (c.f. Section 3.2). As shown in Table 1, the focus contexts motivated by the requirements were rated with a 7-point Likert scale, of which 1 was the least concerned and 7 was the most concerned by Health Integrator in the Digital Vaccine DBE. The step, including the interview session and the list of the focus contexts with their priority rating scores in Table 1, was served as a general constructing phase of the three sequential action research cycles of this study since it facilitated the gathering and prioritising of the issues as a basis of which actions were planned and taken. It is important to note that the rating scores shown in Table 1 do not suggest the importance of these focus contexts but rather how much the focus contexts are concerned in the Digital Vaccine DBE.

Table 1 Priority rating scores for the 15 focus contexts
Full size table

Due to the timeframe, the six focus contexts that were rated with the scores 6 and 7, namely actors’ relationship, actors’ performance, exchanging values, KPIs and indicators, scope and boundaries, and future possibility, were chosen to be addressed in the three sequential action research cycles. As agreed in the common objectives, the three consecutive phases, planning action, taking action, and evaluating action, of the three action research cycles for this study emphasised the use of the DBE method and its module maps as actions, meaning that walkthroughs of the module maps related to focus contexts as well as validation actions based on strategies and intentions (method chunks) were planned, taken, and evaluated. For the first cycle, the focus context—scope and boundaries was chosen as the main working theme for the consecutive three phases. With the support of the scope and boundaries module map (S-map), the usefulness of the strategies and intentions (method chunks) were validated with actions under the circumstance that a refined business focus was being introduced to the Digital Vaccine DBE. Based on the same circumstance, two focus contexts—actors’ relationship and exchanging values were addressed in the second cycle with the use of the actors and relationships (A-map), interchangeability of capabilities (C-map), and interchangeability of resources (R-map) module maps. In the third cycle, actors’ performance, KPIs and indicators, and future possibility were the main issues in focus and the validation actions were planned, taken, and evaluated based on the KPIs, indicators, and actors’ performance (KIP-map), runtime management (RM-map), and digital infrastructures (D-map) module maps.

4 Design and development of the DBE method maps

This section presents the theoretical foundation for the conceptualisation and development of the method for designing DBEs and its module maps. The presented results are based on a previous publication [10], and in this study they are improved and elaborated based on an action research project with a functioning digital business ecosystem with real business settings.

Following the previous studies of the DSR project (as described in Sect. 3.1.1), we further attend to the step of designing and developing artefact for our DBE design method by applying a product-driven SME approach in this study.

4.1 Identification of main concepts and intentions

Due to the lack of existing holistic design and modelling methods for DBEs, we applied SME with a product-driven approach [20]. In other words, we have not observed any existing methods, including the modelling process or procedures and the modelling products, which encompass the comprehensive perspectives of a DBE. Therefore, a product-driven SME approach was chosen in order to identify intentions related to the product parts for constructing the method process in the current study. As motivated previously in Sect. 1, the process should be constructed before integrating existing modelling methods and their product parts which could support this DBE method and its method chunks. That is, the product-driven SME approach for the identification of product element-related intentions has been adopted to inform the construction of the method process.

This approach means that the empirical data and the 30 requirements (as shown in Table 2) in [9] were used to derive the main concepts or artefacts (i.e. product parts). These 22 main concepts were considered related to the product parts of the DBE design method and, in turn, served as the drive for facilitating the intentions of the process and the development of process models as in maps for the method.

Table 2 Requirements and ME intentions
Full size table

The 22 main concepts (shown in italic) are described in the following. Scope of a DBE concerns business focus and activities of the DBE based on its vision, whereas boundaries determine which actors are part of the DBE. Vision is a collection of goals on a strategic level. Based on this difference, both goal and vision are equally important artefacts in the context of DBE considering the multiple actors involved. Actors are organisations or individuals who take part in a DBE and establish relationships with each other. Each actor has specific role(s) and corresponding responsibilities (c.f. Section 2.1 and [12] for the defined DBE roles and their responsibilities). Each actor has also its domain-specific focus area and interests, properties related to performance, and key performance indicators (KPIs). Within a DBE, relevant processes, capabilities, resources, and values of participating actors are shared and exchanged, which contributes to the functioning and sustaining of the DBE. Digital infrastructures and communication channels shared and used between actors constitute the digital environment of a DBE, where communication form(s) agreed by the actors and agreement(s) about exchanged information between them are fundamental. Policies and regulations exist in the context of DBE to impose certain rules and restrictions. Table 2 shows the 30 requirements elicited in [9] and the 32 intentions derived from the identified 22 main concepts based on these requirements.

As shown in Table 2, six requirements, R3, R4, R9, R12, R19, and R20, were considered constraints of the DBE method and thus did not lead to identification of intentions. These requirements were described in more detail in a previous study [9]. The 32 intentions, or so-called engineering intentions, according to SME, were then used as the starting point for constructing the DBE method maps as in process models using the Map approach (c.f. [11, 20] and Sect. 2.3).

4.2 DBE method maps as the design artefacts

Using the Map approach, a holistic process, yet agile by its focus to producing minimal viable results by means of modularisation, for the DBE method is developed with the set of intensions as basis. Due to the complexity of designing an entire DBE, each module map focuses on a design concern and illustrates the process model, in terms of engineering intentions and different, situation-related, strategies to achieve the intentions related to the specific design concern. The notion of module map is still supported by the key characteristics of SME—modularity and method chunks. This means that each and every section (i.e. a triplet < source intention, strategy, target intention >) in these module maps still requires to be specified by one or more method chunks. In the following paragraphs, the module maps are described and the relationships among these maps are explained. Table 3 shows the module maps for the DBE design method and their descriptions.

Table 3 Descriptions of the module maps for the DBE method
Full size table

Five module maps, namely scope and boundaries (S-map), actors and relationships (A-map), interchangeability of capabilities (C-map), interchangeability of resources (R-map), and digital infrastructures (D-map) module maps are considered as baseline module maps for the DBE design method and will be discussed later in Sect. 4.3. These five module maps address the design concerns related to the five essential elements of DBEs and thus are necessary for designing a DBE, i.e. the baseline of the DBE design method.

The other six module maps are integration of processes (IP-map), policies and regulations (PR-map), domain-specific concerns (DSR-map), communication channel and information sharing (CCIS-map), KPIs, indicators, and actors’ performance (KIP-map), and runtime management (RM-map). Even though these six module maps do not concern the essential elements, they are constructed with the basis of the main concepts and requirements obtained from empirical data and are considered complimentary to the comprehensive perspectives of the DBE design method. The integration of processes (IP-map) module maps concerns the operational processes of individual DBE actors and the integration of these operational processes. This integration could be related to the digital infrastructures that are used and shared among the actors. The policies and regulations (PR-map) module maps is about understanding the policies, in terms of rules made by companies or organisations in order to carry out a plan and achieve certain aims, and regulations, meaning restrictions, with the effect of law, made and imposed by public agencies [26], relevant for individual DBE actors as well as a whole DBE. In other words, there could be external policies to which a DBE needs to adhere, but also but also internal policies in the DBE to which the actors need to adhere. The domain-specific concerns (DSR-map) module map is about the activities, competencies, and skills related to DBE actors’ specific domains and how the actors can manage them based on their domain-specific goals. The communication channel and information sharing (CCIS-map) module map concerns the communication channels used and shared among DBE actors for the information agreed to be shared within the DBE. The KPIs, indicators, and actors’ performance (KIP-map) module map is related to the understanding of the static and dynamic aspects of a DBE by means of monitoring relevant KPIs, indicators, and actors’ performance. The runtime management (RM-map) module map concerns changes occurring in a DBE, once the DBE is deployed, i.e. the DBE becomes operational and alive.

4.3 Guidelines for using the DBE method maps

Despite the holistic construction of the module maps for the process of the DBE method, the maps are intended for the use in the agile way, due to their self-containment and loosely coupled nature. This means that the users could use several of the process maps simultaneously or in the users’ preferred order based on their preferences and needs. For each and every module map, the users could perform a chosen section (i.e. a triplet < source intention, strategy, target intention >). When needed, additional strategies could be engineered, added, and used to achieve the listed intentions in the maps. Nevertheless, there are five baseline module maps. Baseline means that a module map is necessary to be used when designing a DBE using the DBE Method. Also, three types of dependencies among the module maps exist. Condition means that a module map is a perquisite of another module map. Include means that a module map requires the execution of the included module map. Feedback means that the execution of a module map may suggest returning to one or more previously performed module map(s). Table 4 shows the notation used for the graphic representation of map dependency in Table 5. Table 5 shows the dependencies among the identified module maps.

Table 4 Notation used for illustrating map dependency
Full size table
Table 5 Dependency of the module maps
Full size table

The five baseline module maps, namely scope and boundaries, actors and relationships, interchangeability of capabilities, interchangeability of resources, and digital infrastructures are considered mandatory to be used while designing a DBE. The idea of enforcing the mandatory use of baseline module maps is based on the five essential DBE elements, namely actor, role, capability, relationship, and digital component, derived from the definition of DBE (cf. Section 2.1). It is suggested that the users should start with the S-map and A-map. Then, the user could proceed with the C-map, R-map, and D-map. The scope and boundaries (S-map) module map concerns the defining of the business focus of a DBE and the involved actors as well as the alignment of actors’ visions and goals since the overall vision of the DBE is often a basis for defining the scope and boundaries. Hence, the scope and boundaries of a DBE and the alignment of visions and goals should cohere with each other. The actors and relationships (A-map) module map is about understanding the actors in a DBE, their roles, and their relationship networks. The interchangeability of capabilities (C-map) and the interchangeability of resources (R-map) module maps are related to the offered and desired resources and enabling capabilities across the involved actors in a DBE and to analyse the interchangeability of them. An example is Fig. 6 discussed later in Sect. 5.2 for validation. The digital infrastructures (D-map) module map is about understanding the digital infrastructures used and shared among actors in a DBE and these shared infrastructures are important as a support for conducting the operational processes or as the means of new innovation when changes occur.

A few examples are given here to illustrate the dependencies described in Table 5. The Include A-map dependency of the S-map suggests that it is required to perform the A-map and understand the DBE actors and their relationships when a user is performing the S-map in order to be able to define the business focus and involved actors and align actors’ visions and goals. The Condition A-map dependency of the C-map means that the A-map needs to be, as a prerequisite, performed before the use of the C-map in order for the user to be able to analyse the capabilities of actors involving in a DBE. The Feedback A-map dependency of the KIP-map suggests that the monitoring of KPIs, indicators, and actors’ performance with the use and support of the KIP-map could trigger and suggest the user to reperform the A-map in order to revisit the current design of existing DBE actors and their relationships and make changes to the design with the reuse of the A-map.

5 Validation with the Digital Vaccine case

We have studied the applicability of the proposed method and the module maps as the design artefacts with action research. Real business settings in a Digital Vaccine case realised by a functioning digital business ecosystem aiming to improve personal tailored preventive health care for citizens, is used to validate the proposed method. With the use and support of the proposed method and the module maps, validation actions were planned and taken as it is in depth described below.

5.1 Digital Vaccine DBE setting

The Digital Vaccine case is a functioning and operating platform-oriented DBE, driven by Health Integrator AB, a Stockholm-based company. This innovative business constellation was at an early stage supported by European Institute of Innovation and Technology Health (EIT Health). Actors such as digital and physical health service providers, health product suppliers, different types of individual end users, health coaches, a data analysing institute, and investors come together and collaborate in the DBE with the outlook set by the driving company—Health Integrator and the support from the public sector—Stockholm Region. These actors have different DBE roles, including driver, modular producer, end user, customer, and governor. The aim of the Digital Vaccine DBE is to shift the focus in health care from reactive to proactive by providing tailored care based on personal needs and supporting healthier lifestyle habits and to reduce the financial burden of health care on the public health care system. Being the driving company and holding the leadership role in the Digital Vaccine DBE, Health Integrator owns a digital health platform. Enabled by the platform, actors can collaboratively realise the aim of improving personal-based preventive health care and maintain healthier lifestyles. For individuals as end users in the DBE, they can set up health goals and track their progresses through measures with the support of health coaches who have the DBE role modular producer. Other modular producers such as health care providers and product suppliers can make their services and products easily accessible and better fit the needs of the end users within the network of this DBE on the curated marketplace. For the DBE role customer, such as employers, they can invest in their employees’ (as end users) health and well-being through the DBE and be supported by the platform to track and report the organisations’ health development data.

The Digital Vaccine DBE has successfully been applied to pre-diabetic patients, people who are at risk for type 2 diabetes which is a condition costing the Stockholm Region about 2.5 billion Swedish kronor annually. The Stockholm Region as the governor and customer, together with Health Integrator as the driver, and Skandia and SEB as the financiers and modular producers, run the project through the Digital Vaccine DBE. The first batch with 210 participants (individual end users) has had the first blood sugar control after six months. The results show that 43 per cent of the participants are no longer classified as pre-diabetic and 61 per cent have lowered their blood sugar [27]. This could contribute to an annual saving of 1.4 billion Swedish kronor as calculated by the Stockholm Region. With the success, a new outlook to target a new group of individuals—20- to 65-year-old working population, a new type of end user, has been set out by Health Integrator as the driving company. As a dynamic issue for the Digital Vaccine DBE, this new outlook expects potential additional business activities, new business goals, and values.

5.2 Multiple wallets for end users

In this scenario, we investigated a change of the business focus occurring in the Digital Vaccine DBE leading to the inclusion of different types of end users being entitled with multiple wallets on the digital platform/marketplace with pre-paid capital from different sources of financial supports. As mentioned above, a new outlook targeting a new group of end users, who are 20- to 65-year-old working population, are being introduced to the Digital Vaccine DBE. This means that the DBE has now an additional business focus, improving the personal-based preventive health care for not only the pre-diabetic patients/citizens but also citizens who are part of the working population and have various occupational and health conditions.

We started by using this scenario as a basis for walkthrough of the S-map with Health Integrator. As shown in Fig. 2, both the goal modelling and the interviews and negotiation strategies were perceived to be helpful when delimiting the new scope and boundaries of the DBE, in terms of trying to introduce this new group of end users as a new business focus to the DBE with the other collaborative actors, such as the public sector—Stockholm Region being the governor and customer of the DBE and the health coaches as the module producers of the DBE. According to our action based on the goal modelling strategy, with the new business focus, documenting business goals of the DBE targeting different groups of end users collaboratively with other DBE actors was considered a suitable strategy. Thereafter, the A-map, having an include type of dependency with the S-map as described in Sect. 4.3, was used and will be discussed later on in this section. To align actors’ visions, the DBE integrated vision-based alignment, driver’s vision-based alignment, and the modelling strategies were considered appropriate and useful for resolving conflicts based on our actions. Despite the new business focus, the actors within the Digital Vaccine DBE could reach consensus on shared clear common visions. After the action of attempting to align actors’ goals, Health Integrator agreed that the DBE role-based alignment and modelling strategies could support the understanding and alignment of the business goals at a more detailed level among the collaborative actors in the DBE context. These actors had different DBE roles, including modular producer, complementor, customer, and governor roles.

Fig. 2
figure 2

The scope and boundaries module map (S-map) of the DBE method

Full size image

Figure 3 illustrates the module map actors and relationships (A-map). Both the Driver-first DBE role-based discovery and the new actor discovery strategies were considered useful. However, in this specific scenario, the action was taken based on the new actor discovery strategy as, based on the new business focus, a new group of end users were being introduced to the Digital Vaccine DBE as new actors. Through the action with modelling strategy, the identification of actors was carried out with a specific focus on the roles and responsibilities (c.f. Section 2.1 [12] and other studies [28,29,30,31]). Following this, both driver centred and single actor’s viewpoint strategies were perceived to be appropriate depending on the situations when identifying actors’ relationship. Given the scenario, driver centred strategy was chosen for the action as it was not necessary to identify all relationships among every single new end user as actor and the existing actors in the DBE. These identified actors, their DBE roles, and their relationships were illustrated in an updated extended actor-resource 4EM model as shown in Fig. 6. Model analysis, as a strategy, was considered applicable to analyse the Digital Vaccine DBE’s relationship network by means of several existing tools, such as [32, 33], supporting the visualisations and relationships of such networks in the context of a DBE. The attractiveness analysis strategy was mentioned as valuable when trying to analyse the relationship network based on the supply and demand in the Digital Vaccine DBE—modular producers’ (providers and suppliers) offers versus customers’ and end users’ needs and preferences which concern quality and quantity parameters as the composite properties of the attractiveness in a relationship.

Fig. 3
figure 3

The actors and relationships module map (A-map) of the DBE method

Full size image

The interchangeability of resources module map (R-map) was used to understand the resources in the DBE with the new actors, especially the financial resources supporting the new group of end users. Due to the condition type of dependency that the A-map has with the R-map, the walkthrough of the R-map (Fig. 4) with Health Integrator was conducted after. This walkthrough suggested that the strategies in the R-map were appropriate. As for this scenario, the end-user focused strategy was chosen for the action of identifying the resources. The model analysis strategy was considered useful when analysing the interchangeability of the resources, such as health care products and services provided by actors with the DBE role modular producer, within the Digital Vaccine DBE as service providers and product suppliers scaled up. Discussion on intangible (soft) resources—assets such as the branding of the Digital Vaccine platform operated by Health Integrator; the unique business model with pre-paid capital in end users’ wallets on the marketplace; the human-related resources such as skills related to health coaching resulting in encouragement and motivation, and knowledge provided by the health coaches, end users as a community, and health data analysing institute occurred during the walkthrough. These intangible (soft) resources were one of the keys leading to value creation and exchange in the DBE [34].

Fig. 4
figure 4

The interchangeability of resources module map (R-map) of the DBE method

Full size image

For the same reason of having the A-map as a condition dependency, the interchangeability of capabilities module map (C-map) (Fig. 5) was validated in a similar fashion. The capability mapping strategy was used to perform action related to the identification of relevant capabilities. The strategies in this map were perceived appropriate and the model analysis strategy for analysing the interchangeability of the capabilities could also be useful as the DBE scaled up.

Fig. 5
figure 5

The interchangeability of capabilities module map (C-map) of the DBE method

Full size image

As shown in Fig. 6, the new actors and related resources for the scenario in the Digital Vaccine DBE were illustrated in the extended 4EM actor-resource model. This resulted in the three different types of end users in the DBE, namely role 3 employee, role 7 private client, and role 8 regional health care client. All three roles represented the actors of this new group of end users (with the DBE role end user), meaning the 20- to 65-year-old working population with various occupational and health conditions, being introduced to the DBE as part of the new business focus. Three different types of financial resources, namely resource 10 private capital, resource 11 employee investment capital, and resource 12 health care funds, were also identified and are shown in bold in Fig. 6.

Fig. 6
figure 6

The different types of wallet resources (shown in bold) for the different end users in Digital Vaccine DBE

Full size image

These three types of end users belonging to this new group are supported by different financial resources. The new end users with the role employee are the ones employed by private companies or employers (with the DBE role customer) which take part in the Digital Vaccine DBE. These companies or employers pre-pay employee investment capital, i.e. wellness benefits, for their employees in order for them to improve personal health through the use of the DBE’s platform. Those with the role private client are the ones who decide to spend private capital for being part of the DBE and utilise the preventive health care services and products offered in the DBE. Regional health care clients are the new end users who are part of the regional health care system with or without underlying health conditions. They are entitled with public health care funds that are pre-paid by the region (public sector with the DBE role customer and governor) to the Digital Vaccine DBE for them to consume preventive health care services and products through the platform.

The actions and walkthroughs of the module maps for this scenario reflect the design of the information system (platform) used for the Digital Vaccine DBE as shown in Figs. 7 and 8. This means that depending on the role of an end-user multiple wallets are created for them on the digital platform according to the financial resources they are entitled with. The user can then choose from which wallets, i.e. with which financial resources, they will pay for the services and products while using the platform. Figure 7 shows a screenshot of the marketplace page populated by health care services and products with different costs and sources of costs offered by actors in the Digital Vaccine DBE. The services and products shown in Fig. 7 are some of the examples among a greater amount of offers on the platform. The end user, in case of being a pre-diabetic patient, has a total amount of pre-loaded 12,500 Swedish kronor, and in this case 4704 Swedish kronor left as a sum of the wallets. The products and services have different costs, including one that is free (“Gratis”) and two that are covered by the public health care funds (“Patientavgift”), as shown in the examples in Fig. 7.

Fig. 7
figure 7

Screenshot of the marketplace page for the Digital Vaccine DBE

Full size image
Fig. 8
figure 8

Screenshot of the checkout page of the digital platform for the Digital Vaccine DBE

Full size image

Figure 8 shows a screenshot of the checkout page illustrating how an end user will pay by choosing to use the pre-loaded money from different wallets depending on the types of end user they are and the sources of financial support they are entitled with (e.g. pre-loaded pre-diabetic funds from Stockholm Region or pre-loaded extra funds from a private employer) or with their own money (“Egna medel”).

5.3 End-user performance

Building upon the previous scenario in Sect. 5.2, this scenario we investigated the cycle of improving end users’ health and evaluating their health performances against their health goals enabled by the Digital Vaccine DBE and its various actors with different DBE roles.

As illustrated in Fig. 9, the cycle, which is completely supported by the digital platform, starts by gathering baseline data regarding an end user’s health condition, such as blood tests or full-body health check-ups. With the help of health coaches and the health data analysing institute—modular producers of the DBE, knowledge about individual preventive health needs and the optimal measures is provided to the end user as valuable insights after analysing the baseline data. According to these insights, a preventive health care plan with health goals for the end user is activated through the platform where products and services matching with the health needs and goals can be consumed. These products and services are not offered by a single actor but rather collectively by DBE actors with the roles modular producer and even end user, such as end-user-initiated services, e.g. Health Buddy. The end user’s progress related to the health goals and plan is tracked by gathering data again after the preventive health care interventions in the evaluation phase. The evaluation data is analysed by health coaches and the health data analysing institute and used as feedback for the end user’s next health improvement cycle.

Fig. 9
figure 9

The healthy cycle for improving and evaluating end users’ health performance enabled by the Digital Vaccine DBE and its digital platform (information system)

Full size image

Using this scenario, we performed walkthroughs of the KPIs, indicators, and actors’ performance (KIP-map) and runtime management (RM-map) module maps. For the same reason of having the A-map as a condition dependency, the KIP-map (Fig. 10) was carried out for the walkthrough after having used the A-map in the previous scenario. As shown in Fig. 10, the four strategies, strategy, actor, capability, and process driven, were perceived to be helpful when identifying KPIs and indicators of the Digital Vaccine DBE. For example, taking the process driven strategy, KPIs and indicators concerning the onboarding and the quality assurance processes of the DBE actors, especially those that have the roles modular producer, complementor, and governor, can be identified. With the capability-driven strategy, KPIs and indicators related to capabilities supporting the improvement of preventive health care realised by DBE roles, such as driver, modular producer, and complementor, can be identified. The action was taken based on the actor driven strategy as shown in an example in Fig. 11. To monitor the static or the structural aspect of the DBE with the identified KPIs and indicators, the end-user-based and DBE vision-based monitoring strategies were both considered appropriate depending on the situation at hand. On the other hand, to address the more dynamic aspect of the DBE, in terms of the performance of the actors, single actor centred and end-user centred strategies were applicable to identify properties of actor performance based on the identified KPIs and indicators. Using these identified properties, the artificial intelligent algorithm-based strategy was suggested suitable for monitoring actors’ performance. The actors could be having any DBE roles but in this scenario the cycle was emphasised and thus led to the focus on the roles end user and modular producer. In other words, the performances concerned both the end users’ progress against health care plans and goals and how the modular producers’ services and/or products contribute to the progress of the end users.

Fig. 10
figure 10

The KPIs, indicators, and actors’ performance module map (KIP-map) of the DBE method

Full size image
Fig. 11
figure 11

The KPIs of different actors and the related goals for the Digital Vaccine DBE

Full size image

As shown in Fig. 11, several KPIs concerning how the different actors with different DBE roles contribute to the progress of the end-user performance were identified using actor driven strategy as shown in Fig. 10 and described above. They were modelled together with the different goals, including resilience goals, DBE domain goals, and business goals of the Digital Vaccine DBE.

The scenario, especially the changes related to the feedback used in new cycles happening during and after the evaluation phase as described above, was also used for validating the runtime management (RM-map) module map (Fig. 12). External context data, internal data, new actor discovery, and actor elimination strategies were suggested to be useful when identifying changes in the Digital Vaccine DBE and analysing its future state under the circumstances of new actor joining and existing actor exiting the DBE. Thereafter, the baseline module maps, i.e. the S-map, A-map, C-map, R-map, and D-map, having an include type of dependency with the RM-map, were used. The D-map will be the only baseline module map discussed later on in this section since all other of the baseline maps were described in Sect. 5.2. In the situation of a new actor joining the DBE, both single actor centred and DBE integrated vision-based strategies were applicable to analyse the new actor’s fitness and qualification based on its performance in the Digital Vaccine DBE. For this, the KIP-map having an include type of dependency with the RM-map should be carried out and was, nevertheless, omitted in order to avoid the redundancy of repeating its use in the same scenario.

Fig. 12
figure 12

The runtime management module map (RM-map) of the DBE method

Full size image

As shown in Fig. 13, the two strategies, namely document analysis and workshop, supported by the collaborative ecosystem modelling approach suggested in [33, 35], were considered to be useful when collaboratively identifying the digital infrastructures shared among actors in the Digital Vaccine DBE, especially actors with the role driver owning the digital platform and those who had a more direct usage of the digital platform such as end user, customer, and module producer. The three strategies, model analysis, DBE actor negotiation (in terms of negotiation meetings among DBE actors), and innovation simulation, were suggested applicable to facilitate the analysis of possible new innovation in this specific situation of a new actor joining the DBE. The strategy innovation simulation could be supported by the many existing scientific research and approaches, such as in [36,37,38].

Fig. 13
figure 13

The digital infrastructures module map (D-map) of the DBE method

Full size image

Figure 14 illustrates a screenshot of the dashboard page showing an end user’s health plan, goals, and progress. The lower section shows the preventive health care services and products provided by the different modular producers that are currently in active usage status for the end user and are contributing to the preventive health care progress. The design and the backend of the information system (platform) as shown in Fig. 14 is able to be supported by the modules maps as described above for this scenario. The backend can be designed to support the data retrieval and monitoring of the KPIs, indicators, and measurement properties that has been identified as relevant. Also, artificial intelligent algorithms incorporated as part of the backend design can be used to analyse the monitored KPIs and properties in order to suggest changes to improve end-user performance. These changes can be the adoption of more suitable services and/or products from other modular producers, the deactivation of an existing in-use services and/or products, and suggestions for other effective services and/or products based on similar health care plans and goals of other end users.

Fig. 14
figure 14

Screenshot of the dashboard page showing an end user’s health progress and the services and products in usage

Full size image

6 Discussion

In the settings and scenarios of the Digital Vaccine DBE used for this study, we tried to demonstrate the complex and intricate nature of a DBE. The self-organising characteristic of the Digital Vaccine DBE is supported by a heterogeneous network of actors having different DBE roles, such as end user, governor, modular producer, providing and consuming resources with enabling capabilities in symbiosis. In the example of the multiple wallets for end users, we have observed how actors in the DBE co-evolve when new actors, i.e. the new group of end users, are introduced to the DBE. This introduction brings new interactions into the network of existing actors. Different new resources and capabilities, such as health care funds, private capital, employee investment capital, and health coaching, are needed to support the new actors in the symbiosis of the DBE in order to continuously fulfil the vision of the DBE.

Given the complexity of DBEs, we have chosen the Situational Method Engineering (SME) approach for addressing our research goal 1—to design and document a holistic method for DBE design based on the requirements reported in [9, 10]. We argue that the SME approach is an appropriate way for developing a method for DBE design encompassing more comprehensive perspectives that reflect the complex nature. With the SME approach, we have achieved the research goal 1 by presenting a method for designing DBE with the module maps (Table 3) as constituents of a holistic assembly. To validate the proposed method as the research goal 2 of this study, action research has been applied to carry out an ex ante evaluation in a real (naturalistic) DBE setting of the Digital Vaccine case.

6.1 Implications for practitioners

The overall structure of the proposed method provided by the combination of these module maps inherits some of the advantages of the SME and the Map approaches. These advantages can be of support for the practitioners while using the method. First of all, the emphasis on modularity of the SME approach works well for the need of addressing the multiple perspectives and the dynamics when designing a DBE. The modularity characteristic is expressed explicitly at a higher level where each of the module map is focusing on a design concern and together reflects the multiple perspectives of a DBE. This high-level modularity enables practitioners to tackle one design concern at a time using the corresponding module map depending on the priority they have in the specific DBE setting. On the other hand, at a lower level, the method chunks used under different situations and for the different strategies and intentions in the maps, reflect also the modularity characteristic. The low-level modularity together with the extension mechanism provided by the Map approach enable the adding of new strategies and intentions to the process models (maps) of the method if needed by practitioners. This supports tackling the dynamics of a DBE as practitioners can extend the method by adding strategies and intentions suited for the way how the DBE actors behave, interact, and react to each other in specific dynamic situations in the DBE.

The structure of the overall process of the DBE design method by means of module maps not only supports the dynamics and holism but also increases the feasibility of the method. The feasibility concerning the application of the method is of importance for practitioners, especially when the organisation in studied is a symbiotic DBE context with heterogeneous actors. With the modular approach, different user roles will either be responsible or participate when applying the module maps. In practice, the organisations or actors playing specific DBE roles (c.f. Section 2.1) can be assigned to these module maps as either the responsible or the participant. For example, the actor(s) with the DBE role Governor can be assigned as the responsible for the policies and regulations (PR-map) module map of the DBE method (Fig. 1). This assignment is based upon the responsibility for providing and/or defining the normative contexts of a Governor in a DBE. At a more detailed level, various working roles (such as modeller, DBE analyst, legal content analyst, and lawyer) can be assigned to the method chunks and strategies. For instance, the legal expert meeting strategy being used to achieve I18 analyse coverage of policies and regulations on all actors in Fig. 1 can be assigned to working roles, e.g. legal content analyst and industrial lawyer.

The modularity of the DBE design method and the assignment of DBE roles to the module maps offer practitioners a solid basis for tailoring a more generic DBE design method to the needs of a specific application domain and context. As mentioned above, each of the module maps of the DBE design method proposed in this study supports a design concern when designing a DBE. The design concerns are based on the empirical data and requirements elicited from 10 industrial DBEs in different business domains, including health care, telecommunication, utility, IT, cyber security [9]. Covering these different domains, the design concerns reflected in the module maps are argued to be able to address a considerable range of practical needs when applying to a specific domain for DBE design. The baseline module maps can be used to provide a necessary structure of a DBE and, then, be complimented by the use of the other module maps. Further, the generic DBE roles and the possibility of assigning the generic roles to the use of these module maps is supporting the method to transit from being generic to specific. Because the needs depending on the application domain can be tackled by the individual actors and organisations who are playing these generic roles and adds to the domain-specific context. Building upon this, the extension mechanism of the SME and Map approaches [11, 19, 20] provides concrete means of attending to the needs of tailoring the method for specific application domains with the input from practitioners, individual actors, and organisations.

6.2 Implications for researchers

6.2.1 Design decisions and rationale as design knowledge

Despite the focus being the design artefact, we would like to highlight some of the design decisions made for this study and their rationale as a contribution to the design knowledge for the research community. We believe that the knowledge concerning these design decisions and the rationale can be useful for subsequent or other similar projects and potential future theorisation [39].

While applying SME in this study, we have chosen the product-driven approach for the method engineering process. Through trial and error, we have learned that the lack of existing methods, including the modelling process or procedures and the modelling products, makes it difficult to commence the work of method engineering and/or reengineering. This means that for the studied system or phenomenon, the existing knowledge about of what and how to model the system/phenomenon is scarce, resulting in a difficult situation to design and develop a method. As briefly described in Sect. 4.1, the rationale behind the choice of the product-driven SME approach is that it supports the identification of engineering goals (intentions) of the developed method based on the product parts. Our experience has suggested that the requirements for a method under development can be used to identify the main concepts of the studied system/phenomenon which are highly related the product elements or product parts of the method. These main concepts can, in turn, be used as the basis for intention identification and the subsequent steps of constructing the process or procedures of the method. These design decisions and rationale as descriptive design knowledge may be of use for researchers and be applied to future similar work in method engineering, especially for complex systems under the circumstances that there have not been enough well-established methods and related method procedures and/or processes.

During the development of our proposed artefact, we have observed that many of the main concepts related to DBE are interconnected, meaning that the dependencies between the intentions are highly intricate. This is one of the main reasons why we have not chosen to illustrate an overall process of the DBE design method in a single map. We have tried to create a single map including all the identified intentions. However, we later realised that having the single map with one linear process based on all these intentions for designing DBE would mean to limit the flexibility of the use of the method. By enforcing this inflexibility, the method would risk failing to address the relevant perspectives and the dynamics of a DBE. Also, a single linear process with all the intentions would be extensive and, in turn, reduce the feasibility for the users to apply the method when designing a DBE. Therefore, we have investigated the requirements and main concepts in [9, 10] and categorised them, which leads to different design concerns, each supported by a module map. Instead, guidelines for using these module maps in a comprehensive manner have been established to embed the prescriptive design knowledge, in terms of ensuring the flexibility and feasibility, in the proposed method. We believe that this knowledge concerning the design decision of prioritising modularity to preserve flexibility and feasibility for method process can be beneficial for other similar research projects aiming to design a comprehensive yet manageable and adaptable modelling method.

Owing to the SME approach, the method chunks for the sections in the module maps can be supported by reusing existing modelling methods, especially the product elements. This is one of the main reasons why we have made the design decision for using SME to guide the design and development of our proposed method. We argue that existing methods which are not composite and do not support integration with other methods, are less suitable for the maps and the method chunks of the method proposed in this study. Modelling methods, such as DEMO [40], MEMO [15], 4EM [5], or ArchiMate [41] belonging to the group of multi-perspective modelling approaches are for example appropriate. Multi-perspective modelling approaches are in particular suitable for modelling of the method chunks for DBE because of their ability to present different sets of concepts in different design concerns and dynamics in DBE. There have been attempts to apply ArchiMate to the contexts of DBEs [13, 42]. In the current study, we emphasise the importance of developing the process aspect of the DBE design method as motivated in the introduction. We have not yet elaborated how different enterprise modelling approaches may support a needed or optimal conceptualisation, i.e. meta-models of the strategies. The identification of how existing modelling methods support the method chunks and these module maps as further attempts will complement the DBE design method with focus on the product elements. This will lead to a clearer picture of the method chunks not being supported sufficiently by existing modelling methods and the inadequacy of these methods, which, in turns, felicitates creation of new methods with the SME approach. Hence, in the next step, we intend to conduct comparisons and mappings of the proposed method and its module maps with established enterprise architecture approaches and enterprise modelling methods, including TOGAF [43], ArchiMate [41], DEMO [40], MEMO [15], 4EM [5].

6.2.2 Action research and its generalisability

To validate the DBE design method as the research goal 2 of this study, action research has been applied to carry out an ex ante evaluation in a real (naturalistic) DBE setting of a Digital Vaccine case. Action research is promoted as a suitable approach for both ex ante and ex post validations in real or naturalistic settings for design science research projects [7]. It possesses some advantages such as the feasibility of being applied to real organisational or business settings and the support of generating self-help competencies for the organisations or businesses and, at the same time, scientific knowledge [22, 44], which are two main reasons for the choice of this approach in the current study.

Although there have been discussions concerning action research projects being one-offs leading to challenges of ensuring scientific rigour and generalising the results obtained through action research in other contexts [23, 45, 46], action research as a research approach is suggested as a possibility of tackling the generalisability in information system research [23]. We argue that the traditional way for scrutinising generalisability of a study can only be justifiably applied when generalisations are conducted under the circumstance where the results of a study are being generalised to the contexts where all and only the same context variables stand true [45]. Concerning the dynamics of DBEs, having another DBE context with the exact same context variables is rare. Therefore, in this study, we focus on the analytic generalisation [47] and the naturalistic generalisation [48]. The former means that the findings from the current study are used to refine the DBE design method, which the refined form of the method can be applied to other contexts or by other researchers and practitioners later. The latter means that the generalisability is achieved when the later researchers and users will decide to use the findings of this study in other contexts which falls within the boundary of application of the current study. We have aided the naturalistic generalisation by clearly describing the research context, including the design of the action research, the setting of the Digital Vaccine DBE, and the DBE design method and its validation, in order to provide the later researchers and users a sufficient understanding of the boundary of application of this study.

Despite the concern about generalisability, findings from this study demonstrate the prospective value of the insights gained through action research and the conduction of validation actions with real users, DBE actors, and designers, in a real DBE setting, which could be difficult to achieve by other means. During the validation in action research cycles, we have observed that the DBE design method and its module maps can be used not only to design a DBE but also to urge the DBE actors to rethink the current design. The modularity of the method and the baseline and dependency structure are perceived by the practitioners as useful characteristics as it can support them in addressing the urgent needs of a DBE by providing a list of important design concerns reflecting in each module maps and the guidance on using them. For example, in the end-user performance scenario of the Digital Vaccine case, the feedback dependencies accompanying the use of the KPIs, indicators, and actors’ performance (KIP-map) module map have suggested a revisit to the understanding of the DBE actors (A-map) and the scope (S-map) of the as-is DBE. Because of the monitoring of actors’ performance supported in the KIP-map, new modular producers might be needed or existing modular producers might be unsuitable for specific end users in the DBE, which calls for the redesigning for the to-be DBE concerning actors and their relationships with the use of the A-map. This also encourages the DBE designers to reconsider the means of the current digital platform of the DBE and the possibility of improving the congruence between IT and business in order to better support the transition in monitoring actors’ performance and adjusting of modular producers in the DBE.

7 Conclusions

In this study, we have extended the work presented in [10], wherein the foundations for a novel method for DBE design were laid based on the requirements reported in [9, 10] and elaborated using the Situational Method Engineering as the underlying methodology. Using the Map approach, we have modelled the processes of the design method covering: identification of the design parts modelled by different module maps including the intentions and the method chunk strategies for their achievement, the definition and use of the dependencies between the maps guiding the combinations of compiling of the different design parts to the overall process of the method.

We further presented the validation of the proposal by conducting action research within the Digital Vaccine DBE. In particular, the two in-use business scenarios were in depth presented in the study: “Multiple Wallets for End Users” having the focus on the inclusion of different types of end users being entitled with multiple wallets on the digital marketplace with pre-paid capital from different sources of financial supports; and the second “End-User Performance Building” modelling the cycle of improving end users’ health and evaluating their health performances against their health goals enabled by the DBE’s modular producers and other supporting DBE roles. Benefiting from the use of the proposed method supported by the SME approach, the Digital Vaccine DBE was redesigned using the different strategies for the intentions in the module maps while facing the dynamic issue of new actors joining the DBE. By choosing the most appropriate strategy or strategies among the provided alternatives, the specific needs for the practitioners were met. Because the process of redesigning a certain concern as part of this dynamic DBE issue was facilitated by the chosen strategies base on the practitioners’ intended purposes. As the specific issue and related concerns may limit the practitioners’ view on the important aspects of the redesigning process, the collection of the module maps and the guidelines for using the maps provided the basis for the practitioners to consider the comprehensive and relevant perspectives of the Digital Vaccine DBE.

The motivation for the study is the need to provide business organisations with a holistic yet modularised methodological aid for dealing with the complexity of DBE design. The presented design method is to be used by both scientists and practitioners when designing DBE, a novel multi-actor business structure fostering new relationship characteristics and inclusions compared to some traditional networked models mentioned in the introduction section. The outcome of the design activity using the proposed method should be the establishment of a functioning DBE which takes into account of the important elements of a DBE. Also, the multiple perspectives that are concerned by the various DBE actors should be addressed.

The main direction for future work concerns the elaboration of the method’s product part—i.e. the definitions of the meta-models for the method chunks using the main DBE elements presented in Sect. 2 as the basis, as well as the additional discovered during the empirical research [9] and even in the sessions of the performed action research. Further attempts in the identification of how existing modelling methods support the product part and related method chunks will, in turn, complements the proposed DBE design method.