Architecture challenges for software ecosystems - ACM Digital Library

22 downloads 119 Views 513KB Size Report
Successful software products and product lines exhibit a force of gravity that attracts external developers. The organization developing the product actively seeks ...
Architecture Challenges for Software Ecosystems Jan Bosch Intuit, Mountain View, CA. [email protected] increasing adoption of a software ecosystem approach. Companies that successful software systems or software product lines experience significant internal and external pressure to open up their interfaces to the outside world [1]. As companies increasingly aim to reposition as networked organizations and reduce their own headcount, outside partners perform significant parts of development. In addition, companies are introducing app-store styled approaches to increase the richness of functionality provided to their customers. This causes a number of challenges on the architecture of the software ecosystem platform. First, it has to provide a stable interface between the platform and the external developers that evolves in a predictable fashion. Second, it has to allow for an appropriate level of integration between the platform and externally developed solutions. Depending on the type of domain, the integration may be limited to a common UI framework, but frequently the integration needs to include the workflow and the data stored in the system. In some cases, the architecture also needs to facilitate integration between two or more externally developed products which adds yet another layer of complexity. Third, the architecture needs to minimize the opportunities for defective or malicious external code to affect the whole system. Although the architecture can never fully address this requirement and often a certification process is required, it can provide significant security boundaries. Fourth, the evolution of software platform inexorably causes it to incorporate functionality that earlier was developed by external developers. In order to minimize the impact of these transitions, the architecture needs to be carefully designed and often announced long before the actual release takes place. This is challenging because deciding upon the right interfaces without actual use of these interfaces by clients is challenging. Finally, most platforms tend to grow in size over time because functionality gets added but never removed. It is important to proactively re-architect the platform in order to replace proprietary code with commercial or open source components. In the remainder of this short paper, the aforementioned challenges are discussed in more detail in the next section, followed by a conclusions section.

Abstract Successful software products and product lines exhibit a force of gravity that attracts external developers. The organization developing the product actively seeks to involve external developers to add functionality to the system. On the other hand, external developers flock to a successful product as it provides an established market where underserved niches provide a business opportunity for these players. The product or product line evolves into a platform for external developers. This causes several software architecture challenges for a software ecosystem, including interface stability, evolution management, guaranteeing security and reliability and composition of independently developed functionality. The paper describes these challenges, discusses practical solutions and identifies research challenges.

1. Setting the Context Software engineering continues to evolve at an enormous rate, both in terms of the size of systems built as well as the speed at which these systems are deployed and evolve. This requires software engineering practitioners, including architects, to continuously develop new approaches to manage the consequent implications for the complexity of software. For large classes of systems, this now means that most software development is more concerned with composition of existing open-source, commercial and internally developed components in creative configurations than with the creation of significant amounts of new software. The new software development is constrained to the truly differentiating functionality that defines the competitive advantage for the system. The consequence of this is obviously that easy composition of software assets increases in importance. The trend discussed above instigates the trend of the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ECSA 2010, August 23-26, 2010, Copenhagen, Denmark. Copyright 2010 ACM 978-1-4503-0179-4/10/08…$10.00.

93

for external developers to adjust their applications or to prepare new functionality exploiting the new interface. Secondly, backward compatibility and avoidance of binary breaks is of enormous importance. In practice, both aspects are difficult to achieve as these require significant predictive abilities by the architect and development team.

2. Architecture Challenges for Software Ecosystems Software ecosystems often are formed around a successful product or product line. As the number of customers using the products from the product line increases, there are external and internal forces that drive the product or product line to provide an application programming interface (API) externally so that external developers, in a directed or undirected fashion, can build functionality that the platform organization either does not want or is unable to develop itself. The challenge while starting a software ecosystem is often one of economics: how can application developers build a business of their own with niche functionality? If the platform organization too aggressively incorporates new functionality into its platform and leaves too little on the table for external developers, the ecosystem developers will focus their energy on other platforms. On the other hand, if the platform only contains commoditized functionality, there is no developer benefit nor a long-term customer base. From a technical perspective, the architecture of the product or product line, including its interface to external developers, is the central and critical pillar that holds the ecosystem effort up. Serious mistakes from a software architecture perspective will cause significant dissatisfaction and abandonment among the external developers. In the remainder of this section, we discuss five architectural challenges that need to be addressed and solved well for a software ecosystem effort to be successful.

