1 Introduction

Digital technologies, as enablers and catalysts of digital transformation, propel inter-company collaboration and value co-creation in platform-centered ecosystems [1,2,3,4]. Platform-centered ecosystems require a set of boundary resources to allow for orchestrated value co-creation [2, 3]. The focal platform’s owner provides these resources as part of platform governance to decide which third parties have access to which boundary resources and how they can be used for value co-creation to satisfy customers [5,6,7,8]. A prominent example of such value co-creation is e-commerce, with an expected accumulated global revenue of US $6.4 trillion in 2024 [9]. Several successful transaction platforms (i.e., digital marketplaces) currently dominate e-commerce––eg., Amazon, Alibaba, eBay, Flipkart, Mercado Libre, and Rakuten––through their surrounding ecosystems [10]. Amazon generated USD 340 billion in revenue from product and service sales in fiscal year 2020, with more than 60 percent of its revenue coming from commission fees from third-party sellers in its ecosystem [11]. The revenue generated within these ecosystems is up to three times higher than that of the focal platform [12]. These transaction platforms are powered by e-commerce-specific innovation platforms––eg., Magento Commerce, Shopify, and WooCommerce [13]––that provide the infrastructure and application services needed to conduct e-commerce transactions [13, 14].

E-commerce ecosystems comprise various independent participants––eg., manufacturers, sellers, customers, and service providers––that are (digitally) connected [15]. These participants compete for scarce resources (eg., products, supplies) while pursuing the common target of fulfilling customer demand [16]. As e-commerce transactions occur via electronic means [17], the platform owner must implement sophisticated boundary resources to manage the various ecosystem participants [3, 18]. Ghazawneh [19] transferred the concept of boundary objects (eg., repositories, ideal types, coincident boundaries, and standardized forms) from social science to (software) ecosystems [3, 20]. Dal Bianco, Myllarniemi, Komssi, Raatikainen [21] used this description to distinguish between three layers of boundary resources in platform-centered ecosystems: development boundary resources, application boundary resources, and social boundary resources. Recent literature on interorganizational integration and coordination emphasized the application of proper boundary resources [22,23,24,25,26]. For instance, Schreieck, Ondrus, Wiesche, Krcmar [26] described boundary resources for integrating a platform owner’s multiple platforms, Lindgren, Saadatmand, Schultze [25] introduced boundary resources for collaboration in road haulage, Leong, Lin, Tan, Yu [24] highlighted boundary resources as an important coordinating mechanism in modular platform architectures.

As an “ecosystem leader” [27], a platform’s owner in an e-commerce ecosystem can define boundary resources while setting and enforcing governance rules [16, 28]. Defining the boundaries and demarcation points between a focal platform and ecosystem participants [29] facilitates the execution of strategically relevant decisions about ownership, entry into new markets, and community building [6, 21]. Although many standards for information exchange have been introduced in e-commerce [30,31,32], extant research on how standardized boundary resources are defined remains scarce (18, eg., [33]). Most extant literature either focuses the analysis on individual aspects of boundary resource design, eg., the user interface (eg., [34, 35]) or refers to dedicated scenarios [36]. Against this backdrop, our research question is as follows:

How can the platform boundary be designed to propel participants’ value co-creation in e-commerce ecosystems?

To answer the research question, we provide evaluated design principles for the shaping of boundary resources in e-commerce ecosystems based on 14 expert interviews and a subsequent qualitative content analysis [37]. Furthermore, we proposed design guidance in the form of a boundary resource model comprising a set of design rules for platforms in e-commerce ecosystems to reduce barriers to entry for participants and to propel network effects [38] based on a content-structuring approach and our elicitation of focal platform types [39].

The remainder of this research article proceeds as follows. First, we introduce the concepts of e-commerce ecosystems and platform boundary resources. Second, we present our design science research approach involving 14 expert interviews. Third, we introduce a boundary resource model for e-commerce ecosystems. Finally, we summarize and discuss our results and propose future research directions.

2 Related literature

E-commerce ecosystems emerge around focal platforms, orchestrating ecosystem participants and enabling transactions among them (Wulfert and Karger, [13]; Wulfert et al., [18]). These platform owners can define and enforce governance rules for interactions with focal platforms (Boudreau, [7]; Hein et al., [28]; Tiwana, [58]). The focal platform’s owners design and implement boundary resources for interactions with other ecosystem participants as a building block of their platform governance (Ghazawneh and Henfridsson, [3]; Eaton et al., [70]; Tiwana et al., [59]).

2.1 Platforms in E-commerce ecosystems

Introduced to the economics literature by Moore [27, 40], digital business ecosystems are complex networks of platform-mediated actor-to-actor interactions involving digital technologies [18]. Independent participants are linked by a common goal—namely the overall ecosystem’s success [16]. An e-commerce ecosystem is a manifestation of a digital business ecosystem in the e-commerce context, with participants conducting digital transactions [17, 18]. E-commerce ecosystems enable the exchange of products and services supported by multiple participants in order to achieve the (final) customer’s objective [18]. The value for the customer is generated multilaterally by the ecosystem participants (eg., seller, service providers etc.) [16, 18, 41, 42]. In the context of e-commerce ecosystems, Zwass [43] defined value co-creation as “the participation of consumers along with producers in the creation of value in the marketplace”. Grönroos [44] and Archpru Akaka, Vargo, Lusch [45] especially, highlighted the involvement of “multiple actors” in the value creation process. In the context of (e-commerce) ecosystems, Burkhalter, Betz, Auge-Dickhut, Jung [46] described value co-creation beyond the focal platform owner’s boundaries. An e-commerce ecosystem’s value for participants increases with the addition of each participant to the network, resulting in direct and indirect network effects [47]. These ecosystems are characterized by a “high system renewal rate, the leading position of core enterprises, the fuzziness of system boundary and high environmental threat” [48].

