Skip to main content

Architectural Decision and Evidence

An architecture is only operationally valid when its decisions:

  • are explicit;
  • have an identified owner;
  • produce verifiable evidence;
  • can be reviewed or invalidated.

Isolated diagrams or descriptions do not constitute an architectural decision.

1. What constitutes an architectural decision​

An architectural decision is any technical choice that:

  • affects security, isolation or trust properties;
  • introduces or removes external dependencies;
  • conditions security requirements or threat mitigation;
  • is costly or difficult to reverse.

Purely local implementation details do not, by themselves, constitute architectural decisions.

2. Minimum acceptance criteria for a decision​

An architectural decision is considered valid when, at a minimum:

  • the context and the problem are clearly described;
  • the main alternatives have been identified;
  • the decision taken is explicit;
  • the accepted trade-offs are documented;
  • there is a link to threats (Ch. 3) and requirements (Ch. 2);
  • there is an identified owner for the decision.

3. Minimum mandatory evidence​

The evidence associated with architectural decisions must include:

  • a decision record (e.g. ADR or equivalent);
  • versioned architectural diagrams;
  • a reference to the version of the system/context;
  • a link to the relevant threats and requirements;
  • date and owner of the approval.

The evidence must be:

  • versioned;
  • reproducible;
  • auditable.

4. Architectural baseline​

The set of approved decisions constitutes the system's architectural baseline.

The baseline:

  • is valid only for the approved context/versioning;
  • serves as a reference for development, testing and operation;
  • must be easily identifiable and consultable.

5. Invalidation and review of decisions​

An architectural decision must be reviewed or invalidated when there is:

  • a significant change to the architecture;
  • the introduction of new external dependencies;
  • a relevant change in the data flows;
  • a reclassification of the risk level (L1–L3);
  • the identification of new critical threats.

Decisions that have not been reviewed must be considered potentially invalid.

6. Integration with other chapters​

Architectural decisions:

  • materialise the mitigation of threats identified in Ch. 3;
  • justify requirements of Ch. 2;
  • condition development, testing and operation practices.

The absence of an explicit link compromises the coherence of the SbD-ToE model.