the case of Software Ecosystems

Open Architectures and Software Evolution: the case of Software Ecosystems Patrizio Pelliccione Chalmers University of Technology | University of Gothenburg, Department of Computer Science and Engineering, Sweden [email protected]

Abstract—Software systems are increasingly constructed on top of a software platform by adding and composing components that more often than not are developed by external actors. Those platforms project into software systems their own architecture and concepts and impose constraints; this strongly influences how components are developed and/or integrated. It is generally recognized that software architectures play a key role in managing software ecosystems and their evolution. While commercially there is an undeniable and increasing interest in software ecosystems, e.g., the Apple’s iOS, Google’s Android, Amazon.com, research in this domain is still in its infancy. This paper analyses, from the software architecture perspective, the state-of-the-art in software ecosystems and highlights future research directions from a technical point of view. Keywords-Software architecture; software ecosystems; open architectures; software evolution.

I. I NTRODUCTION The way software is produced is rapidly changing and increasingly software systems are built by integrating existing services and components according to a specific goal [1]. Development in this context is becoming rapid, flexible, and agile thus asking to rethink traditional approaches, where a producer invest time on producing artefacts and he is the only owner of those artefacts [1]. Moreover, the typical assumption that software is provided together with a machine readable documentation, which can be exploited for reusing purposes, easily turns out to be unfounded [2]. Therefore, the knowledge about services and components to be used is gathered experimentally [1], and the software is continuously validated by learning from real-time customer usage of software [3]. This trend affects also an increasing number of companies. They open up their successful products and product lines for extensions by third party developers [4], [5], [6]. This phenomenon might be explained by a number of convincing arguments [7], such as increase attractiveness and accelerate innovation. Examples of successful ecosystems are Google’s Android, Apple’s iOS, Amazon.com, Apache, Salesforce.com. To tame this openness organizations make use of platforms on top of which external developers can define extensions. Those platforms have their own software architecture that regulates how extensions are built. In other words, extensions of the platform are built, adapted, and integrated according to constraints and rules imposed by

platforms [8]. Software architecture plays a key role in managing software ecosystems and their evolution, e.g., software architecture: • is the key artifact to link ecosystem technicalities with business goals of involved stakeholders [9], • supports communication and knowledge management between the different stakeholders [10], • defines the boundaries of evolution of the ecosystem and helps ensuring the maintenance of the desired and required levels of security, reliability, safety, etc., • defines the degree of freedom for platform extenders [6]. It is in fact recognized that wrong architectural decisions might seriously compromise the success of an ecosystem [11], and platform architectures and their quality attributes strongly influence the behaviour of platform extenders, both positively and negatively [12]. Many research challenges emerge, even considering that research in this domain is still in its infancy [8]. This paper aims at contributing on that by shortly surveying the state-of-the-art and by discussing emergent research challenges of software ecosystem architectures. The paper is structured as follows: Section II provides an overview of software ecosystems and research results in this field. Section III discusses discrepancies between the state-of-the-art and the-state-of-the-practice in the field of software ecosystems software architectures and describes architecture research challenges of such systems from a technical perspective. The paper concludes with final remarks in Section IV. II. S OFTWARE ECOSYSTEMS The first definition of software ecosystems has been proposed by Messerschmitt and Szypersky in 2005 [4] as a “collection of software products that have some given degree of symbiotic relationships”. Several other definitions have been proposed in the last years by refining the concept of symbiotic relationships into the concept of software and technological platform. For instance, Jansen et al. [6] define a software ecosystem as “a set of actors functioning as a unit and interacting with a shared market for software and services, together with the relationships among them”. The work in [8] describes a systematic literature review of software ecosystem research, performed by collecting

