1 Introduction

The development of effective business models, defined by Osterwalder et al. as “the rationale of how the organization creates, delivers, and captures value” [61], is an essential task for a company to become successful. A study by CB Insights [15] in 2019 analyzed 101 bankrupt startups and concluded that 42% of them failed due to a missing market need. But also for established companies, the GE Innovation Barometer [32] in 2018 stated that 64% of the over 2000 business executives have the problem of developing effective business models for new ideas. By comparing the results with a previous study in 2015, the challenge is getting even more prominent (59% of over 3000 executives). An important reason is that customers want solutions for their perceived needs rather than just products [82]. Here, the business models can often be even more important than the latest technology of the product [16]. Therefore, organizations are highly dependent on building and continuously updating their business models to stay competitive.

The development of business models is a complex and creative activity that consists of different phases (e.g., discover, develop) where multiple tasks (e.g., conduct customer interviews, analyze competitors) need to be accomplished [31]. Inside those tasks, communication and collaboration between different stakeholders (e.g., business developer, customer) is crucial or even required [19, 20], different alternative decisions for the business model have to be developed (e.g., subscription, advertisement) [4, 75], and underlying hypotheses need to be validated (e.g., sales channel, product price) [10, 57]. To support the business model development, organizations often rely on light visualization tools like kanban boards [42] for structuring the steps of the development method or modeling artifacts like canvas models [61] for structuring the gained information in different development steps. Due to the complexity of business model development, there are several options for each development step. Consequently, a development method with the wrong steps (e.g., interviewing the wrong target group) can lower the quality of the business model. Here, the guidance of domain experts can support the development so that every stakeholder has the same required understanding of the conducted development steps on the kanban board and within the presented information in the modeling artifacts [73]. In literature, different domain experts propose various methods to develop such business models in the form of development methods (e.g., [57, 75]) and method repositories (e.g., [10, 74]). Moreover, these experts provide knowledge in the form of taxonomies of possible (e.g., [2, 46]) and patterns of successful (e.g., [29, 64]) business models. However, the method should match the organization’s current situation (e.g., social media surveys vs. customer interviews based on target market size), and the information in the modeling artifacts needs to match the application domain (e.g., advertisements vs. sales for mobile apps) of the product/service of the organization [23, 77]. This, in turn, raises the chance of developing effective business models.

Fig. 1
figure 1

Classification of Business Model Development Methods

Full size image

Although various Business Model Development Methods (BMDMs) have been proposed, they do not cover the existing, constantly changing context. As shown in Fig. 1, those methods can be classified through their Degree of Controlled Flexibility [44]. Thereby, controlled flexibility is defined as the combination of the free arrangement of the development steps (i.e., flexibility) and the restricted arrangement of the development method (i.e., control). Here, most approaches (e.g., [57]) provide a Fixed Method that does not focus on the organization’s context and applies the same tasks to every situation. Out of the approaches, also the Selection of a Fixed Method (e.g., [57] or [65]) can be made. Some approaches try to cover this lack of controlled flexibility by providing different Configurations of a Method (e.g., [75]) or basic Tailoring of a Method (e.g., [10]). Nevertheless, these existing methods cannot fit every existing and newly detected context in advance (e.g., low vs. high financial resources). This context, in turn, can be considered with the Modular Composition of a Method where the development method and the modeling artifacts can be continuously adjusted to utilized and stored knowledge from domain experts. Therefore, we consider that modular composition by refining the concept of Situational Method Engineering (SME) [47] for BMDMs. Originally, SME is used for the situation-specific composition and enactment of software development methods.

Fig. 2
figure 2

Classification of Business Model Development Tools

Full size image

Moreover, Business Model Development Tools (BMDTs) currently do not cover utilizing and storing knowledge for the development methods and the modeling artifacts. As shown in Fig. 2, we classify selected approaches through their Usage of Modular Knowledge, where we refer to the utilization of existing knowledge for the development method (i.e., knowledge about different development steps within a development method) and the modeling artifacts (i.e., knowledge about different decisions of the business model) to support the business model development. Here, most approaches focus on the pure visualization of business models with No Knowledge about the methods and within the modeling artifacts (e.g., [25]). Some approaches use Method Knowledge to structure the different phases and development steps with predefined knowledge (e.g., [10]). Other approaches use Artifact Knowledge to guide the possible decisions within the modeling artifact with predefined knowledge (e.g., [55]). Moreover, a few approaches use the Combined Knowledge of fixed methods and modeling artifacts to support the structuring of the development method and the creation of the artifacts (e.g., [11]). Nevertheless, these existing approaches cannot utilize the Modular Knowledge of freely definable methods and modeling artifacts from different domain experts. That knowledge, in turn, can be used as a reusable source for the continuous composition of the development methods and modeling artifacts toward a changeable context. Therefore, we consider modular knowledge by using the concept of Model Engineering (ME) [9] within BMDTs. Originally, ME is used to abstract the specific information from the real world into models and make them reusable.

In order to solve those shortcomings in the Usage of Modular Knowledge and the Degree of Controlled Flexibility, we conducted a design science research (DSR) study [49] to create an approach for the continuous situation-specific development of business models. With DSR, we aim to answer the following overall research question (RQ) of: How to enable the continuous situation-specific development of business models? Based on the two shortcomings, we also divide our overall research question into two subquestions that will be answered within the paper. The first one goes along with the Usage of Modular Knowledge. Here, we want to use both the knowledge from methods and models by applying ME to guide the business model development. For that, we need to utilize and store the knowledge of different domain experts in a uniform and structured way. Therefore, the first question (RQ 1) is: How to utilize and store the knowledge of development methods and within canvas modeling artifacts to support the business model development? The second one is related to the Degree of Controlled Flexibility. Here, we want to refine the concept of SME to allow the situation-specific composition of a business model development method for the provided knowledge. This composition, in turn, goes hand in hand with their enaction to support the stepwise development of a business model. Therefore, the second question (RQ 2) is: How to handle the continuous situation-specific composition and enactment of business model development methods using the utilized and stored knowledge? Within DSR, we are using the domain of mobile apps as a well-established market but abstract the approach to situation-specific business model development in general.

Fig. 3
figure 3

Overview of situational method engineering

Full size image

The rest of the paper is structured as follows: Sect. 2 provides our research background regarding situational method engineering and business model development. Section 3 introduces the related approaches according to our work. Section 4 covers our research approach based on DSR. Section 5 shows the derivation of our solution overview from literature and existing tools. Section 6 covers our approach’s different stages of knowledge provision, method composition, and method enactment. Section 7 shows the underlying architecture together with the implemented tool. Section 8 evaluates the approach based on a case study and discusses the results. Finally, Sect. 9 concludes the paper and shows future work for the next DSR cycle.

2 Research background

In this section, we describe the research background of our work in terms of Situational Method Engineering and Business Model Development.

2.1 Situational method engineering

Situational Method Engineering (SME), with its origin in software development, aims to create a development method based on the situation of a specific project [47]. As shown in Fig. 3, which is adopted from [47], SME has the role of a Method Engineer who analyzes various methods and stores them in a Method Repository. Based on the Situational Factors of the project and Construction Guidelines, the Method Engineer composes a Constructed Method that conforms to the Meta-Model. This development method, in turn, is then used by the Project Manager as Enacted Method to guide the development of the project. To structure the Method Base, a method can be divided into method fragments that are reusable atomic blocks that have a process (called work unit), a product (called work product), or a producer focus [14]. These method fragments are combined into method components that transform inputs of work products into outputs of work products and are tailored into methods. To support (situational) method engineering, different computer-aided method engineering tools have been developed that provide various functions like representing different methods, administrating the method parts, selecting the method parts, and assembly the methods [45].

Fig. 4
figure 4

Business model canvas applied to the example of a ToDo App

Full size image

In our approach, we refine the concept of SME to business model development. Here, in contrast to the software development of the Project Manager who enacts the method, we have the Business Developer who enacts the method and conducts the development steps. Moreover, we are not using the existing computer-aided method engineering tools as they are not supporting the integration of business model specific artifacts like canvas models.

2.2 Business model development

