2014 IEEE/IFIP Conference on Software Architecture
The Role of Platform Boundary Resources in Software Ecosystems: A Case Study Vittorio Dal Bianco∗ , Varvana Myll¨arniemi∗ , Marko Komssi† and Mikko Raatikainen∗ ∗ Aalto
University, School of Science, Finland {vittorio.dal.bianco, varvana.myllarniemi, mikko.raatikainen}@aalto.fi † F-Secure Corporation, Finland
[email protected] Abstract—The success of software ecosystems highly depends on the variety and quality of end-user applications. Therefore, attracting third-party developers and facilitating application development is crucial. Platform boundary resources enable thirdparty developers to create the applications. Thus, the platform boundary resources expose and extend the platform architecture. We conducted an industrial case study on third-party developer experience, particularly on the role of platform boundary resources in exposing the platform architecture and facilitating development. The studied ecosystem is centered on managing end-users’ content across devices; the ecosystem was in its precommercial phase. The results identify the platform boundary resources in the case study and propose a model for classifying the resources. Further, designing the platform boundary resources is not only about opening up the platform architecture. Instead, the platform boundary resources need to account for a rich variety of applications, or at least not limit too much the creativity of thirdparty developers, while still aiming at the ease of development. We conclude that the platform boundary resources need to be created for the third-party developers, rather than from the platform architecture.
I.
Within a software ecosystem, third-party applications are typically end-user applications that are built on top of platform architecture by third-party developers. The third-party developers and applications utilize the assets of the ecosystem that are referred to as platform boundary resources [9]. Platform boundary resources are the key means for exposing and extending the platform architecture in order to facilitate thirdparty application development [9], and an important factor for successful ecosystems. This paper presents a descriptive case study [15] on the role of platform boundary resources in exposing and extending the platform architecture and enabling third-party application development. In particular, the research questions are set as follows:
I NTRODUCTION
What different kinds of platform boundary resources exist in software ecosystems?
RQ2
How does the platform architecture influence the platform boundary resources?
RQ3
How do platform boundary resources support or hinder the development of third-party applications?
The studied ecosystem, Content Anywhere (CAN)1 ecosystem, is being developed by a company called F-Secure. CAN stores users’ data from a device to a cloud storage safely and securely and it enables the sharing and accessing of data from other devices. Additional third-party applications can be developed to provide functionality on top of user’s content in various ways, thus creating an ecosystem.
Software ecosystems, which have evolved from component-based systems [1], software platforms [2], and software product lines [3], are increasingly common for software organizations [4]. Software ecosystems are emerging because companies are facing the fact that the amount of functionality that is needed to satisfy customer needs is more than what represents a reasonable investment [5], [6]. By opening up their product into an ecosystem, the companies also give up part of their control and design capabilities [7] to harness open innovation [8]. However, there is no guarantee that enacting a software ecosystem strategy will lead to a great success [9].
This study provides the following contributions. Our case study addresses the lack of research on real-world ecosystems [10]. For the case study ecosystem, we identify the platform boundary resources. To extend the model of classifying the platform boundary resources into technical and social [14], we propose an onion model of three levels of platform boundary resources that facilitate third-party development. Further, we describe the relations between platform boundary resources, platform architecture, and third-party development. The results highlight the importance of platform boundary resources in facilitating the third-party development: the platform boundary resources need to support a rich variety of applications, be easy to understand and efficient in enabling development, and not limit too much the creativity of thirdparty development. Thus, designing the platform boundary
All participants benefit from a thriving ecosystem [10]. In fact, software ecosystems can be characterized as two-sided markets [11], where on the different sides are end-users and third-party developers. On the one hand, the key to success is to rapidly achieve a large end-user base that attracts thirdparty developers, while, on the other hand, the end-users are attracted by and benefit from the number of applications in the ecosystem where active third-party developers are essential [12], [5]. This phenomenon is called cross-side network effect [11]. Therefore, attracting third-party developers [13], [14] and facilitating application development is crucial for the ecosystems [5], [14]. 978-1-4799-3412-6/14 $31.00 © 2014 IEEE DOI 10.1109/WICSA.2014.41
RQ1
1 CAN was in pre-commercial phase at the time of conducting the study and has also been released recently as younited service (www.younited.com).
11
resources is not merely about opening up the platform architecture.
Software Ecosystem End User
The rest of the paper is organized as follows. On the basis of existing literature, Section II elaborates the key concepts of the research questions. Section III describes the applied case study method. The case company and the ecosystem are described in IV. Section V describes the results in the light of the research questions while Section VI discusses the results. Conclusions are drawn in Section VII. II.
Software Ecosystem Architecture
Selects & Uses
Selects & Uses
Platform Architecture Technical TechnicalBoundary Boundary Resource Resource
Accesses & Is built using
BACKGROUND
In the following, software ecosystems in general and platform architecture and platform boundary resources are described as the essential background for the remaining paper.
Thid-Party Application
Concerns Develops & Maintains
A. Software Ecosystems
Provides & Interacts through
Software ecosystems can be defined as “a set of businesses functioning as a unit and interacting with a shared market for software and services, together with the relationships among them” [16] where “relationships are frequently underpinned by a common technological platform or market and operate through the exchange of information, resources and artifacts” [16]. A software ecosystem exists around a central technology that is often referred to as a software platform [10]. Participants can take different roles in the ecosystem.
Keystone Player
Fig. 1.
Develops & Maintains
Social SocialBoundary Boundary Resource Resource
Uses & Interacts through
Third-Party Developer
Software ecosystem architecture, platform architecture, and actors.
to being by the member organizations rather than being one of the key constituents” [17]. An example of a consortiumbased ecosystem is the Eclipse project [19], which is governed by the non-profit, member-supported Eclipse foundation. The Eclipse foundation has the organizational structure similar of a company, and it exerts company-like control: e.g., developers need to go through a specific legal process when committing code [10]. Thirdly, there may be ecosystems with no referent organization. Many open source communities belong to this type of ecosystems: the ecosystem platform constitutes of Free/libre/open Source Software (FLOSS) [20]. This case study and its findings focus on keystone-centric ecosystems.
Technically, software ecosystems have the following characteristics [17]. Software ecosystems have a central organization that links to others by interface relations, thus having control not over others specific choices but “over the premises of choice” [18]. Software ecosystems have a self-regulatory behaviour: for example, a product line controlled in a centralized way turns into a collaborative approach where the central organization adapts to the surrounding environment and vice versa [17]. Software ecosystems are networked: the network consists of all participants, potentially even of competitors, and thus can be understood as an innovation network [8]. Software ecosystems depend on information and communication technologies: not only on the software platform, but also on the tools that enable collaboration among different participants. The participants in a software ecosystem share value: through the software platform; licensing; having different revenue models; and by providing an improved solution for the end users. The shared value, which is both the software product and the business domain, provides the motivation to contribute to the ecosystem and its technology. Finally, software development is a shared responsibility between the central organization and the other participants; thus there is a shift of control towards third-parties and end-users. This motivates the collaboration and encourages all ecosystem actors.
B. Platform Architecture and Platform Boundary Resources Within software ecosystems, the platform is the key technological resource [10], [21]. The platform may be one vendor’s product, a standard system architecture, or a communications protocol [21]. From a technology perspective, a platform may be a mobile OS or an application; it can be desktopbased, web-based or device-based [5]. Sometimes the software platform can be used as a stand-alone product but at the same time it allows integration with other applications and services; examples include Google Maps [8] and Eclipse [19]. To follow the definition of the software architecture [22], the platform architecture can be considered as the fundamental organization of the platform, embodied in the components and their relationships to each other and to the environment. However, third-party applications are an essential part of the software ecosystem, which means that the architecture must consider structures beyond the imminent boundary of the platform itself. Therefore, the software ecosystem architecture can be considered consisting of the platform architecture as well as of third-party applications (see Fig. 1). Our definition of the ecosystem architecture is different from [10] in a sense
The software ecosystems can be organized in different ways. Firstly, in the keystone-centric software ecosystem, the central organization, called a keystone organization or keystone player, controls the software platform. Most of the famous commercial ecosystems are keystone-centric; including Android, iOS, and Windows Mobile ecosystems. Often, this kind of ecosystem is evolved from a previously closed software product line or product (c.f., [17]), in the simplest way, by opening up APIs. Secondly, in the consortium-based software ecosystem, there is a central organization, but it is “brought in
12
that the actors are not considered being a part of the ecosystem architecture, but actors are entities that interact with the ecosystem architecture. Fig. 1 illustrates the actors. The keystone player is a company or an organization responsible for the development and governance of the software platform. Thirdparty developers, who can belong to third-party organizations, use the resources exposed by the software platform to produce applications upon it. End-users select and use both the platform as well as applications built on top of it.
disciplines. Additionally, as we progressed with data analysis, we felt that the existing division into technical and social boundary resources was not sufficiently descriptive. Therefore, we proposed definitions and a refined model to organize the platform boundary resources. III.
R ESEARCH M ETHOD
The research was conducted as a descriptive case study [15]. The objectives were to make observations about industrial practice in a software ecosystem and make conceptual generalizations [24], [25]. The unit of analysis was the software ecosystem, and as a subunit of analysis, the platform boundary resources. We selected the case because of easy accessibility to the case as a part of a collaboration with FSecure within a research program, F-Secure’s needs conformed with the research interests, and availability of rich data.
The style of the platform architecture is crucial in the success of the ecosystem [21]. This is because the platform architecture must enable the integration of third-party applications. In this sense, a minimal requirement for the platform architecture is to be modular [23]. A platform architecture may be organized as a layered modular architecture [8], or using plugins or interpreters [21]. An important property of the software platform is that it is extensible beyond the borders of the organization controlling it [17]. The keystone player needs to effectively provide the third-party developers with the resources to build applications on top of the software platform: these resources are called platform boundary resources [9], [14]. The platform boundary resources are a means for the keystone player to control and influence what happens in the software ecosystems, while benefiting from the generativity of third-party development [9]. Further, platform boundary resources minimize the coordination effort between the third-party developers and the keystone player.
The data collection took place primarily via a hackathon [26] event organized by the F-Secure. A hackathon (hacking marathon) refers to a highly engaging continuous event, where people in small groups participate in an intensive activity producing tangible results in a limited amount of time. F-Secure organized the three-day hackathon to assess the ease of third-party application development for CAN Ecosystem, to see how the requirements for third-party applications are fulfilled, and the enablers and obstacles to third-party development. Moreover, F-Secure wished to learn more about hackathons, since the hackathon was the first one organized at F-Secure. This hackathon was an internal event: F-Secure’s engineers, who were not been previously involved in the development of CAN Ecosystem, volunteered to take the role of third-party developers. During the hackathon, the data collection included observations throughout the hackathon resulting in written notes; a questionnaire containing ’keep’, ’drop’ and ’try’ fields adopted from agile practices and referring to things that should be kept similar, things that should be abandoned, and things that should be tried; and a log of the group chat used by the participants. We additionally carried out and transcribed about hour-long semi-structured interviews within in the weeks following the hackathon with 12 participants. During the interviews, the previously distribute simple graph-questionnaire about feelings during hackathon were used to trigger questions about difficulties encountered during the hackathon. The interviews chronologically and thematically covered the activities in development from the preparations of the hackathon to the demo and possible further development, and especially the positive or negative experiences related to the use of platform boundary resources. In addition, few technical documents were analyzed separately.
According to Ghazawneh [14], platform boundary resources can be organized in two classes (see Fig. 1). The technical boundary resources provide technical feasibility for the development of third-party applications and are used to access the platform. Application programming interfaces (APIs) are the most commonly recognized form of technical boundary resources. More elaborate cases may include software development kits (SDKs) or even fully integrated development environments (IDE) with additional tools, like debuggers and compilers. Therefore, the technical boundary resources expose and extend the platform architecture (see Fig. 1). The social boundary resources are meant to transfer the knowledge of creating software and to act as a means of interaction between the keystone player and developers. In fact, creating good software requires “...strong connection with all the stakeholders...not only users but managers, administrators ...and others” [23]; thus “creating software is ultimately a highly social activity” [23]. Examples of social boundary resources include incentives, intellectual propriety rights (IPR), platform guidelines and documentation [14], but also training material, promotion and training events, and online community forums. Therefore, the social boundary resources explain the platform architecture to third-party developers (see Fig. 1).
The data analysis was carried out following the conventions of grounded theory analysis [27], [24] using Atlas.ti in order to accumulate empirical evidence around concepts. The essential basis for the analysis and the initial set of codes arose partly from the first-hand experience gained from observations, partly from the concepts in the literature, such as platform boundary resources [9], [14]. This initial set of codes was used for coding the interview transcripts, the observation notes, and the group chat log. The codes were created and refined iteratively as we noticed a concept gaining importance during the data analysis phase. Constant comparison [24] was also
At the beginning of this case study, we used the Ghazawneh’s [9], [14] concept of platform boundary resources and the division between social and technical as lenses to do our research. However, progressing with the data collection and analysis, we realized that Ghazawneh [9], [14] does not provide clear definitions but merely examples. For this reason, we took a research challenge to better understand the essence of platform boundary resources, keeping in mind they are based on the concept of boundary objects [14] from design
13
utilized especially when several interviewees were mentioning similar issues. This was done with the goal of condensing more and more refined empirical knowledge around the codes. During the analysis, the concepts related to the platform architecture emerged from the interviews. This also served as a lense to generalize the low-level concepts, for example, to classify different kinds of platform boundary resources. Thus, all concepts within the contribution either emerged or were refined by data.
App
