Software Architecture: Organizational Perspectives Paul L Bannerman NICTA and School of Computer Science and Engineering, University of NSW, Sydney, Australia paul.bannerman@nicta.com.au Abstract This position paper examines software architecture through the lenses of four organizational perspectives and identifies opportunities for research to improve the positioning and support of the discipline within organizations. It concludes that while software architecture may rest on solid technical foundations, its position in the organization is not as firm. 1. Introduction As a functional discipline, software architecture (SA) recognizes that its effectiveness depends on non- technical factors as well as technical competences. For example, the support of the organizational ecosystem is recognized as essential in establishing, orchestrating and sustaining SA and software architects [7]. This paper reverses the perspective and argues that how SA is viewed, valued and supported by the organization – that is, how it establishes it value to the organization – also critically determines its success. The paper examines SA externally, from four basic organizational perspectives: management and leadership; governance; capabilities; and strategy. Based on these perspectives, it finds that there are opportunities for SA to improve its position within the organization. Areas for further research are proposed. Section 2 presents the analyses through the four organizational lenses and Section 3 integrates the findings and illustrates effective embedded SA with a case study, before conclusions are drawn. 2. Organizational perspectives of software architecture and related challenges Software architecture is a diverse collection of practices. The capabilities of the software architect are described by the profession as both broad and deep, encompassing technology, design, standards, solution determination, application domains, decision-making, software development processes, programming, non- functional requirements, communication, mentoring, strategy, management, leadership, negotiation, politics, diplomacy, consulting, risk management and quality assurance [8, 9, 11, 18]. While it is not explicitly expected that all these capabilities are vested in every architect (indeed, many are shared with developers), there is a strong implication that they are all necessary to competently fulfill the range of duties and challenges of SA in software developing organizations. Furthermore, there is great diversity in the application of SA because of differences in the contexts of software-developing organizations. For example, product suite developers will have different architectural challenges to shrink-wrapped software, customized application, and component developers. This makes it difficult to generalize about architecture practices. However, looking beyond this diversity, considering software architecture as an organizational function from an organizational perspective, there are three major challenges that SA faces in gaining visibility, acceptance and support from the organization. First, software architecture is a technical specialty that operates at a low level within the organization, which means that its contribution is not readily visible or demonstrable. Linking architecturally significant business drivers (such as quality attributes) to realized systems via architectures is important for business value creation [13], but this often has limited visibility in practical terms at the business level. For example, goals such as reduce costs and improve quality, processes and market position attract contributions from all organizational activities. Therefore, it can be difficult for SA to demonstrate its specific contribution to business-level outcomes and its value to the firm. Second, software architects do not have sole claim to architecture within all software organizations. As much as software architects might disagree, similar technical outcomes can often be achieved within traditional software development methods by software design and coding practices (after all, a common view is that good developers make good software LMSA’09, May 19, 2009, Vancouver, Canada 978-1-4244-3717-7/09/$25.00  2009 IEEE ICSE’09 Workshop 37 Authorized licensed use limited to: UNSW Library. Downloaded on June 24, 2009 at 21:34 from IEEE Xplore. Restrictions apply.