Architecture challenges for internal software ecosystems: A large-scale industry case study

Abstract

The idea of software ecosystems encourages organizations to open software projects for external businesses, governing the cross-organizational development by architectural and other measures. Even within a single organization, this paradigm can be of high value for large-scale decentralized software projects that involve various internal, yet self-contained organizational units. However, this intra-organizational decentralization causes architecture challenges that must be understood to reason about suitable architectural measures. In our FSE paper, we present an in-depth case study on collaboration and architecture challenges in two of these large-scale software projects at Siemens. We performed a total of 46 hours of semi-structured interviews with 17 leading software architects from all involved organizational units. Our major findings are: (1) three collaboration models on a continuum that ranges from high to low coupling, (2) a classification of architecture challenges, together with (3) a qualitative and quantitative exposure of recurring issues along each collaboration model. We identified compliant software development as the core challenge. It targets cross-cutting regulations and architecture governance to assist and check for compliance. In addition to our study results, we outline a framework along with tool support that allows to manage these regulations and their violations throughout the life cycle. Internal Software Ecosystems We have investigated two large-scale software projects (about 500 and 950 developers) within Siemens [SEL14]. These projects 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) [SEL14]. ISECOs comprise a keystone organizational unit that provides a platform and multiple client organizational units that build applications upon it. The keystone acts in a creative role but does not have power to direct. Our talk is laid out as follows: First, we outline our study results. Second, we present our current work, a framework that addresses the compliant software development challenge. 114 Case Study Results: