Fostering Value Creation with Digital Platforms A UnifiedTh.docx

Fostering Value Creation with Digital Platforms: A Unified
Theory of the Application Programming Interface Design
Jochen Wulf and Ivo Blohm
Institute of Information Management, University of St.Gallen,
St. Gallen, Switzerland
ABSTRACT
While many firms in recent years have started to offer public
Application
Programming Interfaces (APIs), firms struggle with shaping
digital plat-
form strategies that align API design with aspired business
goals and the
demands of external developers. We address the lack of theory
that
explains the performance impacts of three API archetypes
(professional,
mediation, and open asset services). We couple survey data
from 152
API product managers with manually coded API design
classifications.
With this data, we conduct cluster and regression analyses that
reveal
moderating effects of two value creation strategies (economies
of scope
in production and innovation) on the relationships between API
arche-
type similarity and two API performance outcomes: return on
invest-
ment and diffusion. We contribute to IS literature by developing
a unifying theory that consolidates different theoretical

perspectives
on API design, by extending current knowledge on the
performance
effects of API design, and by empirically studying the distinct
circum-
stances under which digital platforms facilitate economies of
scope in
production or in innovation. Our results provide practical
implications
on how API providers can align API archetype choice with the
value
creation strategy and the API’s business objective.
KEYWORDS
Application programming
interface; boundary
resource; digital platform;
economies of scope; cluster
analysis; API design
Introduction
The growing number of publicly available Application
Programming Interfaces (APIs)
suggests that offering APIs today has become a common
instrument of digital strategy
[85]. The API directory ProgrammableWeb reported over 22,500
registered APIs in
October 2019 and a five-year consecutive growth rate of over 10
percent [85]. By now,
successfully designed and managed APIs outperform traditional
modes of service distri-
bution (such as e-commerce websites) at well-known digital
service providers such as
Expedia, eBay, and Salesforce [51, 73].

The majority of API providers, however, struggles with
designing successful APIs,
because a solid technical solution does not suffice; rather, the
API must align with the
overall business objectives and the demands of third-party
developers and end customers
[11]. Considering that APIs transform entire industries by
enabling agile service develop-
ment, specialization, scalability, and leveraging network effects
[73], many firms overlook
the APIs’ significance for their strategic competitiveness [51].
The misalignment of an
API’s design and its provider’s business objectives may be the
consequence. For example,
CONTACT Jochen Wulf [email protected] Institute of
Information Management, University of St.Gallen
Mueller Friedberg Strasse 8, St. Gallen 9000, Switzerland
Supplemental data for this article can be accessed on the
publisher’s website.
JOURNAL OF MANAGEMENT INFORMATION SYSTEMS
2020, VOL. 37, NO. 1, 251–281
https://doi.org/10.1080/07421222.2019.1705514
© 2020 Taylor & Francis Group, LLC
http://orcid.org/0000-0001-5553-8850
http://orcid.org/0000-0003-2422-5952
http://website
https://crossmark.crossref.org/dialog/?doi=10.1080/07421222.2
019.1705514&domain=pdf&date_stamp=2020-02-19
a lot of API providers adopt transaction-based pricing models

[12]. However, establishing
two-sided platforms by means of an API and attracting third-
party developers requires
paying out commissions to developers for each transaction as
the case of Walgreen’s Photo
Prints API demonstrates [3]. Furthermore, many API initiatives
fail because of insufficient
knowledge about the targeted segment of third-party developers
[12]. Hence, APIs provide
insufficient incentives for these developers or fail to align the
API provider’s business
interests with those of developers [3]. Lastly, focusing on APIs
as a single channel for
distributing software solutions may impose high implementation
effort on software
adopters [58]. Owing to these challenges, API providers require
knowledge that supports
the alignment of API design, their business goals, and the
objectives of third-party
developers.
The literature on digital platforms broadly considers APIs as
boundary resources
through which platform providers execute choices of platform
architecture and govern-
ance [22, 38, 99-101]. Our literature synthesis yields three API
archetypes with character-
istic differences regarding the design of a platform’s
partitioning, systems integration,
decision rights, control, and pricing. Professional services
provide access to cloud-based
information technology (IT) resources, which providers
traditionally distribute as install-
able software or make accessible via browser-based interfaces
[7, 61, 106]. Mediation
services offer access to a two-sided platform’s resources based

on which third-party
developers design complementary service offerings for the
platform’s end customers [75,
79, 94]. Open asset services give free-of-charge access to
organization-internal IT resources
with low integration effort [48, 56, 64, 84].
We survey 152 API providers and investigate the interaction
effects of API design and
two value creation strategies — economies of scope in
production and innovation — on
API return on investment (ROI) and diffusion. We apply
qualitative content analysis to
these APIs in order to reveal API design choices that may
influence API performance.
Applying cluster analysis, we verify the theoretically derived
typology of professional,
mediation, and open asset services. We show that one can
distinguish these services by
distinct API design characteristics. Furthermore, we conduct
ordinal logistic and negative
binomial regression analyses and show that API providers that
align their APIs’ design
with the intended platform-based value creation mechanism
exhibit higher levels of API
ROI and diffusion. Specifically, we find that API providers that
follow the archetypical
designs of professional or mediation services and that target
economies of scope in
production have higher levels of API ROI than others. API
providers that choose an
open asset services design and target economies of scope in
innovation exhibit higher
levels of API diffusion than others.
Our research contributes to closing three research gaps in the

digital platforms litera-
ture. First, prior literature on API design is scattered and
studies API design in disparate
and isolated contexts. One group of authors considers APIs as
distribution channels for
cloud-based professional services [7, 25, 41, 106]. A second
group studies APIs as
boundary resources to multi-sided platforms [27, 37, 38, 75,
79]. A third group analyzes
APIs in the context of open data [48, 56, 64, 84]. Considering
the strategic role of APIs for
platform providers [9] and that this disparate literature
insufficiently explains how the
breadth of possible API design choices relating to platform
architecture and governance
affects strategic API outcomes, Yoo et al. [108] call for a
generalizable theory that explains
API design choices and strategic consequences. Addressing this
call, we provide a unifying
252 J. WULF AND I. BLOHM
perspective on the design of three API archetypes that explains
API design and strategic
API outcomes across these distinct literature streams. It is
grounded in contemporary
literature on platform architecture and governance [99, 100] and
synthesizes prior API
literature.
Second, prior API research does not study the design and
outcomes of individual APIs
but looks at an aggregate level at the set of APIs offered by a
firm [9] and by a platform [8,

93, 101, 107]. These studies only allow limited implications on
the design and perfor-
mance effects at the level of individual APIs. They focus on a
firm’s or platform’s general
use of potentially multiple APIs and do not establish a direct
relationship between the
design of individual APIs and API performance. By choosing
the API as unit of analysis,
we provide novel theory regarding the distinct consequences of
API-level design choices
on API performance in terms of API ROI and diffusion.
Third, prior literature provides disconnected theories of how
platforms facilitate value
creation in platform-based ecosystems [36]. Some authors
theorize on platform-based
economies of scope in production [55, 71]. Other authors focus
on economies of scope in
innovation [1, 74]. An integrating theory that explains how
APIs facilitate either or both
value creation mechanisms is currently missing. Adopting a
conceptualization that “sees
platforms through an organizational lens” [36, p. 1240], we
integrate these two perspec-
tives and study simultaneously how APIs facilitate economies of
scope in production and
innovation.
In summary, our research addresses the lack of theory that
interrelates different API
design choices, platform-based value creation mechanisms, and
API-level performance.
We develop a theoretical model that proposes how the
interaction of API design with
a platform provider’s targeted value creation mechanism affects
an API’s ROI and diffu-

sion. This paper proceeds as follows. In the theoretical
foundations, we discuss prior
research on digital platforms and APIs. Subsequently, we
develop our hypotheses in the
theory development section. We then present our research
methodology and estimation
approach, followed by the results section. After a discussion of
the contributions, we end
with limitations and potential avenues for future research.
Theoretical Foundations
We define APIs as machine-readable interfaces that connect
multiple applications, govern
application interaction, and remove the need to know the inner
workings of how an API’s
functionality is provided [53]. While APIs may also regulate the
communication on local
machines, this study focuses on web services that provide
remote access over the Internet
[20]. We focus our analysis on the large API subgroup of public
APIs that are accessible
from outside of a company’s network [53, 85]. API providers
openly communicate the
specification of public APIs in order to promote APIs to the
community of third-party
developers. In the next subsections, we discuss how API design
relates to the architecture
and governance of digital platforms and prior research on API
archetypes.
Architecture and Governance of Digital Platforms
APIs represent boundary resources of digital platforms [22, 38].
Boundary resources are
software tools that transfer design capability to developers

[103] and allow platform
253
owners to control the ecosystem that is formed by third-party
developers [38]. Hence,
boundary resources are regulations that control the arm’s-length
relationship between
a platform owner and application developers [38]. From a
technological perspective,
digital platforms consist of an extensible codebase for a core
functionality that is shared
by connected modules and interfaces such as APIs. Modules are
software subsystems, that
is, applications that third-party developers provide and that add
functionality to the
platform. APIs support the interoperation between platform core
and modules [99].
One can distinguish platforms by design choices related to
platform architecture and
governance [99-101], which are executed through boundary
resources such as APIs [22,
38, 86]. The information systems literature discusses several
aspects related to API design
(API characteristics) that have an impact on platform
architecture and governance, which
we summarize in Table 1 and discuss in the following.
Architecture has two main functions: (1) partitioning and (2)
systems integration [100].
Partitioning refers to how platform-based functions are
decomposed into relatively

autonomous subsystems (i.e., modules). A trait of partitioning is
platform span (i.e., the
number of modules that is determined by the level of functional
disaggregation) [90]. The
scope of functionalities that a platform owner exposes via APIs
is characteristic for the
platform [8]. The API literature distinguishes between
decomposition at the architectural
level of application functionality or even finer disaggregation at
the level of data or
infrastructure access [108]. Accordingly, API functionality
refers to providing complex
information processing capabilities [107], that is, executing
business processes [110], in
contrast to making accessible lower-level resources, that is,
data- and infrastructure-as
-a-service [25, 46]. Partitioning not only applies to an API’s
level of functional disaggrega-
tion, but also relates to the distribution of end customer-
oriented functionality. APIs can
be designed as a distribution channel that connects third-party
developers with an API
provider’s end customers [92]. APIs then provide end customer
access that allows devel-
opers to exploit platform-based marketing resources [87] and to
offer value-added services
to the platform’s installed end customer base [60].
Systems integration refers to how a platform provider
interconnects with external
developers. It is common to extend a software product by
offering an API as an alternative
Table 1. API characteristics, definitions, and guiding
references.
Platform