E-commerce ecosystems typically evolve around focal transaction platforms. The focal transaction platform that function as virtual loci through which participants conduct retail transactions [49, 50], acts as a hub connecting affiliated ecosystem participants [51], and orchestrates participants’ (retail) transactions [13, 18, 52]. Innovation platforms power transaction platforms, providing necessary application and infrastructure services [13, 53]. Transaction platforms (eg., Amazon Marketplace, Walmart Marketplace, Alibaba.com) match and orchestrate organizations and individual participants from various markets and social groups to form dynamic ecosystems [39, 54]. The major supply-side participants on transaction platforms are manufacturers and sellers [6, 55]. Transaction platforms offer various retail-related services for participants, eg., payment or fulfillment services [10]. E-commerce platforms also increasingly provide innovation services (eg., application programming interfaces, computing power), enabling development of third-party extensions and attracting external developers as additional ecosystem participants [18]. Innovation platforms provide the technological infrastructure and necessary application services to conduct e-commerce transactions [14]. Innovation platforms form the “technical core” of e-commerce ecosystems [56], supplying sophisticated boundary resources to enable development of extensions (eg., shop themes, feature add-ins) by third-party developers as major supply-side participant type [6, 18]. These extensions expand innovation platforms’ application services and their generativity [57]. Hybrid platforms incorporate the two aforementioned platform types’ characteristics and provide transaction and innovation services [39], thereby increasing platform owners’ reach and their ecosystems’ value to incumbents and new participants [53].

2.2 Ecosystem governance

As e-commerce ecosystems comprise several independent participants, these participants’ interactions, collaborations, and value co-creation require a certain degree of governance [58,59,60], which has been identified as an important determinant of an ecosystem’s success [58, 61]. As Tiwana described it [58], “[g]overnance broadly refers to who decides what in a platform’s ecosystem”. Ecosystem governance comprises the set of rules, norms, and policies to which the platform adheres to build its ecosystem [62]. Ecosystem governance involves direct and indirect measures to control the ecosystem and participant interactions within an ecosystem [58]. The focal platform’s owner in a platform-centered ecosystem “sets, and often enforces, the governance rules, determines timing” [16], and reaps the lion’s share of ecosystem revenues. Extant literature has structured and aggregated governance rules and decisions within several governance dimensions [6, 28, 58, 62]. Among others, ecosystem governance involves decisions on access to the focal platform; implementation of boundary resources for access to the focal platform; the division of value among ecosystem participants, including the ecosystem’s pricing structure; and conflict resolution with divergent objectives among participants [18, 58, 62,63,64]. Aside from pricing mechanisms, Boudreau and Hagiu proved that “platform regulation including contractual, technological, and information design” [65] that governs platform openness is key in establishing ecosystems. The authors differentiated between regulation of access and interactions among participants already on the multi-sided platform. Hein et al. [28] proposed governance structures, resources and documentation, accessibility and control, trust and perceived risk, pricing, and external relationships as dimensions of ecosystem governance, which supports decisions on the focal platform’s architecture and the overall ecosystem’s composition. In platform-centered ecosystems (eg., e-commerce ecosystems), the focal platform’s architecture augments governance rules [58].

2.3 Boundary resources

When boundary resources first emerged in social science, they were referred to as “boundary objects”, functioning as interfaces between different social worlds [20] and enabling different actors to work cooperatively without the need for direct management [66]. Boundary resources accomplish this by being easily adaptable to individual use cases and recognizable to all participants [20]. Considering that boundary resources function as interfaces between different participants (i.e., firms), they move within companies’ organizational boundaries [29]. Furthermore, the theory of organizational boundaries provides the base context of ecosystems [29, 50].

Adopting this concept in e-commerce ecosystems supports the design of third-party applications [3], thereby lowering entrance barriers to the ecosystem for new participants [6]. Boundary resources enable reconfiguration, extension, and evolution of platform internal modules as well as third parties’ complements in a modular platform architecture [67,68,69].Boundary resources facilitate access to platforms’ core resources [70, 71]. In providing boundary resources, a platform owner also defines the platform’s governance rules [16, 28]. In particular, boundary resources influence a platform’s openness [72, 73]. By providing these resources, a platform can attract more participants [3]. These resources also can be used to secure the platform and establish control over the platform and its participants [3]. Boundary resources are designed as part of governance rules and can be implemented as part of a platform’s architecture (eg., application programming interfaces) [3, 59, 70].

Dal Bianco et al. [21] identified three layers of boundary resources. The first, development boundary resources (eg., software development kit, integrated development environment) help third-party developers develop applications and provide them to other ecosystem participants. The second, application boundary resources refer to resources that provide access to the platform for a third-party application, eg., an application programming interface that the focal platform provides. Finally, social boundary resources facilitate communication between an a focal platform and third parties. For instance, a social boundary resource could be a blog and a dedicated developer forum. These three boundary resource layers are not explicit, i.e., one boundary resource can belong to different layers simultaneously [21]. For example, a developer forum simultaneously can help develop an application and facilitate communication among ecosystem participants.

Recent literature on inter-organizational integration and coordination emphasized the application of boundary resources for collaboration as well as value creation. Schreieck, Ondrus, Wiesche, Krcmar [26] described the use of boundary resources for the integration of a platform owner’s formerly distinct platforms. The authors distinguished between partial (data and function integration) and full integration (additional user interface harmonization) making use of dedicated boundary resources. Lindgren, Saadatmand, Schultze [25] described boundary resources (eg., CANBUS, XML integrator) applied for value creation between different participants, such as truck manufacturers, road haulage firms, consulting organizations, transport organizations, and research organizations, in Swedish road haulage [25]. Dai [22] analyzed the employment of a modular architecture to strengthen a platform’s network effects for participants. Leong, Lin, Tan, Yu [24] argued that platform modularity (involving boundary resources) is one of the prevalent coordinating mechanisms in the literature. As such specific boundary resource implementations were suggested for innovation platforms [19, 21], open innovation platforms [74], and industrial internet of things [75]. Schreieck, Wiesche, Krcmar [60] investigated the role of data as a boundary resource. In this research paper, we evaluate boundary resources for the particular implementation in transaction platforms and innovation platforms in the context of e-commerce.

