Software Architecture as a Set of Architectural Design Decisions Anton Jansen Department of Computing Science University of Groningen PO BOX 800, 9700 AV, The Netherlands anton@cs.rug.nl Jan Bosch Software & Application Technologies Lab Nokia Research Center PO BOX 407, FI-00045, Finland jan.bosch@nokia.com Abstract Software architectures have high costs for change, are complex, and erode during evolution. We believe these problems are partially due to knowledge vaporization. Cur- rently, almost all the knowledge and information about the design decisions the architecture is based on are implicitly embedded in the architecture, but lack a first-class repre- sentation. Consequently, knowledge about these design de- cisions disappears into the architecture, which leads to the aforementioned problems. In this paper, a new perspective on software architecture is presented, which views software architecture as a composition of a set of explicit design de- cisions. This perspective makes architectural design deci- sions an explicit part of a software architecture. Conse- quently, knowledge vaporization is reduced, thereby allevi- ating some of the fundamental problems of software archi- tecture. 1 Introduction Software architecture [17] has become a generally ac- cepted concept in research and industry. The importance of stressing the components and their connectors of a software system is generally recognized and has led to better control over the design, development, and evolution of large and increasingly dynamic software systems [4]. Although the achievements of software architecture are formidable, still some problems remain. The complexity, high costs of change, and design erosion are some of the fundamental problems of software architecture. We believe these problems are partially due to knowledge vaporization. Currently, almost all the knowledge and information regard- ing the design decisions on which the architecture is based on (e.g. results of domain analysis, architectural styles used, trade-offs made etc.) are implicitly embedded in the archi- tecture, but lack a first class representation. The current perspective on software architecture lacks this notion of architectural design decisions, although ar- chitectural design decisions play a crucial role in software architecture, e.g. during design, development, evolution, reuse and integration of software architectures. In design, the main concern is which design decision to make. In de- velopment, it is important to know which and why certain design decisions have been taken. Architecture evolution is about making new design decisions or removing obso- lete ones to satisfy changing requirements. The challenge is to do this in harmony with the existing design decisions. Reuse of software architecture is the use of earlier tried and tested combinations of design decisions (e.g. design pat- terns or components). In the integration of systems, the main concern is the unification of the design decisions and their assumptions. To address this, we propose a new perspective on soft- ware architecture: we define software architecture as the composition of a set of architectural design decisions. This reduces the knowledge vaporization of design decision in- formation, since design decisions have become an explicit part of the architecture. The contribution of this paper threefold. First, the prob- lems with the current perspective on software architecture are presented. Second, it develops the notion of software architecture as the composition of a set of explicit architec- tural design decisions. Third, various views are presented for visualizing this new architecture perspective. The remainder of this paper is organized as follows. The concept of architectural design decisions is presented in sec- tion 2. In section 3, the problems of software architecture with respect to architectural design decisions are explained in more depth. The next section introduces Archium, our approach to describe software architecture as a set of ar- chitectural design decisions. The approach is applied to a case and illustrated with various views on design decisions in section 6. After this, related work is discussed. The paper concludes with future work and conclusions in section 8. 1