component API element Definition
Guiding
references
Partitioning Function API carries out information processing
task [8, 107, 108]
End customer access API links developers to end customers [60,
87, 99]
Systems
integration
Multi-channel access Functionality or data is accessible through
alternative
channels
[61, 76]
Security API supports data encryption (e.g., https) [42, 63]
Decision rights End customer
relationship
API maintains own relationship with end customers [9, 37, 99]
Control User authorization API supports user authentication
(e.g., key or token
based)
[42, 64]
Pricing Subscription-based
charging
API users are charged by subscription-oriented logic [61, 76,
110]

Transaction-based
charging
API users are charged by transaction-oriented logic [61, 76,
110]
Revenue sharing API provider shares revenues with developers
[54, 77, 79]
Notes: API = Application Programming Interface
access channel [76], because offering APIs facilitates the
integration into customers’
systems landscapes [61]. We refer to such an API access to
services that providers
complementarily distribute as software products or via websites
as multi-channel access.
Furthermore, APIs can allow secure communication by using
message encryption stan-
dards [42]. Security risks (e.g., data leakage) are among the
most important barriers for
adopting professional services [63]. The API trait security thus
characterizes an API
provider’s investments into function assurance by implementing
encryption mechanisms.
Platform governance addresses (1) the allocation of decision
rights, (2) the execution of
control, and (3) a platform’s pricing policies [100].
The decision right to maintain the end customer relationship is a

strategic component
[92]. A platform owner can either keep this right or leave this to
the external developer.
API providers that keep the end customer relationship can steer
API developers towards
implementing services that are complementary to the API
providers’ end customer-facing
offerings [9]. APIs then position third-party modules to fill
holes in the API provider’s
product line [37] or to innovate value-adding functionality to an
API providers’ plat-
form [99].
Regarding the execution of platform control, the process of
granting permission for an
activity represents a functional component in API specifications
[42]. Since APIs allow
access to proprietary resources, API providers must protect their
strategic assets and — at
the same time — encourage developer innovation [99].
Authorization allows API provi-
ders to execute control [9]. Alternatively, API providers may go
without authorization in
order to decrease adoption barriers (e.g., in the case of open
data) [64].
API providers execute platform pricing via two API features.
APIs can serve as a direct
source of revenue via charging [110]. Charging strategies may
include transaction-based
and subscription-based charges [76]. Alternatively, providers
may offer API access free-of-
charge and aim at non-monetary benefits [29]. Furthermore, API
providers can use
revenue sharing to attract API developers with the goal to
enrich an API provider’s

product offerings [54]. For example, the appropriation of value
between providers and
developers through revenue sharing represents a key success
factor for offering a wide
portfolio of services in mobile ecosystems [77, 79].
Typology of Public APIs
A synthesis of API literature (see Supplemental Appendix A)
suggests that API providers
offer three distinct services and that each of these API
archetypes incorporates distinct
API characteristics related to the design of API architecture and
governance. We define
these archetypes in Table 2.
Professional Services
Professional services offer infrastructure-, platform-, data-, or
software-as-a-service. Via
standardized interfaces, they facilitate the consumption of the
API provider’s modularized
offerings [7, 106]. For example, mobile network operators offer
APIs that provide paid
access to the telecommunication network’s functionalities such
as telephony [41].
Professional services represent alternative channels to browser-
based or off-the-shelve
software offerings. For example, with the Cloud Datastore
service, Google offers data-as
-a-service via a browser-based editor and, alternatively, via the
Cloud Datastore API [25].
255

Professional service providers generate direct revenue streams
by charging for API con-
sumption [29, 61, 76].
Mediation Services
Mediation services expose platform resources to third-party
developers, upon which third-
party developers innovate end customer-facing services that are
complementary to the
platform’s end customer-oriented offerings [94]. Mediation
services provide, among
others, business development, marketing, and resource bundling
[87]. Providers of media-
tion services offer incentives in order to subsidize third-party
innovation. The Android
API, for example, includes free API access to Google’s Android
platform and is supple-
mented with revenue-sharing mechanisms via the Google Play
store [79].
Open Asset Services
Open asset services provide free-of-charge access to proprietary
IT assets of a company
[35, 48, 56]. Such offerings include open access to data [48,
64], to infrastructure, or to
applications [35]. While researchers usually discuss open asset
services in non-commercial
contexts [56, 65], profit-oriented companies may equally offer
such services [48]. Open
asset services encourage a provider’s interaction with the
external developer community
[65]. This is because offering free access to company-internal
assets, removing technolo-
gical access barriers such as user authentication restrictions,
and providing generative and

easy-to-integrate IT resources lowers the adoption barriers for
external developers [84].
Furthermore, the use of standardized interfaces and well-
defined governance approaches
establishes trust between the API provider and external
developers [35]. The Github API,
for example, offers free programmatical access to the version
control system’s function-
alities such as forking projects, sending pull requests, and
monitoring development [72].
Theory Development
We adopt Gawer’s [36] organization-centric conceptualization
of digital platforms as
meta-organizations. This conceptualization emphasizes a
technological platform’s capacity
to host inter-organizational service ecosystems [79]. In such
platform-based ecosystems,
Table 2. API archetypes.
Archetype Definition Sources Examples
Professional
service
API provides access to cloud-based IT
resources with direct or indirect charging
that providers traditionally distribute as
installable software or make accessible
via browser-based interfaces.
[7, 29, 47, 61, 76,
106]
Amazon S3 API, SAP Anywhere API,

Google Maps API, AccuWeather Forecast
API, FedEx API, Expedia API
Mediation
service
API offers access to a two-sided
platform’s resources based on which
third-party developers design
complementary service offerings for the
platform’s end customers.
[75, 79, 80, 87, 94] Facebook Graph API, Twitter Direct
Message API, Youtube Live Streaming
API, Amazon Product Advertising API,
LinkedIn API
Open asset
service
API gives free-of-charge access to
organization-internal IT resources with
low integration effort.
[35, 48, 56, 64, 84] New York Times API, DB Open Data API,
BBC Nitro API, NBA Stats API, Github API
value-adding activities of resource integration are provided by
multiple actors and custo-
mers [66]. We distinguish two mechanisms of value creation in

digital platforms discussed
by Gawer [36] that are rooted in cost reductions owing to the
joint value creation of
platform participants in comparison to creating value
separately: economies of scope in
production and in innovation. We propose that value creation
mechanisms in digital
platforms and API design are interlinked, that is, we assume
that distinct API archetypes
fit different value creation mechanisms and target varying
objectives. We depict the
research model in Figure 1.
API Return on Investment, Diffusion, and Value Creation
Mechanisms
API providers may follow two different objectives by offering
APIs that are related to two
major types of business objectives, value generation, and value
appropriation [69]. They
may aim at achieving a positive ROI by creating revenue
streams (relating to value
appropriation) and at reaching a high API diffusion level, which
may stimulate innovation
(relating to value generation) [38, 86]. ROI is commonly used
to assess a new product’s
performance [50]. Return on API investment describes the ratio
between net profit and
costs resulting from investing in API development and
operations. Many APIs directly
target a positive ROI by charging for API consumption [61, 76]
or by generating indirect
revenue streams through an increased attractiveness of a core
product [47]. The diffusion
of a service generally includes awareness and adoption among
potential customers [88].

API awareness characterizes the extent to which external
developers gain information
about the API and its attributes. Adoption entails the usage of
an API by third-party
developers. API diffusion provides non-monetary benefits to
API providers [29] and
enhances the provider’s internal innovation capacities [16].
According to the contingency perspective of organizational
strategy, there is no uni-
versally superior strategy, irrespective of the environmental or
organizational context
[102]. Companies must, therefore, align their internally oriented
resource development
with their externally oriented strategy [40]. We follow this
notion and argue that
Figure 1. Research model.
257
a provider’s internal design of boundary resources (specifically
API design) must match its
externally oriented ecosystem positioning (specifically the
targeted mechanisms of inter-
organizational value creation) in order to achieve positive
outcomes. Inter-organizational
value creation in platform-based ecosystems has its roots in
different economies of scope
[36], which we refer to as value creation mechanisms. In the
following, we develop a fit-as-
moderation perspective by conceptualizing the match between
internal resources and the

externally oriented strategy in a moderation model [102]. The
fit-as-moderation approach
suggests that the interaction between the predictor and the
moderator “is the primary
determinant of the criterion variable.“ [102, p. 424].
Specifically, we propose that the
interaction of an API’s similarity to archetypical API designs
and the levels to which API
providers target value creation mechanisms affects API ROI and
diffusion. Table 3
provides an overview of the constructs and definitions of our
research model.
Economies of Scope in Production
Economies of scope in production is a phenomenon in which the
joint production of
a product is less costly than producing the intermediate and the
end product separately
[78]. If two successive value creation stages are interlinked,
vertically integrating these
stages may allow for jointly optimized production [21, 34].
Targeting economies of scope in production owing to vertical
integration leverages an
API’s ROI for the professional service archetype, because
professional services aim at
facilitating the integration of the service provider’s offerings
into the API developers’
applications [7, 106]. The modularization of IT infrastructure
allows for reusing IT assets
in a flexible manner [70] in inter-organizational service
relationships, which is particularly
valuable for service customers with highly customized and
complex application landscapes
[106]. The use of standardized interfaces facilitates the service

integration in the course of
customer’s application development projects, because software
developers require less
effort to familiarize with the service’s functionality and syntax
[63]. The professional
service’s flexibility and integrability ultimately increase the
attractiveness of a service
provider’s offerings. By creating novel revenue streams via
direct or indirect charging
mechanisms, while requiring relatively low investments,
professional services implement
a value appropriation mechanism and thus directly contribute to
an API’s ROI. An
exemplary professional service is Salesforce’s Analytics API.
Salesforce traditionally is
Table 3. Constructs and definitions.
Construct Definition Sources
Return on investment The API’s return on investment relative to
the company’s original
objectives for the API.
[18, 68]
Diffusion Level of API awareness and adoption among third-
party developers. [88]
Target level of value creation
mechanism
Level to which an API provider targets a mechanism of inter-
organizational value creation in a platform-based ecosystem.
[36]
Target level

