We stand with the people of Ukraine

Please assist humanitarian efforts for the Ukrainian people and those affected by the military invasion of Ukraine by supporting international aid organizations, including the International Committee of the Red Cross.


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?

More details

intro and goals

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.

Read More

constraints

2. Constraints

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.

Read More

scope and context overview

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)

Read More

solution strategy overview

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.

Read More

building block view

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.

Read More

runtime view

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.

Read More

deployment view

7. Deployment View

Technical infrastructure with environments, computers, processors, topologies. Mapping of (software) building blocks to infrastructure elements.

Read More

crosscutting concepts

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.

Read More

architectural decisions

9. Architectural Decisions

Important, expensive, critical, large scale or risky architecture decisions including rationales.

Read More

quality requirements

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).

Read More

risk

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

Read More

glossary

12. Glossary

Important domain and technical terms that stakeholders use when discussing the system. Also: translation reference if you work in a multi-language environment.

Read More


Further information

Now that you know about the template sections, you can dive deeper. Have a look at our extensive documentation:

Learn more!

arc42 offers architecture training.

The data is currently loaded from the backend and should display here shortly. If not, you can see the next dates at trainings.arc42.org .