Modelling Perceived Risks Associated to the Entry of Complementors’ in Platform Enterprises: A Case Study

Abstract

Third-party innovators, i.e., complementors, in platform enterprises develop and commercialize add-on products which are one of the main attraction points for customers. To ensure a sustainable evolution of the enterprise, the platform owner needs to attract and retain high-quality third-party innovators. We posit that the transaction costs incurred upon joining the enterprise as well as the controls imposed by the platform owner throughout the development and commercialization process shape the innovator’s perceived risk and influence his decision on whether to join or not. Based on a literature review, the paper at hand proposes a conceptual model for complementors to assess their perceived risk and subsequently evaluates the model in a case study of a platform enterprise for IT-based modelling tools. While some of the propositions are validated, i.e., that informational controls decrease the perceived environmental uncertainty and implicitly the perceived risks, other propositions, such as the fact that asset specificity is a deterrent to entering the platform enterprise could not be validated. Further case studies are necessary to provide a conclusive proof of the proposed model.

1. Introduction

1.1. Environment and Context

Twenty years ago, there were as many internet users as the city of Madrid has inhabitants. Nowadays, more than 4 billion people are connected to the internet and their number is expected to increase by 2020 to about 70% of the world’s population. Thus, by the end of the decade, there will be around 6 billion smart devices in consumers’ hands [1]. In addition, new materials and nanotechnology support the increase of digitalization. This is understood here as the separation of functionality from a physical/material carrier and its availability as a digital functionality. A simple example would be a thermometer: while previously one had to use a physical device in order to know the temperature at a specific time in a given place. Currently, the physical object is no longer needed as the functionality is available on the mobile device independent of a location. Thus, digitalization and the transformational process accompanying it will impact also the use of material resources and environmental sustainability in the long term.

This transformational process has already enabled new forms of collaboration and value provision, where arguably the most transformative one has been the transition from the individual enterprise to the platform enterprise. The latter revolves around a software platform and builds an ecosystem around the deployment of products created on top of the platform. Resources are harnessed by opening the platform enterprise boundaries and providing an innovation space for third-parties to create add-on offerings.

In their survey, the authors of [2] identified 176 platform enterprises, whose combined value exceeds 4.3 trillion USD and which directly employ more than 1.3 million people. Would these enterprises be one state, its gross domestic product would reside just below that of Japan and above that of Germany [3,4]. Additionally, it would have realized all value creation by employing only a third of Austria’s workforce [5]. The future points consistently into the direction of platform enterprises: out of the 115 unicorns (unicorn company is a company valued at “valued at over $1 billion by public or private market investors”. The term has been coined by Aileen Lee, founder of Cowboy Ventures [6]) in 2015, 80 were platform enterprises [1]. However, for such an enterprise to achieve sustainable success, beyond technology management and new business models, risk management and control mechanisms need to be created to enable the typical co-opetition between the platform owner and third-party innovators.

1.2. Platform Enterprises

Platform enterprises gather different types of independent actors, who intentionally come together in a common technological process in order to create value, which they exploit for business purposes [7]. One can distinguish four different types of constituents (see Figure 1): (a) the platform owner, (b) the platform provider, (c) the third-party producers, i.e., complementors [8], and (d) the customers.

The platform owner is in control of the intellectual property rights as well as the governance of the platform. The platform provider makes the platform available on the technological level by providing the implementation of the core. Additionally, he mediates interactions between the different parties. Third-party producers are independent enterprises or individuals who extend the platform core by innovating add-on functionality and use the platform to build complementary products, which they then offer through a marketplace to the consumers. These are individuals and organizations that interact with the platform enterprise to consume the value created [9]. For the purposes of our work, the platform owner and platform provider are assumed to be the same entity.

The fundamental differences between platform enterprises and pipeline businesses are a shift: (a) from control and optimization of resource flow in one enterprise to the coordination of resource allocation within a network, (b) from the hierarchical organization and control within the organization to incentivizing cooperation of independent actors within a network, and (c) from the focus on customer value optimization to the multi-focus on optimizing the value of the network employing different control and incentive mechanisms, seen from the perspective of the platform owner [9].

The work at hand, concentrates on how the value of the platform enterprise can be sustainably enhanced by control and incentive mechanisms for third-party innovators.

1.3. State of the Art

While research in the last 15 years has emerged around platform enterprises, the focus on complementors has developed only in the last five years. Existing research regarding platform enterprises (or multi-sided markets) centers on network effects [9], on pricing [10], on platform architecture [11], on platform organization [12], platform governance and regulation [13], platform enterprise evolution [14], platform leadership [15] and platform-based ecosystems [16].

At the same time, research regarding the providers of complementary products, i.e., “the complementors”, is rather scarce and mostly focused on app-developers in the mobile industry. Questions addressed were directed at the retention of developers in a platform ecosystem [17] and their motives to desert such an ecosystem [18]. Research such as [19] discusses specifically complementors taking a more resource-oriented perspective, proposing that third-party innovators will enter platform ecosystems in order to gain access to resources especially in cases where their product is complementary to the platform. [20,21,22] explore the appropriation capabilities of the complementor firm as a potential motivator to collaborate with the platform enterprise. The complementor’s motivation to join the market for enterprise IT-applications ecosystems in order to signal compatibility and trustworthiness with customers is examined in [23]. Existing research, like [24], focuses on costs complementors have to deal with when joining a platform ecosystem using the transaction costs theory. On the other hand, [25,26,27] have researched individual motivations to join open source communities. Yet none of the existing research, at least to our knowledge, has proposed a risk-oriented model for complementors in order to assess their entry strategy to platform enterprises. The paper at hand, proposes a risk assessment model aiming to contribute at closing the existing research gap.