of …
… economies of
scope in production
The joint production of successive value creation stages is less
costly
than producing separately if they are tightly interlinked.
[21, 78]
… economies of
scope in innovation
Jointly innovating on two products is cheaper than independent
innovations on these two products.
[14, 74]
Similarity to API archetype Three measures that represent the
similarity to the “average
representative” of the three archetypes of API design
(professional
service, mediation service, and open asset service)
[35, 74,
79]
a browser-based software-as-a-service provider for CRM
solutions. Salesforce’s Analytics

API allows programmatic access to analytics features such as
datasets and dashboards [2].
This API offers easy integrability into customer application
landscapes and clearly com-
municated service-level agreements. It is bound to a
subscription of Salesforce’s cloud
product.
In contrast to open asset services, that are offered free-of-
charge and focus on value
generation by spurring innovation via diffusion in the open
development community [48],
professional services include charging mechanisms and do not
target wide accessibility
among the external developer community (i.e., API diffusion).
From the aforementioned
argumentation, we conclude that there is a fit between an API’s
similarity to the profes-
sional service archetype and the target level of economies of
scope in production with
respect to achieving API ROI.
Hypothesis 1: The interaction of an API’s similarity to the
professional service archetype and the
target level of economies of scope in production is positively
related to API return on
investment.
Targeting economies of scope in production owing to vertical
integration may further
leverage API ROI for the mediation service archetype because
this archetype is geared towards
facilitating the integration of business development and
marketing resources into third-party
developers’ applications [87]. Platform providers, by offering
mediation services, aim to generate

novel or increased revenue streams with relatively low
additional investments and thus target an
increased ROI [80]. Mediation services are frequently provided
to third-party developers free-of
-charge, but with the goal to generate end customer revenues
[94]. Compared to alternative
boundary resources (such as browser-based user interfaces) that
platform providers frequently
offer [38], API-based mediation services allow easy
integrability into third-party applications
and thus increase a platform’s overall attractiveness to
application developers. This, in combina-
tion with a platform’s value appropriation mechanisms, such as
collecting end customer fees or
charges for targeted advertising, results in an increased ROI.
Dropbox, for example, offers the
Dropbox API which exposes standardized file management
capabilities to third parties. Service
providers, such as streamboxr, integrate with Dropbox’s API
and thus free end customers from
having to conduct file integration manually [19]. Third-party
developers contribute to improv-
ing Dropbox’s end customer-facing offerings. Higher end
customer revenues lead to an
increased ROI of the Dropbox API [23]. Consequently, we
conclude that there is a fit between
an API’s similarity to the mediation service archetype and the
target level of economies of scope
in production with respect to achieving API ROI.
mediation service archetype and the
target level of economies of scope in production is positively
related to API return on
investment.

Economies of Scope in Innovation
Economies of scope in innovation occur when jointly innovating
on two products is
cheaper than developing independent innovations on these two
products [36, 74].
Innovating firms share IT resources in the presence of
innovational complementarities
that emerge in business-to-business relationships when a firm’s
innovation increases the
productivity of customers’ research and development
investments [14].
259
Targeting economies of scope in innovation leverages the
diffusion of open asset
services because open asset services are geared towards
stimulating generativity by provid-
ing free-of-charge access to core platform modules [38].
Generativity refers to the “capa-
city to produce unprompted change driven by large, varied, and
uncoordinated audiences”
[111, p. 1980]. Modularity spurs third parties’ innovativeness
through experimentation
[38, 74, 93]. Providing open asset services attracts external
innovators, because of the low
financial cost and developmental effort that innovators require
to establish and maintain
interoperability [56, 101]. The open asset service’s generativity
and modularity ultimately
lead to API diffusion. Open asset services, in contrast to
professional services, do not

target ROI, because they focus on exploring novel modes of
value generation through
involving third-party developers rather than on value
appropriation [16]. The New York
Times Article Search API, for example, allows free search of
articles from 1981 to today
and returns headlines, abstracts, lead paragraphs, links to
associated multimedia, and
other article metadata [98]. This API, by attracting large
interest in the open development
community, has led to the development of diverse mashups,
which may also stimulate
innovations in the New York Times’ offerings. Hence, we
conclude that there is a fit
between an API’s similarity to the open asset service archetype
and the target level of
economies of scope in innovation with respect to achieving API
diffusion.
Hypothesis 3: The interaction of an API’s similarity to the open
asset service archetype and the
target level of economies of scope in innovation is positively
related to API diffusion.
Targeting economies of scope in innovation may leverage API
diffusion for media-
tion services because these services are geared towards
facilitating open access to
resources that link external developers to the platform’s end
customers [87].
Exposing platform resources through mediation services may
trigger third-party devel-
oper innovations of end customer-facing services that go beyond
the API provider’s
scope of imagination [24, 79, 96]. Platform providers, by
offering mediation services,

leverage economies of scope in innovation to broaden the scope
of functionality
offered by the platform [39]. Mediation services, to incentivize
API diffusion, may
involve the distribution of end customer revenues among the
platform and third-party
developers via revenue sharing mechanisms [80]. Innovating
novel value propositions
is important for attracting user crowds independent of the
simultaneous implementa-
tion of value appropriation mechanisms [16]. Platforms may
even focus on diffusion
prior to implementing value appropriation mechanisms in later
stages, because appro-
priating value may conflict attracting platform users [52]. The
YouTube Data API, for
example, is a mediation service that allows content providers to
freely upload, update,
and delete videos on the end-customer-facing YouTube
platform. With this API,
YouTube focused on attracting a large mass of content
providers in an initial stage
of the YouTube platform’s lifecycle and added value capture
mechanisms (such as
targeted advertising) in a later stage [16]. Thus, we conclude
that there is a fit between
an API’s similarity to the mediation service archetype and the
target level of economies
of scope in innovation with respect to achieving API diffusion.
mediation service archetype and the
target level of economies of scope in innovation is positively
related to API diffusion.

Research Methodology and Estimation Approach
We triangulate quantitative and qualitative data collection and
analysis methods in order
to investigate the interrelated effects of API design and targeted
economies of scope on
API ROI and diffusion across professional, mediation, and open
asset services. First, we
surveyed product managers at API providers that are listed in
the Internet’s most
complete public API directory ProgrammableWeb [29, 85, 109]
in order to collect data
on the API providers’ targeted value creation mechanisms as
well as on API ROI. Second,
we collected secondary data regarding the actual diffusion of
these APIs among devel-
opers. Third, we applied qualitative content analysis to the
documentations of APIs on
which we gathered survey and secondary data. This analysis
allowed us to collect data on
the specific API designs that API providers have implemented.
In terms of data analysis,
we combine cluster and regression analyses. We first apply
cluster analysis to the data
from our content analysis in order to verify our typology of
theoretically derived API
archetypes and to develop a more fine-grained understanding of
their dominant design
characteristics. Second, we investigate the differential effects of
production and innovation on API diffusion and ROI for the
three archetypes of API
design by applying ordinal logistic and negative binomial

regression.
Data Sources and Variables
Survey Research: Value Creation Mechanisms, API Return on
Investment, and
Controls
We conducted a cross-sectional survey to collect complete
response data from 185 product
managers who represent different API providers. The survey
was online from May to July 2017
and targeted API product managers at for-profit API providers
that were responsible for the
design of the APIs, the strategies pursued with the APIs, and the
overall API operations. We
mailed the survey to 2950 organizations that were listed on
ProgrammableWeb. The response
rate of our survey was 6.17 percent, which is comparable to
similar studies that use non-
personalized mailings [91]. In order to motivate respondents to
participate, we provided access
to an API industry study that reported preliminary results of our
project. We sent two reminder
e-mails to improve response rates. We considered 152 responses
from for-profit API providers
for our study. Even though we explicitly targeted for-profit API
providers, we could not verify
profit orientation for the other responses in our qualitative API
analysis. In order to ensure
relevance and generalizability of our results, we targeted a
broad range of different industries.
The API providers mainly offered services in regard to IT &
Communication (41 percent),
Education & Science (14 percent), Marketing & Media (10
percent), Wholesale & Retail

(7 percent), or Leisure (5 percent). Most API providers resided
in the USA (38 percent),
Germany (12 percent), UK (9 percent), Switzerland (7 percent),
and France (5 percent).
We undertook various measures for mitigating the risk of
common method variance
that is related to our survey-based measurement of value
creation mechanisms and API
financial performance [81]. We provided a cover story for our
questionnaire to emphasize
that the independent and dependent variables are unconnected.
Second, we developed
simple structured questions and avoided ambiguous terms.
Finally, we explicitly pointed
out in our cover story that all answers would be anonymous and
we would not establish
261
a connection between answers and individuals. We checked the
extent of common
method variance by inspecting the correlation matrix (see
Supplemental Appendix D).
Common method bias is reflected by extremely high
correlations above 0.9 or below −0.9 .
However, in our study, the highest correlations among our
survey variables are −0.24 and
0.41. In sum, these procedural remedies and the results from our
correlation analysis give
no indication of potential threats resulting from common
method bias. We also checked
for non-response bias [4]. In addition, we checked for

differences in industries or
company sizes. We found no significant differences and our
data does not indicate non-
response bias. Supplemental Appendix B provides an overview
of the survey instrument.
As our study focuses on the API-level, we asked the repondents
to indicate the API
which they referred to in the survey. This information was then
used to collect qualitative
and secondary data about the APIs.
API Return on Investment. Whereas on the firm-level, ROI
measures are widely available,
our unique focus on the API level inhibits using objective
financial performance measures.
Thus, we followed a long history of measuring profitability of
new products in the new
product development literature. Following Cooper [18] and
McNally et al. [68], we used
a single-item measure for API ROI that captures the degree to
which an API’s ROI meets
the financial goals of the API provider. Such subjective
measures of financial performance
allow for a relative comparison of API’s financial performance
[68], because they avoid
problems in comparing actual values for different projects and
products [17] and allow to
account for the API provider’s specific organizational goals that
are associated with the
APIs [5]. Furthermore, such relative measures help to capture
the peculiarities of different
industries API providers operate in. Finally, subjective
measures have been found to
produce equally valid performance measurements in a variety of
contexts when being

compared against objective ones [26, 104].
According to Bergkvist and Rossiter [10], single-item
measurements have similar validity
as multi-item scales when the construct being measured is
doubly concrete in the mind of
the respondent. This means that both the object of the study
(i.e., the respondent’s API
provider) as well as its attribute (i.e., its financial performance)
are concrete such that they
can be easily and uniformly imagined [83]. By contrast,
constructs consisting of formed or
abstract objects (e.g., all API providers in a given industry) and
attributes (e.g., service
quality or market orientation) would require a multi-item
measurement. As our measure of
API ROI reflects an overall assessment of financial
performance, it can be considered as
being concrete [83]. The same is true for the respondents’ API
provider. Thus, we consider
our subjective single-item measure as being valid for our
purpose.
Value Creation Mechanisms. Owing to the lack of survey-based
measurements of
Gawer’s [36] platform value creation mechanisms, we introduce
self-developed measure-
ments that capture the extends to which economies of scale in
production and innova-
tion describe a company’s API strategy. The measure for
production comprises three five-level Likert items that
characterize the level to which
an API facilitates the flexible integration, adaptation, and deep
integration of IT
resources. The items are inspired by D’Aveni and Ravenscraft

