Configurations of platform organizations: Implications for complementor engagement

Digital platforms are an organizational form made up of a technological architecture and governance mechanisms for managing autonomous complementors. A platform’s success depends on their engagement in value creation and capture. Prior studies of such engagement have mainly focused on a platform’s governance mechanisms without recognizing their interdependence to its technological architecture. There is therefore a limited understanding of how the interplay between governance and architecture configures platform organizations, and why these configurations produce different levels of complementor engagement. In this paper, our analysis of a 12-year study of a shared platform initiative yields three configurations of platform organizations: vertical, horizontal, and modular. Based on these configurations, we develop propositions that theorize the implications of these organizational forms for complementor engagement. We further propose that these insights, which we derive from a shared platform, are particularly relevant for blockchain-based platforms.


Introduction
Digital platforms 1 as an emergent organizational form (Gawer, 2014;Nambisan et al., 2017) are characterized by (1) technology: a technological architecture constituted of a modular core, standardized interfaces, and complementary extensions (e.g., Baldwin and Woodard, 2009;Karhu et al., 2018), and (2) social processes: a set of governance mechanisms to manage an ecosystem of independent complementors who complete the platform's value proposition by co-creating its value (e.g., Adner, 2017;Nambisan, 2017). By mediating the interactions among such complementors, platforms afford multi-sided markets that are an indispensable part of our contemporary economy (Ceccagnoli et al., 2012;Lusch and Nambisan, 2015).
Especially in industries characterized by network effects, a platform's value proposition depends on complementors to enact and evolve it (e.g., de Reuver et al., 2018;Parker et al., 2017). However, it is challenging for platform organizations to "discover and implement a complex value proposition via an innovation ecosystem while also ensuring that it will benefit from the fruits of the collective effort" (Dattée et al. 2018, p. 470). Securing complementor engagement, i.e., complementors' contribution of value-adding complementarities and their compliance with the platform's rules and processes (Jacobides et al., 2018), is thus the most critical success factor of such organizations (e.g., Boudreau, 2012;Eaton et al., 2015).
Previous platform research highlights that managing complementor engagement is rife with contradictions (Wareham et al., 2014). To foster generativity (i.e., evolvability), the independence of complementors, who work autonomously to satisfy customer needs, must be promoted and facilitated (Huber et al., 2017;Song et al., 2018). To create and maintain a coherent, shared identity for the platform (i.e., stability), however, complementors' pursuit of their own interests must be balanced with the interests of other players in the ecosystem (Eaton et al., 2015;Parker et al., 2017). While there is ample research on the challenge of balancing a platform's stability with its evolvability (Dattée et al., 2018;Tilson et al., 2010), it focuses predominantly on governance mechanisms as the primary means for reconciling these competing demands (Lindgren et al., 2015).
A platform's technological architecture, however, represents another key means to achieve complementor engagement (e.g., Tiwana, 2015a,b). For example, the modularity of the platform's core has been found to be an important determinant of positive network effects (Pagani, 2013) in that it maximizes complementor independence and creativity by ensuring the interoperability among components (e.g., implications for its governance, simply because rights and rules may be embedded in and thus enforced by the technology itself (Jacobides et al., 2018;Nambisan, 2017).
There are few platform studies that explore the mutual interdependence between architecture and governance, and that theorize its implications for complementor engagement. The fact that most empirical platform research deals with proprietary platforms, where access to the platform's evolution is limited and owners have made both architectural and governance decisions prior to going live (Eisenmann et al., 2011), seems to contribute to the current dearth of research on the emergence of architecture-governance configurations and the levels of complementor engagement they produce. Only a handful of recent studies address shared platforms, which are developed and operated by collectives of heterogeneous actors in a more transparent process (e.g., Jha et al., 2016). Since these studies largely rely on the reconstruction of events from historical data, their ability to shed light on the mutual shaping of technological architecture and governance mechanisms in configuring platform organizations and engaging complementors is constrained.
The configurational dynamics of technology and social practices in platform ecosystems merit further attention. For example, platform leaders' decisions and choices regarding the relationship between the degree of architectural openness and the allocation of decision rights do not only shape the appeal and accessibility of complementor opportunities provided by the platform, but also complementors' perceived uncertainty and their willingness to cope with it (Nambisan, 2017). Questions of the mutual interdependence between technology architecture and governance mechanisms need to be examined to understand how to optimize complementor engagement for platform success. To this end, a longitudinal research design capable of tracing whether mechanisms governing a platform ecosystem of complementors "change as a function of the shifting nature of modularity" (Jacobides et al., 2018(Jacobides et al., , p. 2269 holds great promise. In this paper, we take inspiration from work by Dattée et al. (2018), Jacobides et al. (2018), and Jha et al. (2016) to develop new theoretical insights into the interplay between architecture and governance in configuring platform organizations that are capable of developing and sustaining high levels of complementor engagement. Our research question reads: How does the interplay between technological architecture and governance mechanisms generate platform organizations that produce different levels of complementor engagement?
To answer this question, we draw on data collected during a longitudinal 12-year (2002-2013) platform initiative in the Swedish road haulage industry. The purpose of this project was to allow small road haulage firms to integrate embedded, mobile, and stationary technologies. What emerged was a shared (Eisenmann, 2008) or a standardbased platform (Markus and Bui, 2012) that was collectively developed and governed by an industry consortium comprised of customers (i.e., road haulers) and complementors (i.e., software vendors and truck manufacturers). Applying imbrication as a theoretical lens (Leonardi, 2011), our objective is to (i) identify and conceptualize architecturegovernance configurations that enact shared platforms, (ii) gain insight into the interdependence of their technological and social dimensions, and (iii) theorize the implications of these configurations for complementor engagement. Notably, our focus on shared platforms offer us the opportunity to develop insights relevant to blockchain platforms, which are beginning to emerge as peer-based and more cost-effective alternatives to proprietary platforms (Beck et al., 2018). As such, they bear much resemblance to shared platforms.

Complementor engagement
Given that platform organizations are composed of an architectural core that needs to be completed by third-parties' contributions of peripheral components that enhance its value (Boudreau, 2010(Boudreau, ,2012, developing and maintaining complementor engagement is a critical success factor for this form of organizing (Wareham et al., 2014). The notion of complementor engagement captures a platform organization's goal to leverage the expertise and ingenuity of complementors, e.g., a diverse developer community (Benlian et al., 2015;Ceccagnoli et al., 2012), to create new capabilities that will realizing its generative potential (de Reuver et al., 2018;Nambisan, 2017).
As rational actors, complementors strive for competitive differentiation, focusing on their own portfolio of domain expertise, market mechanisms, relational capital, and sector knowledge to create locally relevant solutions. Yet, they must also contribute knowledge that benefits the collective and ecosystem cohesion because, while moderate competition tends to stimulate innovation, intense competition is likely to undermine it (Boudreau, 2012). Platforms thus need to balance the complementarity and competitiveness among complementors (de Reuver et al., 2018), which implies managing the contradiction between a platform's evolvability to foster generativity and its stability to enable efficiency and complementors' value capture (Wareham et al., 2014;Sarker et al., 2012).
Past platform research has reported a positive correlation between the number and heterogeneity of complementors and the variety of complements a platform offers: the broader the range of complementors that contribute components to the platform, the higher the likelihood that it will follow a successful evolutionary path towards dominance (Eisenmann et al., 2011;Jacobides et al., 2018). However, complementor heterogeneity has also been found to lead to significant variance in the quality of complements (Wareham et al., 2014).
While most platform research has prioritized governance as the means for managing complementor engagement (e.g., Huber et al., 2017;Sarker et al., 2012), some studies have begun to recognize "that the choices about who ought to make what decisions are intertwined with the architecture of the governed information technology artifact" (Tiwana 2015b, p. 40). Table 1 provides a summary of literature that explores platforms as configurations of architecture and governance that have implications for the engagement of complementors.
The majority of these papers (11 out of 15) deal with proprietary platforms (e.g., Kapoor and Agarwal, 2017;Karhu et al., 2018;Ozalp et al., 2018). Since the platform owner develops the platform and thus makes all technical decisions, these papers only concern themselves with the interaction between the technical and the social in managing complementor engagement after the platform is operational .
For example, Ondrus et al. (2015) argue that governance mechanisms are particularly relevant once there exists a platform core whose value proposition needs to be completed by complementor extensions; however, it is the architectural core (the configuration of data access, component interoperability, and core-extension coupling) that largely determines a platform's market potential prior to complementor engagement. In contrast, Kazan et al. (2015) suggest that decisions about platform access (direct, indirect, or open access), which determines what value complementors can derive, are intrinsically related to architectural choices made throughout the evolution of a platform. Taking a similar perspective, Tiwana (2015b) argues that component decoupling and interface standardization may reduce coordination costs, but if the architecture is incongruent with complementors' decision rights they are likely to eventually abandon a platform.
Only a few of these platform studies (The last four papers in Table 1) consider shared platforms, i.e., efforts where multiple, independent complementors jointly develop a platform organization over time. The main challenge these collaboratively developed and maintained platforms face is that the competitive dynamics among complementors are present from the platform's inception and are likely to shape not only the technical design of the platform, but also its governance mechanisms. Additionally, the history of interaction among the complementors, as well as the governance mechanisms employed to coordinate the stakeholders during the development efforts, have implications for complementors' willingness to commit their resources  F. Saadatmand, et al. Research Policy 48 (2019) 103770 to the platform once it is operational. While architectural features of the platform, e.g., modularity, create the conditions for smooth coordination (Jacobides et al., 2018), governance remains key to the development of shared platforms, as it provides processes for how to resolve conflict and encourage alignment through rules of engagement (Jha et al., 2016). Furthermore, as the value capture opportunities for complementors evolve in a shared platform, governance mechanisms need to respond more dynamically to the technical and social shifts in collaborative development contexts (Dattée et al., 2018).

Platform organizations
Consistent with Gawer (2014), we argue that technology architecture and mechanisms for governing the ecosystem of complementors make up the organizational form that is the platform. However, to understand how architecture and governance intertwine to become platform organizations, we need to conceptualize each of these elements in turn. Tiwana et al. (2010) highlight that a platform's technological architecture comprises three components: (1) a core, (2) interfaces, and (3) complementary modules that expand the core's functionality. This definition draws on Baldwin and Clark's (2000) general principles of modular systems design, which stipulate that systems have modules whose design parameters are hidden (encapsulated core modules) and visible design rules that facilitate inter-module interaction (specified interfaces). While the core is the hidden layer of a platform's architecture, the interface is made publicly accessible (Baldwin and Woodard, 2009;Karhu et al., 2018).

Technology architectures
The architectural core, which constitutes "one component of, or subsystem of, an evolving technological system when it is strongly functionally interdependent with most of the other components of the system" (Gawer and Henderson 2007, p. 4), acts as a mediating device, transferring messages between disparate parts of the platform. To qualify as a core, it "should perform at least one essential function … or solve an essential problem within an industry" (Gawer and Cusumano 2008, p. 29) and, at a minimum, it needs to broker communications between two entities by means of such functions as user registration, message addressing, and message validation. The core is made accessible to other, possibly third-party, modules through an interface, which is the de-facto standard of interoperability among platform complementors (Boudreau, 2010(Boudreau, ,2012. Hence, the interface acts as a "treaty between two or more sub-elements" (Baldwin and Clark 2000, p. 73) that forces module developers to format their input and output parameters in ways that other modules can readily send messages to and receive messages from the focal module (Baldwin and Woodard, 2009).
The quality of a platform's architecture can be evaluated according to two key measures: the modules' synergistic specificity and the conformability of the core-periphery interface (e.g., Sanchez and Mahony, 1996). The former measures a platform's architectural modularity in terms of the degree of dependence between the core and extension modules. To achieve low synergistic specificity, i.e., loose coupling, core modules must be more general, reusable, and re-combinable (Sanchez and Mahoney, 1996). High synergistic specificity, i.e., tight coupling, implies that extension modules are highly specific to core modules (Schilling, 2000). While an architecture characterized by higher synergistic specificity typically generates a more uniform user experience (as different modules are specifically designed to work together), lower synergistic specificity enables generativity because extension developers can act more independently and are able to pursue their own self-interest.
A highly conformable interface is clearly specified, unambiguous, stable, well documented, and standardized (Tiwana, 2015a). Table 2 summarizes each of these dimensions. Platform providers may offer configuration tools, such as software development kits, schemas or templates to increase the conformability of an interface by helping complementor technologies comply with the architecture standards (Ghazawneh and Henfridsson, 2013). While high interface conformability makes it easier for complementors to adapt to the core architecture, the degree to which they conform to a platform's prescribed interface specifications can vary considerably (Tiwana, 2015a). For this reason, governance is needed.

Governance mechanisms
Governance has a prominent role in the extant platform literature (e.g., Adner, 2017;Benlian et al., 2015;Svahn et al., 2017), in large part because complementors are rational actors whose interests are frequently misaligned with those of the platform owner and the other complementors, with whom they compete (Yoffie and Kwak, 2006). If left ungoverned, complementors with higher status (e.g., producers of best in class products and/or with large install bases) are likely to dominate the platform, which makes it less attractive to other complementors (Wareham et al., 2014). This ultimately constrains network effects (e.g., Zhu and Ianisti, 2012). Hence, a key goal of governance mechanisms is to offer complementor incentives to align the various stakeholders' interests (Kapoor and Agarwal, 2017;Song et al., 2018). Table 3 summarizes the governance mechanisms prior platform research has identified.
Governance mechanisms in shared platforms typically revolve around granting authority over control points to platform actors, and ensuring compliance with the platform's objectives and rules (Huber et al., 2017;Tiwana et al., 2010). Granting authority implies allocating decisionmaking rights over the control points in the platform (locations in an architecture that determine a platform's greatest value or power) to complementors and the platform owner (Dattée et al., 2018;Pagani, 2013). Different sets of decision rights should be allocated in a way that the cost of coordinating and safeguarding the resources can be recouped by the value co-created through the platform (e.g., Tiwana, 2015b). To this end, intellectual property protections and other legal rights of exclusion may either be granted or denied (Benlian et al., 2015). Ensuring complementors' compliance entails that platform providers "craft rules and shape the process of ecosystem development to tie in complements and make complementors abide to them" (Jacobides et al., 2018(Jacobides et al., , p. 2263. This governance mechanism requires that the platform's values and the behaviors expected of complementors are clearly articulated (Huber et al., 2017). Indeed, given the importance of cross-side network effects to platform organizations, incentivizing complementors to build products with the functionality and quality that generate competitive advantage for the platform represents a key management concern (Boudreau, 2010(Boudreau, ,2012Song et al., 2018;Wareham et al., 2014).

A configurational process perspective
The particular configuration that constitutes a given platform organization, evolves out of the interaction between its technological architecture and governance mechanisms. The configuration, in turn, determines the platform's capability to produce and sustain complementor engagement (Gawer, 2014). Even though some of the extant literature highlights this interaction in the realm of proprietary platforms (Tiwana, 2015b), studying emergent platform configurations and their implications for complementor engagement in shared platforms promises us particularly valuable insights into these relationships (Dattée et al., 2018;Jacobides et al., 2018).
The imbrication lens (Leonardi, 2011) is a process perspective that allows us to track the mutual shaping of the technological (components, interfaces) and social (processes, rules) aspects of a shared platform over time. More specifically, its conceptual scaffold encourages the bundling of social and material agency into distinct moments that shape each other and, over time, configure the platform organizations through the sedimentation of socio-material practices into an infrastructure. This perspective maintains that human agency (the ability to act with intentionality, motivation, and rationality) and technological agency ("the capacity for nonhuman entities to act on their own, apart from human intervention" (Leonardi 2011, p. 148)) form the building blocks of practice. When human and technological agencies are put together (i.e., imbricated) into an interlocking, overlapping arrangement, they create technologies and routines ("sequential patterns of social action" (Leonardi 2011, p. 148)). These, in turn, imbricate to form an organizational configuration, whose arrangement determines whether the technology is seen as either affording or constraining users in their efforts to exercise their agency.
Furthermore, the imbrication perspective theorizes that the configuration of human and material agency also determines whether people will change the technology or change their routines. When the technology is regarded as an affordance, i.e., an action possibility for a specific user in a specific context (Gibson, 2014), a sequence of imbrications that changes what people do, is set in motion. For example, a modular platform architecture that enables generativity affords customers a choice among components and how they are combined. This, however, results in a change of governance from a hierarchical, topdown mechanism to a more egalitarian, collaborative one (Jacobides et al., 2018).
In contrast, when the technology is perceived as a constraint, a sequence of imbrications that changes the technology is generated. Taking Mozilla's Firefox as an example, extensions (add-ons) that exhibited a low degree of modularization constrained the evolution of both complements and the overall ecosystem (Tiwana, 2015a). In response, Firefox devised a four-step screening routine (governance process) that permitting only quality extensions to be added to the platform. Any problem identified in the screening process needed to be corrected by the complementor before Firefox performed its screening yet again.

Research design
Our research is based on a 12-year (2002-2013) shared platform initiative within the Swedish road haulage industry. The purpose of the project was to develop collectively a new standard-based platform for integrating data from the three islands of technology on which road haulers relied: stationary enterprise systems, mobile applications, and vehicle-embedded systems. The project was designed as action research and drew on established traditions within the IS discipline. Its approach was problem-solving dominant in that it endeavored to generate and analyze interesting insights that emerged during decision making activities (Lindgren et al., 2004). Given our case study method, we seek to generalize from our empirical material to theory, rather than generalizing to the population of shared platforms (Lee and Baskerville, 2003). Also, the account presented in this paper reflects one of the many possible theoretical trajectories that was identified during the multiyear effort of abductive theorizing (Locke et al., 2008), which has benefitted from a grounded engagement with the empirical material and the platform literature.

Case study
Road haulers' field operations rely on embedded technologies and mobile devices to coordinate work with headquarters that use enterprise systems for route management and cost control (Andersson and Lindgren, 2005;Lindgren et al., 2008). Table 4 presents a summary of these three major classes of technology that operate in a typical road haulage firm.
However, the lack of an industry-specific, standardized shared platform meant that it was difficult for the Swedish road haulers to digitalize their processes and thereby gain the efficiencies they needed to compete in an increasingly open logistics market that brought more and larger international trucking companies (e.g., DHL, Schenker) to the country. Moreover, the proprietary integration solutions that most haulers had invested in over time not only created lock-in effects that produced inefficiencies within individual firms, but they also hindered inter-organizational collaboration that promised optimized fleet utilization and reduced CO 2 emissions (Lindgren et al., 2008).
A shared platform initiative was born in 2002 to help the relatively small, heterogeneous, and independent Swedish road haulers remain competitive by means of frictionless transactions and greater information transparency across a diversity of technologies. The Mobile-Stationary Interface (MSI) initiative can be classified as an industry effort aimed at facilitating smooth coordination of transport processes both within and across road haulage firms. Besides improving the effectiveness and efficiency of the haulers' operations, the platform initiative sought to generate new digital options and business opportunities for technology vendors.

Data collection
The MSI project 2 was initially led by the Viktoria Institute (a research-focused consulting organization) whose customers included mostly transport companies and automobile manufacturers. The transport industry network that Viktoria Institute coordinated, was comprised of fourteen technology vendors, two truck manufacturers, a number of road haulage firms, and a consulting organization owned by fifteen Swedish transport organizations (see Table 5 for a classification 2 VINNOVA (Swedish Agency for Innovation Systems), Swedish ICT (research institute group), MSI Group, and the participating organizations funded the project. of the participating actors). The industry actors brought considerable experience with embedded, mobile, and stationary technology to the project, while the action researchers brought expertise in design-oriented action research (Lindgren et al., 2004), as well as in embedded and mobile computing infrastructures (Henfridsson and Lindgren, 2005). Although Viktoria Institute initiated the project, the authority was assigned to a team of practitioners and researchers once the Client-Researcher Agreement (Davison et al., 2004) was signed in 2003. Throughout the different stages of the project, authority and control shifted among the participants, with more weight being given to industry interests over time. However, the second author served as coordinator to a greater or lesser extent until the MSI's modularized platform architecture was completed by the fall of 2012 (see Table 6 for its main components).
Data were generated throughout the twelve years of the MSI platform initiative. The data included formal interviews, participation in planning meetings and workshops, and documents ranging from e-mails through strategy and technical documents to press releases. Additionally, interviews with MSI members who had played key roles in the initiative were conducted in 2016 to gain an appreciation of the platform initiative's longer-term implications (see Table 7 for a summary of data sources).

Data analysis
We followed an abductive approach to data analysis and theory building (Locke et al., 2008), which involved (1) applying an established theory, (2) observing a surprise in the empirical phenomenon in light of the theory, and (3) articulating a new theory that resolves the surprise (Alvesson and Karreman, 2007). We fulfilled these steps iteratively by moving back and forth between data and theory. Next, we describe how the concepts, categories, and their relationships that we report here, surfaced.
Our analysis commenced by reading and re-reading the empirical material and arranging the events into increasingly coherent narratives. This temporal organizing (see Fig. 1) highlighted that the MSI project exhibited three distinct phases of development, each of which resulted in a distinct platform organization (i.e., architecture-governance configuration). Drawing on the architectural features of each platform, we labelled the phases Open Service Gateway initiative (OSGi), Web Services (WS), and Business Process Modules (BPM) respectively.
These distinct evolutionary phases afforded constant comparison.
During this grounded sensemaking, the co-authors' conceptual understanding of platforms played an integral role in categorization. We, the co-authors, toggled between reviewing the platform literature to generate ideas of what concepts and theories might help explain the MSI initiative's evolution, and the re-reading of the data through the prism of the newly identified concepts. Leveraging concepts that emerged as being fundamental to platforms as organizational forms, we coded the data in Atlasti 7 into categories that clustered into three overarching constructs: technology architecture, governance mechanisms, and complementor engagement. Interviews, meetings, workshops, email conversations, project reports, grant applications, and developer notes were all categorized according to such codes as synergistic specificity, interface conformability, data security, intellectual property rights, decision rights, control points, platform ownership, and competition/ cooperation. To assess complementors' engagement, we coded behavior such attending meetings and workshops, engaging in technology development, and marketing the initiative. In total, we coded the data into 11 categories. In addition, we explored the inter-complementor relationships to understand how cooperative and competitive complementors were in each of the three phases.
Based on a gap we perceived in the platform literature, namely understating the interaction of technology architecture and governance mechanisms over time, we explored process theories that focused on how the technical and social aspects of organizations mutually shape each other. We settled on the theory of imbrication (Leonardi, 2011) as it lent considerable support for analyzing longitudinal data. Our goal was to understand the reciprocal configuring of architecture and governance into somewhat stable organizational forms, and their implications for complementor engagement. After much back-and-forth between the imbrication model and the data, a stable picture of the MSI platform's evolution as shifts in its architecture-governance configurations emerged (Fig. 2).

Empirical findings
Applying the imbrication perspective to each of the three phases of the MSI shared platform initiative, we now present our findings in three imbricational pairs (see Fig. 2). For each, we identify how the material (architecture) and human (governance mechanisms) agencies reciprocally shaped the platform's organizational form and with what implications for complementor engagement. High/low synergistic specificity Synergistic specificity refers to the degree of coupling between the platform core and its complements (i.e., periphery). Extension modules that are highly specific to core modules, exhibit high synergistic specificity. For these extension modules to function, complementor developers and core developers need to exchange more information about the specifications of the systems on both sides. This endangers information hiding on both sides. Sanchez and Mahony (1996), Schilling (2000) Low/high interface conformability This conformability of the core's interface is achieved if it is: • Clearly specified i.e., functions and parameters have self-explanatory, consistent names. • Unambiguous i.e., related concepts are named unambiguously. It should be easy to associate the names with the right concepts without looking them up in the documentation.
• Well-documented i.e., datatypes specs, function specs, and an introduction document that binds the whole into a logical entity exists.
• Stable i.e., the object model is adaptable to future changes. • Standardized i.e., allows different technologies to work together, regardless of language and design If more than two of the 5 criteria are not satisfied, the interface has low conformability. A higher interface conformability implies complementors can integrate their system to the platform without the need for off-platform communication. Sanchez and Mahony (1996) Back in the early 2000s, Swedish road haulage firms, most of whom were small to medium-sized players that specialized in the material they hauled (e.g., lumber, liquids), were faced with two key hurdles when digitalizing their business processes: their lack of technological expertise and a fragmented IT infrastructure comprised of best-in-class embedded, mobile, and stationary systems that had been implemented as isolated solutions over the years. Something as simple as calculating the cost of a delivery had to be done manually by downloading, matching, and manipulating data from these disparate systems. Road haulers had therefore begun investing in custom-built system interfaces, which were maintained by the vendor they had tasked with developing integration solutions. These interfaces were fragile and unstable; changes in one vendor's systems could disrupt the data flow.
Overall, many small road haulers felt they were at the mercy of powerful actors like truck manufacturers who frequently made changes to their embedded systems, thus forcing changes in the haulers' IT infrastructures: "The truck manufacturers keep trying to create new needs and convince us to invest in their proprietary stuff. They equip the truck with lots of new things and then they expect us to use it. I've no idea what we can expect to get from it. I'm sure we'll soon reach a point of no return where we're no longer interested in buying their increasingly digitalized trucks." (transport business manager in one of the road haulage firms) The animosity haulers felt towards the truck manufacturers contributed to the haulers' fragmented IT infrastructures in that they sought out niche IT vendors who were willing to accommodate their unique needs: "The technology vendors can be categorized into two groups. The big players are the truck manufacturers… they've dominated so far. Then we have small niche firms that utilize emerging technologies to develop novel solutions. Road haulers are suspicious of the truck manufacturers due to their brand-specific thinking so they find the smaller vendors to be a bit more flexible… these vendors do what it takes to convince the haulers to implement their specific products." (manager director of Vehco) Table 3 Mechanisms for ecosystem governance.

Governance mechanism Components Quotes
Granting authority Developing resource safeguards (e.g., IP agreements, patents) " Managers should protect against two types of IP-related claims on platform value. In the first, a party asserts patent infringement …A second type of IP-based claim can occur when shared platforms rely on many different patented technologies." Eisenman (2008, p. 47) Allocating decision rights "Decision rights partitioning refers to how decision making authority is divvied between the platform owner and module developers. Decision rights simply refer to who has the authority and responsibility for making specific decisions." Tiwana et al. (2010, p. 679) Allocating control points " To prevent control becoming episodic and fleeting, organizations will need to install control points into a nascent system and to strategically navigate the process of discovering value creation to ensure eventual value capture." Dattée et al. (2018, p. 490) Ensuring compliance Aligning the incentives between the platform's buy-and sell-sides "governance policies that are considered to be advantageous for the platform owner may impose mutual adaptation challenges for other ecosystem participants. For example, despite the benefits of platform updates, the process of releasing updates too frequently may inevitably disrupt the smooth interactions across sides. " Song et al. (2018, p. 137) Aligning complementor incentives "In these conditions of large-scale collective creativity, it is important to establish incentives for members to invest in complementary innovations-that is, to work together in assembling different capabilities and expertise to create effective and holistic solutions for clients." Wareham et al. (2014, p. 4) Openly communicating governance costs "The effort borne by the partners arising from planning, adapting, and safe guarding the resources contributed to the partnership" Huber et al. (2017, p. 567) Monitoring output "the focus of control levers is not limited to output quality but should also address issues of overall complement quantity, the distribution of complementor efforts across heterogeneous market niches, the frequency of complement releases, and other managerial decisions that directly or indirectly influence the quality, character, distribution, and availability of complement supply." Wareham et al. (2014, p. 4)  Into this fractious market stepped Vehco, a university-sponsored start-up in embedded IT, which positioned itself as a service provider capable of helping road haulers to improve their competitiveness and to develop environmentally sustainable business practices. Having just completed a study of haulers' IT requirements and the competitive landscape of the IT vendors serving the industry, Vehco had developed a prototype (EcoHauler) that instantiated an industry platform for integrating embedding, mobile, and stationary systems.
EcoHauler generated not only reports that calculated per-delivery costs, but also provided a calculation of emissions per delivery. To get embedded data from the truck, telematics service providers like Vehco had two options: rely on the Fleet Management System (FMS) standard to access the parameters that the truck manufacturers made available or derive data by reverse engineering the truck's CAN-bus. Like other telematics firms (e.g., Transics), Vehco opted for the latter because the data provided through the FMS standard was very limited and not sufficiently up-to-date, which ultimately constrained the ability of third-parties to innovate: "We looked into FMS very early [when it was released] in all brands: Iveco, Mercedes, Scania, and Volvo. But we got concerned about the errors it had especially in displaying fuel consumption… [Now] we have collaboration with Drivec… [a company that] takes the data directly from the CAN-BUS." (manager director of Transics) The truck manufacturers voiced their opposition to this apparent hack, claiming that it compromised the integrity -and thus the safetyof their vehicles: "What [Vehco] did was actually bad installations… they were piggybacking on the CAN. It made the CAN network function improperly and in some cases this even caused accidents. We didn't see this as a major problem, but still you don't want someone else to play with the nerves in your heart." (Global Telematics Manager, Volvo Trucks) Even though Volvo Trucks regarded the EcoHauler prototype as a warranty infringement, it did not pursue legal action. Given Vehco's start-up status and its commitment to helping the small road haulers in Sweden increase their efficiency and environmental sustainability, a law suit would have generated negative publicity for the truck manufacturer. Still, the hostility between the telematics providers and the truck manufacturers was palpable, especially as truck manufacturers were developing their own telematics offerings.
In May 2002, Vehco and Viktoria Institute's Telematics Group jointly instigated the MSI platform initiative. Recognizing that they needed participation from key players in the road haulage industry, its project leaders decided to present the EcoHauler prototype to industry players in an effort to make the initiative's objectives more tangible and, by eliciting haulers' viewpoints, to align the incentives between the platform's buy-and sellsides. The two seminars (held in fall 2002) generated considerable interest among the members of the Swedish Road Haulage Association (SRHA). In addition, many of the IT vendors signed up to collaborate on the platform development, partly to ensure the compatibility of their own solutions with the evolving platform, and partly to remain apprised of -and possibly to affect -shifts in the competitive landscape. By summer 2003, about a dozen industry players were members of the MSI initiative. Besides Viktoria Institute, Vehco, Gatespace, and a number of road haulers, the founding members of the shared platform initiative were software vendors Hogia, Prolog, Transics, and NL Partner as well as the truck manufacturers Scania and Volvo Trucks.
At the time, Gatespace, a telematics solutions vendor, was promoting OSGi (Open Service Gateway initiative) as an open platform architecture that afforded integration of road haulers' systems. It was also collaborating with Volvo Trucks to develop a solution that used CAN bus data to analyze driver work time. For these reasons, Gatespace was keen to participate in the MSI project. The OSGi architecture allowed software vendors to deploy a large array of wide-area-network services by providing a framework to integrate disparate embedded, mobile, and stationary systems. This made it a viable option to respond to the haulers' integration needs. Indeed, given that OSGi had already been used to develop some open platform initiatives in the telematics domain, and specifically in Volvo Trucks, the MSI project leaders decided to adopt this architecture for the platform development.  Table 6 MSI platform components.

Component Description
Communication architecture There was no central messaging function (i.e., central server or address directory) so each IT system implementing the standard carried its own namespace with unique addresses within the local domain. Combined with the domain name, these addresses were globally unique.

XML-based interface
The XML root element was 'message', which included the actual information content of the MSI message as well as meta information necessary for message addressing and routing. Overall, the XML schema specified a limited domain terminology for communicating road haulage data between embedded, mobile, and stationary IT systems (system-to-system communication). It was structured around formally agreed core objects that were fixed in terms of content and relationships. In addition, the interface prescribed the document schemas and the conditional choreography of document exchanges for road haulage processes comprising multiple parties.

Context schema
This feature afforded IT vendors and road haulers alike the flexibility to adapt a subset of essential global parameters to their local and particular integration requirements.

Business process modules
The order management module dealt with order fulfillment, i.e., scheduling deliveries so that they occurred within the customer-specified time frame and calculating the delivery costs of an order. The purpose of the resource management module was to store information about the hauler's heterogeneous array of resources that needed to be tracked and accounted for during an order's fulfillment, e.g., staff, trucks, gasoline. Use cases for the route optimization module included sequencing deliveries so that transportation costs were minimized, taking into consideration the delivery window specified by the customer as well as traffic information. An extension of route optimization was the reroute module, which afforded the dynamic, just-in-time recalculation of the optimal route as transport conditions changed, e.g., a road accident or mechanical problems. OSGi's framework ran on top of a Java virtual machine and it offered a shared execution environment that installed, updated, and uninstalled applications (aka "bundles"). For software vendors to share information with each other, they needed such bundles to send/receive the data to/from a messaging service. The OSGi server provided an interface for each such services, i.e., a piece of code that offered a template of variables and functions that the service was supposed to have. It also registered the service that a bundle had requested.
The OSGi architecture accomplished data integration as follows: (1) Vendors implemented the data exchange protocol between their internal system and the OSGi bundle; (2) They loaded and installed the JAR (Java Archive) file that included the OSGi bundles; (3) OSGi bundle in the sender system read the data it needed out of the vendor's system by means of a global data structure; and (4) sent the data to the OSGi server requesting a service to send the data; (5) The OSGi server registered the service to send the data; (6) the service sent the data to the requestor, and (7) the OSGi bundle sent the data to the requestor's system via a global data structure. Each vendor implemented sending mechanisms where they were needed based on the function of their systems (for example, an order handling system sent data about an order when this order was changed). The information received was configured at the hauler according to the integration rules.
The OSGi architecture was characterized by high synergistic specificity between the platform core (i.e., OSGi server) and the extensions (i.e., IT vendors' systems). This meant that the IT vendors had to adapt their systems to meet the specific requirements of the OSGi bundles, which limited their systems' reusability in other integration efforts. The need for a JAR file on every complementor's own infrastructure also raised security concerns, simply because the OSGi server would be able to remotely access and update this client-side file. Vendors were worried that the OSGi architecture would compromise the integrity of their infrastructures.
Client-side OSGi bundles were also specific to a given IT complementor's infrastructure. With the data and functions in these bundles not being standardized and with guidance on how to implement the client-side bundles being limited, interface conformability was low. OSGi proved a poor fit for a shared platform given its high core-extension synergistic specificity and low interface conformability. In this situation, seeking to present the road haulers with a consistent and robust user experience, Vehco (owner of EcoHauler) was tapped to centrally operate and maintain the MSI platform. In other words, Vehco was allocated the key control points of the platform's core.
However, contemplating the implementation of the OSGi-based architecture, MSI members became increasingly uneasy by this platform configuration as it gave Vehco significant control. Specifically, Vehco would mediate the customer-supplier relationships of all IT vendors whose systems were being connected, ultimately threatening their market position in two ways. First, as the platform operator, Vehco had the hauler's ear and was likely to become the representative of all vendors. As a result of its centrality, Vehco would also be able to exert control over the other vendors, potentially imposing its architectural decisions onto them. The platform thus took on a vertical form (see Fig. 3) with Vehco disintermediating between the platform complementors to their customers.
Second, OSGi's complex approach to data access management and the security risk that it presented for the IT vendors that sought to use the MSI platform, rendered this architecture unacceptable for competing complementors: "You need so much control of the OSGi architectural solution.
Standardizing things in ways that everybody can understand is doable for sure, but implementing OSGi across all these suppliers of technology you know would be like mission impossible… the data access aspect is so complex to manage." (Managing Director of Vehco) The vertical platform organizations was abandoned due to the IT vendors' low commitment to pursuing the implementation of an OSGibased architecture that was mediated by a single, all-powerful operator (challenging the power balance among complementors). However, the network of customers and complementors did not disband; the collaborative efforts thus far had established the haulers' problems as real and as worthy of a solution.

Imbrication #3: human → material
To kick off the platform development effect anew, the members hired a consultant to identify architectural alternatives. The truck manufacturers emphasized that they preferred an architecture with a standardized interface that could serve as a layer over their own embedded components with read-only access to a limited set of CAN bus parameters (provided by the FMS standard). Their high status in the shared platform initiative meant that these demands effectively reduced the project scope to merely integrating mobile and stationary systems. Examining custom integration projects that MSI members had already implemented, the newly-engaged consultant identified the architecture of the Pharos Mobile standard as the most promising candidate for the shared platform. It was an interface that had been developed for contractor haulers specializing in package delivery. However, these players were larger than the road haulers and they executed routine and pre-defined transport assignments with little variation in information needs.
The Pharos Mobile architecture relied on XML messaging to integrate data across technologies and several MSI members were already familiar with it. Its developer, e-Com Logistics, was therefore invited to run a workshop for MSI members. While the members recognized the merits of a messaging-based architecture, they nevertheless noted that the Pharos Mobile message schemas (their content and structure) were likely to require significant modifications: "Developed by e-Com Logistics, the Pharos Mobile is a standard specifically intended for transports carried out by contractors of haulers. For us, the problem is that it's too large, too detailed, but yet too small… its focus simply is on cargo/package transports." (excerpt from workshop report) In the summer of 2004, the MSI members concluded that it would be easier to develop an architecture from scratch than to adapt Pharos Mobile. However, they were committed to adopting XML (eXtensible Markup Language) for their interface protocol and web services (WS) as the architecture for the platform core. Most of them had experience with WS and they were either already using XML as the data exchange format or were trying to comply with it. Hogia (a vendor of stationary technology) had considerable experience with WS-based mobile-stationary interoperability solutions and offered its XML message schema to the MSI project. Hogia's proprietary XML structure soon became the starting point for the shared platform's interface.

Imbrication #4: material → human
Communicating by means of the WS architecture was accomplished as follows (see Fig. 4): (1) Both sender and receiver implemented the code to communicate with the web service and to pack/unpack the XML file.
(2) The sender prepared the XML file that contained the required data as specified by the MSI interface standard. (3) The sender sent the XML file to the MSI webserver. (4) After assessing that the XML file conformed to the MSI interface standards, the MSI web service sent an acknowledgement to the sender. (5) The MSI web service then sent the data to the requestor. (6a) Upon receipt of the XML file, the requestor sent an acknowledgement to the web service, and (6b) unpacked the XML file, extracting the data and transforming it into the recipient's own data structure.  This architectural design did not require complementors to install and load any third-party modules on their infrastructure to connect to the MSI platform. They simply had to incorporate the send and receive tags into their system's communication module to control what data was transmitted in and out. This effectively decreased synergistic specificity (loose core-extension coupling), allowing complementors to choose to which data requests to respond and with what data. Also, rather than sharing a data structure with a foreign module at runtime, vendors simply mapped their internal data structures to the XML schema, which eliminated the domino effect of changes.
The standardized XML message format paved the way for a highly standardized interface. The complementors' prior experience with WS also reduced the ambiguity surrounding the interface because they understood how it was used and how it affected their data. However, given that the XML standard contained numerous, vendor-specific variants of parameters that were almost identical to each other, its interface conformability was low. The flexibility of the XML context schema and the ethos of equal opportunity that the governance mechanism of preventing complementor dominance had produced, encouraged the accommodation of numerous software vendors' specific needs, thus bloating and complexifying the interface.
Due to the modularity of the architecture, which demanded fewer resources from IT vendors to implement, as well as the expectation that every complementor could now act as an integrator on the platform's community-managed core (Fig. 4), the MSI initiative attracted many new members. These included Consafe Logistics (a stationary provider) and three mobile providers Barkfors, Cybercom, and Pocketmobile.
However, after the MSI members had been working with the MSI XML data structures for about a year, the platform initiative came to an abrupt and unanticipated halt in September 2005. Hogia, whose XML standard had served as the baseline for the MSI's new platform architecture, announced that wanted to shut down and sue the initiative due to infringement of its intellectual property rights. In an email sent to the Viktoria institute, the researchers were accused of misrepresenting the scope of the platform initiative: "When we were asked to share our experiences of standardization… we assumed Viktoria was a research institute and therefore voluntarily shared our material with the group. To my knowledge, however, it wasn't part of the agreed plan that Viktoria would then present a standard that competed with us and other providers. … Hogia would never give away something that someone else could further developed into an alternative to our own product." IBS, a vendor of enterprise resource planning systems, offered the following interpretation of Hogia's reaction: "Hogia still argues like… 'we have our own integration solutions and our own standard, so why would we take part in this effort?' It's simply their business model and making specific solutions for each and every customer firm is profitable for them. But then you think what a standard actually means… it's a solution that many use. IBS has already done several integration solutions that build on MSI." (sales manager at IBS) Other MSI members reacted similarly to IBS in response to Hogia's sudden pivot of commitment to the MSI platform, noting that the vision of a unified platform would make all complementors better off: "[The MSI platform] offers its members a competitive advantage because it serves as a mechanism that neutralizes competition from non-member firms. The more players are involved, the better it works." (Marketing Director of Pocketmobile, mobile computing vendor) Signing a letter that contested Hogia's claims, the remaining MSI members united in opposition to its attempts to destroy the platform initiative. They were more willing than ever to commit resources to the development of a shared platform. Faced with the collective resistance from the MSI members, Hogia eventually withdrew its impending legal action. The MSI group's governance strategy of preventing complementor dominance by not granting a single player authority over the control points that made up the architectural core created the conditions for conflict between the MSI collective and an individual player (e.g., Hogia), but also buoyed complementor engagement. It generated a horizontal platform organization (Fig. 4) that afforded complementors equal opportunities for value capture.
Following the aftermath of the Hogia incident, the shared platform initiative was transformed into a commercial industry consortium, called the Mobile Stationary Interface Group (MSIG), in fall 2007. It was financed through member fees and it developed a formal  F. Saadatmand, et al. Research Policy 48 (2019) 103770 organizational structure with a board of directors, a strategy team, and a technical committee. This reorganization was accompanied by safeguarding the group and its resources against claims related to intellectual property infringement, which entailed formalizing the entity's legal status in a way that protected individual MSI member firms from future legal action.

Imbrication #5: human → material
The establishment of the MSIG generated considerable attention in the trade press and with a new-found energy, group members promoted the initiative heavily at a series of national road transport events. Increasingly they acknowledged that the emerging platform helped them reduce the time and effort needed to connect different vendors' IT systems. A more synchronized architectural understanding among vendors meant that even custom integration projects that did not use the MSI platform benefited from their increased knowledge about one another's technologies. Hogia soon realized that the dynamics in this industry vertical were changing significantly and it decided to return to the shared platform initiative in orderhi son be left behind.
In addition to the technology providers, there were also major road haulage firms that recognized the benefits of the MSI platform: "The MSI standard is an absolute necessity for us to cope with future market requirements. It allows us to spend more time on increasing our market penetration, which will result in improved profitability for ourselves and our customers. It can also help to neutralize (unwanted) competition in the marketplace by lowering switching costs and thereby making technology components easier to replace." (IT director at Samfrakt, a large road haulage firm) In early 2010, persuaded by the MSI platform's favorable publicity, one of the largest road haulers in Sweden, LBC Frakt Värmland, issued a request for proposals to integrate its various systems using the MSI platform. Given the size of the project, several MSI members bid on this assignment, but their proposed solutions relied on proprietary interfaces rather than the new platform. After publicly communicating its disappointment with the proposals, LBC Frakt Värmland eventually selected two vendors on the mobile side and Locus Scandinavia for the stationary part of its architecture and tasked them to capitalize on the MSI platform. Unfortunately, the integration effort proved very challenging largely because of the WS's architecture's relatively low interface conformability. LBC Frakt Värmland concluded that these problems constrained the integration solution too severely to further pursue the MSI architecture. Instead the proprietary interface promoted by one of the integration partners was used as a baseline to develop an integration solution that was nevertheless MSI-compliant.
To address the MSI architecture's perceived lack of usability, MSIG decided to divide the MSI interface into modules that dealt with specific business processes. The interface was decomposed into four modules: the order management module dealt with scheduling deliveries so that they occurred within the customer-specified time frame and with calculating the delivery costs of an order; the resource management module's purpose was to store information about the hauler's heterogeneous array of resources that needed to be tracked and accounted for during an order's fulfillment; the route optimization module instantiated use cases like sequencing deliveries so that transportation costs could be minimized, taking the delivery window specified by the customer as well as traffic information into consideration; and the reroute module extended the route optimization module by affording the dynamic, justin-time recalculation of the optimal route as transport conditions changed. Decision rights over each module would be granted to complementors with expertise in the given module's intended functionality.

Imbrication #6: material → human
Applying the logic of maximum reusability, MSIG divided the MSI interface along horizontal and vertical lines (Fig. 5): (1) header tags specifying the message (e.g., type, sender, receiver), were moved into a 'general' module, which all messages had to inherit to work on the MSI core, and (2) XML tags specifying the parameters related to one of the four business processes formed the 'child' modules.
The BPM interface was both more streamlined and broader in its functionality than the WS-based architecture on which it was built. Given the interface conformability issues of the latter, the re-design of the XML message templates harmonized the interface, thus standardizing the format and meaning of each variable. The simplification of the interface, coupled with improved documentation, significantly increased its conformability. Additionally, by limiting the design focus to a specific business process, the parameter set expanded to support a deeper and more meaningful representation of a business process. Many of these new XML tags were anticipatory; demand for them had not yet been expressed but was expected to emerge in future. The IT vendors competing for the integration work in any one of the four business process verticals were therefore afforded the opportunity to develop new use cases around these new parameters. Notably, by creating a loosely coupled architecture, increased modularization supported generativity.
Enabled by the openness of the more process-oriented BPM architecture, the increased indirect network effects motivated new entrants with high quality offerings supportive of a specific business process to join the platform ecosystem. MSIG received them with open arms as these new members would contribute the necessary knowledge to  further develop the modules. However, their entry also meant greater competition for incumbent MSI members in a given process vertical (Fig. 5). One such new entrants was DPS whose route optimization software had been recognized as having one of the best route optimization algorithms in Europe. Indeed, the MSI platform with its modular architecture and the flexible integration it afforded, provided the conditions for DPS to consider entering the Swedish road haulage market for the first time: "To be honest, I think everybody in road transport should have tried to grab what we're doing like fifteen years ago… But they haven't so that's why MSI appears so interesting to us. Given the language it offers and its focus on flexible technology integration, we eventually get the leverage our product deserves. We need this standard to reduce the barriers and materialize the plug and play vision… then we're all set and ready to go." (DPS Managing Director) While the order management module had been largely developed by Locus for LBC Frakt and was therefore considered relatively complete, the resource and re-route management modules were dependent on the implementation of the order management and route optimization modules. Although the order management module was deemed to play the most central role in the road haulers' integration requirements, the route optimization module, buoyed by a renewed emphasis on environmental sustainability, became the focus of attention.
Despite DPS's newcomer status in the MSIG ecosystem, they were allocated design decision rights over key control points in the three modules related to route optimization. This afforded the outsider firm significant control and power over the development of the shared platform. This governance mechanism of granting one actor authority over a significant portion of control points in the route optimization vertical had the support of all MSIG members who believed that the MSI platform would benefit from DPS's expertise. DPS embraced this leadership position, believing that the quality of its offerings would maintain its competitiveness: "We actually welcome openly sharing our expertise. It's likely it would lead to potentially more business negotiations for us and I expect us to win them all in the end. We've learned it takes a lot of time and resources to develop an effective optimization engine, so I guess others understand they're well behind us… We're therefore not afraid competition would intensify in that way." (DPS Managing Director) However, the completion of the route optimization modules ran afoul of the truck manufacturers' fundamental unwillingness to make sensor data available beyond the requirements of the FMS standard. As owners of the embedded data, they were in a position to limit the scope of the MSI route optimization module, ultimately restricting the value creation potential of IT vendors who leveraged the integration potential of the shared platform. At this time, Volvo trucks was developing its own route optimization module in-house. Once again refusing to cooperate fully, Volvo Trucks and Scania decided to exit the MSIG. In 2011, they instead partnered with DHL to develop a shared platform with similar goals to MSI.
The four business process modules were handed over to MSIG in late 2012. However, complementor engagement had continued to decline after the truck manufacturer's departure. With the truck manufacturers' repeated refusal to make available embedded sensor data, the IT vendors had become increasingly doubtful of the prospects of developing innovative solutions for road haulers. They therefore made no effort to push the diffusion of the modules for their integration projects. Returning to the pre-MSI practice of building custom and proprietary interfaces, however, their improved knowledge of other vendors' systems made it more feasible to implement their own integration solutions at competitive rates. Moreover, many IT vendors were increasingly aware that the MSI platform was not readily reusable in other settings, making it difficult for them to recoup their investment in the shared platform, especially in light of the small size of the Swedish road hauler market. Given these overwhelming odds, the MSIG's board of directors decided to terminate the platform initiative in spring 2013.

Discussion
The objective of our study is to explore the following research question: How does the interplay between technological architecture and governance mechanisms generate platform organizations capable of producing different levels of complementor engagement? To answer this question, we relied on insights from the platform literature, particularly about architecture (Baldwin and Woodard, 2009;Tiwana et al., 2010) and governance (Huber et al., 2017;Wareham et al., 2014), and imbrication as a process theory (Leonardi, 2011) to theorize a longitudinal case study of the development of an industry-wide shared platform (Eisenmann, 2008;Markus and Bui, 2012) in the Swedish road haulage industry. Given that we sought an understanding of the reciprocal shaping of technology architecture and governance mechanisms in configuring platform organizations and these configurations' implications for complementor engagement (Dattée et al., 2018;Gawer, 2014;Jacobides et al., 2018), the collaborative MSI platform development proved invaluable in that data about its evolution was available for our process analysis.
Through the imbrication analysis we scrutinized the emergence of architecture-governance configurations, which yielded three distinct types of platform organizations: vertical, horizontal, and modular. A vertical platform is an organizational form that builds on a technology architecture that exhibits high core-extension coupling and allocates decision rights over key control points to a single ecosystem complementor. This complementor, who is awarded this powerful position based on high status (e.g., experience with an innovative solution), then mediates the relationship between the two sides of the ecosystem, i.e., customers and complementors.
By building on a technology architecture with low core-extension coupling, a horizontal platform is an organizational form that distributes decision rights among ecosystem complementors and therefore gives them relatively equal opportunities for value capture. In contrast to vertical and horizontal platforms, a modular platform is a hybrid organizational form comprised of possible parallel architecture-governance configurations, each of which can embrace a different form. In the MSI case, one module reflected the vertical platform organization, whereas another module took on the form of the horizontal organization during the platform's modular configuration.
Consistent with assumptions in the platform literature (Gawer, 2014;Jacobides et al., 2018), our analysis reveals that each of these architecture-governance configurations produces different degrees of complementor engagement. For example, while relatively low complementor engagement was produced by the vertical platform organization, complementor engagement was relatively high in the horizontal configuration. As part of the modular platform organization, the development of a set of route optimization modules by a company with requisite expertise evolved into a vertical architecture-governance configuration that rendered a relatively low degree of complementor engagement. Even though the prior development of the order management module with its more established functionality reflected a horizontal configuration that produced relatively high levels of complementor engagement, the momentum of the shared platform as a whole was eroded because of the low engagement of complementors that surrounded the route optimization modules.
This finding points to the importance of maintaining consistency of architecture and governance across a platform where one complementor might draw on multiple modules (Wareham et al., 2014). By conceptualizing our findings and noting other patterns that emerged through our imbricational analysis, we now summarize our findings in four propositions to stimulate future research on platform organizations and complementor engagement.

Proposition 1. A vertical platform organization produces low complementor engagement
This proposition captures not only the relationship between the organizational form we label vertical platform and complementor engagement, but also the relationship between the platform architecture and the governance mechanism of allocating key control points to a single complementor (Dattée et al., 2018;de Reuver et al., 2018). By granting decision authority in a shared platform to a single actor, this complementor's position is elevated vis-à-vis the other service providers on the platform (Pagani, 2013;Wareham et al., 2014). Given that this elevated complementor is nevertheless a competitor, this renders uncertain other complementors' ability to distinguish themselves on the platform and to capture value. This uncertainty, in turn, limits the resource commitments that complementors make to the collective endeavor of developing a shared platform.
Our analysis also shows that this governance mechanism is tied up with the platform architecture. In the MSI case, the high core-extension specificity of the OSGi architecture found expression in a client-side JAR files that could be updated remotely by the OSGi server when changes in the platform's core needed to be accommodated. This presented a significant security vulnerability for complementors. Furthermore, the OSGi architecture exhibited low interface conformability as it relied on global data structures that were specifically tailored to each IT vendor's system. In addition to being non-standard, the interface was also poorly documented.
To make such an architecture of high synergistic specificity and low interface conformability work in a platform that brings together diverse complementors, the architecture's control point, i.e., its source of value and/or power, must be allocated to a trusted party (Dattée et al., 2018;Pagani, 2013). Trust in the platform provider who has the capacity to make changes remotely to a complementor's infrastructure, is a key condition for the platform organization's viability. Thus, the material agency of the OSGi architecture necessitated the governance mechanism of allocating the control point (namely the ongoing operation of the core) to a trusted party.
In the case of MSI, Vehco, the company whose EcoHauler prototype had initiated the formation of the platform by bringing key players in the industry together, was granted authority over the core. Its elevated status was based on its experience with a solution -however limitedwhich proved that a platform was a viable solution for integrating the transport firms' three islands of technology. However, Vehco's effective ownership of the core meant that customers' (i.e., road haulers) were likely to perceive Vehco as their integration provider, as Vehco would mediate other complementors' client relationships. The competitive threat this vertical architecture-governance configuration posed, meant that complementor engagement was challenged.
This relationship between a vertical configuration and complementor engagement appears to be highly relevant to blockchain platforms (Beck et al., 2018), which represent a new type of shared platform, whose architecture is considerably different from the way in which shared platforms have traditionally been implemented. Nevertheless, blockchain-based platforms are likely to be governed in highly centralized ways, especially when they are first developed. The complementor with all the decision rights emerges as a "benevolent dictator" in blockchain platforms (Beck et al., 2018). In the face of a platform monopoly developing (Eisenmann, 2008), complementors' willingness to commit resources to the platform is likely to diminish.
An example of this situation is the Maersk blockchain project, TradeLens (Lal and Johnson, 2018). Intended to tie all the participants in global supply chains together (i.e., suppliers, 3 rd party logistics providers, inspectors, customs, etc.), this joint venture between Maersk and IBM has struggled to secure the degree of industry-wide adoption needed to deliver the anticipated efficiency and value (Lal and Scott, 2018). In particular, with Maersk being a complementor on this platform, its competitors have been hesitant to join TradeLens because they are worried that Maersk, as a majority stakeholder in the platform's joint venture, will have access to their confidential trade data. Particiation would thus risk strengthening Maersk's competitive position. Furthermore, given that this blockchain platform is subject to winner take all dynamics (Eisenmann, 2008), complementors might be better off by participating in the construction of a shared platform, in which the incentives of the platform and the complementors are aligned.

Proposition 2. A horizontal platform organization produces high complementor engagement
The key difference between a vertical and a horizontal platform configuration lies in the ownership of the architectural control points. While in the vertical platform one complementor emerges as the dominant player, a horizontal platform organization relies on governance mechanisms that allocate control points more or less evenly across the complementors. By creating a more egalitarian decision-making environment, complementors' interests are more aligned with those of the platform as a whole, creating the economic incentives to commit resources to complete the platform's value proposition (Adner, 2017;Jacobides et al., 2018).
It is however important to note that complementor engagement is afforded by an architecture that exhibits low synergistic specificity. With core-extension coupling being low, investments that complementors make in developing a unique service offering on one platform, should be readily reusable on another. In the case of the MSI project, the WS architecture enabled complementors to develop their extensions relatively independently, thus supporting generativity, which in turn promised greater cross-side network effects and overall platform success.
However, a likely consequence of a more egalitarian development environment is an interface low in conformability despite an architecture (i.e., web services) that makes an unambiguous, clearly specified, well-documented and standardized interface possible (i.e., XML). In the MSI case, we saw that developing a highly conformable interface was challenged by the fact that there was no platform owner to enforce an architectural direction. Rather than dealing with the conflict that accompanies the harmonization of parameters that constitute the haulage industry's XML schema and the prioritizations that this demanded, an inclusive approach that accommodates the integration needs of all complementors materialized. As a result, the interface became bloated with considerable redundancies that created ambiguities, increased the burden of documentation, and raised the cost of implementing MSI-based integration solutions.
This proposition highlights the intertwining of the material and social dimension of the platform organization. An architecture with low core-extension specificity means that barriers to entry are dissolved and more software vendors are likely to seek access to the platform ecosystem (Boudreau, 2012;Jacobides et al., 2018). With increased complementor participation and engagement, the resulting competitive pressures lead complementors to seek differentiation (Ceccagnoli et al., 2012;Cennamo et al., 2018). This, in turn, generates greater diversity in the interface parameters, thereby reducing interface conformability. However, since the interface conformability is the result of accommodating incumbent complementors' specific system needs (thus reducing their implementation costs) complementor engagement among incumbents increases. However, low interface conformability reduces the likelihood that new entrants will commit resources to the platform.
Equal opportunity to capture value from platform transactions, as well as the ability to affect the design of the platform core and interface, is likely to encourage greater complementor engagement in all types of platforms, i.e., proprietary, shared and blockchain. Based on distributed ledger technology and peer-based transaction processing, blockchain platforms are built on the promise of decentralized, horizontal modes of organizing. As Beck et al. (2018) point out, decentralized governance is the goal of blockchain platform owners, who typically fulfill the centralized owner role in the initial phases of the platform's development. Even though typical governance mechanisms such as negotiations and incentives are digitized in blockchain platforms (i.e., smart contracts and tokens), agreeing on the rules that need to be digitized requires intensive collaboration and negotiation among the complementors. The high transaction costs this process entails, however mean that membership in the core team has to be limited. Managing the success and growth of the horizontal platform then generates challenges related to free-riding (Eisenmann, 2008), as new entrants who have not contributed to the effort of developing the platform nevertheless benefit from it. Proposition 3. A modular platform organization produces complementor engagement through parallel architecture-governance configurations A modular architecture is regarded as the most desirable in platform development, as it spurs generativity and broaden the variety of complements produced (e.g., de Reuver et al., 2018;Parker et al., 2017). This is because an architecture with low core-extension synergistic specificity and a highly conformable interface lowers the entry barriers and allows new complementors to generate and capture value in ways that are readily adaptable to change and reusable on other platforms. However, such a platform architecture increases the competition among complementors (Boudreau, 2012;Wareham et al., 2014), thereby increasing negative same-side network effects. Thus, the attractiveness of the platform's architecture sets in motion a competitive mechanism that militates against the very outcome (i.e., complementor engagement) that it is expected to produce. To address this apparent paradox, platform owners might endeavor to build a sensibility for collectivity among the complementors (Boudreau, 2012;Wareham et al., 2014). For example, complementors might be incentivized to create solutions that benefit the platform as a whole, and a sense of collective identity greater vision might be instilled in them.
The MSI Group pursued a strategy of incentives when it allocated the right to make design decisions regarding the XML schema for three of the four business process modules to DPS, a new entrant to the MSI ecosystem. DPS had earned accolades for its route optimization software outside of the Swedish road haulage space. Accorded decision rights over the design of the XML schema for the three modules related to route-optimization, DPS instantly inhabited a dominant position in these modules' development, despite being a newcomer to the platform initiative.
DPS leveraged its decision authority, creating a vertical configuration in the platform's route optimization functionality. While DPS' dominant position was expected to expedite the development of the three new modules (Proposition 3) and to avoid the bloating of the schemas that had occurred in the horizontal platform organization (Proposition 2), engagement waned among the complementors. Initially, it was the truck manufacturers that left due to their unwillingness to provide more embedded parameters to the route optimization modules. The exodus of these high-profile players then made the MSI initiative less attractive to other complementors (Wareham et al., 2014).
It is important to note, that even though a horizontal configuration was apparent in the development of the more established order management module, the declining complementor engagement in the routeoptimization modules shrunk the network of providers so significantly, that network effects were undermined and the MSI platform was decommissioned soon after. Managing a modular configuration thus requires vigilance that each module -or functional sub-set of the platform -generates sufficient complementor engagement. This is because the loss of complements in one functional subset of the platform is likely to undermine the platform's network effects.
One risk of a modular platform configuration is that it might lead to forking, i.e., copying existing code and then extending it in a way that crates a distinct version separate from the original. Frequently associated with blockchain platforms (Beck et al., 2018), forking, represents a strategy for dealing with the increased competitiveness of platforms enacting a modular architecture. The more complementors seek to differentiate themselves within the blochchain platform, the more likely they are to develop proprietary extensions. This implies that the platform is likely to become increasingly fragemented, which undermines the achieving critical mass and network effects in any of the modules or forks.
Proposition 4. Elevating to leadership positions those complementors with prior experience in the functionality a shared platform seeks to develop, expedites the platform's evolution in the short term, but also limits complementor engagement in the long term.
The development of a shared platform necessitates engagement of a diverse set of complementors whose interests may be orthogonal to each other (e.g., Jacobides et al., 2018). This heterogeneity of interests presents formidable challenges for the collaborative endeavor of developing a shared platform. For example, governance costs are likely to increase as a diverse set of complementors try to come to agreement (Eisenmann, 2008).
The MSI case highlights a pragmatic solution to this challenge. By starting the design process with a viable solution, e.g., a working prototype, that can then be collectively adapted, the complementor ecosystem is more likely to development a functional platform core (Dattée et al., 2018). Having something tangible (e.g., code, data structures) to focus the complementors' attention and to align their diverging goals, is particularly helpful in shared platforms that require consensus among members.
However, allocating architectural authority to individual complementors is likely to produce vertical platform configurations, which reduce complementor engagement in the longer term (Proposition 1). This suggests that the success of shared platform design depends on the consortium's ability to switch from a vertical configuration that accelerates technological development in the short term, to a horizontal configuration that promotes complementor engagement, collective identity, generativity and network effects in the long term. How to recognize the optimal point when to pivot from one platform configuration to another might present an opportunity for future research.

Contributions to research and practice
While recent platform research has paid increasing attention to the intertwining of technology architecture and governance mechanisms, this research is largely limited to proprietary platforms and their associated business models (e.g., Cennamo et al., 2018;Kapoor and Agarwal, 2017). This means that the current understanding of how complementor engagement is produced mainly concerns ecosystem orchestration efforts of platform owners once the platform architecturegovernance configuration has been developed. As a result, there remains much to be learned about configuring platform organizations and engaging complementors in value creation and capture (Adner, 2017;Jacobides et al., 2018). This is particularly salient for building blockchain platforms (Beck et al., 2018), which reflect the tenets of shared platforms. In fact, tokenization and smart contracts, which digitize governance mechanism that would otherwise be enacted manually, hold considerable promise for making shared platforms economically viable.
Despite the existence of a handful of studies that explore the development and evolution of shared platforms (e.g., Eisenmann et al., 2011;Jha et al., 2016) where complementor engagement is part of the platform from its inception (Dattée et al., 2018) -meaning that it can be studied over time -none of these studies offers a process perspective on how the technological and social aspects of the platform's configuration reciprocally shape one another and what effect this has on complementor engagement. Indeed, conceptualizing platforms as organizational forms represents a novel perspective on platforms (Gawer, 2014), which directs our attention towards an understanding of the antecedents of complementor engagement in a holistic manner, rather than as a list of individual factors (e.g., Cennamo et al., 2018;Kazan et al., 2018).
Providing insight into how architecture and governance intertwine to form particular configurations that afford greater and lesser degrees of complementor engagement in shared platforms, constitutes our study's primary contribution to platform research. We capture these insights in the first three propositions, which do not only identify three distinct platform organizations (i.e., vertical, horizontal, and modular), but also explain how they emerge through the interplay between social and technical aspects of organizing. Additionally, we discuss the benefits and challenges that each of these organizational forms pose for complementor engagement. For example, while the vertical platform is likely to achieve a temporal alignment among the complementors, and therefore lead to the speedy development of an initial architectural core, it fails to provide the necessary incentives for most complementors to commit resources to co-produce the platform's value.
This nuanced understanding of the interaction between architecture and governance and its implications for complementor engagement provides novel insights to the extant platform literature (Adner, 2017;Dattée et al., 2018;Jacobides et al., 2018). It also raises new research questions including: When should a horizontal architecture-governance configuration, which is useful for the effective development of an innovation initially, be superseded by a vertical organizational form that is more conducive to producing longer-term complementor engagement? What organizational form should a shared platform move to in order to ensure that a core-extension interface with high conformability is assured? How might the architecture-governance configurations of the different functional modules in a modular platform organization be managed so that their inherent diversity does not compromise sameside network effects over time?
These research questions also point to our study's implications for practitioners. A key insight our study offers is that managing complementor engagement is akin to a choreographed dance, where one technical move is followed by a social one to create a continuous evolutionary flow. Platform owners should not only be prepared to preemptively shift from one architecture-governance configuration to another such that the weaknesses of one configuration are addressed by the capabilities of the next (Proposition 4), but also throughout the development process, shift design priorities among the different stakeholder groups constituting the sides of the platform market.
As the interest in blockchain based platforms grows (e.g., Beck et al., 2018), our study provides important insights into what it takes to achieve the aspirational model of a vertical platform configuration. Even though blockchain's distributed ledger infrastructure differs significantly from the technology on which MSI was built, the configurations identified in this paper appear to be materializing in the blockchain space, e.g., the "benevolent dictator" who becomes the defacto platform owner (Beck et al., 2018) reflects the vertical platform configuration. By focusing on the challenges of distributed management throughout a shared platform's evolution and its ongoing operation, we focus on a phenomenon worthy of further scrutiny (de Reuver et al., 2018;Nambisan, 2017).

Limitations
These research contributions need to be qualified by our study's limitations. First, limited to a single shared platform effort based on specific technologies within a particular industry, we examine the collective work of a restricted group of complementors in the Swedish road haulage industry that focused on the development of the MSI platform. Our analysis is thus concerned with the specific issues encountered in this context, as well as the approaches, processes, and tools used to develop a specific platform. Claims of cross-case generalizability to other empirical contexts are thus misplaced.
However, our study does achieve within-case generalizability (Lee and Baskerville, 2003). By developing a process perspective of platforms as architecture-governance configurations, drawing on an extensive exploration of the prior literature on complementor engagement, and reading our data through this theory (and vice versa), we achieve generalization from empirical description to theory. As a result of our reliance on abduction for our data analysis -and its toggling between induction and deduction -our research results promise to be both testable and empirically valid, especially for designers and leaders of platform organizations.
Second, given the longitudinal nature of the 12-year case study we are analyzing, the data's diversity and volume raises legitimate questions about the completeness and accuracy of the record. To address concerns over data quality, we have relied on a number of techniques, including developing detailed timelines, applying different lenses to our data analysis (e.g., the relationships among complementors across the three phases of development). Additionally, based on their proximity to the actual MSI project and the data representing it, the three co-authors took on different roles throughout the data analysis.
The first author who had limited involvement in the MSI project (i.e., she was part of the module development team in the BPM phase) focused on analyzing the data. The second author had the most intimate knowledge of the project due to his involvement as its project manager on and off across the MSI's 12-year existence. He was able to fill in gaps in the data record and provide the contextual background (including actors' emotional states) to help us make meaning of certain events. The third author, who had not been directly involved in the project, focused on asking questions of the data and the two co-authors' interpretations. She continuously challenged the other authors to provide coherent explanations of and evidence for events and their significance. While this approach was laborious and circular, it supported our abductive stance towards theorizing and gave us reasonable assurance of the reliability of our analysis.

Conclusions
As organizational forms that rely on complementors to complete them and to offer a compelling value proposition to their multi-sided customer segments, shared platforms are compelled to develop and maintain complementor engagement. Indeed, developing effective architecture-governance configurations is crucial to this endeavor. Given the recognition by the extant platform literature that there is much more to learn about the implications of the interaction between a platform's technological architecture and its governance mechanisms for engaging complementors, the focus of our paper is to advance a rich understanding of how and why specific architecture-governance configurations emerge in the evolution of a shared platform, and what their respective implications are for complementor engagement.
In this paper, we identify three organizations forms -vertical, horizontal, and modular platforms -each of which generates different degrees of complementor engagement. Interestingly, however, each of these platform organizations poses significant challenges for complementor engagement. For example, even though the architecture-governance configuration that represents the horizontal platform produced the most complementor engagement in our study, the egalitarianism among complementors it enacted also promoted an architectural design characterized by low interface conformability, which manifested itself in a bloated XML schema that included the incumbents' specific integration needs. While this elevated complementor engagement among incumbents in the short term, it was likely to make resource commitments unattractive to new complementors. Thus, long-term complementor engagement would be in jeopardy. In the form of four propositions, our paper captures these and other nuanced insights about the reciprocal shaping of architecture and governance in platform organizations and what its consequences are for engaging a critical mass of complementors. We hope that future research tests and dis/ confirms these in other empirical settings.