Introduction

Major challenges in contemporary information systems (IS) development, such as rapid technological advancements, continuously changing requirements (Norbjerg, 2018), increasing customer demands, shortened application release cycles (Babb et al., 2017), more complex application systems, and limited resources, demand new development approaches. The transformation of complex and monolithic application systems into innovation platforms that provide basic application services and attract external developers for an innovation ecosystem increases the overall generativity with additional apps, themes, and software integrations (Aulkemeier et al., 2016a; Hein et al., 2020). This transformation allows for continuous application engineering and delivery (Dittrich et al., 2018). However, it requires the implementation of boundary resources that enable collaboration and value co-creation among different types of actors by translating diverging viewpoints and interfacing an innovation platform’s application services (Ghazawneh & Henfridsson, 2013; Star, 2010). Boundary resources as a means for opening an innovation platform propel the ecosystem’s generativity, influence the relationship between a platform owner and third-party developers, and thus increase the platform adoption by third-party developers (Eaton et al., 2015; Engert et al., 2022; Miremadi et al., 2023). Examples of boundary resources include application programming interfaces (APIs), integrated development environments (IDEs), and software development kits (SDKs) with related documentation (Dal Bianco et al., 2014; Eaton et al., 2015; Ghazawneh & Henfridsson, 2010) that provide external developers with access to the core functions of the platform (Karhu et al., 2018). Platform boundary resources need to be altered and updated continuously to cope with new market developments, create new business opportunities, and protect the platform against exploitation by third parties (Eaton et al., 2015; Ghazawneh & Henfridsson, 2010; Jansen et al., 2013; Karhu et al., 2018). As demarcation points between an innovation platform and ecosystem participants (Santos & Eisenhardt, 2005), boundary resources bring about a strategic value to the platform owner and need to be managed carefully (Bondel et al., 2021; Vester, 2018; Y. Yoo et al., 2010). Obtaining control over the boundary resources of an open platform is a key element of a platform owner’s ecosystem governance (Baldwin & Woodard, 2009; Boudreau, 2010; Pon et al., 2014; Schilling, 2000).

Following the seminal works of Star and Griesemer (1989) as well as Ghazawneh and Henfridsson (2010), the research interest on boundary resources in the context of digital platforms and their surrounding innovation ecosystem is on the increase. Dal Bianco et al. (2014) analyzed the use of boundary resources in several software ecosystems. Karhu et al. (2018) compared the use of boundary resources with the licensing of a platform’s intellectual property. While Petrik and Herzwurm (2020) investigated boundary resources for industrial internet of things scenarios, Wulfert et al. (2022) focused on the implementation of boundary resources in e-commerce ecosystems. Although boundary resources are generally applicable in innovation ecosystems in different domains (Ghazawneh, 2012), scientific literature on the management of boundary resources is scarce.

Owing to their strategic relevance for innovation platforms (Boudreau, 2010; Y. Yoo et al., 2010), a comprehensive management approach that covers the whole lifecycle from the design to the retirement of the boundary resources is necessary to exploit their full potential. A lifecycle model for boundary resources can be used “as a common reference for communication and understanding” (ISO, 2017, p. 25) among ecosystem participants. Since boundary resources involve and are concerned with software artifacts, we apply an application lifecycle perspective for developing a boundary resource management approach. The concept of application lifecycle management (ALM) is made popular in the Information Technology Infrastructure Library (ITIL) with its application management functions (Fischbach et al., 2013). Many ALM lifecycles in the literature (e.g., Hallerstede et al., 2011) are inspired by the application management cycle included in the ITIL framework (AXELOS, 2012). The ALM considers the entire lifecycle of a software artifact by describing how the software development process should take place from the initial development phase up to the delivery phase and subsequent maintenance (Lacheiner & Ramler, 2011). The global market for ALM is expected to grow to USD 5 billion by 2027, with USD 2.8 billion specifically advocated for ALM tools (StrategyR, 2022). The most popular tools for ALM are, among others, Jama Software, Atlassian Jira, Microsoft Azure DevOps, and Visure (Aston, 2022; Jwo et al., 2013).

Although ALM bears a high potential for innovation ecosystems and although ALM seems to be a promising approach for managing boundary resources, the current body of literature does not consider boundary resources. Research investigated several specializations of ALM for, among others, security management (Demchenko et al., 2017; Zeng et al., 2021), data management (Alhassan et al., 2016; Chen & Zhao, 2012; Khatri & Brown, 2010), cloud application monitoring (Aversa et al., 2015), cloud application provisioning (Benfenatki et al., 2017), and sensor networks (Kabac et al., 2016). Moreover, existing research only focuses on single lifecycle phases, such as retirement (Yu et al., 2017), or investigates APIs as specific artifacts. Several practitioner-based lifecycle approaches exist for API management (Ebert, 2012; Medjaoui et al., 2021; Rossberg, 2014; Vester, 2018; Weir, 2019; Zulian & Bouza, 2021), but without identifying an agreed-upon approach (Bondel et al., 2021).

We therefore go beyond an isolated view on APIs and take a broader perspective on boundary resources for innovation platforms that include technical (e.g., APIs, SDKs) and non-technical (e.g., documentation) artifacts. With this approach, we cover the whole lifecycle of a boundary resource from design to retirement. We provide literature on ALM, with a dedicated lifecycle model on boundary resources required for inter-company and ecosystem-wide collaboration and value co-creation (Engert et al., 2022; Wulfert et al., 2022). While platform owners gain a customizable reference procedure model for the management of boundary resources and the attraction of third-party developers, these developers can anticipate boundary resource evolutions with regard to the reference model. We make use of initial but roughly designed processes for boundary resource management (e.g., Ghazawneh & Henfridsson, 2010; Hein et al., 2019; Star, 2010) and provide a comprehensive reference procedure model. Furthermore, we also consider organizational aspects to ensure an adequate degree of platform openness and ecosystem generativity (Blaschke & Brosius, 2018; Boudreau, 2010). Against this backdrop, we raise the following research question:

How can boundary resources of focal platforms in innovation ecosystems be managed?

To address this research question, we apply a design science research (DSR) approach (Takeda et al., 1990; Vaishnavi et al., 2019). Our DSR approach involves a literature synthesis on ALM in general and boundary resource management in particular (vom Brocke et al., 2015; Webster & Watson, 2002), analyzing the boundary management of selected innovation platforms in e-commerce from the theoretical lens of ALM (Niederman & March, 2019; Yin, 2018). In addition, our DSR approach also involves an evaluation of these findings, with the analysis of nine expert interviews to check our developed lifecycle model and to gain further insights on internal boundary resource development (Misoch, 2015). We chose the e-commerce domain for our boundary resource analysis, as several types of participants are orchestrated using digital technologies in e-commerce ecosystems (Wulfert et al., 2022). Furthermore, collaborative and distributed software development supports diverse electronic business models (Alt, 2020; Aulkemeier et al., 2016a; Timmers, 1998). We propose the boundary resource management lifecycle as a reference procedure model for owners of innovation platforms to implement sophisticated boundary resources and to attract additional third-party developers with their extensions. We provide a detailed reference procedure model for the management of boundary resources to the literature on ALM. Moreover, we emphasize the role of supplementary social boundary resources to enable the use of technical boundary resources by third-party developers.

The remainder of this research paper proceeds with an elicitation on related literature on innovation platforms as the technical foundation of e-commerce ecosystems, existing approaches for boundary resource management, and ALM introduced as the theoretical lens of this research. Second, we elaborate on our DSR approach, incorporating a systematic literature review, a multi-case study, and an evaluation based on an interview analysis. Third, we present our boundary resource management lifecycle by describing the derived layers and single lifecycle stages for technical boundary resources and by mapping them with related supplementary boundary resources. Finally, we discuss our results, provide a research agenda for potential avenues for future research, and briefly present our conclusions.

Related literature

Innovation platforms in e-commerce ecosystems

Facilitated by the ongoing digitalization of the retail sector, (parts of) retail and wholesale functions (e.g., bridging, information, storing) are performed digitally to a certain degree in e-commerce (Laudon & Traver, 2020). In e-commerce, transactions involving information, products, and services are executed using information and communication technology (Choi et al., 1997; Nath et al., 1998; Zwass, 1996). E-commerce ecosystems are conceptualized as manifestations of digital business ecosystems in the context of e-commerce, centered around a focal transaction platform (Wulfert et al., 2022; Yi & Ming, 2011). The transaction platform orchestrates several types of independent ecosystem participants, such as manufacturers, customers, and service providers (Böttcher et al., 2021), who share a common interest, depend on each other, and co-create value (Blaschke et al., 2018; Iansiti & Levien, 2004; McIntyre & Srinivasan, 2017; Wareham et al., 2014). Benefitting from direct and indirect network effects (Armstrong, 2006; Shapiro & Varian, 1998), the value of an e-commerce ecosystem for each participant increases with additional participants joining (Hinz et al., 2020). The purpose of an e-commerce ecosystem is the exchange of physical and digital products for the benefit of a customer (Adner, 2017; Wulfert et al., 2022).