3 Research approach

Following vom Brocke et al.’s [76] guidance, this publication is part of a multi-paper design science research project ([13], eg., 18, 53). We report in this paper about the development of evaluated design principles (Fig. 1) for the design of boundary resources based on Wulfert, Woroch, Strobel, Seufert, Möller [18]. The objective is to increase the confidence in the design principles and improving their fitness for the boundary resources of selected platform types [76]. We further detailed the relation between the initial and updated boundary resources in Appendix A4. With regards to the archetypal movement types suggested by vom Brocke, Winter, Hevner, Maedche [76], our research endeavor is an amplification as we address a similar problem space while providing additional detail for the solution in different platform types.

Fig. 1
figure 1

Scientific Approach

Full size image

The research drew from an interview study of 14 domain experts and utilized the framework for minimum reliability evaluation [77] as a theoretical lens to contribute applicable design knowledge as well as address these design principles’ usability by matching them with the relevant platform types, in the e-commerce environment. To formulate the design principles, we applied the structure that Chandra, Seidel, Gregor [78] proposed, including material property and possible actions. Based on the anatomy of design principles [79], the platform owner can implement our derived principles to attract third-party developers to e-commerce ecosystems. Implementing these principles should ease participation into the ecosystems and propel generativity.

3.1 Data collection

This study’s objective was to transform implicit design knowledge into explicit, prescriptive knowledge, thereby enabling its utilization [80]. Therefore, we conducted semi-structured interviews to address knowledge holders directly within the domain. To create a broad and diverse knowledge base to make the results generalizable [77], experts from all e-commerce ecosystem areas (eg., platform operators, retailers) and all platform types (eg., innovation, transaction) were integrated into the study. We mapped the interviewees’ company-internal roles to the platform layers that Zutshi, Grilo [81] identified and related roles (i.e., business process owner, user interface designer, internal platform developer) on the basis of purposeful sampling [18, 82]. During the data collection process, we contacted 45 innovation (eg., Shopify, Big Commerce, SAP) and transaction (eg., Amazon, eBay, Mercado Libre) platforms in e-commerce from Europe and the US through publicly available addresses and connected with selected employees via professional social media in a purposeful sampling approach [82]. Altogether, we conducted 14 interviews over a six-month period (Table 1).

Table 1 Overview of the interview study participants
Full size table

Our semi-structured interviews were based on a previously known guide to allow for the greatest possible flexibility in examining explicit knowledge [83, 84]. We have chosen a semi-structured interview approach, as we were not only interested in the experts’ evaluations for the five criteria (i.e., criteria fulfilled and not fulfilled) but also collected additional comments, explanations, and examples (Fig. 1). Following the research question and objectives, the interview guide was structured thematically using the 19 design principles and extended thematically with five quality criteria (effectiveness, accessibility, importance, novelty and insightfulness, and actability and appropriate guidance) based on Iivari et al.’s [77] evaluation framework to combine conceptual design knowledge and implicit expert knowledge to provide explicit design knowledge in the form of design principles for implementing ecosystem boundary resources in the e-commerce environment. As accessibility, actability and guidance, and effectiveness should be assessed for each design principle individually and importance as well as novelty and insightfulness should be assessed for the whole set of design principles, we altered the order of the criteria in our interview guide (Appendix A1) to allow the interviewees first assess each design principle individually and second assess the whole set of 19 design principles. Reusability is an important attribute of design principles that ensures the design principles’ applicability for a variety of instances of a class of systems [77, 79, 85,86,87].

During the interviews, the study’s purpose, individual design principles, and quality criteria were explained to the experts in detail and presented with corresponding examples [84]. Based on this, the experts were invited to evaluate the design principles using quality criteria. Special emphasis was placed on the evaluation of the design principles’ importance and novelty to mirror the insights gained in theory with practice and to classify them accordingly. At least two researchers conducted all the interviews, and the interviewer’s role was changed continuously to ensure the highest degree of objectivity. Interviewees 5, 7, and 12 submitted written responses to the interview guide, so we clarified uncertainties and inconsistencies within shorter interviews. The interviews were conducted and recorded electronically because of COVID-19 restrictions and social distancing practices.

3.2 Data analysis

To prepare for the coding and associated analysis of the interviews, they were transcribed completely verbatim [88]. Based on the transcripts, a qualitative content analysis was conducted, which facilitated a systematic analysis of the object of communication regardless of its form [89]. The coding and associated content structuring were conducted in the form of deductive category assignment, with the objective to extract information based on predefined categories [37]. For this purpose, a two-level category system based on the design principles as first-order structuring categories and the five central quality criteria from Iivari, Rotvit Perlt Hansen, Haj-Bolouri’s [77] evaluation framework as second-order categories was constructed to conduct a detailed analysis (Fig. 1). Furthermore, augmenting explanations for the interviewees’ reusability assessment and relevant practical examples as well as best practices were coded based on the research question. We encouraged our 14 interviewees to provide additional explanations for their decisions including possible examples. In our coding manual, we defined an explanation as a statement that clarifies and provides reasons for the assessment of the design principle’s reusability. We referred to an example as a statement that illustrates a particular implementation of a design principle. In this regard, the interviewees often mentioned their particular design instances for the design principle.

Each researcher coded the sample iteratively and independently. Following Mayring [37], a single sentence was defined within the coding scheme as the smallest unit to be coded, and a paragraph as the corresponding context unit, to ensure the highest possible level of detail. The coding scheme was adapted inductively after each coding round and extended based on the insights gained. We provide an excerpt of our coding table in Appendix A2, an overview of the total number of coded segments in Appendix A3, and explicated the relation between the initial and final design principles in Appendix A4. The aggregation and generalization of the interviewees’ explanations and examples resulted in the updated set of seven design principles for boundary resources in e-commerce ecosystems.

4 Design principles for boundary resources

