Method

A recommendation is built before it is written

Our method turns an architecture question into an explicit, reasoned and traceable decision.

The seven steps

Questions first

Before writing a single line: the facts, the evidence, the history, the people involved and the options already ruled out. A recommendation that ignores why an option was ruled out will be ruled out in turn.
A two-step assessment

What is wrong (the technical facts), then what it causes (the consequences for the team and the business). Keeping the two apart avoids debating symptoms.
The options considered

Including the status quo and the options already rejected, each with what it solves and what it costs.
A one-sentence recommendation

Then its justification. If it does not fit in one sentence, it is not ready yet.
The trade-offs we accept

What we agree to lose, and the signal that must trigger a review of the choice.
An implementation plan

Work packages, their prerequisites and their completion criteria.
An explicit request for a decision

Change, investigate or confirm. Every recommendation ends with a question that can be answered.

A short email: a reminder of the context, the assessment, the one-sentence recommendation, the expected decision, a link to the document.
A detailed document, filed in your documentation tool, with its citable external sources.
An index of the recommendations and their status: everyone knows what was decided, when and why.

Decisions are traceable: useful for an audit, a certification or when someone new joins.
Disagreements are written down and argued, rather than replayed at every meeting.
Trade-offs are visible before they come as a surprise.
A documented decision is easy to review when the context changes.

We can start with the questions phase.