No abstract

No abstract

Two years ago, we analyzed the architecture of Sagitta 2000/SD, a large business information system being developed on behalf of Dutch Customs. We were in particular interested in assessing the capabilities of the system to accommodate future complex changes. We asked stakeholders to bring forward possible changes to the system, and next investigated how these changes would affect the software architecture. Since then, the system has been implemented and used, and actual modifications have been proposed and realized. We studied all 117 change requests submitted since our initial analysis. The present paper addresses how well we have been able to predict complex changes during our initial analysis, and how and to what extent the process to elicit and assess the impact of such changes might be improved. This study suggests that architecture analysis can be improved if we explicitly challenge the initial requirements. The study also hints at some fundamental limitations of this type of analysis:(1) fundamental modifiability-related decisions need not be visible in the documentation available, (2) the actual evolution of a system remains, to a large extent, unpredictable and (3) some changes concern complex components, and this complexity might not be known at the architecture level, and/or be unavoidable.

Software architecture analysis helps us assess the quality of a software system at an early stage. In this paper we describe a case study of software architecture analysis that we have performed to assess the flexibility of a large administrative system. Our analysis was based on scenarios, representing possible changes to the requirements of the system and its environment. Assessing the effect of these scenarios provides insight into the flexibility of the system. One of the problems is to express the effect of a scenario in such a way that it provides insight into the complexity of the necessary changes. Part of our research is directed at developing an instrument for doing just that. This instrument is applied in the analysis described in this paper.

Software architecture is generally regarded as an important tool to achieve systems of higher quality. It is claimed that the foundation for a system's quality is laid by the decisions made in the software architecture. A question that is occupying both researchers and practitioners is in which areas should decisions be made in the software architecture? We believe architectural view models play an important role in the answer to this question. View models consist of a coherent set of architectural views. These view models have both a prescriptive and a descriptive role in the development process. Their prescriptive role is that they call for a number of aspects to be considered when defining a software architecture and their descriptive role is that they provide a framework to document a software architecture. Currently, a number of view models exist, the most important of which are the 4+1 View Model of Kruchten and the four views by Soni et al. In our experience with modifiability analysis for business information systems we found that the views in current view models do not include all information required. In this paper we discuss the views we found useful for architecture level impact analysis of business information systems. They are illustrated using a case study we performed for the Dutch Tax and Customs Administration. We claim that when these views are required for architecture level impact analysis, the decisions they capture should also be considered during architecture development.