The development of business models is a complex activity that often requires collaboration between different internal and external stakeholders [20]. Some approaches like the 4I-Framework [23] propose different phases (i.e., initiation, ideation, integration, implementation) to structure the complex process. Different modeling languages are used inside the different process activities with freely definable connection-based or fixed structured geometric-based visualizations. For the connection-based approaches, the e3-value model [34] offers the modeling of different actors within a value network that can be used to calculate financial assessment. For the geometric-based approaches, light-weight modeling artifacts in the form of canvas models are often used. Here, the Business Model Canvas (BMC) [61], as shown in Fig. 4, is the de-facto standard for representing business models. It divides the Canvas Model into nine Building Blocks (e.g., Revenue Streams, Value Propositions). Every building block can be refined through Elements (e.g., In-App Ads or License Subscription for Revenue Streams). Other examples are the Value Proposition Canvas [62] for product/service positioning or the Platform Canvas [76] for digital platforms’ business models. Thereby the BMC is an abstraction of the Business Model Ontology (BMO) [63], which provides an enhanced syntax and semantics. Moreover, the process can be supported with software tools. Here, most software tools in practice focus on the visualization of the BMC [80], while software tools in research also cover different aspects of decision support [13].

In our approach, we develop a BMDT that can use the knowledge of different provided development methods and canvas models to support the design during the business model development.

3 Related work

In this section, we analyze the related work of our approach. Concerning our problem statement, we divide the work into the business aspects of situational method engineering, situational aspects of business model development, and tools for business model development.

3.1 Business aspects in situational method engineering

In literature, various approaches exist for (situational) method engineering. While many are related to software development, some approaches also cover different business aspects. There exist overall frameworks that support the engineering of methods and models. Here, the ADOxx Metamodelling Platform [21] supports the design of domain-specific modeling methods by defining a meta-model according to the ADOxx meta-model. Moreover, the MetaEdit+ Domain-Specific Modeling Environment [84] supports collaborative modeling based on predefined domain-specific modeling languages. However, those frameworks provide just abstract solutions where concrete approaches need to be directly adjusted to the possibilities of the frameworks.

Moreover, some approaches focus on providing comprehensive development methods and, partially, include business aspects. Here, Morschheuser et al. [59] provide a method engineering approach for gamified software, including business-related tasks (e.g., create personas) and artifacts (e.g., prototype). Fridgen et al. [24] use SME to develop use cases for blockchain technology, including business-related tasks (e.g., cluster ideas) and artifacts (e.g., BMC). Giray and Tekinerdogan [33] use SME to construct internet of things development methods by including business-related situational factors (e.g., business regulations), tasks (e.g., develop IoT Canvas), and artifacts (e.g., IoT Canvas). However, those approaches are just conceptual models with a fixed method base and no software support that have a major focus on the construction of the development methods.

Finally, some approaches focus on the service design related to our application area of mobile apps. Here, van Steenbergen et al. [85] propose a concept for method fragments to assemble data-driven service development methods. Adali et al. [1] propose an approach to provide the identification and definition of business services within organizations. However, those approaches are just conceptual models without flexibility in providing knowledge with software support.

3.2 Situational aspects in business model development

Moreover, in the literature, several approaches already provide methods for business model development. Some of them also cover the implicit or explicit situational aspects in which those business models are developed. Osterwalder and Pigneur [61] provide a handbook with practical guidance on developing business models, including knowledge for the business model in the form of guiding questions, examples, and patterns together with a process that should cover market reactions. McGrath [57] offers a framework for business model development based on sequences of different experiments. Sosna et al. [77] provide a dynamic view of the business model that needs to be continuously updated due to internal organizational and external market changes. However, those approaches do not focus on the construction and change of the development methods due to the changing context.

Moreover, some approaches focus on providing support for the method. Here, Frankenberger et al. [23] provide a method with the four phases of initiation, ideation, integration, and implementation, where an internal fit between initiation and ideation together with an external fit between ideation and integration is needed. Geissdoerfer et al. [31] propose a process consisting of the three main phases of concept design, detail design, and implementation, where each phase has several subphases and tasks. Bland and Osterwalder [10] present a method repository containing various experiments and recommended sequences based on the type of business. However, while the first approaches stay on a high level without concrete implementation, the method repository covers just the single factor of the type of business.

Last, some approaches focus on providing support for the models. Osterwalder et al. [63] introduce the usage of taxonomies based on the BMC to store knowledge and categorize organizations. Gassmann et al. [29] present a broad set of business model patterns that can be used to recombine new business models. Remane et al. [64] provide a comprehensive database of patterns from different domain experts. However, those approaches do not focus on supporting the design on the actual business model using software support.

3.3 Tools for business model development

The development of business models can also be supported with software-based Business Model Development Tools (BMDTs). Here, those BMDTs developed in practice and research can provide different forms of knowledge support. Szopinski et al. [80] analyze various software tools in practice on their features. Most of them focus on the pure visualization of the business model based on the BMC. Fritscher and Osterwalder [25] provide an early software tool to develop business models based on the BMC. In a later version, they provide an adaptation of this tool based on the maturity level of the business developer as a context factor [27]. Meertens et al. developed a meta-model out of the BMO to map the business model to an enterprise architecture [58]. Romero et al. [67] propose a meta-model based on the BMC to simulate different outcomes using system dynamics. Wieland et al. [89] propose generating business plans out of the BMC based on a developed meta-model and an implementation using ADOxx. However, those approaches do not focus on using method and model knowledge.

For the method knowledge, some unified frameworks cover the whole journey of business model innovation. Ebel et al. [19] provide a framework with the phases of environment analysis, business model design, business model implementation, and business model management that are connected to knowledge in the form of shared material (e.g., guidelines to develop business models) and stakeholders within a community (e.g., project team). For the environmental analysis, they suggest using an existing repository of industry benchmarks and market analysis as knowledge together with characterizing the context of the industry, the market, and the customer needs. Terrenghi et al. [83] propose a framework for managing business models according to the four phases of analysis, design, implementation, and control. For the analysis, they mention a collection of relevant information for the environment, the customer, and the competitor. Within the control, they suggest continuity in improving the business model. However, those approaches provide high-level conceptual models without direct software support.

For the model knowledge, some tools cover the support of designing the business model. Szopinski [79] provides creativity support by adding external stimuli to the business model development based on a knowledge repository of possible what-if questions. Luedeke-Freund et al. [55] support the development of sustainable business models based on different business model pattern packs that can be selected from different categories during the development. However, those approaches focus on a single knowledge source and do not cover different development phases.

For the combined knowledge, some tools provide modeling support for different steps during the business model development. De Reuver et al. [17] create an online platform that provides SME decision support in finding proper tools for different phases of the development based on the defined goal of the user. Bosselmann et al. [11] provide a domain-specific language with existing vocabulary based on a knowledge repository to configure, analyze, and compare different business models. However, those approaches do not focus on modularizing knowledge from various domain experts.

4 Research approach

In this section, we show our underlying research approach based on design science research. For that, we introduce the methodology behind design science, followed by explaining our process.

4.1 Design science research methodology

In our research, we conduct a design science research (DSR) study [49] to create a situation-specific development approach for business models. We use DSR as it aims to solve a class of problems by developing a solution to a specific problem and then generalize that gained knowledge [41] based on the development and evaluation of a corresponding IT artifact [49]. Here, we solve the problem of situation-specific development in the application area of mobile apps but also ensure that they can be generalized to other application areas.

Fig. 5
figure 5

Three cycles of design science research (based on [48])

Full size image

Design Science Research, see Fig. 5, can be originated between the Environment where it will be applied and the Knowledge Base where it is founded [48]. Here, the Environment includes organizations with their corresponding problems and opportunities. Those real-world problems are usually brought as requirements into DSR using the Relevance Cycle and need to be constantly evaluated with field testing. Moreover, the Knowledge Base includes existing scientific theories and methods. Those foundations are used as the grounding of the DSR using the Rigor Cycle, and the obtained results need to be pushed back in addition to the knowledge. Both cycles are combined using the Design Cycle in Design Science Research, where artifacts are constantly designed and evaluated [49].

We initiate the Relevance Cycle with recent studies about the problems of business model development in companies using the GE Innovation Barometer 2018 [32] and startups using the CB Insights 2019 report [15]. Moreover, we initiate the Rigor Cycle based on the kernel theories of opportunity creation [3] and boundary objects [78]. The opportunity creation theory states that businesses are co-created under high uncertainty [87]. The development is an entrepreneurial process where companies create a business model based on their assumptions that need to be validated with the customers. Therefore, the process needs both parts of exploitation and exploration. The boundary object theory states that development is a heterogeneous task requiring the collaboration of different stakeholders with different knowledge [73]. Therefore, a common understanding between all stakeholders needs to be achieved. Moreover, we based both the Relevance Cycle’s requirements and the Rigor Cycle’s grounding on an exhaustive review of literature on business model development and a tool analysis of existing business model decision support systems. To connect the Design Science Research with the Environment and the Knowledge Base, we use the field testing of the Relevance Cycle and the additions to the knowledge for the Knowledge Base. For the field testing, we conduct a Feasibility Study and a Case Study on developing business models for mobile apps. For the additions to the knowledge base, we provide Demonstrations of our developed artifact and Publications of parts of our research. In the Design Cycle of Design Science Research, we conducted two cycles based on the cycle of Kuechler and Vaishnavi [53]. According to Gregor and Hevner [41], we position the contribution type of our concept as operational principles that can be transferred to other domains together with our software tool as situated implementation of the artifact. Moreover, we use an exaptation according to the knowledge contribution framework by a refinement of existing concepts toward business model development.

4.2 Design science research process

For our research, we use the cycle of Kuechler and Vaishnavi [53]. The cycle, see Fig. 6, consists of the following five iteratively conducted steps. First, we identify the (1) Awareness of [the] Problem based on a real-world problem and provide a (2) Suggestion of a possible solution. Next, we work on the (3) Development of the artifact and conduct an (4) Evaluation of it. Based on the evaluation results, another iteration is conducted, or our research contributions as (5) Conclusion are provided.

Fig. 6
figure 6

Design science research process

Full size image

In the First Cycle, we got Aware of [the] Problem based on the studies on business model development [15, 32] together with the theories on opportunity creation [3] and boundary objects [78]. That information was used for an exhaustive literature review on business model development and a tool analysis on business model decision support systems. The tools are collected by a systematic literature review. Based on those, we derived the requirements of our solution with a grounding in literature. In Suggestion, we provided conceptual parts for the continuous situation-specific development of business models. Here, we focused on RQ 1 of utilizing knowledge by refining the concept of product line engineering [5] to business models. We modeled all possible business models as a feature model based on the structure of the BMC [36]. Moreover, we developed a method to fill the feature model initially and change the selected features based on the conduction of experiments of a method repository [37]. For the Development, we designed a web-based tool support and implemented the conceptual parts as software fragments. As Evaluation, we conducted a feasibility study to show the applicability of an illustrative scenario. Here, we developed possible business models for a mobile to-do app.

In the Second Cycle, we updated our Awareness of [the] Problem by taking the lessons learned from the last cycle. We saw especially limitations in the method by considering an initial development of all possible business models and their following validation through experiments. Moreover, we saw the limitation of using just the BMC as a modeling artifact. Based on those findings, we updated our requirements for the solution. In Suggestion, we provided an integrated concept for the situation-specific development of business models. Here, we focused on solving RQ2 of composing and enacting methods and improving RQ1 by refining the concept of situational method engineering [47]. We utilized knowledge about possible method parts in a method repository [40] and within possible models in a model repository [35]. Out of those, we provided a situation-specific composition and enactment of the method [39]. For the Development, we designed an architecture and implemented the whole concept as a software tool. As Evaluation, we conducted a case study on developing business models of a local event platform. Finally, we draw a Conclusion with the evaluated concept, the integrated architecture, and the software tool.

5 Solution overview

In this section, we present the solution overview for the continuous situation-specific business model development. We derive those requirements from the literature and tools together with forming a solution overview.

5.1 Derivation of requirements

To provide our approach for situation-specific business model development, we need to solve the current drawbacks of the Modular Composition of the Method and the Modular Knowledge. For that, we review the literature on business model development and analyze decision support systems for business model development to identify potential challenges for our approach and the software tool. Out of this and concerning the theories of knowledge boundary [78] and opportunity creation [3], we derive the requirements (R) of the knowledge utilization, the method comprehensiveness, the model visualization, the context awareness, the selection assistance, the development continuity, the stakeholder collaboration, and the artifact traceability.

R1: Knowledge utilization states that the solution should allow the utilization of knowledge of business model development methods and within canvas models. Literature reasoned that business model development could be supported with knowledge about tasks to be accomplished and decisions to be made [73], where the development process can be as important as the model itself [51]. To utilize that knowledge, well-defined syntax and semantics are needed [86] that can also represent different levels of abstractions [56]. Existing tools provide that knowledge based on meta-models and, partly, shared vocabulary [11]. Based on those meta-models, relevant data can be gathered from different repositories and consolidated [71]. Those tools use the knowledge for the visualization [22] or transformation [7] of the models.

R2: Method comprehensiveness states that the solution should allow support for all phases of business model development. Literature reasoned that the development can be guided through development methods, where some methods stay on a high-level description of the process consisting of iterations of exploration and exploitation [57]. Other methods provide deeper insights into the distinguishment of different phases [23] or the conduction of various experiments [10]. Existing tools are developed for different phases of business model development [13]. Here, some approaches provide overall guidance through the stages [17], deeper integration of specific stages like configuration or analysis [71], or overall phase management on all phases [19].

R3: Model visualization states that the solution should allow visual representations of the canvas models. Literature reasoned that the development can be supported by conceptual models to reduce the complex phenomena of a business [56]. Those models are often based on visualizations on the business model itself [51], and corresponding tasks during the development process [81] exist. However, the most used visualization technique is the BMC [61]. The BMC is also well-applied by software tools in practice [80]. Existing tools provide a visualization of the changes in the business model [25], heatmaps based on influencing factors [12], or customization of the canvas components [11].

R4: Context-awareness states that the solution should be aware of the context in which the business model is developed. Literature reasoned that before the beginning of the development, it is it is essential to understand the context in which the development takes place [77]. Here, the context can consist of internal and external factors of the business [57]. Moreover, approaches can take prior experience in business modeling and industrial characteristics of the business into account [80]. However, just a few studies investigate business model development concerning the specific context of the business [8]. Existing tools use the maturity of the user to support the development [27], provide different business model patterns based on the type of business [55], and support ideation based on the context of the idea [50].

R5: Selection assistance states that the solution should assist the development of business models by selecting business model development methods and canvas models. Literature reasoned that at the beginning of the development, business developers can select from various models and methods [73]. For example, this could be different experiments [10] or patterns [64] from large repositories. Existing tools support the assistance with different guidance levels for varying levels of maturity of the users [27] or the application domain of the service to be developed [55]. Here, the method is guided by a wizard for the different phases [88], and the modeling is supported by a previous questionnaire [68]. Moreover, recommendations for visualizations based on the development goal are given [17].

R6: Stakeholder collaboration states that the solution should allow the collaboration of different stakeholders during the business model development. Literature reasoned that business model development is often a collaborative task [73], where different stakeholders interact during the different phases [6], like the phase of idea generation [20]. In general, there is a division between the internal and external stakeholders of a company [73] and the synchronous and asynchronous collaboration [80]. Existing tools provide basic functionalities for sharing business model ideas among different stakeholders [88]. Moreover, they provide functionalities to discuss and rate business models, including their components [72].

R7: Artifact management states that the solution should provide a management of all (canvas) artifacts that are created during the business model development. Literature reasoned that multiple artifacts are created during the development. Here, traceability can ensure understanding of the reasons behind all changes over time [63]. With that, it is possible to see the evolution of a business model [63], analyze the reasons for failed experiments [57], and develop a change plan [8]. Existing tools visualize the evaluation of business models [26], provide a tracing between current and target business models [7], track the reasons for changes [72], and provide advanced reasoning to managers [43].

R8: Development continuity states that the solution should allow continuous changes in the business model and the business model development method during the whole development. Literature reasoned that during the artifact creation, context changes can be detected, which the organization needs to react to [63]. This is because business models are developed under high uncertainty where not everything can be anticipated in advance [57]. Possible changes can be inside the target market, the value proposition, the value capture, or the value delivery [70]. Existing tools provide that continuity with a loop of experimentation [52] and the iterative validation of business model ideas [18].

5.2 Formation of solution overview

