Pervasive digital technology significantly changes the logic of innovation. One of the most important aspects of organizing such innovation processes is shifting the locus of innovation on technological platforms (Tiwana 2015a; Tiwana et al. 2010). A digital platform, i.e. an extensible code base, allows the development of complementary products or services (e.g. applications) that augment a platform’s native functionality (Lyytinen et al. 2016). Companies offering such complementary applications are called software startups or third-party developers (Ghazawneh and Henfridsson 2013). To accelerate innovation on digital platforms, platform owners must create and sustain vibrant ecosystems of third-party developers, which consist mainly of software startups and entrepreneurs that build their business models on the participation in the platform ecosystem (Boudreau 2012). Modular platform architecture enables software startups to develop their own apps independently, yet platform interfaces ensure their interoperability. This tendency towards a disintegrated architecture is mirrored by an increasing degree of interorganizational modularity, distributing the partitioning of innovation among many heterogeneous firms (Baldwin and Clark 2006).
Digital technology therefore creates several idiosyncrasies in the organizational logic of innovation (Yoo et al. 2012). First, the loosely coupled relationships between actors like the platform owner and single third-party entrepreneurs represent a hybrid form of organizations which exhibits characteristics of both markets and formal alliances in the traditional sense of economic exchange theories (Williamson 1985). Second, following this logic, control and knowledge is distributed between various actors (Lyytinen et al. 2016). Finally, such relations are frequently characterized by coopetition (i.e. simultaneous cooperation and competition). For instance, although platform owners encourage the development of third-party innovations, they might compete with software startups in certain market niches (Ceccagnoli et al. 2012).
Although organizing digital innovation around a technological platform has created new business opportunities by providing complementary resources, it also introduced essential new risks. I refer to this phenomenon as risk of third-party innovation. In comparison to traditional risks of software engineering (Barki et al. 1993; Wallace et al. 2004), the locus of this form of risk is not within the own organizational boundaries but on platforms as well as within the focal software startup’s relationship multiple and heterogeneous actors. Exogenous and relation-specific factors like for instance opportunistic behaviour of the platform owner, market related factors as well technological dependencies on the platform, thus constitute crucial threats which lay outside the direct control of a software startup.
To theoretically explain the emergence of software development risks and provide IS management with means for its management, previous research proposes that successful organizations establish a fit between the degree of uncertainty of their environment and their structural and control approaches (Bourgeois III 1985). This perspective extensively examined the role and interplay of control mechanism and environmental factors in influencing the risk of IT projects (Rochet and Tirole 2003).
In the context of third-party development on technological platforms, this perspective runs its limits for two main reasons. First, the contingency approach assuming the existence of a single state of fitness between control mechanisms and potential exogenous hazards is not able to capture the increasing dynamics and complexity of an ecosystem as the focus of IT innovation is shifting to platforms. I therefore utilize configuration theory (Ragin et al. 2006; Ragin and Inquiry 2008) as theoretical lens to overcome the traditional reductionism problem (Meyer et al. 1993) and examine the equifinality of different solutions for managing risk in ecosystems where a different set of elements can produce the same outcome.
Second, entrepreneurial software startups are typically not able to apply direct control mechanisms to govern third-party innovation in platform ecosystems for reducing their risk. Congruent with previous work, which highlights the role of modular architecture as a control function for alliances (Tiwana 2008) or to reduce opportunistic behaviour (Williamson 1985). I argue that the modularization of application-platform linkages is the useful mechanism for software startups to manage the relation with the platform owner.
Addressing these two shortcomings of previous research, the purpose of my work is therefore to shed light on software startups’ third-party innovation risk by explaining its prevalence based on different configurations exogenous hazards from the platform ecosystem as well as the microarchitecture of single applications which may serve as a safeguard against those hazards.
To explore these issues, my research analyses data from a survey of 42 software startups on five leading cloud platforms using fuzzy set Qualitative Comparative Analysis (FsQCA) (Ragin and Inquiry 2008). The FsQCA approach is a case-oriented method that enables analysing asymmetric and complex causal effects by extracting configurations that consistently lead to the outcome of interest (El Sawy et al. 2010).
My study offers three noteworthy contributions. First, it outlines the influence of environmental hazards on the risk related to a major form of organizing digital innovation, platform-based application development. Second, it empirically validates the inseparability of environmental dynamics and architectural choices in such digital innovation settings. Third, it offers insights on how digital architecture can be utilized as a coordination device of software startups to manage interorganizational relations and to reduce risk.
In IS research, risk represents a function of both uncertainty and loss or damage, which is experienced by a decision maker (March and Zur Shapira 1987). A further crucial concept in this context is hazards, which is defined as a source of danger (Kaplan and Garrick 1981). Consequently, if an actor is not able safeguard against such hazards, they create a potential loss, i.e. risks.
Previous approaches examining risk in inter-organizational arrangements like for instance R&D alliances (Das and Teng 1996) or IT outsourcing (Aubert et al. 2004) are theoretically grounded in theories of economic exchange (i.e. transaction cost theory). Following the logic stated in the introduction, however, I argue that the specific characteristics of digital technologies create also significant changes in the nature and analysis of risk. The loosely coupled relationships between the platform owner and a software startup represent a hybrid between characteristics of a market and an alliance. Therefore, significantly new uncertainties evolve for the participants of platform ecosystems. The distribution of control and knowledge among heterogeneous actors accelerates uncertainty regarding the technology itself or the behaviour of the alter (Ceccagnoli et al. 2012). For instance, the platform owner´s control over boundary resources (i.e. software development kit (SDK) application programming interfaces (APIs)) makes software startups increasingly dependent (Ghazawneh and Henfridsson 2013).This limits third-party developers’ space to control the exchange with the platform owner itself. Furthermore, as this new organizing logic of digital innovation frequently requires coopetition (i.e. simultaneous cooperation and competition) to drive innovation, software startups may suffer from platform owners to adopt and modify their applications to capture attractive market niches. While platform owners encourage the development of third-party innovations, the loss of intellectual property is therefore a common threat in this context (Ceccagnoli et al. 2012).
The risk of third-party innovation as an outcome variable is therefore defined as the potential failure of the software startup´s innovation effort in a loosely coupled and co-opetitive relationship with the platform owner. This concept has two distinctive sub dimensions (Nooteboom et al. 1997): risk likelihood (i.e. the probability that the digital innovation effort will fail) and risk impact (i.e. the perceived loss in the form of missing or underachieving the goals of the innovation effort). While the first sub dimension is resulting from uncertainty, the latter is accelerated by the specificity of a digital platform and the resulting migration costs to another technology.
In IS, researchers adopt a contingency approach risk management to examine the role and interplay of control mechanism and environmental factors in influencing the risk of IT projects (Raz et al. 2002; Ropponen and Lyytinen 2000). This approach has been strongly influenced by research in organizational contingency theory, which proposes that successful organizations ensure an originality of fit between the degree of uncertainty of their environment and their structures (Bruns and Stalker 1961). Rather than assuming the existence of best-fitting combinations of predictor variables, I assume equifinality of different configuration of variables Thereby, I take a holistic viewpoint which abstains from evaluating net effects of single variables but treats such configurations in whole as explanatory factors for the outcome of interest. Such an application of configurational theory in the context of digital innovation in platform ecosystems is suitable for two reasons.
First, in configurational approaches whole sets of elements serve to simultaneously explain the outcomes of interest (El Sawy et al. 2010). Because of that, configurational theory is particularly appropriate to explain synergetic and complementary causalities (Ragin et al. 2006). This resonates well with current theoretical perspectives on the organizing logic of digital innovation in general and platform and ecosystem management in specific. Research in this field highlights the inseparability of ecosystem dynamics from app architectures and their mutual effect on innovation outcomes. Therefore, examining variable in isolation therefore is no reasonable approach towards explaining risk in third-party development.
On the other hand, recent organizational and information systems research suggests that the assumption of symmetric causal relationships might not display organizational realities (Fiss 2011). In contrast, configurational theories imply equifinality between different sets of initial conditions and assume asymmetric rather than symmetric relations between conditional variables and outcomes (El Sawy et al. 2010). Consequently, corresponding analysis procedures allow for the detection of sufficient or necessary causes of a dependent variable. For instance, while the existence of a hazard might consistently lead to high risk for software startups, this does not mean that its absence will lead to low levels of risk (e.g. there might be other hazards which substitute for it). Considering these advantages of configurational perspective, I argue that understanding organizational outcomes of the distributed organizing logic of digital innovation strongly depends on configuration of several design choices with its environment.
I divided the concept of third-party innovation risk into two distinctive dimensions: risk likelihood (i.e. the probability that the digital innovation effort will fail) and risk impact (i.e. the perceived loss). The framework comprises two facets of causal conditions for risk. It proposes that from the perspective of software startups, the configuration of four exogenous hazards (i.e. platform specificity; behavioural, market & technological uncertainty) and two endogenous choices to manage their innovation effort (i.e. app decoupling and standardization of interfaces) influence the risk of third-party innovation.
In the selection of my causal conditions, I follow notions of Tiwana et al. (2015a) on intra-platform dynamics and the required fit of architecture and environmental dynamics to process strategic outcomes. My set of causal conditions therefore includes design elements outside (hazards of the ecosystem) as well as within (app decoupling and standardized interfaces) the range of software startups’ influence and is theoretically guided by the dimensions of transaction cost theory (Williamson 1985).
Platform Specificity: The specificity of a certain platform represents the first hazard for a software startup. Platform specificity refers to the transferability of a software startup´s application to a different platform as well as the value of software startup´s assets within alternative partner relations (Rindfleisch and Heide 1997). For instance, platforms require investments in relation-specific knowledge to participate in the platform ecosystem and capitalize from the access to complementary resources and capabilities (Aubert et al. 2004). Specific assets can be for instance, human assets, technological assets or knowledge about platform architecture, interface specifications and market characteristics. High levels of asset specificity and the related investment requirements create dependence between partners, lead to lock-in effects which make it difficult for the software startups and move to another platform (Kude and Dibbern 2009). A high specificity of assets required for building complementary products therefore results for instance in high multi-homing costs (Armstrong and Overton 1977; Armstrong and Wright 2007). Therefore, the amount of a potential loss is likely to be higher under conditions of high platform specificity.
The second exogenous hazard for software startups in platform ecosystems is uncertainty, which is commonly defined as the absence of complete information about the contextual environment. This in turn leads to an inability to predict it accurately. The concept of uncertainty is crucial in organization theory and frequently applied in studies on risk in IS (Milliken 1987). For my study I define uncertainty on the interorganizational environment than on the project level. On this level I apply an environmental perspective on uncertainty, which explains the unpredictability of the firm's environment surrounding a relationship between firms (Gatignon and Anderson 1988).
Market Uncertainty: Market conditions are crucial drivers for the risk of software startups, as for instance the sustainability of the specific niche is required to succeed. Volatile customer demand, the unpredictable emergence of new substitute products or changes in the competitive environment might increase the threat of failure during the development of complementary products (Rindfleisch and Heide 1997).
Technological Uncertainty: Furthermore, technological unpredictability covers the inability to accurately forecast the technological requirements within the relationship, which is especially important in complementary platform markets. Technological complexity and changes are the most significant sources of uncertainty (Nidumolu 1995). Technological uncertainty is also frequently related to a lack of experience with the technologies employed in the ecosystem (Nooteboom et al. 1997), which increases the threat of failure due to inadequate capabilities. Furthermore, the unpredictability of technological evolution might constitute a source of risk during third-party innovation (Lyytinen et al. 2016).
Behavioural Uncertainty: In contrast to environmental uncertainty, which is not directly related to the partner, behavioural uncertainty arises from the complexity and difficulty of evaluating each other’s actions within a relationship. Taken to the platform context, the platform owner might follow its individual interests and cause hidden costs by inefficient and ineffective behaviour (Williamson 1985). Moreover, although platform owners encourage the development of complementary products to nurture the overall value of the ecosystem (Rochet and Tirole 2003), there is often a tension between them and software startups. This tension arises from the software startup´s threat of opportunistic behaviour of the platform owner by for instance exploiting resources or competing in the partner’s niche (Kude and Dibbern 2009).
Building on Tiwana (2015a), who outlines the required fit of application architecture and platform dynamics I extend this line reasoning to the risk of third-party innovation. Prior works highlight that the role of modular architecture as control mechanism to influence the outcome of interorganizational arrangements (Tiwana 2008) or to reduce opportunistic behaviour (Stump and Heide 1996). Therefore, third-party developers possess design alternatives based on which they can influence the governance of their relation to the platform. Concretely, the microarchitecture (in contrast to the macro-architecture of the overall platform) of their apps allows software startups to minimize risk by exploiting the benefits of modularization (Tiwana et al. 2013). On the micro level of application architecture, I focus on the modularization of the app-platform linkages rather than internal modular app architectures. App modularization therefore minimizes the application–platform dependencies on the degree to which an app is required to be conforming to the specified interface that is vice versa determined by the platform owner (Tiwana 2015b). Hence, applications within the same ecosystem can significantly vary in their level of modularization (Mikkola and Gassmann 2003) as its micro-architecture reflects an endogenous choice of the software startup.
App Decoupling: Decoupling allows for changes within a module which do not require parallel changes in the platform and vice versa. App decoupling reduces dependencies at the boundary between app and platform and minimizes the interactions between both (Tiwana 2015a). Hence, the technological volatility of a platform does not necessarily require changes in the single application. It enables the flexible and independent development of apps. Third-party developers are therefore able to adapt the application´s internal implementation without the need of knowledge about internal details of the platform (Tiwana et al. 2010).
Standardized Interfaces: Standardization refers to the use of standards and protocols predefined by the platform owner (e.g. platform specific APIs) that are applied to meet conformance between the platform and the software startup´s applications. A platform owner introduces such standards to manage the relationships between the app and the platform. Standardization reduces the need for iteration between the software startup and the platform owner and ensures interoperability between the platform and the app. This underlines the role of standardized interfaces as a control mechanism (Tiwana et al. 2013).
Both mechanisms allow software startups to developed apps independently and ensure interoperability with the platform and represent an architectural control mechanism to manage their innovation activities in the ecosystem.
My sample consist of 750 startup firms which built their business model on the participation in the ecosystem of five leading cloud platforms (i.e. Microsoft Azure, Oracle Cloud Platform, Amazon Web Services, SAP HANA, and Salesforce Force.com). There were two reasons for choosing these platforms. First, all platforms are well-established and have solid traction among third-party developers. Second, in all five platforms, a high level of power imbalance is prevalent, so that they perfectly meet my requirements for analysing asymmetric third-party relationships.
Key informant data was collected via a web crawling approach which randomly gathered startup contacts from the platforms´ app stores. This approach is consistent with previous surveys of third-party developers. The potential respondents were contacted via an e-mail containing information on the research project, a link to the online questionnaire as well as the request to complete the survey or to forward the questionnaire to other executives (C-level; IT executives) as further potential key informants (Kumar et al. 1993).
In total, I obtained complete data on N=42 cases. This equals a response rate of 5.6 %, a common value in such settings (Benlian et al. 2015). I assessed this possibility by comparing responses of early and late respondents (Armstrong and Overton 1977). T-tests did not reveal any significant differences (p > 0.05) rejecting the presence of non-response bias in my dataset.
Software startups from all five platforms replied (Microsoft Azure: 9; Oracle Cloud Platform: 4; Amazon Web Services: 2; SAP HANA: 9; and Salesforce Force.com: 14). Most of them were high-level executives (C-level: 71.4 %; BU executives: 19 %) and indicated high experience in managing platform-based software development (>10 years: 83.3 %).
Based pilot study with managers in the software industry, I constructed my measurement instrument. To ensure validity, reliability as well as rigor of my research (Lewis et al. 2005), I adapted existing scales to the platform context and refined them based on the insights from the pilot study. Subsequently, these refined items were evaluated in a pre-test procedure. This helped me ascertaining that the formulation of all items was unambiguous and comprehensible.
The psychometric statistics (see Appendix) of the measured constructs indicate a strong evidence for adequate reliability with Cronbach’s α greater than .85 for all variables. Furthermore, I can assert discriminant validity as confirmatory factor analysis yielded high factor loadings concerning so that the Fornell/Larcker criterion is fulfilled for all my study variables.
To reject the possibility of common method bias, I conducted Harman’s single-factor test (Podsakoff et al. 2003). The unrotated factor solution resulted in 5 factors explaining 77 % of the variance (35 % was the largest variance explained by one factor). Hence, common method bias is unlikely to be a problem.
I chose FsQCA as means to analyse the obtained data. This set-theoretic approach is utmost suitable to configurational theories as it aims at extracting whole configurations rather than single factors that help to explain outcomes of interest (Fiss 2011). Thereby, FsQCA draws on set-based measures of consistency and coverage to evaluate the predictive power of the potentially possible conditional configurations. Consistency values display to which degree cases that share a certain combination of conditions also lead to a specific outcome (Liu et al. 2017). Hence, this indicator is analogous to correlation estimates in statistical methods. The other indicator of quality, coverage, represents the degree to which a configuration covers the instances on which a specific outcome is realized. Defined as such, the meaning of coverage values resembles that of R-square values in regression analysis. The FsQCA procedure consists of three steps through which consistent configurations are detected (Ragin and Inquiry 2008): calibration, construction of truth tables, truth table analysis.
Calibration of construct measures is necessary because FsQCA as a set-theoretic analysis approach draws on membership scores (here, e.g. membership in the group of firms with highly decoupled apps) rather than values on interval or ratio scales. In my study, I thus transformed the Likert scale measures into fuzzy set membership scores. These range between 0 and 1 with 0 indicating full non-membership, 1 indicating full membership and 0.5 marking the crossover point (Schneider and Wagemann 2012). I follow the calibration approach outlined by Fiss (2011) and chose the observed maximum and minimum values within the sample to specify full membership and full non-membership for all variables. The median of observed values served as cross-over point. Based on these three values, the calibration procedure in the FsQCA software program (version 2.5) (Schneider and Wagemann 2012) transforms all obtained measures to membership scores.
The second step of FsQCA is the construction and refinement of a matrix of all configurations of antecedent conditions (in my case a 64x6 matrix; in general, 2kxk, with k as the number of conditions observed (Ragin 2008). To fit the requirements of FsQCA, this truth table must subsequently be refined. This procedure evaluates each configuration based on two criteria: frequency and consistency. The frequency assesses which of the configurations appear in the dataset. In Large samples, it is often reasonable to exclude infrequent cases so that it is necessary to set a frequency threshold for the inclusion of configurations in the further analysis procedure. As my sample is medium-sized in terms of FsQCA literature, I chose the standard threshold of 1 which is suitable for samples of this size. The consistency criterion captures if a truth table row consistently yields an outcome. The consistency value thereby should outreach at least .8, so I chose a conservative threshold of .9 (Schneider and Wagemann 2012). Overall, in 28 cases, configurations exceeded the frequency threshold of which 13 also exceeded the consistency threshold for risk likelihood and 17 for risk impact.
In the third step, the truth tables are analysed via counterfactual analysis. This approach is based on Boolean algebra in general and applies the Quine-McCluskey algorithm. This algorithm strips away factors which are not consistently present concerning an outcome (Fiss 2011) to identify the conditions within a configuration which cause the outcome. Hence, the algorithm excludes conditions that are no essential part of a sufficient configuration for the respective outcome and produces two distinct solutions: the parsimonious solution and the intermediate solution. The parsimonious solution on the one hand draws on all simplifying assumptions derived from counterfactuals. It passes a more thorough reduction procedure, so that the data provides strong empirical evidence for the causality of these conditions. Therefore, the parsimonious solution encompasses the causal core of conditional variables. In contrast, the intermediate solution only includes simplifying assumptions based on easy counterfactuals (Ragin 2008). The conditional variables which appear in the intermediate solution but do not appear in the parsimonious solution thus represent the causal periphery of a configuration (Fiss 2011).
The results of the FsQCA reveal several patterns that explain how different configurations of app architecture and environmental hazards result in high or low levels of both risk likelihood and risk impact. I extracted these patterns by comparing structures of different configurations. Black circles indicate the presence of a condition, crossed-out circles indicate the absence of a condition, large circles indicate core condition, and small circles indicate peripheral conditions. Blank spaces indicate a condition may be either present or absent.
I identified seven different configurations that result in a high likelihood of risk. Consistency for configurations ranges from 0.90 to 0.99. Raw coverage, which describes the importance of a certain configuration in explaining the intended outcome, range from 0.26 to 0.46. The overall solution consistency shows these seven solutions can consistently result in high likelihood of risk with 89 %. The overall solution coverage indicates that the extent to which these seven configurations cover high likelihood of risk cases is 76 %. I compared the seven configurations of my analysis to extract two strong patterns:
Pattern (1): In platform ecosystems with a high level of market uncertainty software startups are very likely to perceive a high likelihood of risk in third-party innovation (2a&b; 3a&b), which can be explained by the increased likelihood for market disruption or instability of the software startup´s niche.
Pattern (2): If the interfaces are not standardized and market uncertainty is high (3a&b), especially with lack of app decoupling as peripheral condition, the likelihood of risk for software startups is high as changing market conditions might increase the need for adaptions in the application. However, if apps are not modularized, software startups are not able to improve the application fast and independently. Therefore, lack of modularization reduces the flexibility to react to changes within the market environment.
Furthermore, I identified seven different configurations that result in a high impact of risk that exceed minimum consistency threshold. These seven solutions consistently result in high risk impact with 89 % and cover 81 % of cases with this outcome. Comparing the seven configurations reveals two further important patterns:
Pattern (3): The impact of software startup´s risk in third-party innovation is high when the environment is volatile. Market uncertainty (2a, b, c; 4a & b) and technological uncertainty (1; 4a&b) are the main hazards to result in a high impact of risk.
Pattern (4): The interplay of high interface standardization and low app decoupling (3) represents the second pattern to create a high impact of risk. This can be explained as high standardization requires high investment of the software startup to adhere platform-specific interface standards while a lack of decoupling reduces flexibility and increases the threat of cascading ripple effects that might disrupt its interoperability with the platform.
I compared the sets of causal conditions of low risk with the configurations that lead to high risk to detect relevant differences. Consequently, I identified six configurations that result in a low likelihood of risk.
These solutions consistently result in a low likelihood of risk with 91 % and cover 72 % of cases with this outcome. Comparing the six sets of causal conditions I extracted three further patterns:
Pattern (5): If behavioural uncertainty is missing, software startups perceive a low likelihood of risk (1a&b; 2a&b), although technological uncertainty is high (1a&b). This shows that software startups that can monitor the behaviour of the platform owner face a lower likelihood of risk as they reduce the space for opportunism.
Pattern (6): Configurations of market uncertainty in presence with an absence of technological uncertainty account for low risk likelihood (3a&b) if the company does not draw on app decoupling. This fact can be explained as technological stability allows the software startup to reduce risk by offering ability to react to changes in the market quickly. Under these circumstances app decoupling does not offer additional benefits.
Pattern (7): Likelihood of third-party innovation risk is low when interfaces are highly standardized (2a&b), which reflects the role of interfaces to standardize rules that apps ought to obey and can expect the platform to obey. This underlines the role of app architecture as a control mechanism for risk.
By analysing cases for a low impact of risk, I uncovered six different configurations that result in a low impact of risk. These solutions consistently result in that outcome with 90 % and cover 83 % of cases with a low level of risk impact. By comparing these configurations for low risk impact, I found two final patterns:
Pattern (8): Surprisingly, the specificity of a platform is not a main driver of risk impact but its missing predicts low impact of potential losses (1; 3a&b; 4). From this finding I can derive that software startups do not perceive failure to have a high impact on them when they did not heavily invest in knowledge and other resources that are idiosyncratic for this certain platform or app migration to another platform can be easily achieved.
Pattern (9): If uncertainty in the ecosystem is low, software startups face a low level of risk impact. Especially, when behavioural and technological uncertainty are missing (2; 4; 5). This shows the interplay of a reduced space for opportunism and the stability of the platform in reducing risk.
From the nine pattern that I identified in the comparison of configurations that lead to high and low risk, I can reveal holistic insights of the drivers of third-party innovation risk and the role of app architecture as a control mechanism. Based on the commonalities among the patterns, I identified three holistic findings to explain the risk of third-party innovation and its management.
First, uncertainty of the platform owner´s behaviour as well as the specificity of a platform, are no main drivers of software startup´s risk. Instead configurations in which both are absent display a low impact and likelihood of risk during digital innovation. Hence, while environmental hazards are needed to turn specific assets and opportunistic partners into considerable drivers of risk, engaging with reliable partners or acting on platform with low asset specificity might at least partially mitigate the impact of environmental hazards.
Second, market and technological uncertainty are the main drivers of risk in digital innovation. Unstable market conditions and technological volatility are crucially influencing the impact and likelihood of risk during third-party innovation.
Third, application architecture represents not a direct control mechanism to govern the platform dependencies during digital innovation. Standardization of interfaces might represent a necessary condition to achieve a low level of risk under certain circumstances. Consequently, the use of standardized interfaces is required to minimize risk. However, if apps are highly modularized, this does not necessarily imply low levels of risk, but the effect depends on the environment.
By comparing different configurations that result in high and low risk, I identified nine patterns that describe the role of environmental hazards and app architecture in shaping risk. From these patterns I derive the role of technological and market uncertainty as core drivers of risk. Furthermore, my findings reveal that behavioural uncertainty and platform specificity are not drivers of risk per se. However, their absence is required to achieve low levels of risk. In addition, I detect the role of app architecture as a control mechanism for third-party innovation. As the absence of app modularity is always implying a high level of risk, it is a necessary condition for minimizing risk.
Therefore, the contribution of my study is threefold. First, it contributes to research of risk in IS by applying a configurational perspective on the new organizing logic of digital innovation and providing evidence for the equifinality of different paths in reducing risk. Second, my research contributes to past work on platform dynamics (Ceccagnoli et al. 2012) and intra-platform management (Tiwana 2015a,b) by uncovering the interplay of environmental factors and technological architecture in achieving organizational outcomes. Third, I contribute to previous studies on modularity as interorganizational control mechanism (Tiwana 2008; Tiwana et al. 2013) by revealing app modularization as necessary condition to minimize risk.
From a practical point of view, my results show that app developers should use app decoupling and standardized interfaces to reduce risk in uncertain environments.
See references
Original paper published at HICSS2017
Identify your use-case
Experience next-generation decisions
Get value from day one
In this 5-minute demo, you’ll learn how vencortex® DeOS can help your team achieve better decisions, faster.
Watch demo
