Continuous situation-specific development of business models: knowledge provision, method composition, and method enactment

The development of new business models is essential for startups to become successful, as well as for established companies to explore new business opportunities. However, developing such business models is a continuous challenging activity where different tasks need to be performed, and business decisions need to be made. Both have to fit the constantly changeable situation in which the business model is developed to reduce the risk of developing ineffective business models with low market penetration. Therefore, a method for developing situation-specific business models is needed. As a solution, we refine the concept of situational method engineering (SME) to business model development. SME, in turn, provides means to construct situation-specific development methods out of fragments from a method repository. We develop a concept for the continuous situation-specific development of business models based on design science. The approach uses the roles of a domain expert, a method engineer, and a business developer together with a repository with method fragments for developing business models and a repository with modeling artifacts for supporting the development. Both repositories are filled by utilizing the experience of domain experts. Out of these repositories, situation-specific development methods for developing business models can be continuously composed based on the changeable situation by the method engineer and enacted by the business developer. We implement it as an open-source tool and evaluate its applicability in an industrial case study of developing a business model for a local event platform. Our results show that situation awareness supports the continuous development of business models.


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 depen-dent 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.
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.
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. 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.

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

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

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

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.

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

Situational aspects in business model development
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.

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

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.

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 situationspecific development in the application area of mobile apps but also ensure that they can be generalized to other application areas.
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 Envi-ronment 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.

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

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.

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

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

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.

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

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

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., Stakehold-erGroup, 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, Tool-List) 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 Initialisation-Type (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.

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

Composition of development methods
The second stage, as shown in Fig. 11, aims to compose a development method out of the provided knowledge. 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.

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.

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 develop-mentSkills 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 Informa-tion 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]. 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.

Domain-specific composition of models
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 con- tinuously 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].

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.

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.

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

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

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.

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

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

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.

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 sup-port 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.

Execution
During the conduction, we use our software tool and structure our procedure according to the three stages of (1)  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., mar-ketSize: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.
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 priori- tization) 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.

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

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.

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 over-all applicability. Last, we plan to use data mining techniques to automatically extract the knowledge from various sources (e.g., existing taxonomies).
Funding Open Access funding enabled and organized by Projekt DEAL.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecomm ons.org/licenses/by/4.0/.