The technology-supported transactions in e-commerce ecosystems are enabled by innovation platforms that provide the necessary application services for the exchange of goods between and value co-creation among ecosystem participants (Aulkemeier et al., 2016b; Blaschke et al., 2019b; Wulfert & Karger, 2022). Hence, innovation platforms form the technological infrastructure for e-commerce ecosystems (Wulfert & Karger, 2022). While Blaschke et al., 2019a p. 1) termed innovation platforms as the “technical core” of a surrounding ecosystem, Baldwin and Woodard (2009, p. 19) defined an innovation platform as “a set of stable components that supports variety and evolvability in a system by constraining the linkages among the other components.” By benefitting from these linkages, third-party developers can extend the features of an innovation platform with a variety of extensions, which they achieve by taking advantage of the innovation platform’s architectural modularity and the technical and organizational components’ re-configurability (Jansen & van Capelleveen, 2013; Tiwana et al., 2010). These extensions make use of the application services provided by the innovation platform via a set of boundary resources, which are implemented by the platform owner (Ghazawneh & Henfridsson, 2010). By implementing a set of boundary resources as part of its governance function (Boudreau, 2010), the platform owner defines the openness of and the access to the innovation platform (Boudreau, 2010; Karhu et al., 2018; Tiwana, 2014). A certain degree of platform openness invokes positive network effects and increases generativity for the ecosystem (Blaschke & Brosius, 2018; Karhu et al., 2018).

Tiwana et al. (2010, p. 675) emphasized that third-party developers can use these stable components as an “extensible codebase […] that provides core functionality shared by the modules that interoperate with it and the interfaces through which they interoperate.” While the stable components form the core of the innovation platform, the third-party modules resemble the periphery (Staykova & Damsgaard, 2015). The platform core and periphery are evolvable, with only the boundary resource specifications that should remain stable over a longer period of time to minimize necessary extension adjustments for the developers (Baldwin & Woodard, 2009). According to Zutshi and Grilo (2019), a digital platform is composed of six different layers, namely business, user interaction, development, integration, data, and the information technology layer. Blaschke et al.( 2019a) mentioned four layers of digital platforms. They described the business layer as service dimension and called the user interaction the ecosystem dimension that allows interaction with the platform core. The platform core includes application services and boundary resources (i.e., extensible codebase) necessary for the development of platform extensions. The platform core is executed by a digital infrastructure.

Boundary resource management

The concept of boundary resources stems from the social sciences, in which “boundary objects” (Star & Griesemer, 1989, p. 393) function as “demarcation points” (Santos & Eisenhardt, 2005, p. 491) between different social worlds (Santos & Eisenhardt, 2005; Star & Griesemer, 1989). Boundary resources enable the collaboration and co-creation of value among different types of actors by translating between diverging viewpoints (Star, 2010), and are defined as “software tools and regulations that serve as the interface for the arm’s-length relationship between the platform owner and the application developer” (Ghazawneh & Henfridsson, 2013, p. 175). Since boundary resources serve as interfaces between different ecosystem participants, they move within companies’ organizational boundaries (Santos & Eisenhardt, 2005). Hein et al. conceptualize a set of boundary resources as “affordances” (Hein et al., 2020, p. 91) of the digital platform. These affordances form the boundary and the demarcation between the digital platform core and third-party developers (i.e., complementors) providing platform extension and amplifying generativity. Hence, boundary resources enable collaboration and value co-creation among different ecosystem participants (Autio, 2021; Engert et al., 2022; Hein et al., 2019; Wulfert et al., 2022).

Innovation platforms in e-commerce ecosystems provide boundary resources that support the design, implementation, and provision of third-party developers’ extensions (Ghazawneh & Henfridsson, 2013). Boundary resources lower entrance barriers to the ecosystem for new developers (Alves et al., 2017; Hein et al., 2020) and facilitate access to the focal innovation platform’s core resources (Baldwin & Woodard, 2009; Eaton et al., 2015). The set of boundary resources provided influences the innovation platform’s openness and the associated ecosystem’s generativity (Ghazawneh & Henfridsson, 2010; Karhu et al., 2018; Parker et al., 2016).

The concept of boundary resources includes a variety of manifestations (Eaton et al., 2015). Star and Griesemer (1989) introduced repositories, ideal type, coincident boundaries, and standardized forms as boundary resource types. Dal Bianco et al. (2014) described application boundary resources as interfaces for the third-party extensions’ interaction with the focal platform, development boundary resources as facilitating the third-party extensions’ design and implementation, and social boundary resources as enabling knowledge transfer and the coordination of extension development and boundary resource usage (Carlile, 2002). Application and development boundary resources provide access to the integration and development layer introduced by Zutshi and Grilo (2019). Karhu et al. (2018) developed a set of 16 boundary resources for open digital platforms. Building upon the publications of Ghazawneh (2012) and Dal Bianco et al. (2014), Wulfert et al. (2022) synthesized 14 distinct boundary resources. These boundary resources can be grouped using the boundary resource layers of Dal Bianco et al. (2014). Social boundary resources involve documentation, roadmaps, registration forms, forums, support, and hackathons. While application boundary resources include APIs and workflows, development boundary resources include SDKs, software libraries, software repositories, debugging tools, prototypes, and mockups. We utilize Dal Bianco et al. (2014) conceptualization and differentiate technical boundary resources (i.e., application and development boundary resources) and supplementary social boundary resources. As suggested by Hein et al. (2020), we integrate both perspectives in our boundary resource management lifecycle.

Existing approaches for developing and managing boundary resources in the context of innovation platforms highlight an iterative approach. Star (2010) introduced a model for describing the evolution of boundary resources consisting of standardization and residualization phases. While standardization describes a process in which certain aspects of the boundary object are standardized for a wider application, residualization refers to a process of manipulation of the boundary resource for the specific purpose and use of a group of users. Hein et al. (2019) adapted this initial model, with an additional state for the boundary resource as a result of the standardization. If a boundary resource is successfully standardized and not transferred into a residual, it can become part of standardized IT infrastructure. Ghazawneh and Henfridsson (2010) emphasized a platform governance perspective in their iterative boundary resource development, balancing platform control, and ecosystem generativity.

Application lifecycle management as theoretical lens

ALM was introduced as a complement to product lifecycle management (PLM) for the development, maintenance, and optimization of application systems in organizations (Kääriäinen, 2011; Stark, 2011). While PLM is concerned with hardware lifecycles, the focus of ALM is on software (Kääriäinen, 2011). This requires an integration of both concepts for smart products (Beverungen et al., 2019; Deuter & Rizzo, 2016). In analogy to lifecycles of species in biology (Schuh & Rudolf, 2015), ALM covers the whole software lifecycle from requirements engineering to the deprecation of the application (Stark, 2015). In contrast to this broad understanding of ALM, several research papers focus on software development and their investigations end with the deployment of the software artifact. Software configuration management is seen as a building block of ALM (Kääriäinen, 2011); it provides a repository for software components, supports development activities, and controls the overall development (Estublier, 2000). ALM goes beyond these software development management activities, managing artifacts and documentation that is created along the entire lifecycle of an application, and ALM tools integrate them in overarching tools (Kääriäinen, 2011). In this research paper, we apply the broad perspective of ALM as a theoretical lens (Niederman & March, 2019). This perspective complements application development and operation involving, among other phases, the design, implementation, maintenance, and optimization in a continuous cycle (Table 5).

Although the term application lifecycle management is widely used in software engineering and management, an agreed-upon definition still does not exist (Lacheiner & Ramler, 2011; Pirklbauer et al., 2009). ALM involves “the coordination of activities and the management of artefacts (e.g., requirements, source code, test cases) during the software product’s lifecycle” (Kääriäinen & Välimäki, 2009, p. 150). Rossberg (2014) emphasized that an application’s lifecycle starts with first thoughts on application development and ends with the application’s actual retirement, with possible changes along the application’s runtime. Besides the interplay between application development and operation, ALM involves governance as a third major activity (Tüzün et al., 2019). Pirkelbauer et al. (2009) suggested an integrated perspective (i.e., concepts, management, engineering) on ALM and emphasized the role of ALM in business–IT alignment. Chanda and Foggon (2013) focused on coordination and management activities for people, investment, and technical artifacts over the entire lifecycle from design to retirement. We theoretically ground the DSR process in this broad understanding of ALM.

