ISECOs: Internal Software Ecosystems
Software product lines proved successful to enable reuse of software within an organization. Adopting software product lines involves the development of core assets for a defined scope and the creation of products by reusing them in a prescribed way. Both activities are governed by a single, common management and target improvements for common business drivers like time to market, cost and quality.
In contrast, in software ecosystems, organizations open their platform to external businesses in order to leverage a variety of externally developed functionality. Those businesses are usually autonomous, act within a decentralized environment and cannot be directed by a common management. Platform provider and external businesses have widely varying business drivers, like innovation, market expansion, profit or visibility. A prominent example is Apple’s iOS where Apple acts as platform provider for thousands of autonomous application developers.
We are investigating two large-scale software projects (about 500 and 950 developers) within Siemens where the reality is somewhere between those two development paradigms. They involve a set of internal organizational units that are self-contained profit centers with own business objectives, organizational independent with own product management, and have to a wide extent autonomous processes and software-engineering life cycles. Thus, the view on the organizational structure moves from strict hierarchies towards more decentralized topologies. We define those systems as internal software ecosystems (ISECOs).
Both ISECOs we are investigating comprise a keystone that provides a platform and multiple clients that build applications upon it. Compared to open ecosystems, the number of clients is low and involved parties can and commonly do communicate directly if required. Moreover, clients develop only one to a handful, but large applications.
This intra-organizational decentralization with independent spheres of authority significantly impacts collaboration in software engineering. We identified (1) three different collaboration models on a continuum that ranges from high to low architecture and process coupling; (2) a classification of architecture challenges, including platform openness strategy, composition of decentralized developed software, preservation of the organizational-units independence, guarantee of software qualities across the ecosystem and compliance to architectural intentions and cross-cutting regulations; together with (3) a qualitative and quantitative exposure of respective recurring issues along each collaboration model [FSE'14].
Compliant Software Development turned out as one of the key challanges. IN WORK ...
Schultis, Klaus-Benedikt ; Elsner, Christoph ; Lohmann, Daniel: Architecture Challenges for Internal Software Ecosystems: A Large-Scale Industry Case Study. In: Cheung, Shing-Chi (Org.) : Proceedings of the 22nd International Symposium on Foundations of Software Engineering (FSE 2014) (22nd International Symposium on Foundations of Software Engineering (FSE 2014) Hong Kong 11/16/2014). New York, NY, USA : ACM Press, 2014, pp 542-552. - ISBN 978-1-4503-3056-5