The remainder of this paper presents the research methodology in Section 2. In Section 3 the conceptual model for the complementor’s perceived risk upon entry into platform enterprise is presented. Section 4 presents the results of the case study and Section 5 an outlook on future work.

2. Materials and Methods

The research performed in this work was a combination of literature review and case study. The literature review was used to develop the theoretical framework, while the case study applied the developed model to the domain of modelling tool engineering.

2.1. Literature Review

The literature search was done using the following databases: ABI/INFORM Collection, EconLit, Emerald Insight, JSTOR/Economics, Business and Finance, JSTOR/Marketing and Advertising, ScienceDirect and Scopus.

Search terms were a combination of the following strings: “transaction cost(s)” AND/OR “transaction cost theory” AND/OR “platform control” AND/OR “formal control(s)” AND/OR “performance risk” AND/OR “relational risk” AND/OR “risk management” AND/OR “perceived risk” AND/OR “platform enterprise” AND/OR “platform ecosystem” AND/OR “two-sided market” AND/OR “network effects” AND/OR “complementor” AND/OR “third-party innovation” AND/OR “interconnected firm(s)” AND/OR “strategic alliance(s)” AND/OR “partner ecosystem” AND/OR “collaborative network” AND/OR “business ecosystem” AND/OR “innovation network” AND/OR “cooperative management”.

The search yielded a total of 1.273 results. Based on title, keywords and abstracts 110 papers were deemed to be of potential interest. To ensure completeness additional literature, bibliographies and scientific articles were reviewed. All literature was subjected to the following inclusion/exclusion criteria:

• articles and research were published in English language,
• the material was published in peer-reviewed journals or proceedings,
• literature retrieved was included irrespective of its publication date.

2.2. Case Study Design

Depending on the types of hypotheses formulated specific strategies are the most appropriate for testing. The propositions in this work are either sufficient or necessary conditions. As an experiment, the first best research strategy, was not feasible for testing, we choose the second-best solution [28]. Thus, the empirical research consists of one theory-testing case study, which addresses the research questions defined after the literature review.

Following [29] a formal case study screening procedure was conducted to ensure that from the possible cases the most suitable one was selected. The following criteria applied:

• the availability of key persons from the complementor side willing and able to participate in the interview process.
• the disposition on the complementor side to provide information which was not publicly available especially with regard to the research questions.
• the data available for the study. Three different sources were considered: (a) data coming directly from complementors; (b) data coming from the platform; and (c) third-party data available in relation to the complementor (prior and after joining the platform ecosystem) and the platform enterprise.

As a result of the screening the Open Models Laboratory (OMiLAB) was selected as a platform enterprise to be evaluated. OMiLAB targets modelling method and tool engineering. At its core the ecosystem centers on the commercial proprietary platform ADOxx^®, which facilitates product development by third parties. The technology employed by the platform is that of meta-modelling and the domain addressed is that of modelling tool engineering. The platform is open-use, which means that its core is proprietary but third-parties are able to use it for free. Stand-alone reselling of the platform core is prohibited to third-parties according to the licensing conditions imposed by the platform owner.

The platform enterprise, i.e., the OMiLAB, rests on three pillars:

• The collaborative environment, which encompasses the collaboration models and value sharing between the platform core and the complementors, collaboration activities, physical assets and virtual infrastructure, the governance rules and intellectual property rights.
• The innovation environment, which contains all modelling tool engineering-related matters. It provides conceptual support, documentation and instruments which aid the third-party developer in their work.
• The technological environment contains the platform itself, additional open source tools and functionalities, development services and deployment facilities [30].

Third-parties can join the OMiLAB ecosystem in order to develop and deploy their modelling tool(s). Through dedicated channels they also have the possibility to offer the tool and adjacent services they develop to interested modelers.

Modelling tools are instruments which permit visualization, conceptualization and processing in accordance to a specific goal through the use of models. The domain specificity in modelling tools is included through the individual methods used to create the models. The methods define the modelling language (i.e., notation, syntax and semantics), the modelling procedure (i.e., the process of properly applying the modelling concepts) and mechanisms and algorithms (i.e., the processing entities running on models) [31].

The unit of analysis was the relationship between the complementor and the platform owner. To foster replicability bilateral relationships were examined in depth. Each of them represented an individual case. The complementors were selected as such as to differ in the variables of interest in order to ensure generalizability, particularly in the types of controls as well as the asset specificity and frequency of exchange. From a total of 44 existing complementors, 20 were found to be suitable according to the criteria above and 8 accepted to participate in the case study.

Data about the complementors and the platform owner were also directly collected from the platform enterprise. The platform itself is a commercial proprietary platform residing on the application layer used in the context of the case study for academic purposes. It does not exclude revenue generating activities for the complementors.

All complementors included in the case study units of independent organizations and none of them are a subsidy of the platform owner. Secondly, all of them are solution providers i.e., they are building their modelling tools on top of the platform. Their individual solutions extend the range of applications of the platform. Because the units are fairly small (from 5 to 20 people) we aimed to identify interview the responsible decision makers for joining the platform enterprise from each complementor. This turned out to be in every case one person, which we then interviewed. The table below shows the summary of the complementor’s main topic as well as the interview conducted.