Next, we present the evaluated design principles for boundary resources in e-commerce ecosystems. The model managed the internal platform roles and ecosystem participants using a set of seven design principles (DP 1–7) for boundary resources (Fig. 2). Owners of innovation platforms and transaction platforms can implement the boundary resources to facilitate value creation among ecosystem participants and attract third-party developers. We depicted the boundary resources relevant for each platform type based on the information provided by our interviewees. Innovation platforms provide the necessary infrastructure and application services to power a transaction platforms business model. Third-party developers can extend the innovation platform’s services with additional complements. Summarizing the design principles provides a structure for developers and platform owners and enhances the accumulated design knowledge’s tangibility. This utilization of abstract design knowledge was the central practical requirement, according to the interviewees: “What I think would help comprehension is if there would be some overarching structure among the design principles” (5).Footnote 1 This enabled us to derive seven evaluated design principles and three platform-internal archetypical roles,– business process owner (BPO), user interface designer (UID), and internal platform developer (IPD) [81]. We further investigated which roles provided substantial information on the seven design principles and which roles claimed design principles within their responsibility (Fig. 2).

Fig. 2
figure 2

Boundary resource for platforms in e-commerce ecosystems

Full size image

4.1 Ecosystem conversation

Analogous to social boundary resources [21], the platform boundaries in e-commerce ecosystems provide mechanisms for communication among participants. Conversation mechanisms address the business actor layer [14] and involve dedicated channels, multiple media sources, and diverse demo scenarios [18]. Through conversation channels, participants can contact the platform and easily exchange information about their projects and products [75]. They resemble an interface to propel human-to-human communication among ecosystem participants and with the focal platform. A developer forum, blog, e-learning suite, or instant messaging application can be implemented as a communication channel (eg., Slack or Discord) (4, 5, 7). Conversation channels should fit ecosystem participants’ individual requirements: “Communication channels and media need a fit for the target audience” (5). For instance, most IPDs deemed a written API description to be appropriate (5, 6, 11). Media formats describe the form of the information provided via conversation channels [18]. The information and media exchanged via these channels should address each participant’s needs: “It’s not the most important to be sophisticated in the media format, but that it’s usable and helpful for the audience” (5). However, the number of channels and media shared must be chosen carefully to avoid overwhelming participants. It is also necessary to be transparent about which information is communicated via which channel to avoid confusion (10). As a specific media format, demo scenarios showcase important processes or features of the platform for ecosystem participants [90]. They also provide a starting point in big e-commerce ecosystems with many different possible processes. Interviewees viewed demo scenarios as offering potential shortcuts for otherwise lengthy coordination processes (8, 10): “Demo scenarios are quite essential because if you don’t have them, you’re going to manually answer these questions” (4). Therefore, we proposed DP1: Provide the platform with mechanisms for communication so that ecosystem participants can exchange information transparently and easily.

The selection of appropriate conversation channels and media formats is particularly relevant for transaction platforms orchestrating a variety different of ecosystem participants, eg., sellers, customers, and service providers [15]. This may involve several different social boundary resources accompanying application boundary resources. For innovation platforms that mainly attract external developers, the communication focus is on development boundary resources (6, 11). Communication with developers can be customized to a high degree and limited to only a few media formats on diverse channels: “For the support of extension development, written documentation is mostly sophisticated” (7).

4.2 Extension marketplace

Platform extensions enhance a platform’s features and functionalities (8), and retailers and other ecosystem participants can use them [91]. These extensions can be either software artifacts [92] or service-oriented (3). While third-party developers implement software extensions, service providers can offer additional services (14). Different types of extensions usually are provided via central extension marketplaces in e-commerce ecosystems [13]: “Implementing a marketplace and fostering a network of partners with their own modules and a marketplace [are] a key development for a growing tech company. So, we are planning to do this in the future to keep being attractive on the market and to get a unique selling proposition” (12). Thus, we proposed DP2: Provide the platform with an extension marketplace so that ecosystem participants can provide and use complementary extensions.

An extension marketplace offers business opportunities for third-party developers and service providers [92] who both can be incentivized to provide additional modules and services (5). Incentives for developers can take the form of money and other non-monetary rewards (eg., developer awards, special extension placement) (11, 8). Monetary and non-monetary incentives can increase third-party developers’ loyalty to the ecosystem [93]. If the platform owner does not provide a central solution, developers might collaborate elsewhere without exploiting their full generativity (12). Thus, the platform owner can attract several developers to extend the platform’s features with a central marketplace: “If we introduce incentives, we get more developers working on extensions in the ecosystem and, overall, the offer of extensions becomes broader and better” (7). The extension marketplace can implement evaluation guidelines as internal rules of the platform for rating third-party extensions. These offer input control before extensions are provided in the marketplace [28]. The platform owner can make the evaluation guidelines transparent for third-party developers so they can optimize their extensions and make them more compatible [92]. This transparency can be achieved by offering written guidelines or automatic evaluation tools (13): “You must have certain criteria that you can evaluate your modules against” (4). Aside from these internal guidelines, other ecosystem participants can conduct module rating, which can take the form of external control [28] or a star rating system with optional comments (2, 7). Thus, ecosystem participants can share their opinions (i.e., word of mouth) with other potential users [94]. However, reaching a threshold of opinions and filtering relevant reviews are crucial issues for platforms (9): “It is crucial who is allowed to rate and who can verify a rating or opinion” (3). The ratings must contain useful information for the developers (4). Developer profiles present developers’ professional information, skills, and rewards [95]. These profiles are linked to platform extensions provided via an extension marketplace and allow for assessing each extension with reference to the developer or provider [96]. For extensions that a group of developers or a dedicated software provider develop, the company’s overall reputation can be displayed, including reference projects (10): “We are planning to include extended developer profiles in our marketplace, as we agree this is an important factor in building trust” (5).

