Categorizing Business Goals for Software Architectures

Business goals are the foundation on which software systems are justified, analyzed, and built. Software systems are constructed to realize business or mission goals. Software architecture is the bridge between the business goals and the realized system. Those claims about business goals underlie many methods for designing and analyzing software architectures. However, precisely eliciting and characterizing business goals has always been problematic. Business goals come in many forms and at many levels of abstraction, and the stakeholders of the system are usually not accustomed to making goals explicit. This report provides a categorization of possible business goals, so that stakeholders can have guidance in the goals' creation, expression, and documentation. The categorization was derived by mining a set of 190 distinct business goals elicited in 25 Architecture Tradeoff Analysis Method (ATAM) evaluations and then by performing an affinity diagram process to group the business goals into categories. For each goal, example scenarios are provided to illustrate how the goal might impact a system. Finally, this report shows how the architecture business cycle (ABC) may be extended by the business goal categorization

Relating Business Goals to Architecturally Significant Requirements for Software Systems

The primary purpose of the architecture for a software-reliant system is to satisfy the driving behavioral and quality attribute requirements. Quality attribute requirements tend to be poorly captured and poorly represented in requirements specifications, which focus on functionality. It is often up to the architect‘s own initiative to capture the actual quality attribute requirements for a system under development. Quality attributes come about because of the business goals behind the system being developed. Business goals drive the conception, creation, and evolution of software-reliant systems. This report examines business goals from the point of view of the software architect. It presents a wide survey of business goal categories from the business literature and uses that survey to produce a classification of business goals. It introduces the concept of goal-subject (the person or entity who owns the business goal) and goal-object (the person or entity that the goal is intended to benefit). Those concepts are essential to the structure of a business goal scenario—a systematic way to elicit and express business goals. Using the concept of a business goal scenario drives the Pedigreed Attribute eLicitation Method (PALM), developed by the authors for eliciting architecturally significant business goals. The report illustrates how to use architecturally significant business goals to produce a set of derived quality attribute requirements that can then be vetted and elaborated with the appropriate goal-subject(s) and goal-object(s). This approach has been vetted in two workshops and the method piloted in an industrial setting

Elements of a Usability Reasoning Framework

This technical note brings together two different threads of work: (1) investigating the relationship between usability and software architecture that has generated a number of usability scenarios with implications for software architecture and (2) developing an architecture design assistant, Architecture Expert (ArchE). One key element of ArchE is that quality attribute knowledge can be encapsulated into reasoning frameworks, and a Carnegie Mellon University Master of Software Engineering project team has developed an ArchE reasoning language (ARL) with which to specify the actions of reasoning frameworks within ArchE. This note describes an ARL implementation of two usability scenarios: (1) displaying progress feedback and (2) allowing cancel. These implementations begin to provide ArchE with the ability to reason about aspects of usability that have software architecture implications

Modifiability Tactics

An architectural tactic is a design decision that affects how well a software architecture addresses a particular quality attribute. This report describes how tactics are based on the parameters of quality attribute models. Tactics provide an architectural means of adjusting those parameters, which, in turn, can improve the quality-attribute-specific behavior of the resulting system. This report justifies the tactics for modifiability, using established concepts of coupling, cohesion, and cost motivations as the means of identifying parameters of interest. Various tactics are then described based on their ability to control these parameters. The report also describes a standard set of architectural patterns and their variants in terms of the use of these tactics

Quality Attributes and Service-Oriented Architectures

This report examines the relationship between service-oriented architectures (SOAs) and quality attributes. Because software architecture is the bridge between mission/business goals and a software-intensive system, and quality attribute requirements drive software architecture design, it is important to understand how SOAs support these requirements. This report gives a short introduction to SOAs and outlines some of the main business goals that may lead an organization to choose an SOA to design and implement a system. This report outlines a set of quality attributes that may be derived from an organization's business goals and examines how those attributes relate to an SOA. In addition, this report describes how the SOA impacts those attributes and how choosing an SOA can help an organization achieve its business goals

Preliminary Design of ArchE: A Software Architecture Design Assistant

This report presents a procedure for moving from a set of quality attribute scenarios to an architecture design that satisfies those scenarios. This procedure is embodied in a preliminary design for an architecture design assistant named ArchE (Architecture Expert), which will be implemented on a rule-based platform. This report includes the theory and rationale precipitating the design of ArchE and then describes this design in detail

Illuminating the Fundamental Contributors to Software Architecture Quality

An architectural tactic is a design decision that helps achieve a specific quality-attribute response. Such a tactic must be motivated by a quality-attribute analysis model. This report presents the basic concepts of analysis models for two quality attributes-modifiability and performance, identifies a collection of tactics that can be used to control responses within those models, and discusses how to analyze the models in terms of these tactics. This report also describes how to interpret architectural designs in terms of analysis models and how to apply those models to specific architectures. In addition, it presents the analysis of several different architectural patterns taken from current literature

Deriving Architectural Tactics: A Step Toward Methodical Architectural Design

This is one of several reports that provide the current status on the work being done by the Software Engineering Institute (SEI) to understand the relationship between quality requirements and architectural design. The ultimate objective of this work is to provide analysis-based guidance to designers so that the quality attributes of generated designs are more predictable and better understood. Currently, four distinct problems must be solved to achieve that objective: (1) the precise specification of quality attribute requirements, (2) the enumeration of architectural decisions that can be used to achieve desired quality attribute requirements, (3) a means of coupling one quality attribute requirement to the relevant architectural decisions, and (4) a means of composing the relevant architectural decisions into a design. Embodying the solutions to these four problems into a design method that is sensitive to business priorities is an additional problem. This report deals with the third problem—coupling one quality attribute requirement to architectural decisions that achieve it. This report provides initial evidence that there is, in fact, a systematic relationship between general scenarios, concrete scenarios, architectural tactics, and design fragments. It examines, in detail, two concrete scenarios—one for performance and one for modifiability—and describes how to move from each scenario, through tactics, to design fragments that satisfy the scenario

Analyzing Enterprise JavaBeans Systems Using Quality Attribute Design Primitives

Quality attribute requirements such as those for performance, security, modifiability, reliability, and usability have a significant influence on the software architecture of a system. At the Software Engineering Institute, we are studying and codifying the relationship between quality attribute requirements and the architectural design strategies that impact their achievement. In CMU/SEI-2000-TN-017, we introduced the notion of quality attribute design primitives. Quality attribute design primitives (or attribute primitives) are architectural building blocks that target the achievement of one or sometimes several quality attribute requirements. Our intent is to codify a fairly comprehensive set of attribute primitives in a manner that articulates how each attribute primitive makes its specific contribution toward the achievement of one or several attribute goals. We believe this will provide a very powerful language for constructing or analyzing software architectures in relation to quality attribute requirements. To determine the expressive and explanatory power of these attribute primitives, we will examine various classes of systems. This paper uses attribute primitives to examine the qualities of Enterprise JavaBeans (EJB)-based systems. In particular, we find that attribute primitives hold promise for providing insight into the quality attribute consequences of using various EJB infrastructure features

Applicability of General Scenarios to the Architecture Tradeoff Analysis Method

The SEI has been developing a list of scenarios to characterize quality attributes. The SEI has also been conducting Architecture Tradeoff Analysis Method (ATAM) evaluations. One output of an ATAM evaluation is a collection of scenarios that relate to quality attribute requirements for the specific system being evaluated. In this report, we compare the scenarios elicited from five ATAM evaluations with the scenarios used to characterize the quality attributes. This effort was designed to validate the coverage of the existing set of general scenarios and to analyze trends in the risks uncovered in ATAM reports