Based on those requirements, we develop an overview of our solution. For that, we consider the two stages of composition and enactment of software development methods from situational method engineering [47] and split up the provision of the method repository from the composition of the method. Therefore, as shown in Fig. 7, our approach introduces the five roles of the Meta-Method Engineer, the Domain Expert, the Method Engineer, the Business Developer, and other Stakeholders, that are centered around the three stages of (1) Knowledge Provision of Methods and Models, (2) Continuous Composition of Development Methods, and (3) Enactment of Development Methods.

Fig. 7
figure 7

Overview of our solution concept with the fives roles and three stages

Full size image

The (1) Knowledge Provision of Methods and Models is used to utilize the knowledge about the methods within the canvas models for the business model development. Here, the Meta-Method Engineer creates meta-models (i.e., R1: Knowledge utilization) for the repositories of the methods and canvas models (1.1). Next, different Domain Experts explain their domain knowledge of existing development methods and canvas modeling artifacts to the Method-Engineer (1.2). The Method Engineer, in turn, formalizes that knowledge in terms of development methods (i.e., R2: Model comprehensiveness) and within canvas models (i.e., R3: Model visualization) according to the meta-models to make it usable within the approach (1.3).

Fig. 8
figure 8

Stage 1: Exemplary knowledge provision of method and models

Full size image

The (2) Continuous Composition of Development Methods constructs the Development Method out of the Method Repository and links method steps to the different Canvas Models in the Canvas Model Repository that are used within the development. Here, the Business Developer of the organization explains the current context in which the business model should be developed to the Method Engineer (2.1). The Method Engineer formalizes these Context Factors as the situation of the Development Method and application domain of the Canvas Models (i.e., R4: Context-awareness) together with composing the Development Method (2.2) (i.e., R5: Selection assistance).

The (3) Enactment of Development Methods executes the Development Process and creates and modifies corresponding Artifacts during the development. Here, the Business Developer executes the constructed Development Method as a Development Process and uses the linked Canvas Models as CanvasArtifacts (3.1) (i.e., R7: Artifact management). Moreover, other Stakeholders can contribute to different development steps and modify CanvasArtifacts during the execution (3.2) (i.e., R6: Stakeholder collaboration). Here, that execution can also lead to a change of the context and, therefore, a modification of the development method (i.e., R 8: Development continuity).

6 Solution concept

Based on our derived solution overview, we present the concept of our continuous situation-specific business model development approach. Here, we show our concept based on the running example of a business developer who develops a business model for a mobile to-do app. We divide the concept into the three stages of knowledge provision of methods and models, the composition of development methods, and the enactment of development methods.

6.1 Knowledge provision of methods and models

As shown in Fig. 8, the first stage aims to utilize and store the knowledge of methods and canvas models from different Domain Experts that can be reused for the composition and enactment of varying development methods. Here, in our running example, we use that knowledge to compose a development method for the business model of a mobile to-do app. The Meta-Method Engineer needs to create a Method Meta-Model and a Canvas Model Meta -Model. For the meta-model of Method Repository, we refine the concept of Situational Method Engineering [47] and use BPMN [60] for visualization. Here, we have the Method Elements, which are the atomic parts of the method. Those elements are combined to Method Building Blocks as single development steps and structured according to Method Patterns for providing an ordering. For the meta-model of the Canvas Model Repository, we refine the concept of feature models [5] and use canvas models [81] for visualization. Here, we have the Canvas Elements, which are atomic parts of the models. Those elements are arranged through Canvas Buildings Blocks as hierarchies and mapped to Canvas Models for visualization.

Fig. 9
figure 9

Method Meta Model of the Method Elements and the Method Building Blocks from the Method Repository

Full size image

Therefore, in this stage, we need to consider the Derivation of Knowledge, the Creation of the Method Repository, and the Creation of the Model Repository.

6.1.1 Derivation of knowledge

In the beginning, the Method Engineer needs to derive the knowledge from the different Domain Experts and store them inside the Method Repository and the Canvas Model Repository. For that, the Method Engineer can use multiple sources and collect different knowledge types.

For the multiple sources, we refer to Lethbrigde et al. [54], who divide between data collection strategies of first-, second-, and third-degree. In first-degree strategies, the Method Engineer stands in direct contact with the Domain Experts. Here, the Method Engineer can use interviews or questionnaires to gather knowledge from the Domain Experts. In second-degree strategies, the Method Engineer collects knowledge without directly interacting with the Domain Experts. Here, the Method Engineer can refer to our tool for sharing the knowledge or record workshops of the Domain Experts for later extraction. In third-degree strategies, the Method Engineer analyzes already existing knowledge of the Domain Experts. Here, the Method Engineer can use the results of single studies or accumulate multiple studies using literature reviews.

For the different knowledge types, we analyzed various studies of Domain Experts. For the methods, we found Domain Experts who provide single development methods (e.g., [57, 75]) or repositories of methods (e.g., [10, 74]). For the models, we found Domain Experts who provide taxonomies of possible business models (e.g., [2, 46]) or patterns/examples of successful business models (e.g., [29, 64]).

6.1.2 Creation of the method repository

To use the derived method knowledge of the Domain Experts, the Method Engineer needs to store it into the Method Repository. For that, the chunks of knowledge are modeled as Method Elements, combined within Method Building Blocks, and structured according to Method Patterns.

The Method Elements, as shown in Fig. 9 on the left side, are atomic parts of the methods that have a name and a description. Moreover, they can be divided into Tasks, Types, Stakeholders, Situational Factors, Artifacts, and Tools. Tasks are the main activities that need to be performed during the business model development. Here, various Tasks on different granularity levels (e.g., Interviews Customer, Create Business Model) can be defined. Types are used to structure the Method Building Blocks and Method Patterns. They can be used as guidance in patterns to connect them to building blocks (e.g., discover, develop). Moreover, there are Types that provide logic to those patterns in the composition stage. Here, patterns with the InitialisationType (e.g., init) can serve as a starting point during the composition, and building blocks and patterns with the GenericType (e.g., generic) can be used in every pattern regardless of the required type. Stakeholders are the persons who are involved in the building blocks (e.g., Business Developer, Development Agency). Situational Factors are used to classify in which situation a building block or a pattern should be applied. Here, Ordered Factors provide Ordered Values based on an ordinal scale (e.g., low < medium < high for developmentSkills). In contrast, Unordered Factors provide Unordered Values as nominal variables (e.g., mass or niche for marketSize). Artifacts are working products created and modified during the business model development (e.g., Customer Information, Product Prototype). Here, CanvasArtifacts are special Artifacts (e.g., Value Proposition Canvas, Business Model Canvas) linked to the Canvas Models in the Canvas Model Repository. Tools are used to support the performing of activities (e.g., Prototyping Tools, Data Analytics Tool). There can be Tools for supporting the Tasks or creating and modifying Artifacts.

The Method Building Blocks, as shown in Fig. 9 on the right side, are combined out of the different Method Elements. Here, a single Task (e.g., Interview Customer) is included in the building block together with multiple Types (e.g., discover). Moreover, for the Artifacts, we allow the modeling of InputArtifacts (e.g., Problem Information) and OutputArtifacts (e.g., Customer Information) so that a Method Building Block can be interpreted as the transformator of the Artifact. For the Stakeholders, Artifacts and Tools, we allow the definition of multiple groups (i.e., StakeholderGroup, ArtifactGroup, ToolGroup), where a single group needs to be selected during the composition of the development method. We include concrete elements or abstract lists of elements (i.e., StakeholderList, ArtifactList, ToolList) inside those groups. While the concrete elements are fixed during the knowledge provision (e.g., Early Adopter as Stakeholder), the abstract lists (e.g., list of Early Adopter, Potential Customer, Angel Investor) allow the selection of a concrete element (e.g., Angel Investor as Stakeholder) during the composition of the development method. This, in turn, allows us to reduce the manual modeling effort in the Method Repository while keeping the method space flexible in a targeted manner. Depending on the type of each Situational Factor, we define an OrderedPair or UnorderedPair as a combination of factor and value (e.g., customerValidity:low).

The Method Patterns are used to assemble the Method Building Blocks in a structured way. Each pattern has a name, a description, at least one Type, additional Situational Factors, and a process part in the form of a BPMN Model. The BPMN Model is a process model with exactly one starting point and at least one ending point. Every activity of the BPMN Model is referred to at least one Type (e.g., design), where another pattern or building block with the same type can be inserted during the composition. Moreover, there are Types with special functionalities. Here, the InitialisationType (e.g., init) refers to independent patterns that can be used at the starting point of the development (e.g., Init Development). Moreover, the GenericType (e.g., generic) defines patterns, which can be inserted into any activity of any pattern regardless of the Type (e.g., Validation Cycle). Last, the definition of Situational Factors is similar to the definition in the building blocks.