An extension marketplace for software extensions is particularly relevant for innovation platforms [13, 92], as they provide the necessary application services for business models in e-commerce [97] that can be extended through third-party extensions (12). Additional services for third-party sellers––eg., fulfillment services, credit assessments, and address validations––also can potentially be provided on transaction platforms in dedicated service marketplaces (4). As we did not find any further evidence for service marketplaces, we did not propose them as potential design principle for transaction platforms.

4.3 Ecosystem extension

An ecosystem’s reach can be enlarged not only through an extension marketplace, but also an extension of the ecosystem itself [98]. Connecting or integrating an additional platform to the focal platform allows for more ecosystem participants in general and developers in particular to access the ecosystem: “This is also very effective for customers who rely on having as many partners or marketplaces [in the ecosystem] as possible” (10). This also may enable access to new markets: “The fact is that we are trying to expand our ecosystem so that we can connect the other markets” (8). Extending the ecosystem allows more participants to get involved, which may lead to more collaborative work on individual projects: “Very few major things are developed by one person alone these days; you always have teams” (11). Thus, we proposed DP3: Provide the platform with boundary resources to connect to an additional platform to allow more developers to access the platform and enhance collaboration.

Extending the ecosystem by integrating additional platforms is particularly relevant for innovation platforms, allowing external developers to extend their reach, as well as for potential users of their extensions. Connecting with additional platforms is handled by IPDs that implement the necessary boundary resources and possible abstraction layers: “The biggest one for me on platform integrations is that no two platforms will have the same data model underpinning them, so there’s a bit of abstraction that you have to place in there” (4). Collaboration among the extended ecosystem can be fostered by a central repository that supports effective value co-creation (4, 8, 11). Providing a central repository (eg., Git) for versioning facilitates collaborative coding and integration. This can be either a central repository that the internal platform developers manage, or community-specific repositories (14).

4.4 Standards and guidelines

Standards and guidelines are important when working collaboratively on software projects [5, 99], and they become inevitable when working in an e-commerce ecosystem with many participants who have different perspectives: “So, standards are valuable when you have to work with a lot of developers” (9). In particular, the use of coding guidelines can improve code quality, understandability, and communication: “So, coding guidelines are useful because they support structuring the code, the maintainability, and the readability” (4). Using coding guidelines is a matter of scalability, i.e., greater numbers of participants tend to be more effective, while with smaller projects, participants’ efficacy is limited: “For me, this is a question of scaling: With a small team of five engineers, writing coding guidelines is rather idle” (11). Furthermore, using templates for major development tools helps implement new services around a platform. Tool templates reduce barriers to entry for third-party developers and accelerate overall implementation: “If people can work immediately, it is definitely a very enormous push” (8). These templates also ease the onboarding of new third-party developers: “This lowers the entry barrier for new developers who may not be familiar with the tool” (12). Furthermore, providing predefined and evaluated user interface prototypes can facilitate the development of an e-commerce website’s user interface. These prototypes help evaluate websites’ designs before too much time is invested in their development: “We also show these drafts selectively to existing and future users in order to incorporate feedback into the development before implementation” (12). Generally, defining the user interface prototype beforehand accelerates implementation of a unified user interface. Such prototypes nullify all new discussions about an artifact’s design: “One of the biggest discussions is always: How do I design my application? And because we predefine it, they basically already have a lot of that discussion behind them” (8). UIDs are involved in designing (visual) boundary guidelines. Therefore, we proposed DP4: Provide the platform with standards and guidelines so that users can propel inter-ecosystem collaboration to accelerate development, reduce developers’ barriers to entry, and harmonize design.

This design principle is relevant for innovation and transaction platforms. While the former implements coding guidelines and tool templates to enhance distributed extension development among developers (7, 11), the latter provides UI guidelines for retailers for harmonized shop designs to create a continuous experience for customers (3, 6): “These guidelines will guide us on how we can better achieve the good, consistent user experience across all of our platforms” (1).

4.5 Quality assurance

The quality of third-party extensions developed for the ecosystem must be ensured [18], so when developing an extension, sophisticated testing and verification methods should be provided (11, 12). Establishing a development system similar to the production system allows for conducting quality tests during the development’s early stages [18]. Sandbox environments, in which all available functionalities can be tested with test data, are common (14). However, it is not possible to rely exclusively on test data, which do not correspond in scope and quality to production data: “You can’t replicate production data into a staging system. This is what makes staging mechanisms quite difficult” (4). Furthermore, quality gates should be implemented to ensure proper development when extensions are transported between the test and productive environments: “Important for quality management is to integrate quality gates when transporting to the next stage. In those, the artifact is evaluated against predefined quality criteria in analogy to evaluation guidelines (eg., functionality, security, performance)” (11). An implementation pipeline also needs to be built to ensure the extension’s correct functionality and integration, which may vary depending on the developer and user’s needs (10, 11). Aside from extension development, another key challenge for developers concerns the design, analysis, and monitoring of business workflows on the basis of their complexity in the e-commerce environment [100]. Templates can be used to represent different situations and help the user understand the meaning of the business process quickly [100]. Furthermore, a testing mechanism for the whole workflow to harmonize the retailer and developer’s business processes can increase quality. However, individual workflows’ complexity and length make this quite challenging: “I find it difficult to offer testing of a workflow because they can be enormously long, complex, and diverse” (2). Ideally, the workflow tests are performed automatically, but this presents a huge challenge for the developers: “It is a lot of upfront labor to implement automated workflow testing, but you need it, especially for scaling your business with numerous ecosystem participants” (4). Nevertheless, the benefit of implementing such mechanisms is huge, and it can minimize hard labor (4, 8, 10), resulting in increased generativity, as the developers need not test the workflow themselves: “Through automation, you release cognitive potential within a project because people can then simply occupy themselves with other topics” (10).Therefore, we proposed DP5: Provide the platform with testing and verification mechanisms so that developers can conduct extensive quality tests for the developed extension, as well as test their functionality.

Innovation platform owners need to implement this design principle to ensure third-party extensions’ compatibility with platform services [97] and to provide users of the extensions with acceptable quality (8, 10).