All subjects of the case study are providers of modelling tools. The application domains and topics they address vary. PSS and ComVantage address the domain of production management, SemCheck and Bee-Up enterprise modelling, ValueChains tackles business engineering with focus on the strategy layer, SOM information management, ADVISOR education and bpFM focuses on business process management (see

Table 1. Complementor interviews.

Case	Complementor Topic	Interviews	Interview Partner
SemCheck	Service provider: integrity checking for tool development Domain: Conceptual Modelling	1	Unit leader/Project leader
ComVantage	Modelling tool for production management (semantic rich) Domain: Production Management	1	Project leader
PSS	Modelling tool for product-service-systems Domain: Production Management	1	Project leader
ValueChains	Modelling tool for business engineering Domain: Strategy Management	1	Unit leader/Project leader
SOM	Modelling tool for enterprise information management Domain: Information Management	1	Project leader
BEE-UP	Modelling tool for enterprise modelling Domain: Enterprise Modelling	1	Head developer
ADVISOR	Modelling tool for learning assessment Domain: Education	1	Head developer
bpFM	Modelling tool for rule-based business process management Domain: Business Process Management	1	Project leader

). All complementors were active previous to their joining of the platform ecosystem; they all had recognizable products and services which were used in their portfolio of activities, generating different types of revenue. Thus, they were all considered mature complementors and included in the empirical research, whose results are discussed below.

The interviews were based on an interview guideline which reflected the propositions to be tested and were semi-structured. This allowed for additional insights and proposition refinement. All interviews were recorded and later on transcribed. The interview protocols resulted in more than 40,000 words of qualitative data. To increase the validity of the empirical findings, additional data were gathered in order to triangulate with the interview input. For this, information was collated from external databases, web searches, the platform enterprise, publications and media.

The interviews were transcribed to text. Subsequently the text were imported to the academic trial version of NVivo, relevant text passages were marked with brief labels (‘Asset specificity’, ‘Behavioral uncertainty’, ‘Environmental uncertainty’, ‘Technological uncertainty’, ‘Informational controls’, ‘Co-regulative controls’, ‘Motivational controls’, ‘Relational risk’, ‘Performance risk’) using the corresponding functionality [32]. We subsequently built clusters for each of the different tags. These were then exported to Excel and manually assigned to the different indicators.

Following the coding a total number of 221 statements were assigned to the categories mentioned above. The statements were then compared to the database of external documents and information which had been collected from third-parties and the platform ecosystem in order to ensure their validity. For quality assurance purposes and external validation each interview partner received the coded statements and was requested to assess whether the coding corresponded to their statements. Four of the interview partners gave feedback, with only one of them having minor adaptions.

To substantiate the qualitative assessment done during the coding process the 221 categorized statements were assigned an importance value, i.e., how important the interviewee considered the respective issue, and a directional impact [32]. The scale used was from −2 (negative influence) to 2 (positive influence) with 0 (neutral) as the median. Each of the cases was first assessed in its entirety. Subsequently a case analysis was done by compiling all cases and looking at the number of quotes/construct relative to the average strengths and direction.

The results were evaluated by looking at the results of each individual case vis-a-vis the hypotheses and subsequently by comparing the median values over all cases to the hypotheses.

3. Risk Evaluation Model for Complementors

This section aims to contribute to the body of knowledge on how transaction costs, platform controls and perceived risk influence the third-party innovators decisions to join a platform enterprise (see Figure 2).

Perceived risk is defined as the subjective negative variation from expected outcomes [33,34]. It is an important factor in the decision process of the third-party innovator to join the platform enterprise. Similar to strategic alliances third-party innovators must manage not only their enterprise’s individual performance risk, but also the relational risk between the two partners [35]. Differently to classic alliances where partners join their individual and independent resources together to achieve a better market position [36] in platform enterprises complementors also depend on the technological performance of the platform provider for their product development. Thus, differently than in other types of partnerships they share not only the relational but also the performance risk. Resources shared between the partners can be either property or knowledge [33]. To prevent misuse of such resources both partners are interested in decreasing uncertainty by setting controls in place which allow for a better risk management. Whether the platform enterprise is the appropriate mode of governance for the partnership will be ultimately decided through evaluation of the transaction costs the complementor faces in the partnership.

The transaction cost theory (TCT) posits that the appropriate mode of governance for a transaction is defined by several of its characteristics [37]. These are the specificity of the asset(s) exchanged in transactions, the level of uncertainty (behavioral and environmental) surrounding them as well as the frequency with which they are carried out [38]. All of them influence the costs of the transaction, which are the sum of search and information, the decision, investments in societal relations and the opportunity costs within the boundaries of a firm. The theory predicts the most suitable boundary as well as the relationship for the exchange between two independent firms. Extending Coase’s theorem, Williamson proposes that in search for the most effective exchange different organizational forms will emerge [39].

3.1. Controls in Platform Enterprises

The ultimate goal of governance is to contribute to “maximizing social welfare” by substituting monetary mechanisms together with property rights [40]. Control, as part of the platform governance system, is composed of an array of mechanisms which govern the actions undertaken by the complementors within the ecosystem. It is a measure imposed in addition to pricing [41], established and enforced by the platform owner with contribution from the other system constituents [23]. Licensing agreements, service level agreements (SLAs), the assignment of decision and property rights, contracts, the platform architecture and its interfaces, signaling and relational contracting all represent private controls imposed and enacted by the platform owner [13]. Clan control on the other side, which fosters a set of common values, is sanctioned and enacted by the platform enterprise members [40]. For the purposes of this paper only the private controls are of relevance.