Popular application lifecycles are organized along the following phases, which might carry different names: design, build, deploy, operate, and optimize (AXELOS, 2012). ALM therefore emphasizes the interaction between application development and operation, and describes the interaction as a continuous cycle in which the completed development of a version is followed by deployment and optimization. This subsequently leads to new requirements for the next development iteration and the possible decommissioning of the existing application. We provide an overview of ALM phases covered in selected research papers in Table 5 in the Appendix. This phased approach guided the development of the initial boundary resource lifecycle (Table 3).

Design science research approach

This paper aims to provide a theoretically grounded and empirically validated reference procedure model for boundary resource management in platform-centered innovation ecosystems. We identified a need for a holistic management of boundary resource as an important building block of innovation ecosystems in e-commerce (Boudreau, 2010; Santos & Eisenhardt, 2005). Developing and applying a designed artifact to better understand a problem and generate knowledge is the paradigm underlying DSR (Hevner, 2007; Hevner et al., 2004). The boundary resource management lifecycle as a developed artifact should support owners of innovation platforms in developing and implementing proper boundary resources to attract and orchestrate third-party developers (problem space) (Drechsler & Hevner, 2018; Vom Brocke et al., 2020). The attraction and governance of third-party developers should increase the focal platform’s overall generativity (Blaschke & Brosius, 2018). The boundary resource management lifecycle as a reference model is a meta-artifact (Gregor & Jones, 2007) that can be instantiated for the peculiarities of specific innovation platforms and that can guide boundary resource implementation (solution space). For the development of our meta-artifact, we follow strategy one as described by Iivari (2015).

We applied the DSR approach by Vaishnavi et al. (2019), focusing on the design phase, and developed a lifecycle model for the holistic management of boundary resources in innovation ecosystems. In total, we performed two design cycles in which the latter design iteration is informed by the previous one for an incremental development (Baskerville et al., 2019; Diederich et al., 2020; Norbjerg, 2018; Rosemann & Vessey, 2008). The theoretical foundation of our lifecycle model lies in the ALM literature. Hence, we conducted a systematic literature review to identify relevant lifecycle phases that involve boundary resources in the first design cycle (a) (Vom Brocke et al., 2009). We informed the theory-based lifecycle with a multi-case analysis on selected innovation platforms in e-commerce ecosystems and their communication of boundary resource developments in the second design cycle (b) (Yin, 2018). We evaluated the enhanced lifecycle with nine interviews with domain experts employed at innovation platforms in e-commerce. The evaluation was used to investigate the designed artifact’s applicability and to further inform the design process with data on the boundary resources’ internal design and implementation (Alsaawi, 2014; Myers & Newman, 2007).

To ensure a holistic management of boundary resources from design to retirement, we apply a lifecycle management perspective throughout the two design cycles (ISO, 2017; Kääriäinen & Välimäki, 2009). Since our perspective on boundary resources is focused on a broad understanding of the lifecycle concept, the literature review (i.e., coding of the papers), the case data, and the interview analysis are investigated through a theoretical lens developed during the elaboration on ALM (Niederman & March, 2019). This especially involves the elicitation on the lifecycle phases and their impact on boundary resources. In the following sections, we describe in more detail how the three methods intertwine conceptually to develop the lifecycle model for boundary resource management, and we provide details on the intermediary lifecycle models. The overall DSR approach is visualized in Fig. 1.

Fig. 1
figure 1

Overview of the design science research approach

Full size image

Systematic literature review

The first design cycle aims to analyze the existing literature on ALM in general and their relation to boundary resources in particular to derive a theory-based lifecycle model for the management of boundary resources. A systematic literature search offers an appropriate framework to ensure the results’ traceability, systematicity, and reproducibility, with the literature search involving the application of process and quality criteria (Cram et al., 2020). In line with these principles, we apply vom Brocke et al.’s (2015) approach for literature analysis in combination with that of Webster and Watson (2002). The foundation of the literature search was the conceptualization of the object under consideration, i.e., the application lifecycle management as established in the previous chapter, and its consideration of boundary resources. We conducted a broad search for application lifecycles and their respective management. On September 5, 2022, we searched seven literature databases (i.e., ACM Digital Library, AISeL, EBSCOhost, IEEE Xplore, ScienceDirect, Scopus, and the Web of Science) for title, abstract, and keywords. Our search resulted in an initial sample of 904 research papers (Fig. 2).

Fig. 2
figure 2

Overview of the literature selection process

Full size image

To ensure an appropriate level of quality, we conducted two phases of selection. First, we excluded non-English language articles, panels, and commentaries. Second, we applied additional quality criteria to the selection process. We excluded the following research papers: those that describe the lifecycle of an application at runtime, those with a narrow perspective on ALM, those that do not consider boundary resources, those with a focus on software development, and those that focus on single phases of the lifecycle without considering an overarching lifecycle. We followed Bandara et al. (2015) approach to filter the initial literature sample based on title, abstract, and content, using our quality criteria. After the exclusion of duplicates, our analysis led to 18 papers in which the application lifecycle forms a broad perspective in the subject under discussion. We augmented this set of literature with literature resulting from a one-way backward and forward search adding eight research papers for a total of 26 research papers in the final set (vom Brocke et al., 2015). The team of researchers analyzed the articles within the sample independently using full-text screening, and they coded the relevant text passages to extract the information on lifecycle phases. We applied the generic application lifecycle phases (AXELOS, 2012) as initial coding scheme for the extraction of knowledge on the phases, and iteratively derived the theory-based lifecycle model. We summarized the research articles identified and analyzed, in a concept matrix presented in the Appendix (Webster & Watson, 2002). The identified research articles covered a period of 14 years, with the first article published in 2008. The number of lifecycle phases varies between three and ten, with an average of six lifecycle phases (Table 4).

The theory-based boundary resource lifecycle consisted of a total of 11 lifecycle phases derived from the literature review approach (Table 4). These phases follow each other successively, with the last phase (i.e., governance) leading to the first phase of another cycle run (i.e., requirements). This structure follows the structure of existing application lifecycles (e.g., AXELOS, 2012; Duda et al., 2022; Ebert, 2012; Khabou et al., 2019). Since ALM is concerned with the management of a software artifact, the theory-based lifecycle phases focused on technical boundary resources, such as APIs and IDEs (AXELOS, 2012; Bondel et al., 2021; Vester, 2018). Supplementary boundary resources are rarely discussed as results of single phases (e.g., test and release phase) or main activity of the communication phase (Kääriäinen, 2011; Matthes et al., 2009). However, the management of boundary resources does not only involve technical boundary resources (Dal Bianco et al., 2014; Hein et al., 2020; Star, 2010). Therefore, we enhanced the theory-based lifecycle with knowledge derived from innovation platforms successfully attracting third-party developers and a high generativity indicated by the number of extensions available.

Multi-case study

To enhance the theory-based lifecycle with prescriptive knowledge derived from real-world cases, we conducted a multi-case analysis on eight innovation platforms (i.e., BigCommerce, Magento Commerce, OXID eShop, Salesforce Commerce Cloud, SAP Commerce Cloud, Shopify, Shopware, and WooCommerce) in e-commerce ecosystems (Eisenhardt, 1989; Yin, 2018).Footnote 1 These innovation platforms form the center of larger innovation ecosystems in the context of e-commerce (Table 1). They provide the necessary application services for business models in e-commerce (Aulkemeier et al., 2016b; Timmers, 1998; Wulfert & Karger, 2022) and provide an extensible codebase for third-party developers enabling the provision of platform extensions (Jansen & van Capelleveen, 2013; Tiwana et al., 2010). As we focus our multi-case analysis on innovation platforms, we did not consider Amazon with its leading transaction platform Amazon Marketplace (Amazon, 2022).Footnote 2

Table 1 Meta-information on the selected innovation platforms
Full size table