4.6 Analysis and monitoring

Business analytics provide ecosystem participants with key performance indicators and enable sophisticated analyses of past and current transactions, including analysis of big data generated in e-commerce [5]. Owing to the variety of possible ecosystem participants, business analysis should be accessible to non-experts and filterable for different tasks and roles [101]. The degree of information must be appropriate for each participant so that they can cope with the volume of information (10). This is particularly relevant to BPOs: “We must show detailed information to our users, like how many views they got, how many searches, particular keywords, and how many clicks, and those types of things. The more data that you can provide on that level, the better it is in terms of building a relationship” (4). Providing tools to analyze this data and predefined reports can provide ecosystem participants with business insights and start potential business actions, eg., promotions (8). Furthermore, overall system performance in general and the status of boundary resources in particular must be monitored (3, 13). This requires the platform owner and developers to be informed about the system’s status in real time. This information can be used to fix errors manually or automatically [102]. Developers also are informed about possible system and boundary resource vulnerabilities (11). Third-party and internal developers rely on boundary resource monitoring for their extensions’ proper functioning (5): “Supporting admin and developers by providing an easy system status overview and an informative error log is a key to success” (7). Therefore, we proposed DP6: Provide the platform with analysis and monitoring tools so that users can perform sophisticated business analyses, as well as fix errors that occur as quickly as possible.

While transaction platforms create and provide analyses of current and past transactions in e-commerce ecosystems for a variety of ecosystem participants, innovation platforms provide information on the overall system status in general and boundary resources in particular to their customers and external developers.

4.7 Boundary resource evolution

Aside from boundary resources’ current status, their evolution at a strategic level is relevant to internal and external developers. This strategic evolution reflects a platform’s business strategy and involves the boundary structure, deprecation, and roadmap. The platform owner should provide a transparent structure for the provided features and boundary resources. As contemporary software artifacts tend to be complex, making their structure transparent is key to developing extensions (2). Third-party developers need to know which interfaces are mandatory and how they interact with others [97]. This structure also includes responsibilities for boundary resources and exchanged messages (9). As the platform evolves, the structure must be updated regularly (11). However, boundary resources are likely to hide the platform’s internal implementation, and they are visible only to ecosystem participants. Only a few platforms provide structural diagrams and information on internal modules (1, 9): “There’s a point at which internal transparency is intentionally not desired” (4). Although the literature on platforms recommends keeping boundary resources relatively stable [68], the evolution of platforms necessitates creating, updating, and abandoning boundary resources [71]. Thus, it is critical to differentiate between boundary resource versions and prescribe migration paths for ecosystem participants (7, 12). To a certain degree, new boundary resources that are backward-compatible also can be implemented (6). It is also important to remind companies and developers that they are using outdated interfaces (3): “Before I tell our customers and developers, ‘but the change was in the release notes’, I prefer to go and talk to them. Notes do not matter; conversation is key” (9). Unlike past-oriented deprecation, a boundary resource roadmap describes new platform developments and future boundary resource evolutions. New boundary resources can be introduced, while old ones are abandoned during an initial beta phase before the public rollout (9). Some platforms even provide regular roadmaps on a monthly or quarterly basis (4, 9, 13). Moreover, it is important to train developers and other participants in new features, if applicable (7). The roadmap can include technical and feature aspects (11). However, interviewees warned that a fixed roadmap creates expectations among participants and may result in path dependency (3): “We usually have a phase over process, where we start deprecating the old module and move it into the new module” (1). Against this backdrop, we proposed DP7: Provide the platform with transparency regarding its structure and boundary resource updates so that users can use appropriate boundary resources and adapt to upcoming changes.

The platform structure’s evolution and updates for boundary resources are provided by innovation and transaction platforms in e-commerce. While innovation platforms focus on development boundary resources (5, 9, 10), transaction platforms provide information for third-party sellers on application boundary resources (4, 6, 8). The deprecation and roadmap of boundary resources should be announced with an appropriate lead time to third-party developers so they can adapt to future changes (1). Nevertheless, according to the interviewees, deprecation is far more important than communicating future changes: “I think the deprecated boundary resources and those types of things become far more important as design principles than a road map” (4).

5 Discussion and outlook

In our multi-paper design science research project [76], we developed theoretically grounded and empirically validated design knowledge for boundary resources in e-commerce ecosystems––including social, application, and development boundary resources (Dal Bianco et al., 2014)––and contextualized them for the e-commerce sector (Wulfert et al., 2022). The evaluation of the intermediary design knowledge within a series of interviews with domain expert and their subsequent analysis [37, 83] resulted in an updated set of seven design principles with increased confidence and fitness [76].

We contribute to the literature on e-commerce ecosystems by providing prescriptive design knowledge on the boundaries of innovation and transaction platforms with high confidence and fitness [6, 39]. We also highlighted the inter-company collaboration and multilateral value creation (i.e., joint forces) in e-commerce ecosystems for the benefit of the (final) customer [16]. Moreover, we emphasized the role of third-party developers in e-commerce ecosystems and their implications for the ecosystem’s overall value creation. The ecosystem participants’ joined forces increase the benefit for the (final) customer and the overall ecosystems value. We summarized our design knowledge in an overall framework that is configurable for innovation and transaction platforms (Fig. 2).

Our research also has implications for practitioners. We provided platform owners with concrete recommendations for developing concrete design instances from which they can instantiate boundary resources according to their peculiarities [103, 104]. Following the framework for minimum reusability evaluation and our interview guide [77], our 14 interviewees evaluated the importance and novelty of our overall set of design principles and deemed them important for the orchestration of ecosystem participants in general and third-party developers in particular: “I think that’s why it’s 100% important to address these issues” (10). “It’s good to go through them and compare our system toward them so we can identify which areas need further improvement and where the gaps are” (5). However, some interviewees emphasized prioritization regarding importance within the set of principles (8). Regarding novelty, our interviewees stated that the aggregation of these design principles is novel (3, 5, 14): “The individual design principles are not new, but summarized in this set, it is a good overview that can be given to ecosystem participants” (14). Although the actual boundary resource instances are well known for innovation and transaction platforms, they are not always implemented in practice (7). We also mentioned design instances for boundary resources in the interviewees’ statements.