6.1.3 Creation of the model repository

To use the derived model knowledge of the Domain Experts, the Method Engineer needs to store it in the Canvas Model Repository. For that, the chunks of knowledge are modeled as Canvas Elements, hierarchical modeled within Canvas Building Blocks, and represented through Canvas Models.

Fig. 10
figure 10

Canvas Model Meta Model of the Canvas Elements and the Canvas Building Blocks from the Canvas Model Repository

Full size image

The Canvas Elements, as shown in Fig. 10 on the left side, are atomic parts of the models that have a name and a description. Moreover, they can be divided into Application Domains, Items, Relationships, and Instances. Application Domains are part of the context in which the model should be applied (e.g., Mobile App, ToDo App). Items are chunks of knowledge about specific parts that can be placed onto a Canvas Model (e.g., Save Privacy, Sales). Relationships are dependencies that can occur between two different Items (e.g., excludes, depends). Moreover, they are predefined Relationships that provide decision support in the enactment stage. Here, Requires shows a strong dependency from one Item to another (e.g., a Business User requires High Privacy). In contrast, Excludes shows an opposing dependency between two Items (e.g., High Privacy excludes Advertisements). Moreover, Supports shows a positive influence on one Item to another (e.g., Content Curation supports High Quality). In contrast, Hurts shows a negative influence (e.g., Mass-Market hurts High Quality). Instances provide a selection of a subset of the Items for a specific annotation (e.g., example, pattern). Here, PatternInstance refers to a subset of Items that are often used together (e.g., Items of Razer-Blade Pattern). At the same time, ExampleInstance maps a subset of Items to an existing example (e.g., Items of Todoist Organization).

The Canvas Building Blocks, as shown in Fig. 10 on the right side, provide a hierarchical structuring of those Canvas Elements. Here, multiple Application Domains can be connected to a building block. Moreover, each building block consists of different ItemTrees that can have a Mandatory or Optional ItemType and an optional XOR or OR ItemRelationship. Those ItemTrees are based on the concept of feature models and generate a hierarchical order with a refinement of Items using child notes. Moreover, the Relationships can be used with the RelationshipSelection as cross-tree relationships between the Items. Last, different Instances of the Items can be grouped through the InstanceSelection. Those building blocks are linked to the CanvasArtifacts of the Method Building Blocks during the composition.

Fig. 11
figure 11

Stage 2: Composition of development methods based on the exemplary knowledge

Full size image

The Canvas Models visualize the building blocks in a structured way. Each model consists of a name and a description together with a canvas grid structure. Here, the upper layers of ItemTrees of the Canvas Building Blocks can be mapped to the building blocks within the grid to create different Canvas Models based on a subset of the linked Items.

6.2 Composition of development methods

The second stage, as shown in Fig. 11, aims to compose a development method out of the provided knowledge. For that, the Method Engineer interviews the Business Developer of the mobile to-do app to get the context in which the business model should be developed. Here, we have the Situational Factors of the company (e.g., customerValidation: low,marketSize:mass) and the Application Domain of the product/service (e.g., Mobile App, ToDo App). Based on the Situational Factors, the Method Engineer composes a Development Method in the form of a BPMN model by combining the Method Patterns and the Method Building Blocks. Moreover, he links each CanvasArtifact in the chosen Method Buildings Blocks to corresponding Canvas Building Blocks based on the Application Domain. The Canvas Building Blocks are consolidated and mapped onto a Canvas Model for visualization. Inside this stage, we stick to BPMN and canvas models as there are well-known in the area of business model development.

Therefore, in this stage, we need to consider the Definition of the Context, the Situation-specific Composition of the Method, and the Domain-specific Composition of the Models.

6.2.1 Definition of context

Before the Method Engineer can start with the construction of the method and the linking of the models, he needs to receive the context for which the business model should be developed from the Business Developer. Here, the context is split up into the Situational Factors of the organization and the Application Domains of the product/service.

The list of possible Situational Factors can be derived from the Method Repository. Here, the Method Engineer selects a suitable subset for the organization and chooses a value for each factor. The list of possible Application Domains can be derived from the Canvas Model Repository. Here, the Method Engineer selects a suitable subset for the product/service. For example, the Method Engineer selects the Situational Factors of customerValidation: low and marketSize:mass together with the Application Domains of Mobile App and ToDo App based on the described situation of the Business Developer of the mobile to-do app.

6.2.2 Situation-specific composition of method

Out of the selected Situational Factors, the Method Engineer composes the method. Here, the provided factors and chosen values are used to give recommendations for Method Building Blocks and Method Patterns of the Method Repository. This is done by automatically ordering the useable patterns and building blocks according to the weighted distance between the required of the organization and provided factors of the building blocks and patterns. Here, the weighted distance is calculated by summing up the distance of each factor value and dividing them by the number of factors. While nominal values for factors need a concrete matching (e.g., mass vs. niche for marketType has distance 1), ordinal values are weighted according to the scale (e.g., provided developmentSkills is medium and required developmentSkills was high has distance 0.5 if developmentSkills can have values of low, medium, high). Moreover, matching values in the including direction (e.g., provided developmentSkills is medium and needed developmentSkills was low has distance 0) are automatically included to cover Method Building Blocks and Method Patterns that outperform the defined situation.

In the beginning, the Method Engineer starts by choosing a Method Pattern with an InitialisationType (e.g., Init Development) ordered by the matched Situational Factors from the Method Repository. Next, he fills each activity with a Type inside that pattern with a Method Building Block (e.g., Interview Customer for discover) or a Method Pattern (e.g., Validation Cycle for validate) of the needed Type or the GenericType. Those patterns and building blocks with the needed Type are again ordered as a list through their weighted matching between their Situational Factors and the factors of the organization. This process is repeated until all activities in the method are filled out with building blocks or patterns. To allow a continuous expansion of the method, extending the first pattern by another pattern of Initialisation Type is possible (e.g., Init Validation after Init Development). After the whole method has been constructed, single items of the groups for the stakeholders, tools, and artifacts inside the Method Building Blocks need to be selected (e.g., choose between the Business Model Canvas or Business Information as Artifact). Moreover, during the composition, concrete elements from the abstract lists need to be selected (e.g., selecting specific prototyping software as Tool).

After all Method Building Blocks have been filled, the last step is to check the quality of the method. To ensure the quality of the method, the approach checks if every Method Building Block is filled out, and for every InputArtifact, there is an OutputArtifact created before in the method. Moreover, the approach gives warnings if Method Patterns or Method Building Blocks are not chosen according to the recommendation of the Situational Factors. More details about our composition of methods are available in [40].

6.2.3 Domain-specific composition of models

Out of the selected Application Domains, the Method Engineer composes the models. Here, the provided domains are used to give recommendations for specific Canvas Building Blocks of the Canvas Model Repository. Iteratively, the Method Engineer selects every Method Building Block with at least one CanvasArtifact as an OutputArtifact (e.g., Create Business Model with the Business Model Canvas). For each linked Canvas Model (e.g., Business Model Canvas), the Method Engineer selects Canvas Building Blocks (e.g., Mobile App) that can be used to provide design support during the enactment.

Because those Canvas Building Blocks can come from various experts with different opinions and terminologies in their domain, the building blocks need to be consolidated before they can be used (e.g., knowledge of Mobile App and ToDo App). For that, the approach allows an automatic merging of Items on the same naming and a manual merging of Items with different namings (e.g., Customer of Mobile App is similar to Private User of ToDo App). Nevertheless, because of the Relationships between those Items, conflicts can occur (usage of support in Mobile App and hurts in ToDo App). For that, the approach provides detection of conflicts between the specific Relationships defined within the Canvas Model Repository.

Fig. 12
figure 12

Stage 3: Enactment of development methods based on the exemplary knowledge

Full size image

