“Architecture is about the important stuff. Whatever that is.”
Martin Fowler
Unfortunately, there is no universally accepted definition for the term “software architecture”. However, a few aspects can be identified that are recurrent in the numerous definitions of what software architecture is:
- Structuring and decomposing a system into parts, defining functional responsibilities
- Functionally conditioned interaction of the parts as well as definition of interfaces between the parts
- Decisions (including justifications) that can be very difficult to change afterwards.
In the following, we understand the software architecture as the sum of all architectural decisions, whereby an architectural decision is to be understood as a fundamental decision that is difficult to reverse in the further course.
The interpretation of the term software architecture used here means that an architectural documentation that is created as a model within the framework of a model-driven software development must comprehensibly record all decisions. This is made possible by the following documentation instruments.
Documentation Instruments
- System Context
- Coming soon … Boundary conditions, quality objectives, quality scenarios, stakeholders, case studies, block view, runtime view, distribution view, design decisions, technical risks, glossary