420 paper and then analysing 90 of them. Authors count 43 ecosystems appearing in the literature. They conclude highlighting that there is a growing interest on software ecosystems even though there is not general consensus on what an ecosystem is, and, in general, more research is needed especially in defining analytical models and in the context of real-world ecosystems. Three are the main stakeholders of a software ecosystem: 1) the platform supplier, which is the entity that provides the software ecosystem platform, 2) the platform extenders, which are the external developers that provide independent extensions to the platform, and 3) the customer who composes the system by integrating the software platform with selected independent extensions [5]. These three main stakeholders appear to be a reasonable abstraction of the reality even though sometimes the different roles might be intermixed and other stakeholders might be required; for instance the final end-user might be an additional stakeholder when the customer who composes the system is an entity different from the final end-user. An important distinction needs to be made: some ecosystems are created and maintained by a keystone company, other ecosystems are built around a keystone open-source community. In the first case a company realizes that it is strategic for its business to open the development of new functionalities to external developers. For instance, the company might realize that the R&D it can offer is not enough to satisfy the needs of their customers [5]. Obviously the objective of the company is having return on investment without losing the ownership and the style of the company that characterizes his products. This might lead on having a restrictive platform and even on selecting trusted partners that can play the role of external developers so to alleviate the need of certifying, testing, inspecting, and analysing extensions. In the second case the entity that builds and maintains the ecosystem is an open-source community without a keystone partner responsible of managing the ecosystem. However, complex and large open-source communities are somehow structured, such as the Linux community, and then the distinction among the platform supplier and the platform extender stakeholders is maintained even though the boundaries between them is no so marked. Often in opensource software ecosystems, platform extenders have full freedom in evolving but also on changing the software even though this can cause a divergence from the main baseline. III. S OFTWARE ECOSYSTEMS ARCHITECTURE Software architecture is recognized to be a valid basis for, among others, (i) analysing software systems before the system has been built [13], (ii) making and evaluating early design decisions that impact a system’s life [14], (iii)

facilitating communication with stakeholders, contributing to a system that better fulfills their needs [14], re-use of elements and decisions [13], [14]. When focusing on software ecosystems, the software ecosystems architecture has be defined, based on the definition provided by Bass et al. [14], as “the structure or structures of the system, which comprises software elements, the external visible properties of these elements, and the relationships among them” [8]. Elements in software ecosystems can be systems, system components, and actors, while relationships include software architecture-related relationships as well of actor-related relationships such the adaptation of new members [8]. A more general definition of software ecosystem architecture might be provided based on the definition of software architecture provided in the IEEE/ISO/IEC standard “Systems and software engineering - Architecture description” [15]: The architecture of an ecosystem is the essence or fundamentals of an open system which is constructed around a software platform by adding and composing components that are often developed by external actors. According to the standard, the characterization of the essence of a system pertains to any or all of: • the system’s constituents or elements; • how its elements are arranged or interrelated; • the principles of the system’s organization or “design”; • the principles governing the evolution of the system. An architecture description is then the work product used to express an architecture. An architecture description includes one or more architecture views. Views seem to be particularly useful in software ecosystems due to the high number of system concerns and involved stakeholders. In fact an architecture view expresses the architecture of the system-of-interest in accordance with an architecture viewpoint that frames one or more system concerns held by stakeholders [15]. Architecture is a central and critical pillar of software ecosystems: wrong design decisions might seriously compromise the success of an ecosystem [11]. Relationships between architecture and platform adoption have been investigated in [12]. This study finds that platform architecture plays a minor role in platform adoption since typically software application developers start development by choosing a software platform that already satisfies a large part of the required functionalities. However, what emerges from this study is that platform architectures and their quality attributes strongly influence the behaviour of platform extenders, both positively and negatively. The software architecture of an ecosystem can be seen as a composition of the software architecture of the platform and of each extension. The platform defines the blueprint of the architecture, by, e.g., providing composition and integration

