A method for digital business ecosystem design: situational method engineering in an action research project

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:

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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‐38].

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.

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.