Control mechanisms can be applied upon the initial service specification, i.e., the inception of the partnership, the service development, i.e., the product development upon the technological platform, as well as during service deployment, i.e., the commercialization on the market [41]. As this paper considers the complementor’s perspective we disregard the market regulative control, i.e., the mechanism to maintain good behavior vis-à-vis the customer, assuming that this is in their intrinsic interest.

At the inception of the partnership co-regulative controls applied, include formal instruments such as vetting mechanisms, contracts and other legal documents (such as licensing) as well as the rules and tools deployed to ensure quality and coherence during the product lifecycle. Using the platform-as-a-service (PaaS), the owner compels complementors to use a proprietary development and testing environment. He also mandates rules to be followed. Because everything is hosted on the owner’s side he can simply monitor and control the quality and performance of the third-party functionality. This includes monitoring of transactional criteria, such as availability, responsiveness, and SLA’s. Technological and organizational rules for non-compliance or failure and escalation procedures are available.

Upon entering the platform enterprise and also during the partnership lifecycle, motivational control is synonymous with incentives for complementors. Technically this can include training sessions, forums, documentation, complementor–centered events, technological roadmaps etc. On the business side it might comprise funding, marketing and sales support, promotional events, inclusion in customer-loyalty programs, signaling through certifications etc. All motivational controls have the goal to convince the complementor to connect his product to the platform, which will in turn increase the owner’s direct benefits and also those resulting from indirect network externalities.

Informative controls, which can be observed before and during the partnership, aim to increase the transparency of the ecosystem for the complementor. As such regular sales reports and leads, technical performance reports, customer ratings and feedback, comparative evaluations with other complementors, and strategy plans for the enterprise evolution might be shared by the platform owner [38].

How these controls influence the transaction costs the complementor faces and ultimately the perceived risk is presented in the following.

3.2. Transaction Cost Theory

In IT-related research, studies have focused on the impact of IT outsourcing on transaction costs and company boundaries [23] to establish the degree of outsourcing. In line with the original theory one of the underlying assumptions is that the costs of partnering are exogenous, while the governance modes are endogenous. This is different in platform enterprises. Complementors who join a platform ecosystem cannot influence the governance mode and thus have to rely on other means to reduce the costs of their transactions [23].

Following [8,11,23], the work at hand, considers the influence of ‘platform architecture’ and enterprise uncertainty (technological, behavioral and environmental) on the costs the complementors face when deciding to join the platform ecosystem. Transaction costs in a platform enterprise are the costs the complementor incurs in order to be able to develop his product and to deliver it to the customers [23].

This work follows [23] and proposes that a modular architecture should influence the transaction costs of the complementor on a technical level. The same goes for design rules packaged in an application programming interface (API). The availability of standardized and documented APIs will lower a complementor’s transaction costs for coupling his product to the platform ecosystem. Thus, the argument is that ‘platform architecture’ is crucial to the amount of transaction costs for the complementor.

The platform ecosystem also influences uncertainty through the governance regulations, i.e., the allocation of decision right, control mechanisms and license policies, it enforces [14]. For example, modularity and standardized APIs are assumed to reduce technological uncertainty. Uncertainty about the platform owner’s policy regarding competition among complementors increases the market uncertainty and is assumed to decrease the complementor’s motivation to enter into the platform ecosystem [23].

3.3. Complementor’s Perceived Risk Depending on Controls and Transaction Cost Theory

Performance risk, i.e., the probability that the partnership will not deliver the expected outputs, depends largely on the asset specificity of the platform. This is the degree to which assets can be reused for other purposes and by other users, without sacrificing their “productive value” ([39], p. 105). The more specific an asset is, the harder it is to redeploy and the stronger the lock-in effect the complementor faces. Specificity can be divided in three aspects [41]: site, physical and human asset. The first one is associated to the geographical location in which the investment is positioned. For platform ecosystems which deploy as PaaS and manage access to the whole value chain via internet, the physical location of the resources is expected to be of little relevance. The importance of the physical asset specificity is also strongly limited as the platform owner will be interested in providing suitable development and deployment environments which scale for a large number of complementors and products. Thus, third-party firms will expect to consider only the add-on computing power for their own product development an influencing factor, if they require it. Human asset specificity in turn plays an important role especially in proprietary platform enterprises. The need for the firm’s employees to learn the platform specifics, i.e., architecture, interface specifications, as well as the need to develop expertise in the technical and business interaction processes with the platform ecosystem imposes high costs on the complementor. Additionally, investments in relation-specific knowledge might be necessary for the complementor’s developers to properly use the resources provided by the platform owner. The more specific an asset is that the complementor develops the stronger is the lock-in effect and consequently the higher the switching costs are when considering multi-homing. Hence asset specificity will negatively impact the complementor’s propensity to join the ecosystem. Motivational controls, such as free trainings and documentation will help decrease the complementor’s investment needs and subsequently their perceived risk of entering the partnership. This leads us to:

Hypothesis 1a.

Motivational controls decrease asset specificity for the complementor and thus decrease his perceived risk in joining the platform enterprise.

Hypothesis 1b.

High-asset specificity increases the complementor’s risk in joining the platform enterprise.

Environmental uncertainty is the “inability to ascertain the structure of the environment” ([37], p. 23) and thus results in the unpredictability of the indirect environment of the ecosystem. Environmental uncertainty includes technology and its changes, customer demand as well as customer requirements and competition from other complementors [39]. It includes also institutional and cultural uncertainty.

