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.
Table of Contents
- Support & Sponsors
- About the Author
- Acknowledgements
- Color Scheme
- Tooling and Build
- WCAG Accessibility Report
- Lighthouse Quality Report
- Content Analytics
- Pageviews and Visitor Count
INNOQ supports this site.
INNOQ supports creation and maintenance of this site and the whole arc42 ecosystem. Thanx a lot, this support is highly appreciated.
About me (Gernot)

My name is Gernot Starke. I’m:
- happily married, we have two (grown-up) kids and live in Cologne, Germany.
- Fellow at INNOQ,
- Coaching and consulting medium and large-scale enterprises on topics around software architecture and methodical software engineering.
- Co-founder and maintainer of arc42, the template for pragmatic and systematic software architecture documentation.
- Founder of aim42, the open-source framework for systematic software architecture improvement.
- Active member and working group lead within the International Software Architecture Qualification Board, iSAQB.
- Trainer for the iSAQB curriculum (modules FOUNDATION, IMPROVE, REQ4ARC and ADOC).
- Regular speaker at IT-conferences.
- Author and co-author of more than a dozen books on software architecture, patterns, arc, and the like. Most of these books are written in German. Take a look at Leanpub for some of my English books.
- Author of quite a few articles
Acknowledgements
- Thanx to Michael Mahlberg, Peter Hruschka, Markus Meuten and Daniel Lauxtermann for suggestions, bug fixes and moral support.
- Thanx to Steffen Späthe for his intense reviews and constructive comments concerning the content.
- Thanx to Dr. Alexander Lorz and Dr. Michael Sperber for intense discussion around quality.
- Thanx to Per Starke for his awesome technical support in things around Liquid and Jekyll.
-
Thanx to Remko Plantenga @exde3297, Martin Weck @martinweck, Eberhard Wolff @ewolff, Paul Boeck @PapaBravo, Dean de Bree @ddebree, Markus Stier @mstier, Fabian Angst @angstitc for their contributions.
- Numerous issues and PRs were fixed with support by GPT-5, Claude-Sonnet and Gemini-2.5 Pro. These LLMs know css definitely better than I do.
Find the complete list of contributors here
Color Scheme
Each content type carries an identity colour. Cards use a paper background with a coloured rail on the left — the same pattern used across detail pages and section headers, so the colour acts as a wayfinding cue rather than decoration.
#1A3A5CText on dark fill:
#C8E6F5 · 8.5:1 (AAA)#00B8F5Text on fill:
#003366#FFB3B3Text on fill:
#8B0000#FFC95CText on fill:
#2C3E50#92EF80Text on fill:
#1B5E20#A04323Soft fill:
#FBE9E3 · Muted: #6B6B6BRail / accent:
#682D63 · Soft fill: #E6DAF2
Accessibility note: identity colours are validated for WCAG contrast on the surfaces they appear on; see WCAG Accessibility Report and Lighthouse Quality Report.
Tooling and Build
- This page is based upon Jekyll, a static website generator.
- It’s maintained on Github and published via github-pages.
- A custom Docker Compose environment handles dependency installation, graph data generation, JavaScript bundling (esbuild), and Jekyll serving — no manual toolchain wiring needed.
- In case you want to run the site locally, use
docker compose upafter cloning the repo locally. -
The site’s UI is a bespoke design, crafted to reflect the arc42 brand: a violet/teal palette, accessibility-first typography, and an interactive D3.js force graph as the visual centrepiece.
- build_revision: 6fa4c9da44f93c099a0c5905e2b9bc8c9f47cb28,
- last built and published on Sat Sep 5 15:31:06 2026
Lighthouse Quality Report
We continuously monitor the site’s quality using Google Lighthouse. It audits performance, accessibility, SEO, and best practices.
View the latest Lighthouse Report
Content Analytics
Here we analyze our content, especially the links between content elements. In the long run we aim at having everything well-connected:
- Every quality is associated with at least one (high-level) property (check: Qualities without Tag)
- Every quality has relations to other qualities (check: Orphan Qualities)
- We have a method for synonyms in place.
- Every quality has at least one specific requirement (check: Qualities without Requirements)
- The list of related qualities (
related:) in the header of every quality file contains only existing qualities (check: Orphan Relations) - Every standard relates to one or multiple qualities (check: Standards without Qualities)
Qualities without Tag (aka property)
Tags assign a quality to one or more high-level properties, like
secureorusable. A quality without a tag shows up in no property overview and is hard to find.
All qualities in this site have at least one tag defined (excluding synonyms, which inherit tags from their canonical entry).
Orphan Qualities
The
related:field of a quality names the other qualities it is connected to. A quality that names none is a dead end: the graph shows it isolated, and readers have nowhere to go from it.
All qualities in this site have at least one directly related quality defined (excluding synonyms, which inherit relations from their canonical entry).
Synonyms
Different terms often mean the same quality. We keep one canonical page per concept and redirect the alternative terms to it, instead of maintaining near-duplicate content.
See our complete Quality Aliases and Synonyms mapping for details.
Total synonym pairs: 28
The synonym system ensures:
- Canonical terms have comprehensive content and definitions
- Graph visualization shows single nodes with multiple labels
Qualities without Requirements
Requirements make a quality concrete and testable. They point at qualities via their
related:field — a quality nobody points at stays an abstract term.
The following 36 qualities currently have no requirements directly related to them (excluding synonyms):
Co-existence, Communicability, Conciseness, Consent Management, Controllability, Credibility, Data Minimization, Data Residency, Devops-Metrics, Distributability, Durability, Effectiveness, Energy Proportionality, Expected physical environment, Features, Functional Adaptability, Functional suitability, Immunity, Injection Resistance, Intervenability, Legal Requirements, Longevity, Model Transparency, Operational constraint, Operational and Environment Requirements, Personalization, Safe integration, Securability, Self-containedness, Self-descriptiveness, Simplicity, Suitability, Themability, Upgradeability, User engagement, Versatility,
Orphan Relations
Every quality has a
related:field in its header, listing the names of related qualities. Here we check for entries in that field that name a quality which does not exist.
All quality relations reference existing qualities - no orphan relations found.
Standards without Qualities
Every quality standard (like ISO-5055) should have at least one quality related to it. Standards are linked from the
standards:field of the qualities, not from the standard page itself.
All standards have at least one quality related to them.
Pageviews
Stats powered by Plausible Analytics