Software architecture defines a system's structure, components, interfaces and guiding principles for designing complex software. It creates abstractions to achieve scalability, maintainability and reuse and makes quality requirements explicit. Architectural decisions shape technology, operations and organizational aspects across enterprise, domain and team…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
Software architecture describes a software system’s fundamental structures, their relationships, and the principles guiding its development and evolution.
The term applies architectural thinking to software systems. ISO/IEC/IEEE 42010 treats architecture descriptions as a way to make systems, stakeholders, concerns, and views traceable.
Architecture decisions organise responsibilities, dependencies, and quality goals. Identify stakeholder concerns first, then relevant views, and justify key decisions through alternatives and consequences. Architecture is an evolving decision framework, not a one-time diagram.
Components and their relationships form the recurring building blocks of a system.
A stakeholder concern such as security, performance, or modifiability shapes architecture questions.
A view represents a system from a particular perspective for a particular purpose.
Software architecture guides long-term technical and organisational decisions. It is distinct from detailed software design and from planning individual deliveries, while connecting to both through justified quality and interface decisions.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.