Architecture Decision Records (ADRs)

This section contains all Architecture Decision Records made within the project. To create a new one, copy the ADR template and name it NNNN-kebab-title.md.

Architectural Significance

How do we decide on which decisions we need to capture in an Architectural Decision Record (ADR)? O. Zimmermann wrote an article proposing the following guiding principles:

1. The requirement is directly associated with high business value (benefit vs. cost) or business risk.
2. The requirement is a concern of a particularly important stakeholder such as the project sponsor or an external compliance auditor.
3. The requirement includes runtime Quality-of-Service (QoS) characteristics (such as performance needs) that deviate from those already satisfied by the evolving architecture substantially.
4. The requirement causes new or deals with one or more existing external dependencies that might have unpredictable, unreliable and/or uncontrollable behavior.
5. The requirement has a cross-cutting nature and therefore affects multiple parts of the system and their interactions; it may even have system-wide impact, short term and/or in the long run (examples: security, monitoring).
6. The requirement has a First-of-a-Kind (FOAK) character: For instance, this team has never built a component or subsystem that satisfies this particular requirement before.
7. The requirement has been troublesome and caused critical situations, budget overruns or client dissatisfaction on a previous project in a similar context.

Translating that to our case is a bit tricky but works for a lot of things:

1. The decision is directly associated with goals relating to the project’s success (student and professional workshops, demonstrators, development projects). E.g.: How do we document and publish the API for our core services?
2. The particularly important stakeholder is only partly relevant.
3. QoS characteristics are also mostly arbitrary, but play an important role for the local dev env and when actually scaling out.
4. The decision introduces or deals with external dependencies - these are mostly in the form of code libraries and tooling. E.g. Which tools do we use to deploy our infrastructure? (Terraform, Ansible, Puppet, Chef, etc.) As in our case, external dependencies also mean knowledge that has to be acquired in order to maintain the system.
5. The decision has a cross-cutting nature and therefore affects multiple parts of the system and their interactions; it may even have system-wide impact, short term and/or in the long run (examples: security, monitoring, event formats, tooling).
6. FOAK is quite common in our case, as a lot of this is new to some of us. Nevertheless, an important indicator.
7. The decision has been troublesome and caused intensive discussions before.

Records