[21], Garcia et al. [34],
and Gawer [36]. The instrument for economies of scope in
innovation consists of three
items that describe the extent to which APIs allow to tap the
inventive capacities of the
external developer community, to exploit the creative potential
of external developers,
and to enhance an API provider’s innovation capabilities. This
instrument is informed
by Bresnahan and Trajtenberg [14], Gawer [36], and Nambisan
and Sawhney [74].
Controls. We included two API-level controls. We proxied the
API’s quality of imple-
mentation by capturing the functional quality and service
innovativeness of the API.
Functional quality captures the degree to which an API offers
unique features compared
to, is clearly superior to, and is of higher quality than
competing APIs [97]. Service
innovativeness captures the degree to which an API is
innovative in the specific industry
of the API provider [30]. The API provider-level control
number of employees accounts for
organizations of different size, as an API might be more central
for the overall business
model of smaller organizations than larger organizations. We
further included two
respondent-level controls. The respondent’s years with the API
provider and affiliation
may potentially bias response behavior [81].

Content Analysis and Cluster Analysis: Similarity to API
Design Archetypes
Following a fit-as-moderation perspective, we propose that APIs
with different design
traits require distinct value creation strategies. While we
collected data on value creation
strategies by applying survey research, we followed a different
approach for investigating
API design. First, we applied content analysis to the API
websites and related information
in order to collect data on API’s specific design characteristics.
Then, we applied cluster
analysis to this data in order to reveal API design archetypes
and verify the three
theoretically derived API designs — professional, open asset,
and mediation services.
Finally, we measured the degree to which each API’s design
followed these archetypes
by measuring their similarity to these design archetypes.
API Designs Characteristics. In order to collect data on the
specific API designs, we
applied content analysis to the corresponding API websites, the
APIs’ technical doc-
umentation, as well as their terms of use. Based on the nine API
design characteristics in
Table 1, we developed a coding scheme that comprised
definitions of the API design
characteristics, respective binary indicators (for existence and
non-existence of an API
characteristic), and coding examples. Using this coding scheme,
we content analyzed all
152 APIs for which respondents returned a complete
questionnaire. In order to ensure
the reliability, two independent researchers coded all APIs.

Using a coding template, the
researchers had to provide evidence for why they have coded an
API design character-
istic in a certain way. The two researchers reached a Cohen’s
Kappa of 0.82, which
indicates excellent agreement [57]. Based on the coding
templates, the coders discussed
and resolved coding differences resulting in nine dichotomous
variables per API. These
variables indicate whether a certain API design characteristic
has been implemented by
an API provider or not (0 = no implementation, 1 =
implementation).
API Design Archetypes. We identify archetypes of API design
as cluster centroids by
applying cluster analysis to the nine dichotomous API design
characteristics. Cluster
analysis groups entities such that the in-group variation is small
in relation to inter-
group variation [67]. By defining distinctive variables (i.e., API
design characteristics),
cluster analysis groups entities (i.e., APIs) according to their
reciprocal similarities
263
describing natural groups [62]. In order to avoid idiosyncratic
errors specific to
a certain clustering technique, we used different cluster
algorithms applying distinct
distance metrics. As the primary goal of the cluster analysis was
to identify archetypes

of API design, we used four different partitioning clustering
approaches that create
cluster centroids (i.e., average representatives for each cluster)
that we conceptualize as
archetypes. We used Spherical K-Means using Cosine distance
[49], a numeric opti-
mization approach using Jaccard distance [62], as well as K-
Medians [62] and
Partitioning Around Medoids [82] using Hamming distance. The
idea of such algo-
rithms is to randomly assign entities to a pre-defined number of
clusters (k) and then
reassign entities iteratively to the centroids of these clusters.
All these clustering
approaches and distance measures are apt for dichotomous data.
Determining an
appropriate number of clusters, we used the Dunn-Index and
Average Silhouette
Values that measure the compactness of clusters while also
taking into account their
separation.
Similarity to API Design Archetypes. Finally, we measured the
similarity of each API to
the identified cluster centroids (i.e., API archetypes) for each
clustering algorithm: (1) We
determined the archetypical design for each cluster (i.e., the
average representative). (2)
We calculated the distance between each API and these
archetypical implementations
using the distance measures that were used for the clustering
(e.g., for the Spherical
K-Means clustering using Cosine distance, we used Cosine
distance). (3) We transformed
the obtained distance measures to similarity measures in order
to increase the interpret-

ability of our results. We scaled each distance measure by
dividing it by its maximum
value so that it ranges between 0 and 1. Then, we subtracted
these scaled distance
measures from 1.
Secondary Data: API Diffusion
We follow Setia et al. [88] who conceptualize diffusion of open
source software as
awareness and adoption among developers. We collected data on
API diffusion in three
major developer communities: Github, Stack Overflow, and
ProgrammableWeb. For adop-
tion, we collected the number of publicly available software
repositories that use the API
and that were uploaded by third-party developers on Github. For
measuring awareness,
we retrieved the number of API-related comments within Stack
Overflow as well as the
number of followers of a given API on ProgrammableWeb. All
these data were retrieved
using the search mechanism provided by these communities
using the API title and “API”
as search terms (e.g., “clickmeter API”) in December 2018.
These measures provide an
objective measure of API diffusion and are apt for dealing with
APIs in commercial and
non-commercial settings.
Results
Construct Validation
In order to confirm validity and reliability of our survey-based
measures, we applied explora-
tory and confirmatory factor analysis. The Measure of Sampling

Adequacy was 0.75, indicat-
ing good applicability of exploratory factor analysis. We used
the latent root criterion
(Eigenvalues >1) for extracting five factors that could be
clearly interpreted. Alphas of at least
0.79 suggest good reliability of factors. Composite Reliabilities
(CR) exceeded values of 0.5 and
the Average Variance Explained (AVE) for each factor
surpassed 0.5. Thus, convergent
validity could be assumed [6]. The discriminant validity was
checked by using the Fornell-
Larcker criterion, which claims that a factor’s AVE should be
higher than its squared
correlation with every other factor [32]. Thus, discriminant
validity could be assumed.
Construct validation results are shown in Supplemental
Appendix C.
Our three items measuring API diffusion represent count data.
Standard techniques to
factor analysis do not deal well with the discrete, non-negative
nature of count data and might
lead to biased results [105]. In order to extract an overarching
API diffusion measure, we
applied non-negative matrix factorization to our three API
diffusion items. Non-negative
matrix factorization is frequently applied to extract latent
factors from count data [59, 89]. We
followed Brunet et al. [15] and extracted one latent API
diffusion factor that accounted for
62.7 percent of the three original item’s variances. We

successfully validated the appropriate-
ness of extracting a single API diffusion factor following the
ideas of Frigyesi and Höglund
[33].1 We made sure that our results are robust regarding other
approaches to non-negative
matrix factorization algorithms. Supplemental Appendix D
depicts means, standard devia-
tions, minimum, and maximum values, as well as correlations of
our variables. In all
subsequent analyses, we used obtained factor scores as well as
z-standardized scores.
Validation of API Archetypes
Average Silhouette Values and Davies-Bouldin-Indices indicate
a robust three cluster solution
(see Supplemental Appendices E and F). Supplemental
Appendix G exhibits that all clustering
approaches produce similar results, that is, there is an average
agreement of 92.3 percent
between the different clusterings. This agreement is backed by a
contingency analysis. All χ2
tests are statistically significant (p < 0.01) and an average
Cramer V of 0.87 indicates a very
high correlation between the nominal clusterings. We report
results for the Spherical K-Means
clustering using Cosine distance only. Based on our theoretical
considerations, the imple-
mentation of API design characteristics reflects a conscious
design decision of an API
provider. Following this line of reasoning, Cosine distance is an
asymmetrical distance
measure and, thus, takes into account such conscious design
decisions only [31]. By contrast,
other applicable distance measures also take into account non-
implemented API design

characteristics for which we cannot infer conscious design.
After validating the cluster
structure, we report frequency distributions to characterize the
API clusters (see Table 4).
We calculate Cramer Vs to test whether or not the API design
characteristics significantly
differ across the three clusters. We analyze global differences
across all clusters and apply
posthoc tests, comparing single clusters. In order to ensure that
the analysis represents
a realistic picture of API design characteristics, the assignment
of APIs was manually verified
for plausibility. We report cluster centroids (i.e., the API
characteristics’ values for the three
archetypes) and archetypical examples in Table 5.
Professional Services. APIs in the professional services cluster
are characterized by a high
probability of offering sophisticated information processing
functionalities that go beyond
the simple provision of data and for which API providers
request transaction- and
subscription-based charges. User authorization and security
measures are also quite
strongly associated with this cluster. This cluster can be well
matched to the group of
265
professional services [7, 61, 106]. Choosing the professional
service archetype, API
providers create an API that enables their clients to integrate
the functionality of the

API provider’s offerings directly into the client’s existing
information systems and the
evolving business operations. These APIs are frequently built to
leverage an already
existing service or product of the API provider for which the
API usually represents an
alternative access channel. With a share of 67 percent, the
professional service cluster is
the biggest API cluster. As an archetypical example,
Salesforce’s Analytics API offers
programmatic access to analytics features [2].
Table 4. Implementation of API design characteristics by API
cluster as percentage.
API Design
Characteristic
Professional Services
(1)
Mediation Services
(2)
Open Asset Services
(3)
Cramer’s
V
Group
Comparisons
End Customer Access 0 66.67 4.35 0.76** 3-2**, 1-2**, 3-1
Multi-Channel Access 72.55 59.26 100 0.27** 3-2**, 1-2, 3-1**
End Customer
Relationship