Data, workflow and UI integration The second architectural challenge is concerned with deciding upon and designing the level of integration that is allowed for externally developed applications. In practice, one can decide three levels of integration. At a minimum, the use of a common UI framework allows for common look-and-feel but otherwise does not allow for deeper integration in the platform. The second level is that the externally developed applications can be integrated in the workflow of use cases, consequently extending the functionality in the use case. The third level is concerned with external applications gaining access to the data stored in the platform. The challenge in the latter two cases is that incorrectly designed or malicious external applications are able to corrupt the basic system. However, this is discussed below in a different challenge. Finally, in some cases, the architecture also needs to facilitate integration between two or more externally developed applications which adds yet another layer of complexity. The architectural challenge is this case is rather obvious: designing the integration at each of the levels of UI, workflow and data is difficult as it requires deep understanding of the abilities that external developers want to have access to. The complexity of the final solution needs to be limited to the extent possible as simplicity will increase adoption of the platform and it will simplify maintaining interface stability over time.

Interface stability Once the organization decides to give external developers the opportunity to build functionality that complements the product or product line, it is required that a platform interface is defined that external developers can use to develop against. In this case, obviously, the interface has to be sufficiently expressive that external developers can build relevant functionality. On the other hand, it also should decouple the platform organization from the external developer community to the extent possible. Achieving this allows the platform organization to release new version of the product or new products in the product line without having to be concerned with disabling the externally developed applications operating on top of the platform. No interface, however, can be static and consequently the platform interface needs to evolve over time. The architectural challenge is firstly to allow the interface to evolve in a predictable fashion and with significant time

Security and Reliability Concerns The customers of the platform, be it a unique product or a product out of a product line, will use the composition of the original product and the various external applications developed on top of the platform. This leads to security and reliability concerns as defective or malicious code in externally developed applications may cause the overall system to become disabled. Although the architecture can only minimize the opportunities for defective or malicious external code to affect the whole system, it does play a significant role in minimizing the overall risk to the system. Typically, a certification process is required that evaluates the external product from a correctness and maliciousness perspective. However, as certification adds a significant barrier for external application developers, the more light-weight the process can be the better. 94

Security and reliability concerns addresses by the architecture simplify the certification process. The architecture challenge is twofold. First, the scenarios in which defective or malicious code can affect the system negatively need to be understood well. These scenarios should be addressed in the external interface of the platform to the extent possible. Second, as it is impossible to predict all the ways in which the platform will be used, responses are constantly needed when new vulnerabilities are identified. However, this should be achieved without violating interface stability.

competitive edge over time. The obvious need is to find ways to remove code from the platform at the same rate as functionality is added. The architectural challenge is to proactively rearchitect the platform in order to replace proprietary code with commercial or open source components. This requires proprietary interfaces to be evolved towards industry-standard interfaces for which often multiple publicly available components are available.

Evolution: Including New Functionality

Successful products and software product lines often evolve to software ecosystems as the organization is unable and unwilling to develop all the functionality requested by its customers and because external developers recognize the product or product line as a highly relevant market opportunity for their area of expertise. Once the organization decides to open up to outside developers, there is a host of business and architectural challenges that need to be addressed. Interestingly, where the organization earlier was able to address weaknesses in its business and architectural strategies through imposing process on its R&D organization, this is not an option in the case of external developers. Consequently, the organization needs to increase its architectural capability to compensate for its lack of process control, except for a certification process, over its external developers. In this paper, we have addressed what in our experience are give key architectural challenges. These include interface stability, integration of UI, workflow and data, security and reliability, incorporating new functionality and, finally, refactoring the platform to replace proprietary functionality with commercial or open-source software components.

3. Conclusion

Virtually all functionality starts out as highly differentiating, possibly even specific for an individual customer. Over time, the functionality “commoditizes” and becomes less differentiating, until it becomes a commodity. In response to this trend, the software platform needs to evolve by incorporating functionality that earlier was developed by external developers. In order to minimize the impact of these transitions, the architecture needs to be carefully designed and interface changes need to be announced long before the actual release takes place. The architectural challenge is, again, twofold. Together with the product management function, the scope of the platform needs to be constantly adjusted upwards and incorporate new functionality that needs to be exposed through the interface. Secondly, the interfaces need to be published significantly ahead of the time of deployment in order to give external developers the opportunity to adjust their application and exploit the new functionality. Giving the need for interface stability, deciding upon the right interfaces without actual use of these interfaces by clients is difficult. Evolution: slimming down the platform

References

The final architectural challenge discussed in the paper is concerned with an often-ignored aspect of software platforms. As platforms are concerned with continuously adding new functionality, the total size of the platform is constantly increasing. As system size is directly correlated to system complexity and inversely to developer productivity, platforms tend to erode and lose their

[1] Jan Bosch, From Software Product Lines to Software Ecosystems, Proceedings of the 13th International Software Product Line Conference (SPLC 2009), August 2009.

95