On the modularity impact of architectural assumptions

In software architecture design, the end product is the combined result of a wide variety of inputs, most of which are provided by the non-technical stakeholders. These include the analysis of the problem domain, the functional and non-functional requirements, the architectural or technical constraints. However, a software architecture is typically also influenced by different, less visible factors such as the architect's prior experience and his creativity. In this paper, we focus on so-called architectural assumptions, which are key premises made by technical stakeholders in the early phases of the software development life-cycle. Often these assumptions are made silently and not documented explicitly in the description of the architecture. As a result, they introduce a certain degree of rigor in the software product that hinders the evolvability, variability, and reusability of the architectural solution as a whole and its individual building blocks. Additionally, architectural assumptions in many cases exert a crosscutting influence on the software architecture and its description. This makes it hard to discover them, assess their individual architectural impact, and treat them as first-class architectural elements. In this position paper, we explore and discuss these modularity problems in specific examples from a patient monitoring system (e-health). Furthermore, we introduce the distinction between problem-space and solution-space architectural assumptions, and we discuss their intrinsic differences.