0.98 66.67 0 0.76** 3-2**, 1-2**, 3-1
Function 92.16 88.89 0 0.79** 3-2**, 1-2, 3-1**
Subscription-based
Charge
97.06 11.11 0 0.91** 3-2, 1-2**, 3-1**
Transaction-based
Charge
96.08 7.41 4.35 0.9** 3-2, 1-2**, 3-1**
User Authorization 98.04 100 65.22 0.48** 3-2**, 1-2, 3-1**
Security 68.63 74.07 21.74 0.36** 3-2**, 1-2, 3-1**
Revenue.sharing 0 18.52 0 0.4 3-2, 1-2**, 3-1
N (percent) 67.10 17.76 15.13
Notes: **p < 0.01, * < 0.05; API= Application Programming
Interface
Table 5. API archetypes and archetypical examples.
API Design
Characteristic
Professional Service Mediation Service Open Asset Service
A
Salesforce Analytics
[2] A Dropbox [23] A New York Times Search [98]
Function 1 1: analytics functionality 1 1: file synchronization
and

storage functionality
0 0: retrieval of article data only
End customer
access
0 0: no marketing of third-
party apps to end
customers
1 1: marketing for apps that
integrate with Dropbox API
0 0: no marketing of third-party
apps to end customers
Multi-channel
access
1 1: alternative browser
interface
1 1: browser-based access and
desktop integration
1 1: browser-based access to
articles
Security 1 1: HTTPS encryption 1 1: HTTPS encryption 0 1i:
HTTPS encryption
End customer
relationship
0 0: salesforce has no end
customer relationship

1 1: third-party app customers
require a salesforce subscription
0 0: third-party app customers
don’t require NYT subscription
User
authorization
1 1: authentication model
(API Key, OAuth 2)
1 1: OAuth authentication 1 1: developer key required
Subscription-
based
charging
1 1: requires paid
salesforce subscription
0 0: API use does not require a
dropbox subscription
0 0: no charging
Transaction-
based
charging
1 0i: no charges per API
call
0 0: no charges per API call 0 0: no charging

Revenue
sharing
0 0: salesforce does not
share revenues
0 0: dropbox does not share end
customer revenues with app
developers
0 0: NYT does not share end
customer revenues with app
developers
Notes: API = Application Programming Interface; A
=Archetype; 1 = Implementation; 0 = No Implementation;
i = Nonconformance with archetype
Mediation Services. APIs in the second cluster are characterized
by providing developers
access to end customers; the provider of a mediation service,
however, entertains its own
direct relationship with these end customers. APIs in this
cluster most frequently engage
in revenue sharing approaches and make strong use of user
authorization. As for profes-
sional services, API providers offer a broad range of
functionalities that go beyond
infrastructure and data access. Given these characteristics, this
cluster matches well with
the mediation service [75, 79, 94]. Based on extant information
processing functionalities

that mediation services provide, API developers can develop
new service offerings for the
API providers’ end customers. This API cluster accounts for 18
percent in our sample.
The Dropbox API, as an archetypical mediation service, allows
app developers program-
matic access to file synchronization and storage functionalities
[23]. Dropbox provides
marketing for apps that integrate with the Dropbox API on its
website and requires app
customers to have their own Dropbox subscription.
Open Asset Services. APIs in the third cluster are characterized
by providing multi-
channel access to IT infrastructure or data resources, that is, the
API reflects an alternative
access option. API providers apply neither transaction-, nor
subscription-based charges.
Also, they offer no revenue sharing options. Further, they show
the lowest usage of user
authorization and security options. Given these traits, APIs in
this archetype match well
open asset services[48, 56, 64, 84]. With low access barriers
and their high versatility, such
APIs are intended to involve the general public in approaches to
open innovation. This
API cluster accounts for 15 percent of all surveyed API
providers. The New York Times
Article Search API is an archetypical open asset service that
offers free access to article data
and metadata that is also available via the New York Times
website [98].
Hypothesis Test
In order to test our hypothesis, we again present results that are

based on the Spherical
K-Means clustering only. However, results are very consistent
between the different
clustering approaches. API ROI reflects a single item that has
been measured with a five-
point Likert scale. Thus, API ROI can be best described as
being of ordinal nature such
that ordinal logistic regression is an appropriate modeling
choice [13, 43, 45]. Similarly,
we apply negative binomial regression in order to account for
the fact that the API
diffusion measure relies on count data.
We first test our API ROI hypotheses (Hypothesis 1 and
Hypothesis 2). Ordinal logistic
regression is a generalization of binary logistic regression and
can accommodate depen-
dent variables that consist of more than two ordinal levels by
applying a cumulative logit
model. A central pre-requisite of ordinal logistic regression is
the proportional odds (also
known as parallel regression) assumption that claims that the
relationship between each
pair of outcome categories of the dependent variable is the same
[43]. We applied Brant’s
[13] test in order to test this assumption. We yielded non-
significant test statistics
indicating that proportional odds can be assumed. We estimated
the following regression:
Model 1: Pr API ROI � jjXð Þ ¼ 11þexp �αjþXβ½ � with
267

Xβ ¼ α þ β1Economies of Scope in Production þ β2Similarity
Mediation Archetype
þ β3Similarity Professional Service Archetype
þ β4Economies of Scope in Production x Similarity Mediation
Archetype
þ β5Economies of Scope in Production x Similarity Professional
Service Archetype
þ β6Functional Quality þ β7Service Innovativeness þ
β8Employees API Provider
þ β9Respondent Management Level þ β10Respondent Years
with API Provider
API ROI reflects the level of financial goal attainment (1 = API
ROI goals are not met at
all; 5 = API ROI goals are completely met), X the vector of
predictor variables, β the vector
of estimated coefficients, α the intercepts, and j the number of
ordinal response levels for
API ROI. Consequently, Pr(API ROI ≥ j | X) is the probability
that API ROI is higher or
equal to the API ROI level j, conditional on the predictors X.
We test model 1 in a step-
wise fashion. We first test for direct main effects excluding the
interaction terms (model
1a). Then, we included the moderation effects in order to test
our hypotheses (model 1b).
Table 6 shows the results of the ordinal logistic regressions.
Model 1a indicates that we
cannot detect any significant main effect of economies of scope
in production and the
variables measuring the similarity to the design archetypes of
professional/mediation
services. Model 1b reveals positive interaction effects for
economies of scope production
and similarity to the professional service archetype (β = 0.46, p

≤ 0.01) as well as to the
mediation archetype (β = 0.39, p ≤ 0.05).
A likelihood ratio test reveals that R2 increases significantly (p
≤ 0.01) from 0.25 to 0.30
when comparing the models with (model 1b) and without
moderation effects (model 1a).
The log odds (exponentiated beta coefficients) for both
interaction effects are > 1, that is,
indicating that API providers following a mediation or
professional service design and
targeting economies of scope in production have a higher API
ROI than others. In order
to better understand the results of these interaction effects, we
evaluate how the predicted
probabilities of the different levels of API ROI change with
varying degrees of similarity to
Table 6. Ordinal logistic regression results.
Hypo-thesis Variables
Model 1a API ROI
(main effects)
Model 1b API ROI
(full model)
Coefficients
Exp(β)
(Odd Ratio) Coefficients
Exp(β)
(Odd Ratio)

Economies of scope in production 0.20 (0.19) 1.23 0.23 (0.2)
1.26
Similarity professional service archetype 0.12 (0.16) 1.13 0.16
(0.17) 1.17
Similarity mediation archetype -0.16 (0.16) 0.85 -0.23 (0.17)
0.79
H1 Economies of scope in production *
similarity professional service archetype
0.45** (0.18) 1.57
H2 Economies of scope in production *
similarity mediation archetype
0.37* (0.18) 1.45
Functional quality 1.15** (0.23) 3.14 1.17** (0.24) 3.22
Service innovativeness -0.08* (0.00) 0.66 -0.37 (0.20) 0.69
Employees API provider -0.06 (0.13) 0.95 -0.07 (0.14) 0.93
Respondent API Affiliation 0.72 (0.47) 2.06 0.71 (0.48) 2.04
Respondent years API provider 0.01 (0.16) 1.01 -0.03 (0.16)
0.97
R2 0.26 0.30
Δ R2 0.04*
Notes: **p < 0.01, * < 0.05; API = Application Programming
Interface; ROI = Return on Investment; N = 152
the API design archetypes and economies of scope in
production. Table 7 shows that API
providers that simultaneously target economies of scope in

production and follow
a professional service or a mediation service design have higher
probabilities of reaching
high to very high levels of attaining their API ROI goals. For
instance, API providers that
follow professional service design and have reported high levels
of economies of scope in
production have a 68 percent chance of reaching high to very
high level of goal attain-
ment. By contrast, API providers that follow a professional
service design without
explicitly targeting economies of scope in production or vice
versa have lower probabilities
of reaching the same levels of goal attainment (36 percent and
39 percent). Thus, we find
support for our hypotheses 1 and 2.2
Testing our API diffusion hypotheses, we first applied a chi-
square test for dispersion
and found our data to be overdispersed with p < 0.01 [45]. We
believe that this over-
dispersion (conditional variance of API diffusion is greater than
its conditional mean) is
Table 7. Predicted probabilities for ordinal logistic regression.
Similarity to Design Archetype and Level of targeted economies
of scope on
production
Cumulative Probability for
Minimum Level of Goal Attainment
for API ROI
Low Moderate High

Very
high
High Similarity to Professional Service & High levels of
production
0.99 0.93 0.68 0.33
High Similarity to Professional Service & Low levels of
production
0.95 0.78 0.36 0.11
Low Similarity to Professional Service & High levels of
production
0.95 0.8 0.39 0.13
High Similarity to Mediation Service & High levels of
production
0.98 0.89 0.57 0.24
High Similarity to Mediation Service & Low levels of
production
0.93 0.72 0.29 0.08
Low Similarity to Mediation Service & High levels of
production

0.97 0.86 0.5 0.19
Notes: API = Application Programming Interface; ROI = Return
on Investment
Table 8. Negative binomial regression results.
Hypo-thesis Variables
Model 2a API Diffusion (main
effects)
Model 2b API Diffusion (full
model)
Coefficients Exp(β) Coefficients Exp(β)
Economies of scope in innovation -0.34 (0.26) 0.71 -0.32 (0.22)
0.72
Similarity to mediation archetype -0.08 (0.23) 0.92 0.00 (0.19)
1.00
Similarity to open asset archetype -0.22 (0.22) 0.80 -0.24 (0.19)
0.79
H3 Economies of scope in innovation*
similarity to open asset archetype
0.45* (0.22) 1.57
H4 Economies of scope in innovation*
similarity to mediation archetype
0.07 (0.2) 1.08
Functional quality 0.29 (0.28) 1.33 0.29 (0.24) 1.33