The multi-case study approach enabled us to derive, more broadly, information on boundary resource management from a series of cases that might differ in environmental aspects but share a common phenomenon (Yin, 2018). Moreover, selecting multiple cases is paramount in identifying cross-case patterns, and represents the basis for comparative analysis (Eisenhardt, 1989; Van Aken, 2004). It is an essential approach to transcend the specificity of each individual case and abstract generally applicable knowledge that benefits the class of the artifact (Gregor et al., 2013; Lee et al., 2011). Hence, we could analyze the “same phenomenon in […] in a variety of situations” (Yin, 1981, p. 101). The shared phenomenon of our eight cases is their success in e-commerce measured by the number of supported e-commerce websites (builtwith, 2022; Datanyze, 2021), their design as an extensible codebase enabling third-party developers to design third-party extensions (Tiwana et al., 2010), and as a provider of application services for e-commerce businesses (Wulfert & Karger, 2022). We have selected these platforms to derive knowledge from successful boundary management and go “beyond a single success story” (Chandra Kruse & Seidel, 2017, p. 186).

For the platform analyses, we leveraged a plethora of primary and secondary data sources to collect architectural information on each case that is publicly available (Hänninen et al., 2018). First, we searched for information on the official websites, including textual information, graphics, and videos of the eight innovation platforms. In this part of the analysis, we tried to limit ourselves to objective information. We critically analyzed advertising texts or content that aimed at making a profit and did not include them in our analysis if we had any doubts. We also analyzed information and texts from other media that dealt with the eight platforms, such as newspapers, industry journals, and practitioner magazines. The case data is analyzed through the theoretical lens of lifecycle management for boundary resources (Niederman & March, 2019), with the objective of synthesizing a holistic management model.

For the development of the enhanced boundary resource management lifecycle, we aggregated the information on boundary resource management derived from our multi-case analysis in a cross-case approach (Yin, 2018) and updated the theory-based lifecycle accordingly. In particular, the case analysis revealed a number of potential supplementary social boundary resources, such as quality criteria, status cockpit, and deprecation schedule, that augment the design, development, publication, and maintenance of technical boundary resources (Adobe, 2022c; SAP, 2022c; Shopify, 2022e). Consequently, we were able to decouple the lifecycle of technical and supporting boundary resources while retaining a lifecycle phase-based relation between them (Fig. 3). Moreover, the multi-case analysis emphasized the significance of boundary resource governance and communication when it comes to the management of boundary resources in innovation ecosystems (BigCommerce, 2022b; OXID, 2021). We therefore introduced the layered structure of the boundary resource management lifecycle, with governance and communication as core layers. We also introduced the description continuous to the communication phase in order to linguistically emphasize the significance of the communication between the owner of a focal platform in innovation ecosystems and third-party developers providing platform extensions (Jansen & van Capelleveen, 2013; Staykova & Damsgaard, 2015). The number of lifecycle phases for the management of boundary resources was reduced to nine, with boundary resource governance and continuous communication as core activities.

Expert interviews

We evaluated the enhanced boundary resource management lifecycle with a series of interviews with domain experts (Schreier, 2014). Within the interviews, we addressed the implementation and management of boundary resources on selected innovation platforms in the context of e-commerce. We chose to conduct semi-structured interviews to directly address the knowledge holders within the domain. In total, we conducted nine expert interviews with an average duration of 38 min (Table 2). To create a broad and diverse knowledge base, we generalized information from a diverse set of interviewees (Iivari et al., 2021). Within the data collection process, we contacted a total of 46 innovation platforms based in Europe, Latin America, and the USA through publicly available information of the companies and profiles of platform representatives on professional social networks such as LinkedIn. Although we mainly contacted platform representatives at management level, we were forwarded to interviewees directly involved in the design and development of (technical) boundary resources. We classified the interviewees by their company’s internal role according to innovation platform layers identified by Zutshi and Grilo (2019), and by related roles, such as business process owner, user interface designer, and internal platform developer (Wulfert et al., 2022). We could acquire an almost equal number of roles for the interviews (Table 2). As requested by the interviewees, we did not mention any company names.

Table 2 Expert interview overview
Full size table

Our semi-structured interviews were based on a previously known guide to ensure that all conversations covered a similar range of questions regarding the management of boundary resources while allowing the greatest possible flexibility in exploring explicit knowledge (Merton & Kendall, 1946; Misoch, 2015). The interview guide was created based on our research question, using ALM as the theoretical lens, and the enhanced boundary resource management lifecycle. We were able to discuss all lifecycle phases of the enhanced lifecycle and go into further detail for the supplementary boundary resources. The expert interviews were conducted via electronic communication media, between December 2021 and June 2022. Depending on the interviewees’ preferences, the interviews were conducted either in English or in German. Interviewees 2 and 7 provided additional textual answers for our interview guide. We introduced each interviewee to the topic and the purpose of the study at the beginning of the interview (Alsaawi, 2014).

For the knowledge extraction, the interviews were anonymized and transcribed to perform a qualitative content analysis (Nunkoosing, 2005), which aims at systematically analyzing an object of communication regardless of its form (Schreier, 2014). Specifically, we used the content structuring approach as a form of deductive category assignment to extract information according to predefined categories (Mayring, 2014). We used our enhanced boundary resource lifecycle as the initial categorization system and iteratively adapted and expanded this scheme with our nine expert interviews. We reached a stable set of codes after the first five interviews. We chose a single sentence as the coding unit, thus ensuring the highest possible level of detail, while a paragraph of an interview can be considered as a context unit (Mayring, 2014). Multiple codes can also be applied to a single sentence if the sentence has several meanings. We used MAXQDA for the coding (Krippendorff, 2013) and the subsequent construction of a quantitative graphical representation (Kuckartz & Rädiker, 2022). In total, we coded 369 segments (Fig. 1). We include leading quotes from the interviews in the results section (Yin, 2018).

