Overview

Variability in software-intensive systems is understood as the ability of a software artifact to be changed (e.g., configured, customized, extended, adapted) for a specific context, in a preplanned manner. This means, variability can be considered as "anticipated change". Variability

• helps manage commonalities and differences between systems,
• supports the development of different versions of software by allowing the implementation of variants within systems,
• facilitates planned reuse of software artifacts in multiple products,
• allows the delay of design decisions to the latest point that is economically feasible,
• supports runtime adaptations of deployed systems.

Mechanisms to accommodate variability include software product lines, configuration wizards and tools in commercial software, configuration interfaces of software components, or the dynamic runtime composition of web services. As variability is primarily reflected in and facilitated through the software architecture, VARSA 2011 addresses variability at the software architecture level.

Motivation

Currently, variability is primarily addressed in the product line (PL) domain, but not thoroughly studied as a concept that affects and is affected by many areas of software engineering. For example, in PL, the focus is on modeling variability in features and decisions, rather than treating variability related to the architecture and all architecture aspects, as a cross-cutting concern or quality attribute.

On the other hand, in the software architecture domain, variability seems to be not well understood and any change or difference between systems is potentially characterized as variability, without systematically managing variability. However, software architecture acknowledges that variability is a concern of different stakeholders, and in turn affects other concerns.

Also, the relation between quality attributes and variability in the architecture is only poorly understood, even though quality attributes cause major challenges in architecture practice. For example, architectures are usually described using multiple viewpoints and views. In views, only some variability concerns are of interest for a particular stakeholder. On the other hand, quality attributes are concerns that are affected by variability and thus must be represented in the architecture.

Moreover, variability in the software architecture goes beyond feature or decision models but encompasses models and views that are particularly relevant for software architecture (e.g., deployment models, information models, development models, adaptation models). As the software architecture is the centerpiece of software systems and acts as reference point for many development activities (e.g., requirements, design, implementation, maintenance), and many of today's software systems are built to accommodate variability, variability should be treated as a first-class concern in software architecture.