The decision to join the platform ecosystem will decrease economic uncertainty for complementors especially if they (a) can signal trustworthiness by association with the ecosystem [22,41]; and (b) get access to a larger and more diverse customer base which was not available to them through their previous activities. Studies have shown that partnerships with platform ecosystem increase investors trust in the complementor’s ability to generate future profits and thus improve their ability to attract funding. Also, platforms tend to have large installed customer bases, to which the complementor gets access and is able to service, especially if it occupies a niche segment or a segment underserviced by the other ecosystem members [21]. Because complex software which is directed towards businesses is difficult to assess in advance, the association with an industry leader will tend to make the complementor’s overall product portfolio more attractive to new customers, especially if the platform products are complementary with services offered outside the ecosystem.

Uncertainty about the competitive environment within the ecosystem will tend to increase the complementor’s costs, because of the need to assess threats of competition from other complementors or the platform owner himself [42]. Informational controls decrease the uncertainty as they provide transparent information about the platform owner’s view on the ecosystem. Thus:

Hypothesis 2a.

Informational controls will decrease the complementor’s environmental uncertainty and his perceived risk in joining the platform ecosystem.

Hypothesis 2b.

High environmental uncertainty will decrease the complementor’s motivation to join the platform ecosystem.

Due to its centrality in platform ecosystems technological uncertainty has been extracted here from the environmental uncertainty and given a consideration of its own. In highly innovative and dynamic environments it will be difficult to draw up contracts which cover all ex-post eventualities [43,44]. Thus, platform ecosystems, which we assume are innovative [45], will tend to impose high monitoring and enforcement costs on complementors. Modularization which is designed to increase the pace of innovation will play a dual role. On the one side, because it hides platform developments from the complementors, it will tend to increase uncertainty. On the other hand, because of modularization complementors can easily and rapidly adapt their complements, which will in turn decrease their uncertainty [11]. APIs will tend to decrease the technological uncertainty, especially if they are using standards or well-known programming languages, they are well documented and if they are weakly appropriable by the platform owner [20]. The availability of documentation, technical communities and boundary objects such as software development kits (SDKs) will decrease the complementor’s cost for monitoring technological developments.

The less the complementor is able to know about the technological make-up of the platform and its evolution, the more it will cost for him to develop his product on the platform. Hence the higher the technological uncertainty is, the less the complementor will be inclined to join the platform ecosystem.

Hypothesis 3.

High technological uncertainty will decrease the complementor’s motivation to join the platform ecosystem.

Behavioral uncertainty is the “strategic non-disclosure, disguise or distortion of information” ([46], p. 57). The less complementors are able to observe the platform owner’s behavior, the more they will tend to stay away from the environment [47]. Governance instruments such as co-regulative controls, which impose certain rules and norms on the partnership, increase the predictability of the platform owner’s behavior and thus reduce the uncertainty [23]. Previous collaborations or partnerships between the two parties will also tend to decrease the level of uncertainty because of the already existing trust and experience on the complementor’s part [22].

While the platform owner’s goal is to create a vibrant and growing ecosystem, there remains a continuous tension between him and the complementors [10]. These must fear that the platform owner will exhibit opportunistic behavior and appropriate complementor-specific innovations into the platform core or offer substituting products for those of the third-party [19]. Additional concerns include the fact that the platform owner might withhold information or resources which are important for the value-creation process [23]. After the commencement of the partnership and the initial investments done by the complementor, the platform owner might also decide to exploit the lock-in [9].

Thus, the costs necessary to assess and mitigate the behavioral uncertainty provoked by the platform-owner will negatively impact the complementors propensity to join the ecosystem, while co-regulative controls which clearly delineate property rights will decrease the risk for the complementor. Thus, we propose:

Hypothesis 4a.

Co-regulative controls will decrease behavioral uncertainty and reduce the perceived risk of entering the platform enterprise for the complementor.

Hypothesis 4b.

High behavioral uncertainty will decrease the complementor’s motivation to join the platform ecosystem.

In the following we provide first evaluation results of these hypotheses from a single-case study.

4. Case Study Results

4.1. Asset Specificity and Motivational Controls