Service innovativeness 0.01 (0.29) 1.01 -0.02 (0.24) 0.98
Employees API provider 0.35 (0.21) 1.42 0.36* (0.18) 1.43
Respondent API Affiliation -1.19 (0.65) 0.30 -1.14 (0.63) 0.32
Respondent years API provider -0.11 (0.22) 0.90 -0.07 (0.19)
0.94
R2 0.25 0.30
Δ R2 0.05**
Notes: **p < 0.01, * < 0.05; API = Application Programming
Interface; N = 152; Reported are standardized beta values;
Standard errors in parentheses
269
caused by a distribution that is found in many online-contexts.
Most APIs have a low to
moderate diffusion and a handful of APIs show very high
diffusion. In order to deal with
this overdispersion, we tested a variety of alternatives including
quasi-poisson, negative
binomial, or zero-inflated regression models [45, 106].
However, likelihood ratio and
deviance tests revealed that negative binomial regression best
represents our data such
that we have chosen this approach. Negative binomial
regression models are based on log-
transforming the conditional expectation of the dependent
variable [97] (i.e., API diffu-
sion). In greater detail, we have tested the following regression:
Model 2: logðEðAPI diffusion j XÞÞ
¼ α þ β1 Economies of Scope in Innovation þ β2 Similarity
Open Asset Archetype

þ β3 Similarity Mediation Archetype
þ β4 Economies of Scope in Innovation x Similarity Open Asset
Archetype
þ β5 Economies of Scope in Innovation x Similarity Mediation
Archetype
þ β6 Functional Quality þ β7 Service Innovativeness þ β8
Employees API Provider
þ β9 Respondent Management Level þ β10 Respondent Years
with API Provider þ r
API diffusion refers to the value of API diffusions and X to the
vector of predictor variables.
Thus, E(API diffusion | X) reflects the expected value of API
diffusion given the predictor
variables in the model [95]. Again, we test this equation in a
stepwise fashion in order to
disentangle main and interaction effects. Table 8 shows the
negative binomial regression results.
In model 2a, we find no main effects of our API design
measures and the targeted level of
economies of scope in innovation. Model 2b shows that the
interaction between economies of
scope in innovation and similarity to the open asset archetype is
significant (β = 0.45, p < 0.05).
This interaction effect significantly increases R2 from 0.25
(model 2a) to 0.3 (model 2b) with p <
0.01. These results indicate that neither increasing the similarity
to the open asset archetype nor
following an economies of scope in innovation strategy is
associated with a significant increase
in API diffusion in isolation. The exponentiated beta coefficient
for designing APIs according to
the open asset archetype is 1, that is, striving towards open
asset design alone has no positive or
negative effect on API diffusion. By contrast, the exponentiated
beta coefficient for the interac-

tion term of similarity to the open asset design and economies
of scope in innovation strategy is
1.57. This means that API providers that embark on economies
of scope in innovation in
conjecture with an open asset design increase the diffusion of
their API by 57 percent when
being compared to API providers that follow an open asset
design only. We find no support for
the interaction between economies of scope in innovation and
the similarity to the mediation
archetype. Thus, we can support Hypothesis 3, while we have to
reject Hypothesis 4.3
Finally, we probe our moderation analyses through visual
representations (Figure 2, 3,
and 4). These plots support our fit as moderation perspective
showing that an alignment
between API design archetypes and targeted economies of scope
leads to superior API
ROI and diffusion.
Discussion
Our analysis of how a provider’s choice of API archetype
interacts with its targeting of
platform-based value creation mechanisms in influencing API
ROI and diffusion provides
support for the theoretically derived hypothesis that the
interaction of targeting economies
of scope in production and an API’s similarity to the
professional service archetype is

positively related to API ROI (Hypothesis 1). Second, our
results support our theoretical
argumentation that the interaction of targeting economies of
scope in production and an
API’s similarity to the mediation archetype is also positively
related to API ROI
Figure 2. Interaction between economies of scope in production
and similarity to professional services.
Figure 3. Interaction between economies of scope in production
and similarity to mediation services.
Figure 4. Interaction between economies of scope in innovation
and similarity toopen asset.
271
(Hypothesis 2). Third, our analysis shows that the interaction of
targeting economies of
scope in innovation and an API’s similarity to the open asset
service archetype is positively
related to API diffusion (Hypothesis 3). Our results do not
provide support for the fourth
hypothesis that the interaction of targeting economies of scope
in innovation and an API’s
similarity to the mediation service archetype is positively
related to API diffusion
(Hypothesis 4). A strategy that targets economies of innovation,
thus, does not suffice
for achieving high diffusion with APIs that are similar to the
mediation service archetype.

This finding conforms with prior literature, which suggests that
diffusion of media-
tion services requires careful coordination of cross-platform
externalities and the
execution of platform ignition strategies [28]. External
developers will only become
aware of and adopt a mediation service if it provides access to
enough customers that
external developers target [94], if there is complementarity
between the API provider’s
and the developer’s capabilities [52], and if there is an adequate
level of platform
governance [99].
Theoretical Contributions
We provide three contributions to the literature on digital
platforms. First, we develop
a unifying theory that consolidates different theoretical
perspectives on API design and
strategy. Prior literature on API design is scattered and
discusses selective aspects of
API design in disparate contexts. Some authors study APIs that
provide marketing and
distribution capabilities to third-party developers on two-sided
platforms [e.g., 79].
This stream of literature focusses on an API’s ability to provide
end customer access
and to spur novel end-customer-facing value propositions from
third parties. It
produces theories with limited transferability to APIs on one-
sided platforms that
primarily focus on value appropriation. A second group of
authors studies APIs that
provide open data services [e.g., 56]. It focusses on an API’s
ability to expose assets to

external developers free of charge in order to achieve high API
diffusion. The research
results are not applicable to fee-based APIs that do not target
API diffusion but API
ROI. A third group of authors considers APIs as distribution
channels for cloud-based
professional services [e.g., 7]. This perspective focusses on fee-
based offerings to API
developers and excludes indirect value appropriation
mechanisms on two-sided mar-
kets. Considering that APIs represent key strategic resources of
platform providers that
determine a platform’s prosperity [9], a generalizable theory on
API design is required
[108] that integrates the disparate perspectives on API design
and explains the
strategic impact of design choices across these isolated
contexts. Our unifying per-
spective on API design that is grounded in contemporary
literature on platform
architecture and governance [99, 100] synthesizes prior API
literature. We differentiate
between three API archetypes with archetypal design -
professional services, modera-
tion services and open asset services — and offer a fit-as-
moderation perspective on
the applicability of economies of scope in production and
innovation to these API
archetypes. In so doing, we respond to Yoo et al.’s [108] call
for further research on
the strategic role of design decisions regarding boundary
resources for digital
platforms.
As our second contribution, we choose the individual API as our
focal unit of analysis

and, thus, extend the knowledge on the performance effects of
API design. Prior research
studies the aggregate use of APIs and discovers positive
performance effects of API
adoption on the firm level [9] and on the platform level [8, 93,
101, 107]. Thus, prior
empirical research studies sets of APIs offered by a firm or by a
platform and look at the
collective role of APIs for firm and platform performance,
respectively. Firm-level and
platform-level analyses do not allow a direct linkage between
individual APIs (particu-
larly API design characteristics) and their performance impacts.
At the firm level, Benzell
et al. [9] compare firm performance (market value, R&D
expenditure, data breaches)
before and after the first introduction of APIs. They show that
whether or not a firm
adopts APIs predicts a substantial increase in a firm’s market
value. At the platform level,
Xue et al. [107], for example, study how developer’s adoption
of APIs, which are offered
by a platform, influences their likelihood to continue
developing new applications for
this platform. They examine how the adoption of APIs generally
influences platform
performance (in terms of the number of apps hosted by a
platform). Benlian et al. [8], as
a second example for a platform-level analysis, regard the scope
of functionalities APIs
collectively offer as part of their operationalization of platform

openness, and show
a positive relationship of platform openness with a platform’s
perceived usefulness and
developer satisfaction. Because most platforms offer multiple
APIs and alternative
boundary resources such as software development kits, these
studies only allow limited
implications on the design and performance effects at the level
of individual APIs. We
take into account different architecture-related and governance-
related design decisions
that APIs incorporate and distinguish between three API
archetypes of professional,
mediation, and open asset services. We relate these API
archetypes to API ROI and
diffusion. Our results extend our knowledge regarding the
distinct consequences of
different API-level design choices. We, thus, respond to de
Reuver et al.’s [24] call for
further research on platform boundary resources that creates
direct platform design
knowledge.
As our third contribution, we respond to Gawer’s [36] call for
empirical efforts to
validate her proposed organization-theoretic platform
perspective. We adopt Gawer’s
[36] organization-theoretic conceptualization of platform-based
ecosystems that allows
us to empirically study two modes of ecosystem value creation
simultaneously: econo-
mies of scope in production and innovation. With our
moderation-as-fit-perspective, we
establish that the provider’s API design must match the targeted
mechanism of inter-
organizational value creation and the business objective (ROI or

API diffusion). Our
results suggest that, depending on the design, APIs facilitate
production or innovation. Moreover, the fit of API design with
value creation strategies
determines whether value exploration targets (via API
diffusion) or value appropriation
targets (via ROI) are achievable.
Practical Implications
Our results generate two practical implications. First, API
providers are challenged with
overlooking an API’s relevance for strategic competitiveness
[51]. Our results show that
API providers should carefully align API archetype choice with
the value creation
strategy and the superordinate business objective. Offering
professional services may
result in a positive ROI if they improve a software solution’s
integrability. Mediation
services may increase direct or indirect revenues in case they
facilitate the integration of
273
platform resources, such as end customer marketing capabilities
for third-party devel-
opers. Open asset services, in contrast to the other two API
archetypes, do not focus on
value appropriation but on value generation only. They may
generate high levels of API
diffusion if the API provider successfully involves third-party

developers in joint
innovation. Second, API providers have difficulties in attracting
third-party developers
and in defining appropriate approaches to value appropriation
[3, 12]. We suggest that
API providers should align approaches towards value generation
and appropriation
with the value creation strategy. Leveraging economies of scope
in production legit-
imates transaction-based or subscription-based API pricing. The
realization of econo-
mies of scope in innovation, on the contrary, is not linked to
value appropriation, but is
an effective instrument for attracting third-party developers.
Limitations and Further Research
One should interpret the results cognizant of the following
limitations that open up avenues
for further research. First, owing to our focus on public Internet
APIs, the results do not apply
to private APIs or non-Internet APIs that local applications
expose. Further research may
apply our model to investigate non-Internet APIs in local
applications. Second, our study is
limited to APIs offered by for-profit providers. Further research
may adapt our research
model to study APIs that non-profit providers such as
governmental institutions offer. Third,
we do not study the effects of simultaneously offering more
than one API. An avenue for
further research is to build on our theory and explore the
interaction effects that result from
offering multiple APIs. Fourth, we limit our conceptualization
of economies of scope in
production to linkage effects resulting from facilitating the

