Glossary

Active Reviews for Intermediate Design (ARID) method A method in which the architecture design (or part of it) is presented to a group of reviewers—typically the engineers who will use the design. After the presentation, a set of scenarios is selected. The reviewers attempt to use the elements in the architecture to satisfy the scenarios. The reviewers are asked to write code or pseudocode or to create sequence diagrams for the purpose of identifying interfaces. This method can be used in preparation for element interaction design.

ADD See Attribute Driven Design method.

ADL See Architecture Description Language.

Analysis The process of breaking a complex entity into its constituent parts as a means of understanding it. Analysis is used at different moments in the design process; for example, the inputs are analyzed to make design decisions and the resulting architecture is also analyzed to gauge if it is appropriate to satisfy its associated drivers.

Application framework A reusable software element, constructed out of patterns and tactics, that provides generic functionality addressing recurring domain and quality attribute concerns across a broad range of applications. Also called a framework.

Architectural concern An additional aspect that needs to be considered as part of architectural design but that is not expressed as a traditional requirement. Examples include general concerns, such as creating an overall system structure, and more specific concerns, such as managing exceptions or generating logs. Other architectural concerns include internal requirements, which are seldom expressed by customers, and issues resulting from analysis activities, such as architectural evaluations.

Architectural design The activity of making decisions to translate ideas from the world of needs (architectural drivers) to the world of solutions, in terms of structures.

Architectural drivers The design purpose, architecturally significant requirements, and architectural concerns that serve as an input to the design process. These considerations are critical to the success of the system and, as such, they drive and shape the architecture.

Architectural evaluation A technique to analyze and assess the value of architectural decisions.

Architectural pattern See Patterns (Architectural and Design).

Architecturally significant requirement (ASR) A system requirement that has a particular importance with respect to the software architecture. ASRs include quality attributes, primary functional requirements, and constraints.

Architecture Description Language (ADL) A notation to document an architecture. ADLs typically employ both a graphical notation and a (formally defined) textual notation to describe an architecture—primarily the computational (runtime) components and interactions among them—and its properties.

Architecture Tradeoff Analysis Method (ATAM) An established method for analyzing architectures, driven by scenarios. Its purpose is to assess the consequences of architectural decisions in light of quality attribute requirements and business goals.

ARID See Active Reviews for Intermediate Design method.

ASR See Architecturally significant requirement.

ATAM See Architecture Tradeoff Analysis Method.

Attribute-Driven Design (ADD) method An iterative architecture design method that takes drivers as inputs and produces an architecture. In each iteration, structures are produced by refining elements identified in previous iterations. These structures are created primarily from design concepts, which are selected and instantiated to address a subset of the drivers that are selected for the iteration.

Big Design Up Front (BDUF) The (now largely discredited) practice of attempting to do all of the architectural design at the beginning of a project. It is usually associated with a waterfall software development life cycle.

Brownfield development Software development that builds upon an existing asset. Contrast with greenfield development.

Constraint A decision over which the architect has little or no control. It may be either technical or organizational.

Cost Benefit Analysis Method (CBAM) A method that associates costs, benefits, and schedule implications with strategies chosen to make improvements in an architecture. This method is used to rank the strategies, as a means of finding an optimal set of strategies to implement in the next iteration.

Design concept The building blocks from which the structures that make up the architecture are created. Different types of design concepts exist, including reference architectures, deployment patterns, architectural patterns, tactics, technology families, and externally developed components (such as frameworks).

Design concepts catalog A collection of design concepts for a particular application domain.

Design decision A decision that is made during the design process, including the selection of a design concept and the instantiation of the selected design concept.

Design iteration A group of design decisions through which a subset of the drivers is transformed into structures. One or more design iterations are performed within a design round.

Design pattern See Patterns (Architectural and Design).

Design purpose The reason why the architecture design is performed. For example, the design may be performed for estimation during pre-sales, prototyping, or development purposes.

Design round The architecture design activities performed within a development cycle if an iterative development model is used, or the entire set of architecture design activities if a waterfall model is used.

Deployment pattern A pattern that provides a model for how to physically structure the system to deploy it.

Development cycle The development of a project increment (i.e., a project iteration).

