Short description of the requirements, driving forces, extract (or abstract) of requirements. Top three (max five) quality goals for the architecture that have the highest priority for the major stakeholders. A table of important stakeholders with their expectations regarding architecture.
Anything that constrains teams in design and implementation decisions or decisions about related processes. Can sometimes go beyond individual systems and are valid for whole organizations and companies.
Summary of the fundamental decisions and solution strategies that shape the architecture.
The behavior of building blocks as scenarios, covering important use cases or features, interactions at critical external interfaces, operation, and administration plus error and exception behavior.
Overall, principal regulations and solution approaches are relevant in multiple parts (→ cross-cutting) of the system. Concepts are often related to multiple building blocks. Include different topics like domain models, architecture patterns and -styles, rules for using specific technology and implementation rules.
11 - Risks and Technical Debts
Known technical risks or technical debt. What potential problems exist within or around the system? What does the development team feel miserable about?
Delimits your system from its (external) communication partners (neighboring systems and users). Specifies the external interfaces. Shown from a business/domain perspective or a technical perspective.
Static decomposition of the system, abstractions of source code, shown as a hierarchy of white boxes (containing black boxes), up to the appropriate level of detail.
Technical infrastructure with environments, computers, processors, and topologies. Mapping of (software) building blocks to infrastructure elements.
Important, expensive, critical, large scale, or risky architecture decisions including rationales.