vertical integration of provider
and customer systems. We do not study production economies
relating to horizontal bundling
and the use of shared inputs in digital platforms, to which future
research may attend. Fifth,
apart from economies of scope in production, this research only
studies economies of scope in
innovation. Another area for further research is a focal study of
mediation services and how
API design aligns with economies of scale in demand, which
will require a detailed analysis of
cross-platform externalities. Sixth, our measurement approach
is limited in that, while the set
of analyzed API design elements is theoretically motivated,
backed by a thorough synopsis of
the available literature, and empirically verified, we do not
claim exhaustiveness of API
archetypes. Also, API ROI is the product manager’s perception
rather than an objective
measure. Moreover, we analyze the levels to which an API
provider targets the value creation
mechanisms and do not provide objective measures for
economies of scope in production and
in innovation. Further research may introduce other
measurement approaches to extend our
findings. Seventh, our cross-sectional analyses only ascertain
association, but not the causal
relationships inherent in our theoretical arguments. A fruitful
area of further research that
may expand on our results deals with investigating
longitudinally how a time-varying API
strategy impacts a provider’s platform evolution.
Conclusion
In spite of the rich literature on digital platforms, there is

sparse knowledge on the design of
APIs and on how to successfully align API design with an API
provider’s contextual condi-
tions. In this research, we developed and validated a theoretical
model that explains how the
choice of API design interacts with the levels to which an API
provider targets different value
creation mechanisms and how this interaction affects API ROI
and diffusion. We contribute
to the IS literate an overarching theory of API design that
unifies prior theoretical perspectives
and that extends current knowledge on the performance effects
of API design.
Notes
1. The basic idea of Frigyesi and Höglund [33] is to investigate
how well an extracted factor or
a number of extracted factors can reproduce the initial items
from which the factor(s) were
formed. They suggest to calculate the residual errors for an
increasing number of factors for
a data set and a permuted version of that data set. If the residual
errors calculated from the
permuted data set have the same size as the residual errors from
the original data set, non-
negative matrix factorization has captured all the “noise” within
a data set such that the
extracted factor(s) do not contain useful information. However,
the factors in the original
data set show considerably smaller residual errors than the

factors extracted from the
permuted data set. Differences are biggest for one single factor
such that we conclude that
this single factor captures the relevant information from the
underlying items.
2. We also performed a robustness check in which we
considered API ROI as interval-scaled
data and applied ordinary least square regressions. Results are
consistent and lead to identical
implications.
3. We also performed a robustness test for verifying these
results. In greater detail, we applied
log transformation to the three items with an offset of 1 [44] as
well as applied exploratory
and confirmatory factor analysis. The psychometrical properties
of this latent API diffusion
factor were excellent. All three items loaded unambiguously and
significantly with p < 0.01 on
that factor. Chronbach α was 0.86, the Average Variance
Explained was 0.68, and the
Composite Reliability was 0.86. Using the Fornell-Larcker-
Criterion the factor was clearly
distinguishable from the other ones. Testing Model 2 by means
of ordinary least square
regression, we found very consistent results that lead to the
identical implications.
Acknowledgements
The authors acknowledge the JMIS Editor-in-Chief and the
anonymous reviewers for their valuable
contributions during the review process.
ORCID

Jochen Wulf http://orcid.org/0000-0001-5553-8850
Ivo Blohm http://orcid.org/0000-0003-2422-5952
References
1. Adner, R.; and Kapoor, R. Value creation in innovation
ecosystems: How the structure of
technological interdependence affects firm performance in new
technology generations.
Strategic Management Journal, 31, 3 (2010), 306–333.
2. Analytics REST API developer guide. Salesforce, 2019.
https://developer.salesforce.com/docs/atlas.
en-
us.bi_dev_guide_rest.meta/bi_dev_guide_rest/bi_rest_overview.
htm (accessed October 8,
2019).
3. Anuff, E. Almost everyone is doing the API economy wrong.
Techcrunch, 2016. https://
techcrunch.com/2016/03/21/almost-everyone-is-doing-the-api-
economy-wrong/(accessed
October 8, 2019).
275
https://developer.salesforce.com/docs/atlas.en-
htm
https://developer.salesforce.com/docs/atlas.en-
htm
https://techcrunch.com/2016/03/21/almost-everyone-is-doing-
the-api-economy-wrong/

https://techcrunch.com/2016/03/21/almost-everyone-is-doing-
the-api-economy-wrong/
4. Armstrong, S.T.; and Overton, T.S. Estimating non-response
bias in mail surveys. Journal of
Marketing Research, 14, 3 (1977), 396–402.
5. Baer, M.; and Frese, M. Innovation is not enough: Climates
for initiative and psychological
safety, process innovations, and firm performance. Journal of
Organizational Behavior, 24, 1
(2003), 45–68.
6. Bagozzi, R.P.; and Yi, Y. On the evaluation of structural
equatation models. Journal of the
Academy of Marketing Sciences, 16, 1 (1988), 74–94.
7. Benlian, A.; Koufaris, M.; and Hess, T. Service quality in
software-as-a-service: Developing
the SaaS-Qual measure and examining its role in usage
continuance. Journal of Management
Information Systems, 28, 3 (2011), 85–126.
8. Benlian, A.; Hilkert, D.; and Hess, T. How open is this
platform? The meaning and
measurement of platform openness from the complementors’
perspective. Journal of
Information Technology, 30, 3 (2015), 209–228.
9. Benzell, S.G.; LaGarda, G.; Hersh, J.; and Van Alstyne,
M.W. The Paradox of Openness:
Exposure vs. Efficiency of APIs. Boston University, 2019.
http://dx.doi.org/10.2139/ssrn.
3432591(accessed October 8, 2019).

10. Bergkvist, L.; and Rossiter, J.R. The predictive validity of
multiple-item versus single-item
measures of the same constructs. Journal of Marketing
Research, 44, 2 (2007), 175–184.
11. Boyd, M. Making API decisions: Are you connecting
business and technical interests?
ProgrammableWeb, 2017.
https://www.programmableweb.com/news/making-api-decisions-
are-
you-connecting-business-and-technical-
interests/analysis/2017/09/27 (accessed October 8, 2019).
12. Boyd, M. How to pick the best business models for your
APIs. ProgrammableWeb, 2017.
https://www.programmableweb.com/news/how-to-pick-best-
business-models-your-apis/ana
lysis/2017/09/27. (accessed October 8, 2019).
13. Brant, R. Assessing proportionality in the proportional odds
model for ordinal logistic
regression. Biometrics, 46, 4 (1990), 1171–1178.
14. Bresnahan, T.F.; and Trajtenberg, M. General purpose
technologies ‘engines of growth’?
Journal of Econometrics, 65, 1 (1995), 83–108.
15. Brunet, J.-P.; Tamayo, P.; Golub, T.R.; and Mesirov, J.P.
Metagenes and molecular pattern
discovery using matrix factorization. Proceedings of the
National Academy of Sciences, 101, 12
(2004), 4164–4169.
16. Chesbrough, H.W.; and Appleyard, M.M. Open innovation
and strategy. California
Management Review, 50, 1 (2007), 57–76.

17. Chryssochoidis, G.M.; and Wong, V. Customization of
product technology and international
new product success: Mediating effects of new product
development and rollout timeliness.
Journal of Product Innovation Management, 17, 4, 268–285.
18. Cooper, R.G. The dimensions of industrial new product
success and failure. Journal of
Marketing, 43, 3 (1979), 93–103.
19. Create Audio Playlists On Dropbox. Streamboxr, 2019.
https://streamboxr.com/(accessed
October 8, 2019).
20. Curbera, F.; Khalaf, R.; Mukhi, N.; Tai, S.; and
Weerawarana, S. The next step in web services.
Communications of the ACM, 46, 10 (2003), 29–34.
21. D’Aveni, R.A.; and Ravenscraft, D.J. Economies of
integration versus bureaucracy costs: Does
vertical integration improve perfoermance? Academy of
Management Journal, 37, 5 (1994),
1167–1206.
22. Dal Bianco, V.; Myllarniemi, V.; Komssi, M.; and
Raatikainen, M. The role of platform
boundary resources in software ecosystems: A case study.
IEEE/IFIP Conference on Software
Architecture, Washington, DC, USA: IEEE Computer Society
2014, pp. 11–20.
23. DBX platform - Develop apps for 500 million Dropbox
users. Dropbox, 2019. https://www.
dropbox.com/developers (accessed October 8, 2019).

24. de Reuver, M.; Sørensen, C.; and Basole, R.C. The digital
platform: A research agenda. Journal
of Information Technology, 33, 2 (2017), 124–135.
http://dx.doi.org/10.2139/ssrn.3432591
http://dx.doi.org/10.2139/ssrn.3432591
are-you-connecting-business-and-technical-
interests/analysis/2017/09/27
are-you-connecting-business-and-technical-
interests/analysis/2017/09/27
business-models-your-apis/analysis/2017/09/27
business-models-your-apis/analysis/2017/09/27
https://streamboxr.com/
https://www.dropbox.com/developers
https://www.dropbox.com/developers
25. Demirkan, H.; and Delen, D. Leveraging the capabilities of
service-oriented decision support
systems: Putting analytics and big data in cloud. Decision
Support Systems, 55, 1 (2013),
412–421.
26. Dollinger, M.J.; and Golden, P.A. Interorganizational and
collective strategies in small firms:
Environmental effects and performance. Journal of
Management, 18, 4 (1992), 695–715.
27. Eaton, B.; Elaluf-Calderwood, S.; Sorensen, C.; and Yoo, Y.
Distributed tuning of boundary

