1.

Introduction

In the earlier days of information technology, independent software vendors each

provided their own systems and software products were not considered too differently from the
physical products. Business relationships of actors in the value chain were also similar to the more
traditional structures of a value chain of physical products. Until the late 1980s, software products
were delivered by vertically integrated companies that provided customers with “stacks” of
complete systems that included proprietary hardware, software and operating system. Over time,
this vertical structure of stacks turned into modular and horizontal structure eventually shaping
the modern landscape of platform ecosystems.

Platform business models soon became one of the most important features of the new
world of technology and information economy. Modern software ecosystems welcome buyers and
customers into their platforms. Allowing them to creatively collaborate with other buyers and
suppliers of the platform promotes added competitive value of the ecosystem as a whole. Proper
management of such relationships is therefore as crucial as the quality of the services provided in
the platforms for an ecosystem to be successful.

Recent literature focused on the designs of the platform and the associated business
strategies for managing the platform. Openness is one of the key factors that defines the design
of a platform. One way to analyze this is to explore how open the platform is to different actors
in it; Demand-Side User, Supply-Side User, Platform Provider, Platform Sponsor (Eisenmann,
Parker, & Van Alstyne, 2008). Opening a platform can be beneficial since it will reduce users’ lock-
in concerns and encourage network effects (Parker & Van Alstyne, 2008). However, more open a
platform is, more challenging it is to prevent the users from escaping the ecosystem and possibly
migrating to the competitors’.

For more closed platforms, on the other hand, it is much easier to prevent this problem.
Proprietary nature of the closed platforms locks in users in their “walled garden” exposing them
to different parts of the platforms’ extensions and allows the platform to keep benefiting from the
spillovers generated by users (Mehra, 2011). Escaping the closed ecosystem is also possible but
once the user had entered, prior investments and switching costs hinder this decision. Such
convenience, from a managerial viewpoint, seems to have encouraged the industry leaders such
as Google, Amazon, Facebook, Apple and Microsoft to opt for rather closed platforms.

In light of the exponential growth of software products and to remedy the possible
infringement of privacy that can be followed, General Data Protection Regulation (GDPR) went
into effect in 2018. One can state that it is highly expected for privacy awareness to be promoted
and thoroughly practiced by all actors in the platform ecosystem and especially by the providers
and sponsors. Users’ concerns regarding the privacy and personal data are inseparable from the
modern platform ecosystems given the nature of them being nearly entirely based on software
products. Software has no physical limitation but only has conceptual, social and economic ones
(Beizer, 2000). This challenges software products’ damage control capability since simply
implementing better quality control of the production line is not viable.

However, despite the increasing cases of gigantic success of platform economics, there
has been little formal modeling to address the question of how a platform sponsor can best
suppress the exit rate of users under crisis scenarios in order to secure profits in the platform
ecosystem. More specifically, the platform’s different portfolio structures, how each structure
compares in the sensitivity to the crisis, and if hardware-software integration grants favorable
outcomes under crisis are overlooked. Therefore, this research aims to highlight the moderating
effect of hardware-software integration and the mediating-moderating effect of privacy
infringement crisis on the spillover to the platform provider per different brand architecture
choices.