Furthermore, we considered our design principles’ relevance for platform-internal roles based on interviewees’ job descriptions and explanations [81]. The platform-internal roles are the actual user group of the design principles, as they might instantiate them for concrete boundary resources at innovation and transaction platforms. The BPO is the interface for ecosystem participants and relies on proper conversation and communication of possible system errors and boundary resource updates (DP1, DP6, DP7). UIDs are concerned mainly with intra- and inter-ecosystem standards and guidelines regarding interfaces (DP3, DP4). Guidelines must be communicated accordingly (DP1). The IPD is responsible for the evolution and maintenance of the platform’s technical core (DP2–7). Moreover, our interview analysis revealed that the digital transformation in retail in general and e-commerce in particular remains in its infancy at the company level. Our interviewees stated that incumbent retailers and small and medium-size enterprises often use existing and standardized software (i.e., innovation platforms) provided by software vendors (i.e., Shopify, Magento) (2, 8). They rarely implement their own technical cores and even more rarely open them up to external developers as innovation platforms, possibly due to strong network externalities in existing innovation platforms and winner-take-all tendencies [53]. New platforms would need to distinguish themselves from existing ones and identify possible niches [38]. A potential downside of applying a standardized technical core is that it likely will yield uniform UIs, but interviewees reported that the user interface as a digital storefront is key in distinguishing oneself from competitors (4, 6). Otherwise, competitors could be distinguished only by their product prices [105]. Our interview analysis also indicated that innovation platforms in e-commerce must parcel their services out to enable single developers and smaller groups of developers to participate in e-commerce ecosystems (5, 8, 10, 13). Single developers cannot cope with complex workflows in e-commerce alone. This complexity requires collaboration and value co-creation among third-party developers to provide the focal platforms with useful extensions [5]. In line with existing literature on platform envelopment [106], we also identified a tendency among innovation platforms to integrate successful extensions (7, 9).

In design principle 3, we suggested the connection to “foreign” platform to enlarge the community of third-party developers. This connection also propels developers’ and sellers’ multi-homing given their presence on another platform with the downside of mitigating potential lock-in effects [64, 107,108,109]. Connecting two rival platforms can influence ecosystem competition [110,111,112] and could provide a pathway to enveloping services of the competing platform [106]. “My opinion is that there is no link between two rival platforms, because the result might be a single marketplace” (2). Our interviewees even mentioned antitrust concerns for platform cooperation and acquisition (2, 4). With changes in the ownership structure of the foreign platform, a full integration of the platform can be achieved [26]. Aside from potential implications on the competition, our interviewees also raised concerns for the technical feasibility of connecting different platform (5, 9, 12, 13).

This research project has limitations that offer interesting avenues for future research. The developed design principles for boundary resources in e-commerce ecosystems focus mainly on attracting third-party developers, but we contacted focal platforms for possible interviewees [82]. Thus, our interviews capture prescriptive knowledge on implemented boundary resources [78], but disregard potential third-party developers’ requirements. Future researchers also might try to interview developers in e-commerce ecosystems about their requirements for successful collaboration and value co-creation. Moreover, we could not interview a user interface expert from a transaction platform. Interviewing additional user interface experts could result in interesting insights for standards and guidelines (DP 4). These design address user interface implementations. Regarding the number of interviews conducted, we followed the literature on qualitative interviews, suggesting sufficiency and saturation as potential indicators [82, 113, 114]. We achieved a high level of sufficiency by approaching a variety of innovation and transaction platforms in e-commerce ecosystems as measured by size (Table 1) and representative interview partners as indicated by their internal roles [81]. We also reached data saturation emphasized by the fact, that our interviewees picked up information that we already documented in previous interviews independently of the platform type [39, 82]. However, future studies could analyze single participants further and roles’ involvement in the design and implementation of boundary resources in innovation ecosystems. Another important future research direction would be to formulate design principles for other ecosystem participants explicitly, eg., retailers and content providers [15]. These additional design principles can be accumulated to develop a holistic design theory [85] concerning attraction and collaboration between a variety of ecosystem participants [115].

Future studies also could add design principles with more concrete design features that can showcase potential instances of prescribed boundary resources and simplify their implementation for platform owners [103, 104]. These design features can resemble an intermediary step in the implementation of concrete design instances (eg., APIs, SDKs) and, thus, simply the implementation of boundary resources [103]. If the design principles are instantiated and implement by the platform-internal roles, researchers and practitioners can also measure the performance of concrete boundary resources, such as the availability of APIs and number as well as frequency of API calls.

Moreover, as our interviewees were working for platforms mainly active in Europe and the U.S., future research may consider e-commerce platforms conducting business in Africa, Asia, and Latin America [63]. Such studies also could include cultural implications on boundary resources [64]. Although they might not impact technical boundary resources, social design principles (eg., ecosystem conversion, extension marketplace) require culture-specific adaptations. Future studies also may analyze the need to implement a boundary resource in connection with platform size, as measured by revenue, number of employees, or number of complementors. Although we derived our design principles from an e-commerce context and interviewees working in the e-commerce sector, several interviewees (3, 10, 11) suggested that the design principles also might apply to (software) ecosystems in other industries [92]. They even mentioned that they would be quite useful for large enterprises. Vom Brocke et al. [76] referred to the application of design knowledge in additional problem spaces as projectability. Although we developed and evaluated the design principles for the e-commerce context, they might be applicable in other contexts. Thus, future studies could evaluate the design principles’ applicability in other contexts to improve their fitness in other domains.

6 Conclusion

