In any IT-intensive organization, it is useful to have a model to associate a value with software and system architecture decisions. More generally, any effort---a project undertaken by a team---needs to have an associated value to offset its labor and capital costs. Unfortunately, it is extremely difficult to precisely evaluate the benefit of "architecture projects"---those that aim to improve one or more quality attributes of a system via a structural transformation without (generally) changing its behavior. We often resort to anecdotal and informal "hand-waving" arguments of risk reduction or increased developer productivity. These arguments are typically unsatisfying to the management of organizations accustomed to decision-making based on concrete metrics. This paper will discuss research done to address this long-standing dilemma. Specifically, we will present a model derived from analyzing actual projects undertaken at Vistaprint Corporation. The model presented is derived from an analysis of effort tracked against modifications to specific software components before and after a significant architectural transformation to the subsystem housing those components. In this paper, we will discuss the development, implementation, and iteration of the model and the results that we have obtained.

Article Experience with performing architecture tradeoff analysis Share on Authors: Rick Kazman Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Mario Barbacci Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Mark Klein Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , S. Jeromy Carrière Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Steven G. Woods Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile Authors Info & Claims ICSE '99: Proceedings of the 21st international conference on Software engineeringMay 1999 Pages 54–63https://doi.org/10.1145/302405.302452Online:16 May 1999Publication History 103citation1,056DownloadsMetricsTotal Citations103Total Downloads1,056Last 12 Months16Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

The article describes our view on the importance of exchanging not only system information in the reengineering community, but also exchanging a description of the semantics that underly the extraction, annotation and augmentation of the information one wishes to exchange. The semantics are more than the schema of the information exchanged. They include the rationale for the structure of the schema itself. We also make the point that we need to be explicit about what it means to reconstruct architecture, in terms of the architectural semantics that we are hypothesizing for the system being analyzed. We present the discussion in the context of a revised set of levels based on the CORUM II model.

This paper presents the Architecture Tradeoff Analysis Method (ATAM), a structured technique for understanding the tradeoffs inherent in the architectures of software-intensive systems. This method was developed to provide a principled way to evaluate a software architecture's fitness with respect to multiple competing quality attributes: modifiability, security, performance, availability, and so forth. These attributes interact-improving one often comes at the price of worsening one or more of the others-as is shown in the paper, and the method helps us to reason about architectural decisions that affect quality attribute interactions. The ATAM is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.

When performing architectural analysis on legacy software systems, it is frequently necessary to extract the architecture of the system, because it has not been documented, or because its documentation is out of date. However, architectural information does not exist directly in the artifacts that we can extract. The architecture exists in abstractions; compositions of extracted information. Thus, extracted artifacts must be able to be flexibly aggregated and combined. We call this process "view refinement and fusion". This paper presents a workbench for architectural extraction called Dali, and shows how Dali supports flexible extraction and fusion of architectural information. Its use is described through two extended examples of architectural reconstruction.