arc42 answers the following two questions in a pragmatic way and can be tailored to your specific needs:
- What should you document/communicate about your architecture?
- How should you document/communicate?
1. Introduction and Goals
Short description of the requirements, driving forces, extract (or abstract) of requirements. Top three (max five) quality goals for the architecture which have highest priority for the major stakeholders. A table of important stakeholders with their expectation regarding architecture.
Anything that constrains teams in design and implementation decisions or decision about related processes. Can sometimes go beyond individual systems and are valid for whole organizations and companies.
3. Context and Scope
Delimits your system from its (external) communication partners (neighboring systems and users). Specifies the external interfaces. Shown from a business/domain perspective (always) or a technical perspective (optional)
4. Solution Strategy
Summary of the fundamental decisions and solution strategies that shape the architecture. Can include technology, top-level decomposition, approaches to achieve top quality goals and relevant organizational decisions.
5. Building Block View
Static decomposition of the system, abstractions of source-code, shown as hierarchy of white boxes (containing black boxes), up to the appropriate level of detail.
6. Runtime View
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.
7. Deployment View
Technical infrastructure with environments, computers, processors, topologies. Mapping of (software) building blocks to infrastructure elements.
8. Crosscutting Concepts
Overall, principal regulations and solution approaches 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.
9. Architectural Decisions
Important, expensive, critical, large scale or risky architecture decisions including rationales.
10. Quality Requirements
Quality requirements as scenarios, with quality tree to provide high-level overview. The most important quality goals should have been described in section 1.2. (quality goals).
11. Risks and Technical Debt
Known technical risks or technical debt. What potential problems exist within or around the system? What does the development team feel miserable about?
Icon from Flaticon.com
Important domain and technical terms that stakeholders use when discussing the system. Also: translation reference if you work in a multi-language environment.
Now that you know about the template sections, you can dive deeper. Have a look at our extensive documentation:
- Real-world examples
- FAQ - Frequently asked questions
- Our extensive template documentation, organized by template section.
- Our (sketchy) collection of software patterns.
- Out (new) site on our Quality Model, collecting quality properties/attributes.
arc42 offers architecture training.Two expert trainers at all times, highly practical and pragmatic, ideal preparation for iSAQB CPSA-Foundation certification.
Next available dates (in German):
- June 27-30 2023, Frankfurt/Main (fully booked)
- Sept 12-15 2023, Frankfurt/Main (fully booked, waiting list available)
- November 14-16 2023, ENGLISH + online (Trainer: Wolfgang Reimesch)
- Dec 5-8 2023, Munich (fully booked, waiting list available)
- January 23-26 2024, Munich
- March 19-22 2024, Munich
- June 11-14 2024, Munich
iSAQB Advanced Topics
IMPROVE: Learn to effectively evolve and maintain systems.
- June 19-21 2023, Mannheim (Gernot Starke with Peter Hruschka)
- Nov 28-30 2023, Hamburg (Carola Lilienthal with Gernot Starke)
Req4Arc: Getting your Requirements right.What to do if your requirements need improvement.
- September 5-7 2023, Frankfurt (Peter Hruschka with Gernot Starke)
- April 16-18 2024, Frankfurt (Peter Hruschka with Gernot Starke)
ADOC: Architecture DocumentationHow to efficiently and effectively create and maintain useful technical documentation.
Early bird rates available. Contact us for inhouse training.