In this paper, we presented seven design principles for implementation of boundary resources in innovation, transaction, and hybrid platforms in e-commerce environments derived from an interview study with 14 domain experts. Benefitting from the interview analysis, we could improve the design principles’ fitness and confidence for innovation and transaction platforms in our multi-paper design’s research approach. Implementing boundary resources using our design principles would generate collaboration among ecosystem participants in general, join ecosystem participants forces, and enable the contribution of of third-party developers to the e-commerce ecosystem’s multilateral value creation in particular. While DP1 mainly focuses on transaction platforms involving a diverse set of ecosystem participants, we also found evidence for ecosystem communication among third-party developers and platform owners. DP2, DP3, and DP5 are concerned with innovation platforms, easing developers’ onboarding and widening the dissemination of their extensions. DP4, DP6, and DP7 are relevant for both types of platforms by enabling improved transaction orchestration and extension quality simultaneously. Hybrid platforms need to implement all boundary resource types to attract ecosystem participants in general and third-party developers in particular. We also introduced three internal platform roles responsible for the implementation of boundary resources, namely business process owner, user interface designer, and internal platform developer. Finally, this paper provides utilizable design knowledge in the form of seven design principles for the design of boundary resources in e-commerce ecosystems.

7 Appendix 1: Interview guide

7.1 General information

This interview will take approximately 45 min and aims at assessing the use of design principles for software interfaces (eg., application programming interfaces, software development kits, developer documentations) in e-commerce ecosystems lowering barriers to entry for developers and retailers providing the ecosystem with additional content. We will use the term boundary resource as a more abstract description of interfaces. Design principles for boundary resources will be evaluated against five criteria (accessibility, importance, novelty and insightfulness, actability and appropriate guidance and effectiveness). The interview will be conducted virtually (eg., Zoom, Teams). We want to record the interview and therefore need your consent that will be inquired at the beginning of the interview. In the following we provide you with a short introduction to e-commerce ecosystems and boundary resources. Following that we describe the proposed design principles as well as their purpose. After those introductions the interview course and the interview questions are explained in detail.

7.2 Boundary resources in e-commerce ecosystem

E-commerce ecosystems provided by a digital platform owner aim at enlisting external participants to utilize value creating mechanisms. Those ecosystems establish connections between its participants through which new relationships are implemented. For ecosystems their size and their exploitation of network effects are crucial. Therefore, one important goal of an ecosystem is to constantly increase the number of participants. Additionally, the accessibility for new participants like retailers and their developers should be uncomplicated. Therefore, the provision of boundary resources (i.e., interfaces) could help increasing the number of participants. Those resources serve as interfaces between the ecosystem provider and partners (eg., external developers). For this purpose, they can either be used to forward knowledge and capabilities for designing and implementing applications and extensions for the ecosystem or they are used by the provider to impact the design and implementation of the ecosystem. Prominent examples are application programming interfaces and related documentations, so that an external developer is supported in building a connection to the platform.

7.3 Design principles

Design principles are prescriptive statements that show how to do something to achieve a certain goal. The formulation of design principles is highly relevant in e-commerce ecosystems. They help platform owners with the design of their software interfaces for external developers. The purpose of the proposed design principles is to achieve standardization of boundary resources in digital business ecosystems in e-commerce to reduce barriers to entry for developers and propel network effects. In doing so the focus are boundary resources as the transition zones between the ecosystem core and its periphery. Consequently, the design principles are focused at supporting the specific requirements of customers and developers within e-commerce ecosystems that extend the focal platform with additional content (eg., shop themes, plug-ins, integration components). Our preliminary research resulted in 19 design principles and are illustrated in the following.

Before we start with the evaluation of the design principles, we would like to ask some general question about the interviewed person and business:

  • What is your name?

  • What is your task/role within your organization?

  • What is your relationship to the ecosystem of your organization and to boundary resources?

  • How important are marketplaces for your business?

  • Do you provide specific interfaces for customers and developers? What is the involvement of (external) developers in your ecosystem?

  • Does your company apply some sort of enterprise architecture management and use reference architectures (eg., TOGAF)? Do your architectural models reflect interfaces for external partners?

Now, the above stated design principles will be evaluated. For this purpose, we evaluate them according to five criteria: accessibility, importance, novelty and insightfulness, actability and appropriate guidance and effectiveness.

First, we will evaluate every design principle developed by Wulfert, Woroch, Strobel, Seufert, Möller [18] using the three criteria accessibility, actability and appropriate guidance and effectiveness on each design principle. After that we will assess the design principles as a set with the remaining criteria. In the following the 19 principles are listed and for each one a question about their accessibility, actability and appropriate guidance and effectiveness is stated. In the interview you may answer by saying “Yes” or “No” and add an explanation as you wish. Mainly, the following three questions are asked for every design principle:

  • Accessibility: Is this design principle easy for you to understand?

  • Actability and appropriate guidance: Do you think that this design principle can realistically be carried out in practice?

  • Effectiveness: Does this design principle help with the design of interfaces for e-commerce ecosystems in practice?

At last, you will be asked the following two questions about the importance and novelty and insightfulness concerning the whole set of design principles developed by Wulfert, Woroch, Strobel, Seufert, Möller [18]:

  • Importance: Does this set of design principles address a real and important problem in your professional practice?

  • Novelty and insightfulness: Does this set of design principles provide new ideas and insights for you?

8 Coding table

In Table 2, we depict an excerpt of our coding table consisting of the codes, code descriptions, and anchor examples.

Table 2 Coding Table Excerpt
Full size table

9 Overview on coded segments

In Table 3, we summarized the total number of coded segments for each code per interview, the total number of coded segments per code, and the total number of coded segments per code.

Table 3 Code-Matrix-Browser Overview per Coding Segments
Full size table

10 Updated design principle and reference interviews

In Table 4, we indicate the updated design principles initially proposed by Wulfert, Woroch, Strobel, Seufert, Möller [18]., highlighted the main changes in bold for the design principles within this study (left column), and indicated reference interviews that led to the updated design principles.

Table 4 Updated Design Principles and Reference Interviews
Full size table