DevOps A portmanteau word, combining “development” and “operations”. DevOps stands in contrast to earlier forms of running a software project, in which development teams developed software and then “tossed it over the wall” to operations. In DevOps, the two teams work closely together and adopt processes, tools, and architectures to make it easier to rapidly modify, build, test, release, and monitor software.

Element (in definition of software architecture) One of the parts that compose the structures of the architecture. Elements may exist at runtime or development time or they may exist physically. Elements are connected by relations.

Element interaction design The identification of the modules and their associated interfaces to support the nonprimary use cases. This is typically performed using sequence diagrams according to the decisions made during architectural design.

Element internals design The internal design of the elements identified as part of element interaction design, so as to satisfy the element’s interface.

Externally developed component A design concept that is concrete in nature and that is not built as part of the system development, but rather is acquired and reused. Such components include application frameworks, products, and platforms.

Greenfield development Software development that begins with little or no legacy code base to build upon.

Instantiation The process of adapting a design concept to the particular problem being addressed. It involves creating elements and relations, and associating responsibilities with the elements, from the selected design concept. Instantiation can also refer to configuration when design concepts are externally developed components.

Interface The externally visible properties of elements that establish a contractual specification that allows elements to collaborate and exchange information, via relations.

Marketecture A single-page, typically informal, representation of a software system architecture. This representation is aimed primarily at nontechnical people, and is used to present a system vision.

Minimum viable product (MVP) An evolutionary prototype with only those core features that allow the product to be deployed. It emphasizes hypothesis testing by fielding the product with real users and collecting usage data that then helps to confirm or reject the hypothesis.

Patterns (architectural and design) Conceptual solutions to recurring design problems that exist in a defined context. When they are used to address an architectural driver, they are “architectural patterns”; when their use has just a local influence—for example, when used to perform element internals design—they are “design patterns”.

Platform A complete infrastructure upon which to build and execute applications.

Pre-sales A phase in project development in which the scope of the project, a business case, and an initial plan are established. This phase is used by the customers (or funders) to decide whether they want to pursue the project.

Primary functional requirements Functionality is the ability of the system to do the work for which it was intended. Primary functionality is usually defined as functionality that is critical to achieve the business goals that motivate the development of the system.

Product A self-contained functional piece of software that can be integrated into the system that is being designed and that requires only minor configuration or coding. Also called a software package.

Proof of concept (PoC) A prototype that is used to quickly evaluate a technology, thereby determining whether it can satisfy critical architecture scenarios, usually related to quality attributes such as performance and scalability.

QAW See Quality Attribute Workshop.

Quality attribute A measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders. Quality attributes are orthogonal to functionality.

Quality attribute scenario See Scenario.

Quality Attribute Workshop (QAW) A facilitated brainstorming session involving a group of system stakeholders in eliciting, specifying, prioritizing, and achieving consensus on quality attributes.

Rationale A line of reasoning and justification that led to a design decision.

Refactoring Changing the system’s architecture or code, without affecting its functionality, to achieve different quality attribute responses.

Reference Architecture Blueprints that provide an overall logical structure for types of applications, consisting of a reference model that is mapped onto one or more architectural patterns. It has been proven in business and technical contexts, and typically comes with a set of supporting artifacts that facilitates its use.

Relation (in definition of software architecture) One of the parts that compose the structures of an architecture. Relations may exist at runtime or development time or they may exist physically. Relations connect elements.

Scenario A technique to specify quality attributes that describes a stimulus received by the system and a measurable response to this stimulus. Scenarios are testable, falsifiable hypotheses about the quality attribute behavior of the system under consideration. Completely developed scenarios are described using six parts, but less elaborate (“raw”) scenarios can also be described.

Sketch of a view A preliminary type of documentation that is created as part of the design process. The sketch can be refined to become a full-fledged view, typically after the design activity has finished.

Software architecture “The set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”.

Spike A time-boxed task that is created to answer a technical question or gather information.

Structure A coherent set of software elements, relations, and properties. Structures are represented in views.

Tactic A proven design strategy that influences the control of a quality attribute response.

Technical debt The decisions—often called “hacks”—made in a software project that trade off short-term gains, such as ease of implementation, at the cost of long-term sustainability of the system. By taking such shortcuts, the software base “goes into debt”.

Technology family A group of technologies with common functional purposes.

View A representation of an architectural structure. A view usually includes a graphical representation of the structure and additional information that complements the information presented in the diagram.