Contrary to the expectation derived on the basis of theory, the complementors did not perceive the fact that the platform is proprietary and imposes proprietary programming languages and interfaces negatively (see

Table 2. Evaluation of interview fragments regarding asset specificity (Number of quotes per interview/Average strength and direction (from −2 to 2), “n/a: not applicable”, i.e., interviewee did not reference the particular indicator in the interview.

Indicator	Modelling Tool
	SemCheck	ComVantage	PSS	ValueChains	SOM	Bee-Up	ADVISOR	BPFM
1. Complementor uses proprietary platform language to create product	n/a	2/1.5	3/1.66	4/0.5	3/1.33	2/0.5	1/0	2/0
2. Complementor uses proprietary platform functionality to create product	n/a	3/0.66	2/1	2/2	2/0.5	1/2	1/1	2/0.5
3. Complementor uses proprietary interfaces to create product	2/−1	n/a	1/0	n/a	n/a	n/a	n/a	2/0.5
4. Complementor uses proprietary platform SDK to develop product	n/a	2/1.5	4/1.25	2/1	1/0	5/1.2	2/0.5	1/1
5. Complementor uses proprietary platform deployment environment to compile product	1/1	2/1	1/1	3/1.66	2/1.5	1/0	1/0	2/1
6. Complementor has received trainings which have decreased it human asset specificty	0/1	2/4	2/2	1.66/3	2/1	1/1	0/1	2/1
7. Complementor considers existing documentation helpful in knowledge transfer	1/1	3/1.66	1/3	1/1	3/0.66	2/2	0/0	3/0.33
Aggregation across all indicators/interview	0.57/0.5	2/1.47	2/1.42	1.95/1.30	1.85/0.71	1.71/0.83	0.71/0.36	1.43/0.55
Aggregation across all cases	1.53/0.89

). As most of them (with exception of SemCheck, ValueChains and ADVISOR) did not have an IT-supported modelling tool before entering the ecosystem, several interviewees concluded that for them time to market was more important than openness and they didn’t care if the platform was proprietary as long as the learning curve/entry barriers were not too high.

It was mentioned that in the case of this specific platform it was its narrow domain-specific focus which helped keep the entry barriers low as well as the motivational controls available. Indicators (6) and (7) which represented the motivational control were in line with the hypothesis showing a strong positive correlation between the incentives received and the perceived lowering of asset specificity and implicitly of the risk the complementor faces.

The relatively low effort to implement an own modelling tool was given as only the notation, the procedure and the processing algorithms had to be implemented. This could be easily done by inheriting mechanisms based on the platform technology, i.e., the meta-model, and on a flat scripting language which had similarities to other languages (such as JavaScript and Prolog) in which the developers were fluent. It was important for complementors that they did not need to deal with any user interface design and optimization, model storage, versioning and repository mechanisms, user and role administration as well as performance optimization issues as these came all out of the box in the platform’s case.

The findings above are presented in more detail for the case of ComVantage, which is a modelling tool for predictive maintenance in the domain of production management. ComVantage was a common initiative of an industry/academia consortium which started in 2011. The project owner of ComVantage had used the specification provided by the consortium to evaluate two alternatives, the ADOxx^® platform and the Eclipse platform. While the latter was using the Java programming language, which is an open industry standard, and offering standardized APIs and a framework for modelling tool engineering, called EMF, it did not provide support in the tooling and deployment of the modelling toolkit. This meant that the project owner had to take care of the top to bottom development of the tool. Because the specification was for a quite complex tool and a lot of processing functionality this alternative was deemed hardly feasible, because “we just did not have the time and resources to develop everything from scratch”. Also, Eclipse is not originally geared towards the modelling tool engineering community but generally towards software engineering. Thus, specific concepts which were deemed necessary were not available out of the box. The alternative was to use a proprietary platform specific to modelling tool engineering. One of the industrial partners knew about the platform from a commercial environment and suggested it as a possible alternative. Upon evaluation, the team decided to join the platform ecosystem, because “[…] we had assessed it. Although we had to find some workarounds because some of the specifications we had could not be realized, we could reuse about 90% of the platform functionality directly for our purposes”. The interviewee also highlighted the fact that reuse of concepts, i.e., of existing notations and relationships, lowered additionally the development entry barrier, as the team could observe existing implementations directly in the operational platform environment.

Considering the findings above, it is concluded that hypothesis 1a was supported by the data as the mean from indicators 6 and 7 showed the expected positive correlation, while hypothesis 1b could not be confirmed by the empirical data in this case as the aggregated median result of indicators 1–5 showed no negative correlation which was originally expected.

4.2. Environmental Uncertainty and Informational Controls

The empirical findings were in line with the expectations derived from the theoretical basis, namely that a higher environmental uncertainty was detrimental to the complementor’s motivation to join the platform ecosystem. Similarly, it was seen that informational controls, especially technological roadmaps were helpful in decreasing environmental uncertainty and mitigating the perceived risk of the complementor.

Indicators 1, 2, 4, 5, and 6 (see

Table 3. Evaluation of interview fragments regarding environmental uncertainty (Number of quotes per interview/Average strength and direction (from −2 to 2), “n/a: not applicable”, i.e., interviewee did not reference the particular indicator in the interview.

Indicator	Modelling Tool
	SemCheck	ComVantage	PSS	ValueChains	SOM	Bee-Up	ADVISOR	BPFM
1. Complementor accesses the modeler base of the platform ecosystem	1/2	1/1	1/1	1/1	2/0.5	2/2	1/1	1/2
2. Complementor signals quality and trustworthiness through association with the platform	2/1.5	1/2	1/1	1/1	1/0	1/0	1/1	1/1
3. Complementor’s functionality is easily substitutable with existing platform functionality	3/−2	1/0	1/0	1/0	2/0	1/0	1/−1	1/0
4. Complementor knows competition strategy in the ecosystem	1/2	n/a	2/1.5	1/0	1/1	2/1.5	1/1	1/1
5. Complementor knows technological roadmap for platform development	1/−1	3/−0.33	1/0	1/−1	n/a	1/−1	1/0	1/0
6. Complementor has access to customer ratings and other market relevant information	2/2	1/1	2/1	2/1.5	1/0	1/0	0/0	1/2
Aggregation across all indicators	1.43/0.64	1/0.52	1.14/0.64	1/0.36	1/0.21	1.14/0.36	0.71/0.43	0.86/0.86
Aggregation across all cases	1.035/0.5

) got responses which were congruent with the theoretical expectations, namely that items which decrease the complementor’s perceived environmental uncertainty in the ecosystem will be valued positively. Nonetheless it was rather surprising that the possibility of substitution of the complementor’s functionality (indicator 3) through the platform was rated mostly “neutral”. Only SemCheck considered substitution as a “highly negative” influence on its decision to join the platform ecosystem. ADVISOR considered it “negative”. In both cases, it turns out that the complementors had had modelling tools previously and their fears for platform substitution were not that much for the new ecosystem but for their already existing user base. Especially in the case of SemCheck the project owner considered that the functionality overlap between the existing platform functionality and the complementary tool was more than 70% and thus the platform was posing a potential threat to the tool. In the case of ADVISOR this percentage was lower because of the domain (education) addressed by the tool and the concepts which made it more specific.

The findings above are presented in more detail for the case of SemCheck, which is a modelling tool for conceptual modeling. SemCheck started its development early in the mid-90s as an open source community and had built several releases of its tool. It has quite a large user base which regularly uses the tool, but it does not have any development resources committed to it any longer. Thus, the project manager decided to join the platform ecosystem in order to gain access to development resources to further the functionality of SemCheck and most importantly, to gain access to an enlarged user base. Because the platform is also commercially used it was considered as a synergistic benefit for the existing user base of SemCheck, which did not use its tool for revenue creation but adjacent services to it. In the case of SemCheck the possibility of functionality appropriation by the platform weighed very negatively. The decision to join was aided by the fact that the platform owner had extended a motivational incentive to the SemCheck project manager, which had guaranteed amongst others that in the first two years of platform ecosystem membership there was a strategic commitment to not compete in the same functionality niche from the platform side. The SemCheck project manager is still concerned about the substitution possibility and has expressed the desire of a shared code repository as an instrument to mitigate environmental uncertainty.

Considering the findings above, it is concluded that hypothesis 2a and hypothesis 2b were both supported by the empirical data.

4.3. Technological Uncertainty

The theoretical discussion suggests that the more the complementors know about the platform technology the more motivated they will be to join. The empirical findings support this supposition (see

Table 4. Evaluation of interview fragments regarding technological uncertainty (Number of quotes per interview/Average strength and direction (from −2 to 2); “n/a: not applicable”, i.e., interviewee did not reference the particular indicator in the interview.

Indicator	Modelling Tool
	SemCheck	ComVantage	PSS	ValueChains	SOM	Bee-Up	ADVISOR	BPFM
Complementor uses SDK to develop and test its product	n/a	2/1.5	1/1	4/1.5	3/0.66	2/1	1/0	1/1
Complementor uses technical documentation, FAQ’s, developer forum, direct contact to platform staff for technical information	1/2	3/1.66	2/2	3/1.33	2/1.5	1/1	1/0	1/1
Complementor uses standardized API to interface with the platform	1/2	1/1	n/a	n/a	n/a	1/1	n/a	n/a
Complementor reuses platform modules to create his product	1/1	2/1.5	2/1	2/2	1/0	2/0.5	3/1	1/1
Aggregation across all indicators	1/1.66	2/1.42	1.66/1.33	3/1.61	2/0.72	1.5/0.88	1.66/0.22	1/1
Aggregation across all cases	1.73/1.09

).

Complementors stressed that it very important to have a suitable and pertinent documentation for the platform. Depending on the developer’s personality, documentation, frequently asked questions (FAQ’s) and developer forums were named as important information sources or the personal contact. The lead developer of Bee-Up mentioned: “I am more of a do it yourself guy. I read about it and then try to figure out a solution by myself. I don’t contact anyone directly except when I don’t have any other solution. I prefer posting in the forum. They are really up to speed on that one.” Differently ValueChains and PSS owners stressed their extended contact with the platform support team especially in the process of implementing algorithms and mechanisms or rule-based visualizations in the modelling language.

All complementors valued the SDK positively and none of them mentioned the desire to use their own environment. Exception was the SemCheck case which hooks into the platform by a Java-based API and thus does not directly do development in the SDK but in a Java-editor. Standardized APIs were seen by only three (SemCheck, ComVantage, and Bee-Up) as relevant. All three tools interact with external functionality which they such as to couple to their modelling tool. In the case of SemCheck this is an integrity checker for conceptual consistency which is Java-based, in the case of ComVantage it is an RDF-engine aimed at parsing RDF-statements and validating them and in the case of Bee-Up it is a call on an external PetriNets analyzer implemented in C++. Modularity was rated positively as a reducer of technological uncertainty by all interview participants. Several participants also mentioned that it was important to them that they could easily couple their development in the platform for testing, as this needed no compilation run and thus shortened the development time considerably.

The findings above are presented in more detail for the case of SOM, who was the first complementor to join the ecosystem. The SOM manager, a firm believer in tool support, had tried several open-source platforms and also tried to self-develop his tool. According to the head developer the high rate of developer fluctuation, the lack of resources and the poor documentation available made development difficult as one could not trace what specific parts of the code were doing what. In addition, in their previous experience the lacking conceptual integrity of the platform architecture had proven to be a problem when confronted with the SOM requirements. SOM is a strongly formalized modelling method which prescribes composition and de-compositions algorithms as well as dependencies between different views. Processing of such a method requires a conceptually coherent architecture with high performance rate in tactical operation, because a multitude of functions have to be executed automatically.

One of the most important decision points for the SOM team was the existence of professional documentation and support. Because of the specifics of their method the SOM team reused less platform functionality as the rest of the complementors, but instead used the proprietary programming language ADOscript to create what they needed. As SOM models require in some cases more than 1.500 function calls in a model bundle, the scalability and stabile performance of the platform was seen as another major motivator.

Considering the findings above, it is concluded that hypothesis 3 was supported by the empirical data in this case.

4.4. Behavioral Uncertainty and Co-Regulative Controls

The empirical analysis showed that the behavioral patterns of the platform owner played an important role in the complementor’s cost assessment. Differently than before, we observed a high variation among the distribution of indicators (see

Table 5. Evaluation of interview fragments regarding behavioral uncertainty (Number of quotes per interview/Average strength and direction (from −2 to 2), “n/a: not applicable”, i.e., interviewee did not reference the particular indicator in the interview.

Indicator	Modelling Tool
	SemCheck	ComVantage	PSS	ValueChains	SOM	Bee-Up	ADVISOR	BPFM
1. Complementor has licence and cooperation agreement with the platform owner.	1/1	1/−1	2/−1.5	0/1	1/1	0.5/2	0/−1	1/2
2. Complementor has a trust relationship with platform owner (e.g., previous collaborations).	1/2	1/2	1/2	1/2	1/2	1/2	1/2	1/2
3. Complementor has no access to information about rules of the co-operation process in the platform.	1/−2	2/−0.5	1/0	1/−1	1/−1	1/0	2/−0.5	1/0
4. Complementor competes with platform owner in the complementary product market.	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a
Aggregation across all indicators	1/−0.33	2/0.39	1/0.66	1/0	1/0.5	1/0.33	1.33/0.5	1/0.66
Aggregation across all cases	1.16/0.34

). Interestingly enough the distribution across complementors was quite similar for each indicator, which shows a general lack of communication between the platform owner and the complementor community for indicators 1 and 3. All complementors indicated either a neutral or negative impact resulting from not being privy to the plans for future platform releases and what technological changes they might entail. The complementors who indicated a “negative” impact also mentioned that they are currently in the process of extending their tool and that knowing what will come next, platform wise, would simplify their assessment about how many resources to commit to the project. The other complementors mentioned that currently they have a stable product version running, where they do not plan any changes in the near future. Even more negative impact was assigned by the complementors to the fact that very few explicit rules exist with regard to the complementor-platform collaboration. While they mentioned that they appreciated the flexibility which comes with ad-hoc, case-by-case decisions, they also indicated that for the long-term planning they consider a stable set of rules as necessary or at least helpful.

Each and every interviewee mentioned that one of their strongest reasons to join the platform ecosystem was a trust relationship with the platform owner. The answers for trust ranged from personal contact, previous collaborations, and recommendations. Interestingly enough also every complementor indicated that the platform owner is currently no competition for their complementary product. SemCheck referred to the environmental uncertainty question, explaining that the focus in that answer was on potential future developments.

Considering the findings above, it is concluded that hypothesis 4a and 4b were supported by the empirical data in this case. Because the criteria varied largely this premise might warrant a critical evaluation though, with an extended number of indicators or a larger group of respondents in order to elaborate the relative importance of each criterion.

5. Conclusions

The paper at hand presented a risk evaluation model for complementors who are interested in joining platform enterprises. The model and corresponding hypotheses were built on an extensive literature study. A first empirical evaluation was done using a case study of the Open Models Laboratory (OMiLAB), where third-party innovators can use a technological platform to engineer their own domain-specific modelling tool and make them available to consumers.

The research conducted aimed to contribute to the body of knowledge on how transaction costs, private platform controls and perceived risks influence the third-party innovator’s decision to join a platform enterprise.

The empirical application showed that especially motivational and informational controls are perceived as positive by the complementors. As far as co-regulative controls go, there is a need to examine different controls in more detail. For example, an open source license agreement might be perceived as positive while a proprietary license agreement might yield different results. Given the complexity of the topic we plan to widen our research in analyzing how different types of co-regulative control influence the perceived risk of complementors.

Differently than expected, asset specificity, as one transaction cost component, did not correlate negatively with the complementor perceived risk. This needs further exploration as existing research does not provide conclusive support. It might be that the indicators selected here (modularity, API, SDK) need further refinement or improvement, although they are most often used in literature. In line with the assumptions of the model all uncertainty types (behavioral, technological, environmental) were mitigated by additional controls which helped the complementors get a more complete set of information about the platform enterprise itself and the behavior of the platform owner. In this context further research on how complementors use platforms to signal trustworthiness to a customer base and how this possibly decreases their perceived risk of joining the enterprise is of interest.

A second case study in in preparation for the domain of enterprise application software, more specifically ERP systems. The first aim is to refine the indicators for the platform specific transaction costs as well as to validate the model proposed.

To validate our model further we plan to expand the domains we address. The first domain will be that of product-service-systems. Differently than with pure information technology (IT) products, physical products require also physical production facilities which might change the impact asset specificity has on the transaction costs. We plan to focus on the metal processing industry in order to evaluate how digital services offered by complementors alter the production process and product lifecycle. Behavioral uncertainty in this context will also need to include factors as business culture, as location independence will not be that easily achieved as in the case study we presented here.

Behavior and uncertainty are also closely linked to business culture. While the eight selected complementors in our case study were from 6 different European countries (Sweden, Romania, France, Germany, Austria, and Italy), the questions posed to them during the interview did not address any cultural specificity. Future research could consider whether enterprises born global, such as platforms, homogenize culture through the environment they offer or if complementors from different countries are more averse/adept to joining platform enterprises due to their cultural background. Exploration of such research questions, while interesting, is beyond the scope of our research and also our means, as there is a need to access an environment which aggregates a large number from different complementors from several countries to enable empirical exploration.