The coding of the interview transcripts resulted not only in an aggregation of the lifecycle phases for boundary resource management, but also in a more detailed allocation of supplementary boundary resources to these phases as depicted in Fig. 3. The small-stepped and detailed phase descriptions seemed not to be applicable in practice where, for instance, plan, design, and development activities happen even iteratively yet in an agile manner (#2). In total, the final boundary resource management lifecycle consists of five phases for technical boundary resources (Fig. 3). Two interviewees made an even broader segmentation of the boundary resource management lifecycle, describing an internal perspective concerned with the design and development of boundary resources, an extern perspective when boundary resources can be used by third-party developers, and a release phase as transition between the internal and external phase (#2, #4). Moreover, the evaluation led to several additions to the supplementary boundary resources and changes in the mapping to boundary resource management phases. For instance, our interviewees frequently reported the necessity for developer-requested changes such that we introduced change requests as supplementary boundary resource (#1, #3, #7). Another example would be the mapping of the supplementary boundary resource “terms of use” that was initially mapped to the release phase during the multi-case analysis. However, the interview coding revealed strong evidence for an even earlier consideration of terms of use already in the design phase and even in the governance in which external responsibilities are determined (#2, #7).

The iterative development of our boundary resource management lifecycle resulted in two intermediary lifecycles and a final boundary resource management lifecycle (Fig. 3). We summarize the development process in Table 3.

Table 3 Overview of the development process of our boundary resource management lifecycle
Full size table

Boundary resource management lifecycle

Based on our DSR approach, which is theoretically grounded in the current body of literature on ALM and involves empirical data from eight case analyses triangulated by nine interviews with domain experts, we developed a reference procedure model for the management of boundary resources in innovation ecosystems for the domain of e-commerce. We take a lifecycle perspective to ensure an adequate management of boundary resources from design to retirement (AXELOS, 2012; ISO, 2017). The boundary resource management lifecycle resembles a reference procedure model for the particular context of e-commerce ecosystems (Jörg Becker & Delfmann, 2007; R. Schütte, 1998). The core of the boundary resource management lifecycle is formed by governance activities, illustrated with a light grey shading, spanning the whole lifecycle, and includes portfolio management, responsibility management, business alignment, and the determination of the lifespan for each boundary resource (Chappell, 2008; Vester, 2018). The core of the boundary resource management lifecycle is surrounded by activities for enabling a bidirectional communication with ecosystem participants, such as third-party developers and service providers, across the entire lifecycle depicted in turquoise. As suggested by ISO (2017), our proposed boundary resource management lifecycle is “organized into stages.” We shaded the lifecycle for managing technical boundary resources in green. The lifecycle for technical boundary resources is divided into five phases, namely plan and design, development and test, release, maintenance and optimization, and deprecation. We also mapped major supplementary boundary resources to each lifecycle stage of the technical boundary resources in the outer circle shaded in blue (Fig. 3). The differentiation of technical and supplementary boundary resources is in line with findings from our case and interview analysis (e.g., Shopify, 2022b, #7, #10). Their intertwined nature is reflected by visually integrating both circles (Fig. 3).

Fig. 3
figure 3

Boundary resource management lifecycle

Full size image

Boundary resource governance

The owner of the focal platform in a platform-centered ecosystem “sets, and often enforces, the governance rules” (Adner, 2017, p. 48). These rules are direct and indirect measures to control innovation ecosystems and their participants (Tiwana, 2014). As part of the ecosystem governance that involves “platform regulation including contractual, technological and information design” (Boudreau & Hagiu, 2009, p. 187), boundary resource governance defines the portfolio of necessary boundary resources in coordination with business requirements, the necessary boundary resources’ lifetime, overall procedures, and responsibilities (Tüzün et al., 2019; Vester, 2018). The portfolio represents the entire set of past, present, and future boundary resources. The coordination of business requirements with the boundary resource portfolio defines the openness of the platform (Boudreau, 2010; Hein et al., 2016). “Before designing new boundaries, internal and external responsibilities need to be clarified and communicated. Who is responsible for what? Which services do we need to provide as a platform provider? Which application services are open for developersFootnote 3?” (#9).Footnote 4 Boundary resource governance can also promote compatibility of an innovation platform’s boundary resources with other platforms, thus increasing the reach for third-party developers (Spaeth & Niederhöfer, 2022).

The governance of boundary resources is an overarching task for the management of single boundary resources and orchestrates development and maintenance tasks (Chappell, 2008; Tüzün et al., 2019). Our analyses revealed three types of platform release cycles that also involve the boundary resources. While the majority of analyzed platform cases favor scheduled quarterly releases with fixed boundary resource lifecycles (Adobe, 2022d; OXID, 2021; Shopify, 2022e), unscheduled release cycles with prior announcements are also implemented in practice (#1, #2). Another approach introduced by interviewees #4 and #7 prescribes a continuous evolution of boundary resources without the necessity for deprecation; however, interviewee #4 also highlighted backward compatibility as a major prerequisite. “We generally operate on a pattern of backward compatibility. Eventually, there’s something that can’t be, but we can really try not to deprecate things” (#4). “To avoid versioning, we ensure that our API is backward compatible. This is part of our API contract. This also results in a number of API fields that are unused.” (#7)

In this regard, breaking and non-breaking changes were introduced by several innovation platforms (BigCommerce, 2022b). While breaking changes usually misplace communication with external applications and result in a new API version, non-breaking changes can be implemented into production systems without any interference for developers. However, third-party developers are encouraged to “write code against our APIs that will not break if an endpoint begins returning additional fields” (BigCommerce, 2022b). Adobe also highlights backward-incompatible changes in a dedicated section of their developer blog (Adobe, 2022a). OXID (2022d) uses a three-tier application landscape consisting of a development, maintenance, and legacy environment. The legacy environment is supported with updates until the next maintenance version is released. The development environment is one version ahead of the maintenance version that is productively used by customers and extension developers. SAP Commerce Cloud makes use of development and quality assurance environments before a boundary resource is made available in productive systems (#5, #9). Four interviewees also reported on a pipeline of staging systems with intermediary quality gates (#1, #5, #6, #8).

Versioning is a common approach that owners of innovation platforms use in order to introduce new and updated APIs while continuing old ones for a predefined transition period (BigCommerce, 2022a; SAP, 2022d; Shopify, 2022e; WooCommerce, 2022c). Versioning can also be used to map possible dependencies between technical boundary resources and external tools (Adobe, 2022e; Shopware, 2022d). Semantic versioning can also give meaning to version numbers by emphasizing major, minor, and patch versions in a single string (Preston-Werner, 2022).

Continuous communication

Continuous communication deals with the continuous information of developers and additional ecosystem participants, with general information about boundary resources (Priyadarsini et al., 2020). Developers depend on timely information about the status of technical boundary resources, as the extensions they develop make use of application and development services provided via boundary resources that are provided by the innovation platform. Communication in this context means publishing supplementary boundary resources to ecosystem participants and includes information such as news, advantages and disadvantages, projects, roadmaps, new services, and other information (Vester, 2018). This activity is neither tied to a lifecycle phase nor to a single boundary resource release (AXELOS, 2012). Developers and additional ecosystem participants are frequently informed about the status of the boundary resources independently of single lifecycle phases and boundary resource releases. “One of the biggest challenges is always communicating.” (#1)

Supplementary social boundary resources are used for the continuous communication layer of our boundary resource management lifecycle (Dal Bianco et al., 2014). Communication should be ahead with regard to technical boundary resources’ time of actual release cycles to allow third-party developers to cope with upcoming changes (Schwarz & Legner, 2020). Depending on the type of technical boundary resource and lifecycle stage, it is possible to create different supplementary boundary resources and publish them for communication (Dal Bianco et al., 2014; Hein et al., 2020; Schwarz & Legner, 2020). Besides extensive textual documentation (OXID, 2022a; SAP, 2022d; WooCommerce, 2022f), supplementary boundary resources can also involve developer forums (WooCommerce, 2022e), animated guides, videos (SAP, 2022a), communities and forums (Shopify, 2022d), and hackathons (BigCommerce, 2022g). Boundary resource parameters and documentation are often available via internal or external repositories such as GitHub (BigCommerce, 2022c; Github, 2022a, b, c). Product release notes often contain information on boundary resources for developers (Salesforce, 2022e). “If you are active in this ecosystem, then you get information on all channels and, additionally, if you are active as a developer on that platform, then there is a special mailing [list]” (#4). Platform providers can also offer certification programs for partners and developers (WooCommerce, 2022a) and even academies for training developers in the use of boundary resources, including online training courses and blended learning (OXID, 2022b). Smaller platforms also favor direct contact for the communication of changes on boundary resources. “We also go to our developers in some cases. If we have only a few developers who are now using an old resource, just as we want to deprecate it, then before I tell them it was in the release notes, I’d rather go and talk to them” (#4).

Technical boundary resources include development and application boundary resources (Dal Bianco et al., 2014) that are necessary for the development of platform extensions by third-party developers. The management of these boundary resources involves all stages, from requirements management and design to their deprecation (Deuter & Rizzo, 2016; Patni, 2017). In the following sections, we integrate the supplementary boundary resources used in the boundary resource management lifecycle stages.

Plan and design

The plan and design stage begins with the determination of requirements for boundary resources (Hallerstede et al., 2011; Vester, 2018). During our analysis, we identified business requirements and developer demands as major sources of requirements. While the former reflects the innovation platform’s strategic focus as part of the governance activity’s business alignment, the latter requires a close communication with the developers of platform extensions (Bondel et al., 2021; Hallerstede et al., 2011). Developers can make demands for new boundary resources via workshops, hackathons, feature forums, and direct contact with business process owners (BigCommerce, 2022f; Bondel et al., 2021). The governance decision needs to be reflected in order to balance openness and control in boundary resource design (#5). Demand management deals with the collection, analysis, and processing of requirements demanded by developers. These requirements can be collected via the previous iteration of the lifecycle for an existing boundary resource and proactively collected for a new boundary resource (Mohagheghzadeh & Lindman, 2022). “During the project work, we start with a discovery research phase that allows us to map out the business requirements, the user needs, and from that, we create platform features and boundary resources” (#2). The requirement definition involves the formulation of functional and non-functional requirements. While the former describes the behavior of the boundary resource as demarcation objects between the focal platform and third-party extensions, the latter defines the intended performance with regard to service-level agreements (Akana, 2020).

After the requirements have been identified and documented (Bondel et al., 2021), they can be translated into feature specifications, business cases can be derived for them, and dedicated boundary resources fulfilling these requirements can be planned (Deuter & Rizzo, 2016; Hallerstede et al., 2011). The boundary resource specification is created and harmonized with the endpoint structure and behavior (Bondel et al., 2021). For technical boundary resources traversing another iteration of the lifecycle, it is necessary to determine which parts of the boundary resource must be updated (#3). Technical boundary resources can only be made available for a specific group of developers, for instance, for gold and silver developers. It is important to consider developers’ flexibility and offer technical boundary resources for a number of programming languages to allow developers to flexibly use their favorite language when implementing extensions (Salesforce, 2022b). Since boundary resources and the associated terms of use are inseparable, this aspect is a relevant supplementary boundary resource (#2, #9). The focus of supplementary boundary resources, such as guidelines and regulations, is on accumulating and organizing necessary information.

Development and test

The previously designed technical boundary resources are implemented and tested (Bondel et al., 2021), while supplementary boundary resources are finalized in this stage (Chappell, 2008). The process of developing and testing can take an iterative form (#3). Since contemporary IS are complex, software artifact development including boundary resources is conducted in teams requiring shared repositories and code orchestration (#4). “For development, each boundary resource has its own repository” (#2). The development of extensions usually takes place in preconfigured platform environments and integrates necessary boundary resources (Salesforce, 2022a). Before their release to production environments, boundary resources can be flagged as beta. “We often release boundary resources as a beta first. And then it’s kind of a beta component for three months, and during beta we’re allowed to deprecate and change things” (#4). The development of technical boundary resources can be steered by a roadmap overview for products (Shopware, 2022c; WooCommerce, 2022b) and by a detailed roadmap explorer for new boundary resources (Salesforce, 2022d; SAP, 2022e) that can be communicated to ecosystem participants. “We provide a roadmap on our documentation site, where we share information about features we are implementing or planning to implement” (#2).

Testing of technical boundary resources involves the investigation of functionality, performance, and behavior (Bondel et al., 2021). Automated and standardized tests of boundary resources ensure sophisticated testing for each boundary resource and each version (#1). This testing ensures a higher quality of extensions and stability of technical boundary resources (Priyadarsini et al., 2020, #3, #9). “Our marketplace template for e-commerce includes a suit for automated tests. Both units and end-to-end tests involving our boundary resources” (#2). Innovation platforms usually formulate quality criteria for boundary resource implementation and testing (Adobe, 2022c) and provide a rich set of methods and tools for testing extensions that are also used for testing boundary resources, such as environments for testing API calls and responses (Adobe, 2022f; SAP, 2022c). Testing involves unit tests, integration tests, and dedicated tests for the usage of technical boundary resources (#7). Staging in sandbox environments to test extensions and the correct use of API calls is a common approach for innovation platforms (BigCommerce, 2022e). “We have a dedicated, free-of-charge staging environment, where third-parties can develop and test their platform extensions manually and automatically” (#2). Supplementary boundary resources are checked for their harmonization with their technical counterparts and overall communication strategy (#8).

Release

In the release stage, previously developed and tested technical boundary resources are deployed into production environments and can be accessed by developers (Chappell, 2008). This release is accompanied by the publishing of supplementary boundary resources, such as release plans, documents, and changelogs, enabling and supporting the use of technical components. In addition to these written documents, multi-media tutorials and e-learning material can be provided (OXID, 2022a; SAP, 2022d; WooCommerce, 2022f). The platform owner needs to ensure that external developers accept and use the technical boundary resources (Hallerstede et al., 2011). To coordinate release activities and harmonize boundary resource types, our interviewees consider a deployment strategy mandatory. “You definitively need to implement a deployment for internal and external coordination” (#5). The release of technical boundary resources is often part of continuous deployment pipelines (Bondel et al., 2021; Priyadarsini et al., 2020). For the release of boundary resources and features, innovation platforms can implement a transportation route from development and quality assurance environments to production systems, that needs to be followed, with dedicated quality gates between these environments (#6, #8). The platform provider can also decide to release more complex boundary resources in several iterations in subsequent releases (Tang et al., 2011). In addition to the release of a new stable version, innovation platform owners may also grant access to pre-release versions to provide developers with the ability to test the developed extensions’ compatibility with forthcoming versions of the innovation platform (WooCommerce, 2022d).

Maintenance and optimization

In the maintenance and optimization stage, the boundary resources are operated in production environments (Bondel et al., 2021; Tang et al., 2011). This stage includes tasks, such as monitoring the status of technical boundary resources and collecting, categorizing, and evaluating developers’ feedback (Chung & Kim, 2010). The task is therefore the structured analysis of all feedback (Deuter & Rizzo, 2016). “Metrics collected automatically during platform use serve as evidence of the design and implementation quality of existing and future boundary resources” (#7). Our multi-case analysis revealed that, for maintenance tasks, status pages for monitoring the APIs’ and developer services’ operability (BigCommerce, 2022d; Shopify, 2022f) and sophisticated cockpits for monitoring the status of single APIs that are even customizable for the APIs that developers use (OXID, 2022c; Salesforce, 2022c) help minimize the effort for bug fixing and optimizations (#3, #7). “Providing a status page for the platform and the boundary resources used is an important trust-building and support-reducing measure” (#7). Platform providers also provide tools and functions for fixing bugs in using boundary resources (Shopware, 2022a). “APIs can report their status, utilization, and utilizing ecosystem participants” (#4). Boundary resource downtime and bugs can be communicated in dedicated forums (WordPress, 2022). The behavior of boundary resources can be reproduced by implementing logging mechanisms (SAP, 2022b). “We do monitor, for example, the status of our systems and APIs as well. If we see some issues with a technical boundary resource, we have a process in place that we go investigate and make sure we fix it before it becomes a system critical issue impacting operation” (#1).

While maintenance activities aim at correcting issues of boundary resources in use, optimizations try to avoid problems and improve the performance of boundary resources. Depending on the requested changes, feedback can be used to incrementally optimize the boundary resource, or the feedback can be implemented in a future lifecycle in a new boundary resource version (Hallerstede et al., 2011). Incremental optimizations are deployed into the current version of the boundary resource (Chung & Kim, 2010). Optimizations can affect the innovation platform’s openness and control characteristics positively, but also negatively. Therefore, it is part of change management to analyze an optimization’s potential benefits and risk for the overall ecosystem. Platform providers introduced a priority concept for boundary resource optimizations, indicating the necessity of updating and the vulnerability to external fraud (Adobe, 2022b). Since optimizations may involve numerous application services, a team of internal platform developers needs to handle optimizations (#1).

Deprecation

In the deprecation stage, the unnecessary, unsafe, and outdated versions of boundary resources are indicated for deprecation and retired (Bondel et al., 2021; Shopify, 2022e). Deprecation practices vary depending on the type of boundary resource. Deprecating technical boundary resources requires a migration plan to upgrade to a new or updated resource (Shopware, 2022b; Tang et al., 2011). Deprecations are announced in developer forums (Shopify, 2022c) and dedicated boundary resource release notes (Shopify, 2022a). “We mark deprecated features in the documentation along with links to documentation topics that describe how to achieve the functionality after the deprecation” (#2). The deprecation stage includes the planning of deprecation schedules, the implementation of transition plans, and the management of adequate communication of the deprecated boundary resource to developers (Shopify, 2022e). “For new [boundary resource] releases, there are always release notes, and deprecations are announced via various channels” (#3). Boundary resources of older innovation platform versions are likely to be deprecated after a transition period (Shopify, 2022c). “Whenever new boundary resources are implemented, what we usually do is start a phase-over process where we start deprecating the old module and move it into the new module in a phased approach, shifting the utilization to the new resource” (#1). If a boundary resource is indicated as deprecated, it can be unpublished and removed in a following release (Chung & Kim, 2010; Patni, 2017; Shopify, 2022e; Shopware, 2022b). Deprecating technical boundary resources is a more complicated endeavor for smaller platforms, who tend to keep old but still used boundary resources. “Unfortunately, we also have to keep many old boundary resources because they are still in use. We can’t migrate them” (#1). Keeping old building blocks of a boundary resource can also be used to ensure backward compatibility (#1). If backward compatibility is propagated, boundary resources can only be deprecated if they are no longer used at all (#4).

Discussion

We developed a theoretically grounded and empirically validated lifecycle model for the management of boundary resources in innovation ecosystems. Innovation ecosystems with sophisticated boundary resources and a critical mass of developers can cope with the contemporary challenges of traditional IS development. Boundary resources can be differentiated between technical boundary resources and supplementary boundary resources (Dal Bianco et al., 2014; Ghazawneh & Henfridsson, 2013). We developed the reference procedure model (Jörg Becker & Delfmann, 2007) in a DSR approach consisting of two design cycles. The first design cycle utilized a review of the existing ALM literature as input for deriving suitable lifecycle stages of boundary resource management (vom Brocke et al., 2015). The second design cycle investigated eight case studies of innovation platforms in e-commerce to derive boundary resource management activities and supplementary boundary resources for each lifecycle stage (Yin, 2018). We evaluated these results with the analysis of interviews with nine domain experts employed at innovation platforms in e-commerce (Misoch, 2015). We developed two intermediary lifecycle models (i.e., theory-based lifecycle, enhanced lifecycle) to come up with the final boundary resource management lifecycle consisting of five lifecycle phases (Fig. 3). With our reference procedure model, we not only depict the lifecycle of boundary resources in innovation ecosystems but also prescribe (i.e., theory for design and action) how owners of innovation platforms should manage these boundary resources (Gregor, 2006). The “choice of lifecycle models for the design process influences what it is that is designed” (Clemmensen et al., 2008, p. 137). Mapping supplementary boundary resources to technical boundary resources’ lifecycle stages gives platform owners guidance on which documents to create and publish (Dal Bianco et al., 2014; Ghazawneh & Henfridsson, 2010). In this regard, third-party developers can be addressed directly.

Critical appraisal

We chose e-commerce as the domain of interest, as innovation ecosystems in e-commerce are very dynamic in nature, with participants (e.g., customers, developers) joining and departing (McIntyre & Srinivasan, 2017; Wulfert et al., 2021). This requires a diverse set of application services to support the variety of business models, such as electronic shops, digital marketplaces and electronic auctions (Alt, 2020; Timmers, 1998; B. Yoo & Jang, 2019), and has a continuous stream of new extensions and updates (Ghazawneh & Henfridsson, 2013; Medjaoui et al., 2021). Since we abstracted from the peculiarities of eight cases and nine additional interviews that include “a range of possible real situations” (Kosiol, 1964, p. 758), it is possible to consider our boundary resource management lifecycle as a reference procedure model (Delfmann, 2006; Fettke & Loos, 2002; R. Schütte, 1998; Vom Brocke, 2015). The boundary resource management lifecycle also contains variants for a number of activities and decisions that can be selected when instantiating and implementing the reference model for a particular company (R. Schütte, 1998; Vom Brocke, 2015). For instance, we reported on a versioning and a backward-compatible approach for establishing an updated version of an already existing technical boundary resource (#4, #7, Adobe, 2022a). Moreover, the reference model is designed in a flexible manner to be changed and extended for the customization implementation at a particular company.

Besides the mapping of technical boundary resources and supplementary social boundary resources emphasized in our boundary resource management cycle, we integrated boundary resource governance and continuous communication as fundamental activities guiding the development and maintenance of boundary resources (Eaton et al., 2015; Ghazawneh & Henfridsson, 2013; Vester, 2018; Wulfert et al., 2022). To highlight the necessity of governance and communication for the management of boundary resources, we applied a layered approach for the lifecycle model. Boundary resource governance forms the inner layer in which fundamental decisions regarding the boundary resources of an innovation platform, such as the boundary lifecycle duration, versioning standards, responsibilities, and the portfolio of boundary resources, are made (Boudreau, 2010; Ghazawneh & Henfridsson, 2013). The continuous communication layer involves activities relevant for the communication with ecosystem participants (e.g., third-party developers) (Vester, 2018). The continuous communication is responsible for the dissemination of the boundary resources across the innovation ecosystem. Moreover, the interviewees emphasized the importance of adequate communication between platform owners and third-party developers regarding the management of boundary resources (#1, #2, #4, #9). Therefore, we integrated a dedicated layer for continuous communication along the lifecycle of a boundary resource (Bondel et al., 2021; Kääriäinen & Välimäki, 2008; Priyadarsini et al., 2020). We amplified the communication aspect with the mapping of dedicated supplementary boundary resources for the support of the communication of technical boundary resources (Dal Bianco et al., 2014). The outer layers are formed by technical and supplementary boundary resources that resemble the demarcation points for the information and involvement of ecosystem participants (Dal Bianco et al., 2014; Wulfert et al., 2022).

Our multi-case and interview analysis revealed a diverging behavior of platform owners about updating technical boundary resources. While the first group of platforms uses strict versioning, the second group propagates a high level of backward compatibility, avoiding new versions. The former approach makes changes and new developments transparent but potentially requires effort in updating extensions to new versions and adapting the use of tools for developers. The latter approach allows for a parallel usage of boundary resources for different developments and reduces possible adaption efforts for developers but may increase potential boundary resource overheads (#2, #4, #7). A possible explanation for the two different approaches can be found in the varying amounts of power the platform owner can wield on ecosystem participants (Annabelle Gawer, 2021; Kretschmer et al., 2022). Introducing new versions of boundary resources while simultaneously deprecating the old version force developers to use the new version after a defined transition period (Star, 2010). Platforms with lower amounts of power in their innovation ecosystems would need to provide backward compatibility. The amount of power and control over the ecosystem also prescribes whether the platform owner can define boundary resources on its own or tune distribution by ecosystem participants (Eaton et al., 2015). We account for the ecosystem participants’ integration in the boundary resource management lifecycle with the continuous communication layer, with possibilities to post requirements, and by enabling a dialog of business process owners or internal platform developers and developers.

For the development of the boundary resource management lifecycle, we differentiated between technical and supplementary boundary resources (Dal Bianco et al., 2014). These two types include the possible boundary resources as described by Karhu et al. (2018), Star (2010), and Wulfert et al. (2022). We argue that supplementary boundary resources are often bound to a lifecycle stage and a specific version of a technical boundary resource. We therefore provided a mapping of major supplementary boundary resources per lifecycle stage of the technical boundary resource. If the technical boundary resource is created, updated, and deprecated, the explaining supplementary boundary resource also needs to be adapted.

Although our boundary resource management lifecycle seems to have an iterative form, single stages can also be organized in an agile manner (Nerur & Balijepally, 2007; Shore et al., 2022). An example of an agile realization can be the development and test stage, with incremental development of the software artifact and increment tests (#2). These increments can be arranged for the completed boundary resource (Priyadarsini et al., 2020).

Scientific and managerial contribution

We contribute to the current research on ALM by providing a reference procedure model for managing boundary resources. The integrated lifecycle management approach for a holistic management of boundary resources accounts for the strategic role of boundary resources in innovation ecosystems (Bondel et al., 2021; Vester, 2018; Y. Yoo et al., 2010), addresses third-party developers, and fosters an ecosystem’s generativity. We provide a novel tool for analyzing and prescribing collaboration in innovation ecosystems. We provide further insights on the role of boundary resource governance and continuous communication as important activities in managing boundary resources. Moreover, our boundary resource management lifecycle emphasizes the focal innovation platform’s role for implementing boundary resources while controlling and governing value co-creation. The reference procedure model’s development process also highlights the role of innovation platforms in e-commerce. Boundary resources are especially important in electronic markets, enabling digital collaboration and value co-creation. We decoupled technical and supplementary social boundary resources in line with existing research (Dal Bianco et al., 2014; Engert et al., 2022; Ghazawneh & Henfridsson, 2013; Hein et al., 2020; Wulfert et al., 2022), but emphasized their intertwined nature for ecosystem participants over the whole boundary resource management lifecycle. Technical boundary resources require a supplementary counterpart for efficient ecosystem-wide application. Within our lifecycle model, supplementary social boundary resources are mapped to technical boundary resources per lifecycle stage.

While platform providers can customize this reference model for their individual peculiarities, developers can reproduce the lifecycle of technical boundary resources, anticipate the development of future boundary resources, and benefit from associated supplementary boundary resources. Although the potential impact of continuous software engineering for the software industry is recognized in research and practice, especially for cloud environments (Dittrich et al., 2018; Wilson, 2017), the role of technical boundary resources remains unchanged as stable demarcation points between innovation platforms and third-party developers (Baldwin & Woodard, 2009). However, the accelerated evolution of innovation platforms as a core of innovation ecosystems often causes adjustments for previously stable boundary resources. Hence, the boundary resource lifecycle can be used as a toolkit for boundary resource management when it comes to implementing and communicating changes in interfaces in proper documentation. The reference procedure model for managing boundary resources can therefore be used to cope with evolving innovation and cloud environments in which extensions are “released in small increments and constantly modified” (Norbjerg, 2018, p. 72). The reference procedure model can be applied as an important tool for the development of ecosystems surrounding innovation platforms in e-commerce.

Limitations

This study entails some limitations, which provide opportunities for future research. Since the literature on boundary resource management is sparse, we started our design science approach with an investigation of the ALM literature to identify relevant lifecycle stages. Although technical boundary resources are software artifacts (Dal Bianco et al., 2014), it might be disputable whether all stages are relevant for the management of boundary resources. We therefore conducted an additional design cycle to refine the lifecycle for boundary resource management with insights from practice derived in a multi-case analysis. However, innovation platforms did not provide detailed information on pre-release lifecycle stages that were considered during our analysis as internal. For information on these internal phases, we especially benefitted from the evaluation of the enhanced lifecycle during our interview analysis. For our interview analysis, we were able to obtain interviews with nine domain experts employed at innovation platforms that provide application services for transaction platforms in e-commerce and online retailers (Aulkemeier et al. 2016b; Wulfert & Karger, 2022). Unfortunately, our interviewees demanded that the results of the interview analysis be published anonymously without any reference to the innovation platform. Therefore, we could not draw any direct relations or conclusions from an evaluation of the comparison of case studies and interviews. Instead, we used the interview analysis to evaluate the results of our multi-case analysis.

Our design science research approach involves qualitative research methods for data collection and data analysis. As the results of qualitative research are often criticized as subjective and biased by the investigator (e.g., Beuving & De Vries, 2015; Guba & Lincoln, 1982; Miles et al., 2014; Straub & Gefen, 2004), research rigor with regard to reliability and validity needs to be ensured for qualitative research endeavors (Golafshani, 2003; Miles et al., 2014; Recker, 2013).Footnote 5 To ensure the construct validity, internal validity, external validity, and reliability of our research project, we applied the tactics put forth by Guba (1981) and Yin (2018) for an increased research rigor. We ensured construct validity by establishing a chain of evidence triangulating multiple data sources in the multi-case analysis (Yin, 2018) and our interviewees verified the interview transcript to avoid misunderstandings and misinterpretations (Shenton, 2004). To increase the internal validity of our research project, we provided transparency on our research procedure, allowed for data triangulation across the applied methods, and depicted linkages among the methods applied. Moreover, we tried to match patterns (i.e., lifecycle phases) derived from existing literature with our case observations (Yin, 2018). Following Hänninen et al. (2018), we used a variety of secondary data sources for our multi-case analysis. We acquired the interviewees based upon a random sampling approach among the population of existing innovation platforms and approached a total of 46 platforms with only nine platforms offering volunteers for interviews. We elaborated on the purpose of the interviews, provided additional information a priori to the interviewees, and offered the possibility for refusing the interview (Guba, 1981; Shenton, 2004). With regard to the number of interviewees, we applied sufficiency and data saturation as indicators (Guest et al., 2006; Hagaman & Wutich, 2017; Seidman, 2019). While sufficiency was achieved by contacting a variety of innovation platforms in terms of size, revenue, and provided services, and by reaching interviewees with different positions (Table 2), data saturation was already achieved after the seventh interview with two additional interviews in the pipeline. Data saturation was measured by the degree of new information added and changes to the coding scheme caused by the consecutive interviews (Guest et al., 2006). The degree of additional information was already low when analyzing the seventh interview and high saturation of information on boundary resources in general and boundary resource management stages in particular was achieved, despite the platforms’ diverging peculiarities. External validity was ensured by abstracting from the peculiarities of analyzed case companies and interviewee information. Hence, our boundary resource management lifecycle approach might be implemented for a sophisticated boundary management for technical boundary resources and supplementary social boundary resources in other domains of interest. Although we conducted our multi-case analysis with a replication logic (Yin, 2018), the external validity of our study could be further increased by analyzing innovation platforms and consulting interviewees in other domains. Reliability was enriched by providing supplementary information on our research endeavor (e.g., concept matrix, intermediary lifecycles). By providing transparency on the intermediary lifecycle models, we maintained a consistent chain of evidence throughout our design science research project (Yin, 2018). Among the team of authors, we periodically reflected on the research design, execution, and results and prepared research diaries for the design science research project (Guba, 1981; Yin, 2018).

Research agenda

Drawing on existing calls for research on boundary resources and platform governance (e.g., de Reuver et al., 2018; Hein et al., 2020; Schüler & Petrik, 2021; Y. Yoo et al., 2010) and our research on boundary resource management, we distilled three areas for future research (i.e., innovation ecosystems, boundary resource management, types of boundary resources) and suggested questions guiding future research, namely Table 4.

Table 4 Future research agenda
Full size table

The first research area is concerned with future research on boundary resources on (innovation) ecosystem level. Despite first attempts to conceptualize the concept of generativity in platform contexts (e.g., Blaschke & Brosius, 2018; Fürstenau et al., 2023; Jarvenpaa & Standaert, 2018) and to analyze its effect on third-party developer adoption (Miremadi et al., 2023), the impact of boundary resource provision on ecosystem generativity remains underrepresented (Hein et al., 2020). In this regard, the role of boundary resources in the dichotomy between platform openness and platform control is worthwhile investigating (e.g., Benlian et al., 2015; Spaeth & Niederhöfer, 2022; Y. Yoo et al., 2010). Another possible avenue for future research would be an analysis of the influence of boundary resources on different types of ecosystem participants (Eisenmann et al., 2009). The influence of proper boundary resource implementation on third-party developers and their dyadic relationship with platform owners would also be worthwhile investigating. In particular, providing transparency about boundary resource development and provisioning might mitigate distributed tuning of boundary resources by other ecosystem participants (Eaton et al., 2015).

The second research area deals with boundary resource management—analyzed in this research paper—in particular. Adding to the boundary resource management lifecycle, future research might derive design guidelines for implementing boundary resources for innovation platform owners and abstract from domain peculiarities of existing research (e.g., Engert et al., 2022; Wulfert et al., 2022). Although we chose e-commerce as the application domain for our research on the management of boundary resources to achieve a high fitness for one domain, the lifecycle might be applicable in other domains (e.g., agriculture). Hence, a possible avenue for future research would be to test the boundary resource management lifecycle in other domains and increase its projectability while retaining a high fitness (Vom Brocke et al., 2020). Hence, future research could discuss the management of boundary resources with additional experts from other domains and third-party developers. Future research could also evaluate the boundary resource management lifecycle’s benefits and performance by applying it in selected companies and customizing it to the peculiarities of these cases (Hevner et al., 2004; Vom Brocke, 2015). The performance could be evaluated using appropriate indicators, such as the number of third-party developers, the number of extensions, developer satisfaction, and interface downtime. Another possible avenue for future research would be a more detailed analysis of the core phases boundary resource governance and continuous communication. Analogous to ALM, which is typically supported in practice using dedicated tools depending on the lifecycle stage or integrated solutions (Aston, 2022; Jwo et al., 2013), boundary resource management needs to be supported with IS. Future research might investigate existing ALM solutions for the coverage of boundary resources and implement potential extensions for these tools. An important avenue for future research would be the development of a tool supporting the different boundary resource types’ entire lifecycle in an integrated manner.

The third research area identified is concerned with different types of boundary resources (e.g., Dal Bianco et al., 2014; Ghazawneh & Henfridsson, 2013). It could be worth investigating for which innovation platforms and technical boundary resources backward compatibility is required and for which new versions discarding old ties are sufficient. A possible explanation for this might be the platform owner’s relative power within the surrounding ecosystem (Hein et al., 2016; Hurni et al., 2022; Kretschmer et al., 2022). Moreover, future research could investigate the relationship between technical and supplementary boundary resources in more detail. Existing investigations distinguished these boundary resource types, but did not discuss their relationship (e.g., Dal Bianco et al., 2014; Ghazawneh & Henfridsson, 2013). Moreover, future research could strive for deriving archetypes of boundary resources to enable a more focused management and implementation. We summarize the research areas with potential research questions for future research endeavors in Table 4.

Conclusion

We developed a reference procedure model for the management of the whole lifecycle of boundary resources in innovation ecosystems from the perspective of focal platform owners. The boundary resource management lifecycle is structured in four layers: boundary resource governance, continuous communication, technical boundary resources, and associated supplementary boundary resources. With this research, we add value to the literature on ALM with a special focus on technical boundary resources and supplementary social boundary resources. The ALM perspective was especially applied for technical boundary resources and extended for this particular type of software artifacts. Supplementary boundary resources are mapped according to these lifecycle stages to support boundary resources’ ecosystem-wide application. The lifecycle for the management of technical boundary resources consists of the following stages: plan and design, development and test, release, maintenance and optimization, and deprecation. Major supplementary boundary resources include written documentation, repositories, changelogs, tutorials, status reports, and transition plans. The boundary resource management lifecycle supports owners of innovation platforms in organizing boundary resources and orchestrating third-party developers. Third-party developers can anticipate potential changes in boundary resources made by the platform owner applying our model to boundary resources used. We contribute to the current body of knowledge on ALM by providing a sophisticated reference procedure model for the management of technical and supplementary boundary resources. In the same vein, we enhance existing research with a mapping of supplementary boundary resources to technical boundary resources’ lifecycle stages while highlighting their intertwined nature.