resources: The case of Apple’s iOS service system. MIS
Quarterly, 39, 1 (2015), 217–243.
28. Evans, D.S.; and Schmalensee, R. Matchmakers: The New
Economics of Multisided Platforms.
Boston, MA, USA: Harvard Business Review Press, 2016.
29. Evans, P.C.; and Basole, R.C. Revealing the API ecosystem
and enterprise strategy via visual
analytics. Communations of the ACM, 59, 2 (2016), 26–28.
30. Fang, E. Customer participation and the trade-off between
new product innovativeness and
speed to market. Journal of Marketing, 72, 4 (2008), 90–104.
31. Foreman, J.W. Data Smart: Using Data Science to
Transform Information into Insight.
Indianoplis, IN, USA: John Wiley & Sons, 2013.
32. Fornell, C.; and Larcker, D.F. Evaluating structural equation
models with unobservable
variables and measurement error. Journal of Marketing
Research, 18, 2 (1981), 39–50.
33. Frigyesi, A.; and Höglund, M. Non-negative matrix
factorization for the analysis of complex
gene expression data: Identification of clinically relevant tumor
subtypes. Cancer Informatics,
6(2008), 275–292.
34. Garcia, S.; Moreaux, M.; and Reynaud, A. Measuring
economies of vertical integration in
network industries: An application to the water sector.
International Journal of Industrial
Organization, 25, 4 (2007), 791–820.

35. Gawer, A.; and Henderson, R. Platform owner entry and
innovation in complementary
markets: Evidence from Intel. Journal of Economics &
Management Strategy, 16, 1 (2007),
1–34.
36. Gawer, A. Bridging differing perspectives on technological
platforms: Toward an integrative
framework. Research Policy, 43, 7 (2014), 1239–1249.
37. Ghazawneh, A.; and Henfridsson, O. Micro-strategizing in
platform ecosystems: A multiple
case study. International Conference on Information Systems,
Shanghai, China: Association for
Information Systems, 2011, pp. 1–19.
38. Ghazawneh, A.; and Henfridsson, O. Balancing platform
control and external contribution in
third-party development: The boundary resources model.
Information Systems Journal, 23, 2
(2013), 173–192.
39. Ghazawneh, A.; and Henfridsson, O. A paradigmatic
analysis of digital application
marketplaces. Journal of Information Technology, 30, 3 (2015),
198–208.
40. Ginsberg, A.; and Venkatraman, N. Contingency
perspectives of organizational strategy:
A critical review of the empirical research. Academy of
Management Review, 10, 3 (1985),
421–434.
41. Gonçalves, V.; and Ballon, P. Adding value to the network:
Mobile operators’ experiments
with Software-as-a-Service and Platform-as-a-Service models.

Telematics and Informatics, 28,
1 (2011), 12–21.
42. Gosain, S. Realizing the vision for web services: Strategies
for dealing with imperfect
standards. Information Systems Frontiers, 9, 1 (2007), 53–67.
43. Gunarathne, P.; Rui, H.; and Seidmann, A. Whose and what
social media complaints have
happier resolutions? Evidence from Twitter. Journal of
Management Information Systems, 34,
2 (2017), 314–340.
44. Guo, J.; Zhang, W.; Fan, W.; and Li, W. Combining
geographical and social influences with
deep learning for personalized point-of-interest
recommendation. Journal of Management
Information Systems, 35, 4 (2018), 1121–1153.
45. Harrell, F. Regression Modeling Strategies. Cham,
Switzerland: Springer, 2015.
46. Hartmann, P.M.; Zaki, M.; Feldmann, N.; and Neely, A.
Capturing value from big data -
A taxonomy of data-driven business models used by start-up
firms. International Journal of
Operations & Production Management, 36, 10 (2016), 1382–
1406.
277
47. Henfridsson, O.; and Bygstad, B. The generative
mechanisms of digital infrastructure

evolution. MIS Quarterly, 37, 3 (2013), 907–931.
48. Hjalmarsson, A.; Juell-Skielse, G.; Ayele, W.Y.; Rudmark,
D.; and Johannesson, P. From
contest to market entry: A longitudinal survey of innovation
barriers constraining open data
service development. European Conference on Information
Systems, Münster, Germany:
Association for Information Systems, 2015.
49. Hornik, K.; Feinerer, I.; Kober, M.; and Buchta, C.
Spherical k-means clustering. Journal of
Statistical Software, 50, 10 (2012), 1–22.
50. Im, S.; and Workman Jr, J.P. Market orientation, creativity,
and new product performance in
high-technology firms. Journal of Marketing, 68, 2 (2004), 114–
132.
51. Iyer, B.; and Subramaniam, M. The strategic value of APIs.
Harvard Business Review Digital
Articles, 2015. https://hbr.org/2015/01/the-strategic-value-of-
apis (accessed October 8,
2019).
52. Jacobides, M.G.; Cennamo, C.; and Gawer, A. Towards a
theory of ecosystems. Strategic
Management Journal, 39, 8 (2018), 2255–2276.
53. Jacobson, D.; Brail, G.; and Woods, D. APIs: A Strategy
Guide. Sebastopol, CA, USA: O’Reilly,
2011.
54. Jansen, S.; Brinkkemper, S.; and Finkelstein, A. Business
network management as a survival.
In S. Jansen, S Brinkkemper, and A. Finkelstein (eds.),

Software Ecosystems: Analyzing and
Managing Business Networks in the Software Industry.
Cheltenham, UK: Edward Alger
Publishing, 2013, pp. 29–42.
55. Krishnan, V.; and Gupta, S. Appropriateness and impact of
platform-based product
development. Management Science, 47, 1 (2001), 52–68.
56. Kuk, G.; and Davies, T. The roles of agency and artifacts in
assembling open data comple-
mentarities. International Conference on Information Systems,
Shanghai, China: Association
for Information Systems, 2011.
57. Landis, J.R.; and Koch, G.G. The measurement of observer
agreement for categorical data.
Biometrics, 33, 1 (1977), 159–174.
58. Lee, D. The API for absurdity. Techcrunch, 2016.
https://techcrunch.com/2016/08/27/the-api-
for-absurdity/(accessed October 8, 2019).
59. Lee, D.D.; and Seung, H.S. Algorithms for non-negative
matrix factorization. Advances in
Neural Information Processing Systems, Denver, CO, USA:
Neural Information Processing
Systems Foundation, 2001, pp. 556–562.
60. Lee, S.M.; Kim, T.; Noh, Y.; and Lee, B. Success factors of
platform leadership in web 2.0
service business. Service Business, 4, 2 (2010), 89–103.
61. Legner, C. Do web services foster specialization? An
analysis of commercial web service
directories. International Conference on Wirtschaftsinformatik,

Wien, Austria: Association for
Information Systems, 2009, pp. 67–76.
62. Leisch, F. A toolbox for k-centroids cluster analysis.
Computational Statistics & Data
Analysis, 51, 2 (2006), 526–544.
63. Lin, A.; and Chen, N.-C. Cloud computing as an innovation:
Percepetion, attitude, and
adoption. International Journal of Information Management, 32,
6 (2012), 533–540.
64. Lindman, J.; Rossi, M.; and Tuunainen, V.K. Open data
services: Research agenda. Hawaii
International Conference on System Sciences, Wailea, HI, USA:
IEEE Computer Society, 2013,
pp. 1239–1246.
65. Lindman, J.; Kinnari, T.; and Rossi, M. Business roles in
the emerging open-data ecosystem.
IEEE Software, 33, 5 (2016), 54–59.
66. Lusch, R.F.; and Nambisan, S. Service innovation: A
service-dominant logic perspective. MIS
Quarterly, 39, 1 (2015), 155–175.
67. Malhotra, A.; Gosain, S.; and Sawy, O.A.E. Absorptive
capacity configurations in supply
chains: Gearing for partner-enabled market knowledge creation.
MIS Quarterly, 29, 1
(2005), 145–187.
https://hbr.org/2015/01/the-strategic-value-of-apis
https://techcrunch.com/2016/08/27/the-api-for-absurdity/

https://techcrunch.com/2016/08/27/the-api-for-absurdity/
68. McNally, R.C.; Akdeniz, M.B.; and Calantone, R.J. New
product development processes and
new product profitability: Exploring the mediating role of speed
to market and product
quality. Journal of Product Innovation Management, 28, s1
(2011), 63–77.
69. Mizik, N.; and Jacobson, R. Trading Off Between Value
Creation and Value Appropriation:
The Financial Implications of Shifts in Strategic Emphasis.
Journal of Marketing, 67, 1 (2003),
63–76.
70. Mueller, B.; Viering, G.; Legner, C.; and Riempp, G.
Understanding the economic potential of
service-oriented architecture. Journal of Management
Information Systems, 26, 4 (2010),
145–180.
71. Muffatto, M.; and Roveda, M. Product architecture and
platforms: A conceptual framework.
International Journal of Technology Management, 24, 1 (2002),
1–16.
72. Munaiah, N.; Kroh, S.; Cabrey, C.; and Nagappan, M.
Curating GitHub for engineered
software projects. Empirical Software Engineering, 22, 6
(2017), 3219–3253.
73. Murphy, M.; and Sloane, S. The rise of APIs. Techcrunch,
2016. https://techcrunch.com/2016/
05/21/the-rise-of-apis/(accessed October 8, 2019).

74. Nambisan, S.; and Sawhney, M. Orchestration processes in
network-centric innovation:
Evidence from the field. Academy of Management Perspectives,
25, 3 (2011), 40–57.
75. Niculescu, M.F.; Wu, D.; and Xu, L. Strategic intellectual
property sharing: Competition on
an open technology platform under network effects. Information
Systems Research, 29, 2
(2018), 498–519.
76. Nüttgens, M.; and Iskender, D. Business models of service-
oriented information systems -
A strategic approach towards the commercialization of web
services. Wirtschaftsinformatik,
50, 1 (2008), 31–38.
77. Oh, J.; Koh, B.; and Raghunathan, S. Value appropriation
between the platform provider and
app developers in mobile platform mediated networks. Journal
of Information Technology, 30,
3 (2015), 245–259.
78. Panzar, J.C.; and Willig, R.D. Economies of scope.
American Economic Review, 71, 2 (1981),
268–272.
79. Parker, G.; Van Alstyne, M.; and Jiang, X. Platform
ecosystems: How developers invert the
firm. MIS Quarterly, 41, 1 (2017), 255–266.
80. Parker, G.G.; and Van Alstyne, M.W. Two-sided network
effects: A theory of information
product design. Management Science, 51, 10 (2005), 1494–
1504.

Fostering Value Creation with Digital Platforms A UnifiedTh.docx

Fostering Value Creation with Digital Platforms A UnifiedTh.docx

Recommended

Recommended

More Related Content

Similar to Fostering Value Creation with Digital Platforms A UnifiedTh.docx

Similar to Fostering Value Creation with Digital Platforms A UnifiedTh.docx (20)

More from budbarber38650

More from budbarber38650 (20)

Recently uploaded

Recently uploaded (20)

Fostering Value Creation with Digital Platforms A UnifiedTh.docx