To detect conflicts, the approach analyzes the model in the merging process in terms of the possible conflicts (Mandatory vs. Optional, Requires vs. Excludes, Supports vs. Hurts). The most accessible type of conflict can occur by directly comparing two Items (e.g., mandatory Item in Mobile Apps and optional Item in ToDo Apps). Here, the Items can have different Item Types or Item Relationships. Here, the Method Engineer has the choice to choose one option that will be used during the enactment. More computation-intensive is the detection of Relationships that can be across the model’s hierarchy because faulty Relationships can lead to impossible combinations of Items (e.g., unreachable Item in Mobile Apps due to Relationships in ToDo Apps). Here, the approach merges the Relationships step by step into each other and continuously traverse the whole tree to find conflicts. During this merging process, the Method Engineer has to decide how he wants to resolve the conflicts. The outcome of the merging is stored based on virtual links so that resolved conflicts can be easily applied to changes in the Canvas Model Repository. More details about our composition of models are available in [35].

6.3 Enactment of development methods

The third stage, as shown in Fig. 12, aims to enact the development method and allows collaboration between different stakeholders during the development steps. For that, the Business Developer enacts the development methods in a lightweight process engine to receive an executable process.

The process engine is based on a Kanban Board where the development steps out of the composed method are grouped into ToDo, In Progress, and Done steps. Here, the Predefined Method Building Blocks (e.g., Interview Customer) from the composed method are used but also Flexible Method Building Blocks (e.g., Find Target Group) from the Method Repository can be additionally executed. During the execution, the Business Developer can communicate with all other Stakeholders that are mentioned in the definition of the corresponding Method Building Block. Moreover, if the building block is linked to a Canvas Artifact, the different stakeholders can collaborate on the specific Canvas Model. Here, the knowledge from the connected Canvas Building Blocks can be used to recommend Predefined Canvas Elements (e.g., Save Privacy (SP)), but also own knowledge can be used as Flexible Canvas Elements (e.g., High Quality (HQ)). Last, the execution of the development method can lead to a change in the context.

Therefore, in this stage, we need to consider the Execution of the Development Steps, the Artifact Creation in Development Steps, and the Change of Context.

6.3.1 Execution of development steps

For the enactment of the development method, the Business Developer needs to execute various development steps. Those development steps mostly come from the composed method but can also be flexibly selected from the Method Repository during the development. Here, every development step is backed up by a Method Building Block to guide its execution.

During the development, the Business Developer selects a subset of development steps in ToDo and puts them into In Progress (e.g., Create Business Model). While we use a Kanban Board to simplify the execution, our approach also considers and displays the composed BPMN Model during the execution. Here, only the activities ready for execution in the BPMN model are added to ToDo in the Kanban Board. During the execution, the Method Building Blocks define the Stakeholders that need to collaborate on the development step to create and modify OutputArtifacts from given InputArtifacts. For that, each Method Building Block provides a Task (e.g., Create Business Model) together with a description so that all Stakeholders (e.g., Business Developer, Marketing Manager) have the same understanding of the executed process. Our approach includes a discussion feature on the single steps to support the collaboration. This, in turn, helps the stakeholders in the conduction of the Task and the joint creation of the needed Artifacts, including the CanvasArtifacts. After the development step is executed, it is put into Done. Consequently, the execution of steps and the created Artifacts provide traceability in the whole development of the business model.

6.3.2 Artifact creation in development steps

During the conduction of single development steps, the Business Developer needs to develop different OuputArtifacts (e.g., Business Information) from given InputArtifacts (e.g., Market Information). Some of those are CanvasArtifacts (e.g., Business Model Canvas) and, therefore, mapped to specific Canvas Models in the Canvas Model Repository. Thus, the development of those Artifacts can be supported with the knowledge of the linked Canvas Building Blocks from the composition stage.

Here, the development needs to be divided into the development of Artifacts and CanvasArtifacts. Inside both developments, various stakeholders with different knowledge backgrounds collaborate. For the Artifacts, the approach provides a collaborative text editor where the artifact information of the artifact (e.g., Customer Information) or the link to the artifact (e.g., Prototype) can be deposited. For the CanvasArtifacts, the approach provides a collaborative canvas editor based on the knowledge of the linked Canvas Building Blocks (e.g., Mobile App) from the composition stage. Here, the predefined explanations in the Canvas Model Repository ensure that all stakeholders have the same understanding of what the Canvas Model is used for and which meaning the different Canvas Elements (e.g., Subscription) have. The Canvas Model can be filled with predefined Items or with newly defined Items. Based on the predefined Items, design support is possible by visualizing their Relationships. Here, the approach can show missing (e.g., Professional User requires Save Privacy) or contradicting (e.g., Save Privacy excludes In-App Advertisements) Items. Moreover, hints of positive (e.g., Cheap Price supports Mass Customer) and negative (e.g., High Price hurts Mass Customer) influences can be given. Last, the Instances of Items can be used to suggest possible business model patterns (e.g., Razer-Blade) or provide comparisons to existing organizations (e.g., Todoist).

6.3.3 Change of context

Finally, the conduction of single development steps can also lead to a change of the context. Here, the Business Developer of the mobile to-do app needs to contact the Method Engineer to update the Situational Factors and/or the Application Domains and, thereby, the resulting composed method.

In order to adapt to those changes, the approach provides different possibilities. First, the adaptation has just small influences on the composing method in future steps. Here, the Method Engineer replaces Method Patterns and Method Building Blocks for the method or Canvas Models and Canvas Building Blocks for the models in the future (e.g., no artifacts need to be updated). Second, the adaptation has medium influences that lead to changes in the past development. Here, the Method Engineer replaces Method Patterns and Method Building Blocks for the method or Canvas Models and Canvas Building Blocks for the models together with executing the affected development steps again (e.g., possibility of updating the affected artifacts with a new version). Third, the adaptation has high influence that leads to massive changes in the composed development method. Here, the Method Engineer composes a new method, exports the created Artifacts from the old method, and imports them to the new method (e.g., old artifacts could be reused or updated in the new process).

7 Solution implementation

Based on our developed solution concept, we present our implemented software tool. For that, we show our underlying architecture and provide insight into the tool.

7.1 Integrated architecture

The high-level architecture of our tool can be seen in Fig. 13. It consists of the external Database to store the Methods, Models, and Development Methods together with the Method Engine, the Model Engine, and the Development Method Engine. The Method Engine is used to provide the method repository needed for the composition of the development method. For that, the Method Editor receives the Method Knowledge and has features to create/update/delete the single method elements, method building blocks, and method patterns. All those method knowledge is stored in the Method Repository for later usage. Similarly, the Model Engine is used to provide the model repository needed for the composition of the development method. For that, the Model Editor receives the Model Knowledge and has features to create/update/delete the single canvas elements, canvas building blocks, and canvas models. All those model knowledge is stored in the Canvas Repository for later usage.

Fig. 13
figure 13

Component-based architecture of our solution

Full size image

The Development Method Engine consists of the Development Method Composer and the Development Method Enactor. The Development Method Composer takes Context within the Context Manager and splits it up into the Situational Factors for the Method Composer and the Application Domains for the Model Composer. The Method Composer takes those Situational Factors and the Methods to compose the situation-specific method. The Model Composer takes those Application Domains and the Models to compose the domain-specific models. Moreover, the CanvasArtifacts of those models are linked to the development steps of the method.

The Development Method Enactor uses the Development Method for execution, where different stakeholders provide Information (e.g., discussion posts, artifact parts) for the development. Here, the Method Enactor executes the different development steps with additional knowledge about the Methods. During the execution of each step, the Model Enactor can be used to work on the CanvasArtifacts with additional knowledge from the Models. Moreover, within the Collaboration Manager, the different stakeholders can work together on the Artifacts, including the CanvasArtifacts. Here, the Artifacts and the CanvasArtifacts can be stored within the Artifact Manager. Last, a Business Model is created out of the conduction of the development steps.

7.2 Software tool

Our developed BMDT is called Situational Business Model Developer. The tool supports all three proposed stages, is released as open-source,Footnote 1 and can be directly used in the web browser.Footnote 2 For that, the tool is based on the web technologies of AngularFootnote 3 and PouchDB.Footnote 4 In the following, we show the usage of our tool for specific steps of our stages.

Fig. 14
figure 14

Stage 1: Creation of a method pattern and a canvas model

Full size image

First, we have (1) Knowledge Provision of Methods and Models. For the methods, method elements are combined to method building blocks and structured according to method patterns. Such a method pattern is shown in Fig. 14a. Here, we have the A) BMPN Model, which can be used to structure Method Building Blocks or other Method Patterns using B) Type Placeholders. Moreover, different C) Types and D) Situational Factors can be defined for the method pattern. For the models, canvas elements are structured through canvas building blocks and visualized through canvas models. Such a canvas model is shown in Fig. 14b. Here, we have the Business Model Canvas as E) Canvas Model where a F) Canvas Building Block is mapped too. Moreover, different G) Application Domains can be defined for the canvas model.