mechanisms, imposing constraints on how the extensions have to be constructed, regulating how the ecosystem will evolve during its life, and so on. Each extension of the platform affects the architecture of the ecosystem especially due to dependencies among extensions. To explain this concept let us consider the Linux ecosystem. Linux is built on a central notion of software package, and packages are added and assembled to build a specific software system. New features are added to the ecosystem by defining new packages and systems (specific installations) are assembled by installing selected packages. Then each installation might evolve by adding, removing, or replacing packages. These operations are generically called upgrades. Packages have dependencies and conflicts among them; they are declared in package metadata and some hidden dependencies might be implicitly defined in maintainer scripts and configuration files that are launched during the upgrade process [16]. A. Role of architecture in software ecosystems Software architectures have an undoubted importance in creating, managing, and maintaining software ecosystems: • Define the degree of freedom for platform extenders: the architectural decision to keep an architecture closed or to open influences the degree of freedom for any platform extender [6]. As discussed in Section II this is a strategic choice for companies playing the role of platform supplier. • Communication and knowledge management: as highlighted by a survey devoted to understand actual needs of software architecture practitioners, one of the most important need of software architects is having support for communication [17]. In the context of software ecosystems, communication and knowledge management have some peculiarities and specificities since technologies, skills, and knowledge must be shared also with external developers. Platform suppliers need to decide the information and knowledge to be shared with platform extenders [10]. A multi-level communication strategy might be required to properly differentiate information flows within companies, between trusted companies, and with other players. • Bridge between technicalities and business goals: in software ecosystems, software architecture is the key artifact to link the technical implementation with the business goals of both the keystone company and the external developers [9]. B. Research challenges More research is required in the software ecosystems area [8]. In this section we define the most interesting research directions from a technical point of view. 1) Composition and integration: software ecosystems ask for advanced integration means (e.g., mediators, connectors, integration patterns) that ensure the integration of

the extension with the platform in a dependable way, i.e., while preserving the quality characteristics of the ecosystem (see subsection III-B2). Moreover, integration means should support also the integration and composition among existing extensions. The extension built out of existing ones should be released as a “normal” extension so to enable its reuse. Integration means should be automatically synthesized according to the models of the extensions and of the platform and according to the goal of the integration. Several challenges, with respect to the state of the art of in the field of synthesis of mediators and connectors, need to be addressed. One strand of research concerns synthesis techniques to address the problem of inferring integration extra-logic that aims at solving unexpected issues due, e.g., to the incompleteness of the models the synthesis process reasons on [1]. Dependencies of an extension that has been built by composing existing extensions should be automatically calculated taking into account dependencies of the composed extensions. This holds also for conflicts among extensions. Linux might be considered as a reference example for the management of dependencies and conflicts among extensions, called packages in the Linux world [16]. Dependencies and conflicts among packages might change during the ecosystem life-cycle and this should be taken into account. Moreover, some dependencies might be conditional and depending on the presence of particular conditions. The status of the dependency, i.e., if it has been “activated” or not, must be considered also when removing extensions so to keep an ecosystem coherent. This aspect is also not taken into account by Linux [16]. 2) Quality assurance techniques: it is crucial for platform suppliers to have a way of certifying the quality of extensions provided by external developers. Only in this way they can maintain a quality standard already established or to be established with final end-users. Moreover, only through the definition of such mechanisms platform suppliers might have the assurance that both defective and malicious extensions will not affect the entire ecosystem. Quality here might involve different aspects such as security, performance, dependability, etc. The software architecture of the ecosystem might be profitably exploited to define advanced analysis technique for guaranteeing the satisfaction of both functional and non-functional requirements. To be applicable in practice, these techniques must be lightweight and must be able to completely hide formality to end-users. A recent empirical study on architectural languages shows in fact that once companies have to choose between an easy, practical, and informal language and a formal and heavyweight language they select the first one without any doubt [17]. Thanks to lightweight quality assurance techniques, platform suppliers might have a certification suite to execute the required analysis techniques. The idea is to verify a set

