What is software architecture?

One of the most used definitions says that the architecture of a system comprises its components, their relationships and how they interact with each other. In this way, each and every system has an architecture, although it is not always documented.

The way the architecture is established is responsible for the quality of the system. Issues such as system availability, reliability and security are established by it. Therefore, it is extremely important that the process of defining the architecture of a software is well established. For this, one can use the architectural process, described below.

Architectural process

Within the process of building software architectures, there are 3 steps: Architectural analysis, architectural design and architectural evaluation. The following image shows an overview of how this process works, and then each of the steps is described in more detail.

Architectural analysis

The architectural analysis step is where the Architecturally Significant Requirements (ASR) for that system are identified. These, in turn, differ from functional requirements because they do not intend to define the objective of the system, but its quality. Therefore, concerns about security, performance and reliability are included, for example. ISO25010 is a standard for software quality that has the criteria by which systems can be evaluated.

To define the ASR, some questions can be asked in relation to the items of ISO25010. About the "availability" attribute, for example, one might ask "which parts of the system need to be available 24/7?". Regarding "performance", "what is the minimum acceptable time to execute a certain functionality of the system?".

In the architectural analysis stage, which of these are relevant to the system in question will be mentioned and parameters will be added to assess whether the requirements are met. One way to define this is through quality attribute scenarios.

Architectural design

Architectural design is the theoretical construction of architecture itself. All requirements obtained by the analysis step must be taken into account to make architectural decisions. At this point, architectural patterns, reference architectures and architectural styles that make sense for the system in question are considered. Ideally, the architecture is described and documented.

This documentation can be done informally, semi-formally and formally. The first refers to documentation that does not follow previously established rules, such as the use of diagrams with simple captions. The semi-formal uses some existing modeling language, such as UML (Unified Modeling Language). Finally, the formal describes the architecture through a written language that simulates the architecture in all its details — similar to a programming language.

The following image shows steps contained within the architectural design, having the ASR as method input. First, the so-called trade-offs are analyzed and resolved through architectural decision making. Next, potential architectural solutions are chosen, described and documented. These solutions are input to the architectural evaluation step.

Architectural evaluation

At this stage, the goal is to verify if a possible architectural solution defined in the design stage is really meeting the system's ASR. There are different methods to perform this evaluation, one of them is the use of quality attribute scenarios. The scenarios consist of a possible context in which the architecture will be acting and, based on them, it is analyzed whether the system will perform as expected by the defined ASRs.

Completion of the architectural process

These steps are not performed just once in the vast majority of situations, they are performed as many times as necessary to achieve what is expected of the system architecture. At some point, the architecture becomes fully validated and the architectural process is terminated as long as there are no changes to the system's ASRs.

Conclusion

Defining the architecture of a system is not a simple task and is extremely important for the quality of what is developed. Thus, having a well-defined planning process and architecture documentation helps a lot to develop a system that meets the expected requirements for such.

References

[Bass et al. 2012] Bass, L., Clements, P., and Kazman, R. (2012). Software Architecture in Practice. Addn-Wesley, 3ª edition.

[Gorton 2011] Gorton, I. (2011). Essential Software Architecture. Springer Publishing Company, Incorporated, 2nd edition

[Hofmeister et al. 2007] Hofmeister, C., Kruchten, P., Nord, R. L., Obbink, H., Ran, A., and America, P. (2007). A general model of software architecture design derived from five industrial approaches. Journal of Systems and Software, 80(1):106 – 126.

[ISO/IEC 2011] ISO/IEC (2011). ISO/IEC 25010:2011(en) systems and software engineering — systems and software quality requirements and evaluation (square) — system and software quality models. On-line.