Fig. 15
figure 15

Stage 2: Definition of context and situation-specific composition of method

Full size image

Second, we have (2) Continuous Composition of Development Methods. For that, we first need to define the context, as shown in Fig. 15a. Here, we use a subset of the H) Application Domains of the canvas model repository and I) Situational Factors of the method repository. After that, we need to compose the method based on the situation, as shown in Fig. 15b. Starting with an InitalisationType, we stack different J) Method Patterns into each other and fill the activities with abstract K) Incomplete Method Building Blocks or I) Complete Method Building Blocks. After that, we need to open those K) Incomplete Method Building Blocks and choose concrete instances.

Fig. 16
figure 16

Stage 3: Execution of development steps and model creation in development steps

Full size image

Third, we have (3) Enactment of Development Methods. For that, we need to execute the development steps, as shown in Fig. 16a. Here, we see a M) Kanban Board, where all executable N) Development Steps are displayed. Those steps can come from the predefined development method or be flexibly defined during the development. Moreover, for each N) Development Step, we provide information and execution guidelines together with collaboration features. One type of collaboration is model creation, as shown in Fig. 16b. Here, we have a O) Canvas Artifact, where predefined model knowledge or own model knowledge can be used during the development. Moreover, with the predefined knowledge, we provide P) Decision Support like conformance errors or missing elements.

8 Evaluation

Based on our developed solution concept and the implemented software tool, we conducted a case study on developing possible business models for a local event platform called OWL Live. Based on the guidelines of Runeson and Höst [69], we divide that evaluation into steps of forming the experimental setting of the evaluation, followed by execution, the analysis of the results, and their interpretation concerning our approach.

8.1 Experimental design

In the beginning, we need to define the experimental design in which the case study takes place. Due to the guidelines of Runeson and Höst [69], the design can be divided into the Definition of a Case, the Initiation of a Case Study Protocol, and the Clarification of Ethical Considerations.

For our study, we justify our Definition of a Case based on the elementary parts of the Objectives to achieve, the Research Question to answer, the Theory to concern, the Case to study, the Methods to rely on, and the Selection Strategy to use as discovered by Robson and McCartan [66]. The Objective of the study directly relates to the aim of the design science study to develop a situation-specific business model development approach. With this explorative purpose of our study [66], we want to gather new insight about our approach and find future research aspects for the third DSR cycle. For that, we aim to answer our Research Question of how to enable the situation-specific development of business models, including our subquestions, and apply the Theory on boundary objects. As the Case, we provide a holistic, single unit, case study on developing the business model for a local event platform called OWL Live. The platform is created as part of an ongoing research project and acts as a two-sided platform between event providers and event visitors. Here, the owner wants to use new data mining techniques to aggregate events from different providers together with natural language processing to provide an enhanced recommendation system to the visitors. Developing the business models in an ongoing research project also has two specialties that we need to consider during the development. First, the project is backed up by a consortium of public institutions (i.e., university, culture office) and a private company (i.e., development agency) involved in the platform. Second, the project partners have already discovered parts of the business models as parts of discussions, design thinking workshops, and a preliminary feasibility study on which the business model should base. As Methods to collect data and corresponding Selection Strategy, we conduct interviews with the project manager to gather information on the topics of the knowledge repositories and the context of the development method. Moreover, we use Grey Literature Reviews (GLRs) [28] to provide knowledge in terms of methods and models. Moreover, we analyze the existing information generated through discussions, design thinking workshops, and a feasibility study in the past. While some of the information is publicly accessible (e.g., the feasibility study), other information is confidential (e.g., current monetization calculation).

Next, we need to provide an Initiation of a Case Study Protocol. Here, the protocol is a continuously changed document that keeps track of the study’s execution, used to analyze the results and draw conclusions regarding the interpretation. A text document captures all information outside the tool support for our case study. For all stages, we use our software tool.

Last, we need to provide a Clarification of Ethical Considerations. We consider the following things: First, we explain the case study to the project manager and inform him about the whole procedure. Second, we state our data collection and storage strategy. Third, we clarify the publication of parts of the study and omit the release of confidential information.

8.2 Execution

During the conduction, we use our software tool and structure our procedure according to the three stages of (1) Knowledge Provision of Methods and Models, the (2) Continuous Composition of the Development Methods, and the (3) Enactment of the Development Methods.

In the stage of (1) Knowledge Provision of Methods and Models, we interviewed the project manager to get the scope for which the business models should be developed. Out of that context, we conducted two GLRs according to Garousi et al. [28] to gather method knowledge about business models for mobile apps in general and model knowledge for business models of digital platforms, digital marketplaces, and content aggregators. With the knowledge of the GLRs, we filled the Method Repository with Method Elements, grouped them into Method Building Blocks, and arranged them into Method Patterns. Moreover, we filled the Canvas Model Repository with Canvas Elements, arranged them into Canvas Building Blocks, and mapped them on Canvas Models. Here, we used the existing Value Proposition Canvas and Business Model Canvas together with a new defined Feature Set Canvas. Moreover, the highlights of our Method Repository can be accessed in our research paper [40] and the whole repository inside the corresponding technical report [38]. Last, the results for both repositories can be accessed in our tool.

Inside the stage of (2) Continuous Composition of Development Methods, we interviewed the project manager to gather information about the current state of the platform (e.g., target customer), the situation of the project (e.g., marketSize:mass), and the application domain of the app (e.g., content aggregation). Out of that context, we composed the development method as shown in Fig. 17. We structure that method through our extracted business model initialization pattern according to the discovery, analysis, design, development, and validation phases. In the Discovery, we suggested identifying different target groups of the platform together with observing their pain points and the discovery of store trends to broaden the ideation scope of potential features. While for the event provider, we suggest customer interviews, the event visitors could be reached using social media. In the Analysis, we suggested estimating the current market potential and analyzing the competitors inside and outside the store. In the Design, we gathered information on the last phases that could be used to develop potential feature sets, value propositions, and business models for the platform with the support of the knowledge of the linked canvas models within the canvas model repository. Moreover, we suggested providing a competitive advantage analysis and prioritizing the feature according to those results. In the Development and with the additional information of the project manager, we suggested developing a beta-version in front of the product development, which should be validated intermediate. Moreover, during the actual product development, we recommend using concurrent marketing in terms of inbound and outbound marketing. Last, in the Validation, we proposed the ongoing validation of both customer groups by using the scalable approach of surveys.

Fig. 17
figure 17

Composed development method for OWL Live based on the identified context

Full size image
Fig. 18
figure 18

Developed business model and SWOT analysis for the content aggregator

Full size image

Inside the third stage of (3) Enactment of Development Methods, we used the ongoing interviewing of the project manager together with the already existing information of the project to develop possible business models. We structured that development according to the accomplished phases of discovery, analysis, design, and the ongoing phase of develop. During the Discovery, the first groups of event providers and event visitors were identified and refined into different subgroups (e.g., culture actors for event providers, early adopters for event visitors). Moreover, different trending apps (e.g., social networks, news aggregations) were analyzed regarding possible features (e.g., invitation mechanism, social media connection) and business models (e.g., paid recommendations, affiliate marketing) of the platform. After that, the primary sources of event findings (e.g., word of mouth, posters) were identified and analyzed. While the customer interviews for the event provider were conducted in the design thinking workshop before, the survey was conducted with an analysis of results from an existing social media website and the conduction of new polls on a local social media app. During the Analysis, the results of the existing feasibility study were strengthened by a market analysis by identifying key factors about the market (e.g., estimation of events) and the potential market groups (e.g., different visitor groups). Moreover, the existing competitors in terms of general apps (e.g., ticket sellers, social networks with event features) and local providers (e.g., city marketing, newspapers) were analyzed. During the Design and based on the knowledge of the canvas model repository, the Value Proposition Canvas, the Business Model Canvas, and the Feature Set Canvas were developed. The value proposition was designed for the chosen target groups of event providers (e.g., already digitized providers) and event visitors (e.g., early adopters). The business models for the three different ideas of a content aggregator (e.g., personalized advertisements, affiliate links to existing ticket sellers), an own ticket seller (e.g., personal arranged relationships, commission fee), and a sponsored platform (e.g., privacy-friendly usage, independent prioritization) were designed. Moreover, a new development step of SWOT analysis, including a SWOT Canvas Artifact, was conducted to analyze the different ideas. Last, the feature set for the platform was created, and a competitive advantage against the competitors was conducted. A simplified overview of the business model and the SWOT analysis for the content aggregator can be seen in Fig. 18a, b. Currently, in the Development, the app’s beta version is developed, while the ongoing interviews and surveys should validate the different business models and feature sets. Moreover, inbound marketing (e.g., landing page, social media posts) is planned to ensure high traffic during the upcoming beta.