of suitably defined properties on each single extension and then, based on the performed verification, the certification suite should be able to guarantee the preservation of quality characteristics of the entire ecosystem. 3) Ecosystem evolution: as highlighted in [11], a software ecosystem has to provide a stable interface between the platform and the external developers and this interface has to evolve in a predictable way. Unfortunately, systems are more and more subject to evolution and the requirement of having the ecosystem evolving in a predictable way might result to be too restrictive. It can be then refined saying that the interface has to evolve in a controlled way, instead of a predictable way. This means that evolution in general cannot be predicted; however it should be supported and controlled by mechanisms devoted to minimize side effects of the evolution, such has backward compatibility. 4) Modeling software ecosystems: despite of the huge number of architectural languages that have been proposed in the last two decades, we are still missing an industry ready, well-accepted, and recognized language for producing architecture descriptions [17]. In the context of ecosystems, things become more and more difficult. However, a language for representing ecosystem architecture is required since it can be considered as the backbone on top of which realizing the other techniques described in this section. The architecture of an ecosystem has to consider the software platform together with extensions, dependencies, and conflicts defined among them. The architecture description, to be useful, should be always perfectly synchronized with the ecosystem evolution. Modeling facilities should support different views so to enable the modeling of different aspects including software technicalities, business, and communication and knowledge management. IV. C ONCLUSION Despite the number of successful ecosystems available on the market, such as Google’s Android, Apple’s iOS, Amazon.com, Apache, research in software ecosystems is still in its infancy. Studying software architecture of ecosystems promises to give great advantage to future ecosystems. In this paper we analysed research that has been made in this topic, highlighted main roles architectures have, and defined research directions from a technical point of view. R EFERENCES [1] P. Inverardi, M. Autili, D. Di Ruscio, P. Pelliccione, and M. Tivoli, “Producing software by integration: challenges and research directions (keynote),” in ESEC/FSE’13. ACM, 2013, pp. 2–12. [2] A. Bertolino, P. Inverardi, P. Pelliccione, and M. Tivoli, “Automatic synthesis of behavior protocols for composable web-services,” in Proceedings of ESEC/FSE ’09. New York, NY, USA: ACM, 2009, pp. 141–150. [Online]. Available: http://doi.acm.org/10.1145/1595696.1595719

[3] H. H. Olsson, H. Alahyari, and J. Bosch, “Climbing the “stairway to heaven” – a multiple-case study exploring barriers in the transition from agile development towards continuous deployment of software,” EUROMICRO conference, pp. 392– 399, 2012. [4] D. G. Messerschmitt and C. Szyperski, Software Ecosystem: Understanding an Indispensable Technology and Industry. The MIT Press, Sep. 2005. [5] J. Bosch, “Software ecosystems: Taking software development beyond the boundaries of the organization,” Journal of Systems and Software, vol. 85, no. 7, pp. 1453 – 1454, 2012. [6] S. Jansen, S. Brinkkemper, J. Souer, and L. Luinenburg, “Shades of gray: Opening up a software producing organization with the open software enterprise model,” Journal of Systems and Software, vol. 85, no. 7, pp. 1495 – 1510, 2012. [7] J. Bosch, “From software product lines to software ecosystems,” in Proceedings of the 13th International Software Product Line Conference, ser. SPLC ’09. Pittsburgh, PA, USA: Carnegie Mellon University, 2009, pp. 111–119. [8] K. Manikas and K. M. Hansen, “Software ecosystems - a systematic literature review,” J. Syst. Softw., vol. 86, no. 5, pp. 1294–1306, May 2013. [9] R. Kazman, M. Gagliardi, and W. Wood, “Scaling up software architecture analysis,” J. Syst. Softw., vol. 85, no. 7, pp. 1511– 1519, Jul. 2012. [10] S. Jansen, A. Finkelstein, and S. Brinkkemper, “A sense of community: A research agenda for software ecosystems,” in Software Engineering - Companion Volume, ICSE 2009., 2009, pp. 187–190. [11] J. Bosch, “Architecture challenges for software ecosystems,” in Proceedings of the Fourth European Conference on Software Architecture: Companion Volume, ser. ECSA ’10. New York, NY, USA: ACM, 2010, pp. 93–95. [12] S. Jansen, “How quality attributes of software platform architectures influence software ecosystems,” in Proceedings of the 2013 International Workshop on Ecosystem Architectures, ser. WEA 2013. New York, NY, USA: ACM, 2013, pp. 6–10. [13] D. E. Perry and A. L. Wolf, “Foundations for the study of software architecture,” SIGSOFT Softw. Eng. Notes, vol. 17, no. 4, pp. 40–52, Oct. 1992. [14] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003. [15] ISO/IEC/IEEE, “ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description,” 2011. [16] R. Di Cosmo, D. Di Ruscio, P. Pelliccione, A. Pierantonio, and S. Zacchiroli, “Supporting software evolution in component-based foss systems,” Science of Computer Programming, vol. 76, no. 12, pp. 1144 – 1160, 2011. [17] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, and A. Tang, “What industry needs from architectural languages: A survey,” IEEE Transactions on Software Engineering, vol. 39, no. 6, pp. 869–891, 2013.