All project decisions that are worth documenting are architectural decisions because decisions about the organisation (or the ways of working) are architectural relative to the organisation (or the project) as a system itself.

We can think about most decisions as initiating small (or not so small) projects of carrying these decisions out in the context of the "main" project, or across interacting projects (e. g. projects sharing people or other organisational resources, or projects of creating systems that interface with each other). Therefore, it seems reasonable to reuse the alpha framework (see Project alphas) to structure our thinking about these decisions, which includes writing decision documents, discussing them, and, ultimately, making the decision.

I take many alphas ("sections in the decision document", i. e., important objects of attention in thinking about a decision) directly from Jeff Tyree's and Art Akerman's "Architecture Decisions: Demystifying Architecture" (see also my summary), but structure them in a new way.

Here're the alphas of an (architecture) decision, with titles slightly modified relative to the alphas of a project:

Tyree and Akerman suggested a rule of thumb for deciding when an architecture decision warrants documentation (the amount of the documentation should be adjusted to the impact of the decision):

To test a decision’s architectural significance, an architect should ask the following question: does this decision affect one or more system qualities (performance, availability, modifiability, security, and so on)? If so, an architect should make this decision and document it completely.

Stakeholders

The stakeholders of a decision should be a subset of the stakeholders of the project if the decision is made in the context of a single project, or, if the decision affects multiple projects, a subset of the union of the stakeholders of these projects.

For each stakeholder, document their areas of concern that are affected by the decision, and their preferences in these areas of concern.

Each stakeholder has a status: "Doesn't need to be informed" / "Informed that decision is being discussed" / "Involved in the discussion" / "Shared their feedback or preference" / "Informed about the decision" / "Informed that the decision has been implemented" / "Informed that the decision has been obsoleted".

Issue/Opportunity

The standard project alpha equivalent to this one is called "Opportunities". I use the word "issue" and singular form to highlight that decisions are often made to address issues rather than seize opportunities. Also, decisions usually address only a single issue or an opportunity, or, to put it in another way, it's often a bad sign when people try to solve multiple issues or seize multiple opportunities with a single decision (Russian proverb: "за двумя зайцами погонишься, ни одного не поймаешь").

Sub-alphas:

• Issue (problem, subject matter). Explain the urge for making the decision (rather than deferring it for later, which should be the default strategy): “Describe the architectural design issue you’re addressing, leaving no questions about why you’re addressing this issue now.” This alpha is also sometimes called "Goals".
• Implications. Describe (try to predict) counterfactually how the situation with the issue (opportunity) will unfold if either of the decision options is chosen. How other related issues and opportunities will be affected? For example: "if the team spends resources on this issue, it won't have the resources to seize that other opportunity". What will be the second-order effects (see Ask series of "Whys" about a solution)? There are always at least two possible options: "do something" and "do nothing", often more: "plan A", "plan B", "plan C", "do nothing".
• Non-goals/Scope. Describe what is in the scope of the decision and what is out of scope explicitly.
• Related decisions.
• Relevant principles. “If the enterprise has an agreed-upon set of principles, make sure the decision is consistent with one or more of them. This helps ensure alignment along domains or systems.” I think that industry best (state-of-the-art) practices or prior experience (within the team, personal, or found online) could also be referenced here. The project alpha roughly equivalent to this one is "Innovations".

Description