Table 1 Comparison of our approach against existing approaches and tools
Full size table

8.3 Analysis

Our design science study aims to answer the overall research question (RQ) of how to enable the situation-specific development of business models. For that, we refined our RQ into the first question on how to utilize the knowledge (RQ 1) and the second question on how to compose and enact the development method (RQ 2) together with comparing our approach against existing solutions.

To evaluate the Utilization and Storage of Knowledge, we have conducted a GLR as an indirect method to create a Method Repository and a Canvas Model Repository. For the Method Repository, identifying Method Elements and their combination into Method Building Blocks was straightforward. Here, arranging the Method Patterns was a bit challenging due to the nested usage of patterns to allow specific orchestration of the development method during composition. For the Canvas Model Repository, identifying single Canvas Elements was relatively straightforward. Here, problematic was just the dimension of finding related elements for all building blocks of the canvas models and prioritizing which elements should be taken and which not. Moreover, most GLR results for digital platforms stayed just on a high level without providing any insights. More challenging was the development of Canvas Building Blocks. Here, it was hard to find the right granularity of the decomposition of the elements together with the mapping of item sets to instances and connecting items through relationships. Again, the presentation of building blocks to Canvas Models was easy. Overall, the utilization of knowledge was applicable with respect to RQ1. Nevertheless, it is advisable that a skilled Method Engineer does the steps of formalization of the knowledge instead of the Domain Expert.

To evaluate the Composition and Enactment of the Development Method, we developed possible business models for the local event platform. For the Composition of the Development Method, we have interviewed the project manager to gather the context in which the development takes place. While the context factors can be easily defined (e.g., marketSize:mass), additional information (e.g., different customer groups) about the project must be considered for the composition. During the composition, we investigated that working with the patterns can be a challenging task. In contrast, the composition of models was relatively straightforward with the limitation that we developed all knowledge. However, a subsequent interview with the project manager reveals that the guided composition supports identifying additional development steps. For the Enactment of the Development Method, we have executed the development method in close exchange with the project manager. During the case study, we have gathered results for the first four stages while the platform is currently developed within the fourth stage. Here, we followed predefined development steps of the composed development method but also conducted flexible steps. During the execution, the descriptions of the steps support a common understanding among all stakeholders. Moreover, the tool provided traceability of the approach while the artifacts supported the collaboration and later transparency. The main results were the different developed canvas models in the third stage. A discussion with the project manager regarding the different business models revealed their relevance and the possibility of identifying new decisions (e.g., lock-in mechanism). Overall, the composition and enactment were applicable with respect to RQ 2, and the guidance shows potential during the composition and enactment. Nevertheless, it is advisable that a skilled Method Engineer does the steps of the composition of methods and models instead of the Business Developer.

To provide a Comparison of our Approach and show the benefits against existing solutions, we compare it against existing approaches (see Sect. 3.2) and tools (see Sect. 3.3) for business model development, as shown in Table 1. Here, the existing approaches are mostly focus on an manual offline setting (e.g., Design Thinking Workshops [30]), where existing knowledge for methods and models can be gathered through books (e.g., Business Model Generation [61]) or workshop cards (e.g., Business Model Pattern Cards [29]). The knowledge for a specific context needs to be selected manually to provide a composed development method (e.g., experiments from Testing Business Ideas [10]) and models (e.g., a taxonomy of mobile apps [36]). Those composed development methods can be used as a guideline for development steps to conduct (e.g., steps to do on a Kanban board [42]) and (canvas) artifacts to create (e.g., Business Model Canvas as structure [61]). Existing tools in practice focus on providing visual structures and collaboration features (e.g., comparison of different tools in [80]). Tools in research mostly focus on the provision of a fixed set of method knowledge (e.g., pattern packs in [55]) or a simple explanations of existing methods (e.g., different techniques in [17]). Moreover, those tools do not provide a composition stage for selecting the knowledge so that also different contexts are just partially supported (e.g., different goals in [17] for methods or different categories in [55] for models). During the enactment, they allow the execution of fixed processes (e.g., different steps for discovery, design, and analysis in [11]) and the management of (canvas) artifacts (e.g., versioning of business models in [25]).

8.4 Interpretation

One reason for our explorative case study during DSR is the derivation of suggestions for further improvement for the third cycle. For that, we analyze our current threats to validity and derive further implications.

In order to critically discuss the Threats To Validity of our evaluation, we use the framework of Yin et al. [90], which divides between the criteria of construct validity, internal validity, external validity, and reliability. Construct Validity refers to guaranteeing that the most verifiable case study results are based on the research question. To achieve that, we follow an explorative purpose to conduct all stages mentioned in our approach. However, there is the limitation that our case study relies on a single unit in one case instead of multiple units in different contexts. Due to that single unit, we could not compare our results against other approaches by measuring efficiency and effectiveness. Internal Validity refers to establishing trustworthiness due to casual relationships during the case conduction. To achieve that, we follow the guidelines of Runeson and Höst [69] to use a well-established procedure. However, there is the limitation that we - with experience in the approach and the software tool - develop the business model with the support of the project manager instead of being independently developed by the project team without prior experience. External Validity refers to the extent to which the results can be applied to other cases. To achieve that, we follow the design science procedure of Vashnavi and Kuechler [53], which aims to abstract the gained knowledge to solve most cases in the problem class. However, there is the limitation that our knowledge is currently narrowed down to our findings in the grey literature reviews. Reliability refers to the reproducibility of repeating the case study. To achieve that, we use a case study protocol together with a mix of direct and independent selection methods. However, the development of business models is a creative task, so repeated conduction by stakeholders with different knowledge backgrounds can lead to different results.

Moreover, we found some Implications for the next cycle. We divide those implications into the three areas of knowledge generalization, complexity reduction, and multiple unit analysis. For the Knowledge Generalization, we currently have just a base of knowledge for methods and models that focuses on mobile applications and, in particular, on event apps. This, in turn, limits the approach’s applicability in other cases. Therefore, we want to extend the knowledge with a special focus on methods and models for different types of mobile applications. For the Complexity Reduction, we currently focused on the applicability of all stages of our concept inside the software tool and dismissed a user experience that is easy to understand. This, in turn, limits the usage of the tool by end-users. Therefore, we want to increase the usability of the approach so that end-users can use it without prior introductions. For the Multiple Unit Analysis, we currently have applied the approach to the case of a local event platform. This, in turn, limits the evaluation if the approach can be easily transferred to other scenarios. Therefore, we want to validate the transferability by creating several business models in different contexts within a user study. Moreover, we plan to evaluate our approach against similar approaches by measuring efficiency and effectiveness.

9 Conclusion and future work

The development of business models is a challenging task that can be supported by the knowledge of methods and models from different domain experts. Here, the knowledge needs to match the organization’s situation and the application domain of the product/service. Using two cycles of DSR, we have developed a situation-specific business model development approach with the three stages of knowledge provision, method composition, and method enactment. We have implemented the whole approach in an open-source software tool and conducted a case study on developing possible business models for a local event platform. The evaluation shows that situation awareness can support the development of business models, while our approach has some limitations that we need to solve in the next DSR cycle.

In the future, we will conduct a third DSR cycle to work on the extensibility of our approach, evaluate its usefulness in different contexts, and use automation for knowledge provision. For that, we plan to modularize our concept so that single development steps (e.g., calculate business outcome) can be supported by different software modules. Moreover, we will evaluate our approach based on a user study where mobile app business models should be developed in different contexts (e.g., mass-market). Here, the end-users should directly use the software tool themselves to validate the overall applicability. Last, we plan to use data mining techniques to automatically extract the knowledge from various sources (e.g., existing taxonomies).