Capture of Architecture Rationale

Arcadia
1

As detailed in ISO 42010; Architecture rationale records explanation, justification or reasoning about architecture decisions that have been made. The rationale for a decision can include the basis for a decision, alternatives and trade-offs considered, potential consequences of the decision and citations to sources of additional information.

I hope we can all agree that recording and capturing this information within the model is extremely powerful and useful.

It is not practical to record every architecture decision about a system however criteria to consider when it is important to capture rationale could include:

  • decisions regarding architecturally significant requirements;
  • decisions needing a major investment of effort or time to make, implement or enforce;
  • decisions affecting key stakeholders or a number of stakeholders;
  • decisions necessitating intricate or non-obvious reasoning;
  • decisions that are highly sensitive to changes;
  • decisions that could be costly to change;
  • decisions that form a base for project planning and management (for example, work breakdown structure creation, quality gate tracking);
  • decisions that result in capital expenditures or indirect costs.

The following information could be captured for each decision:

  • the decision is uniquely identified;
  • the decision is stated;
  • the decision is linked to the system concerns to which it pertains;
  • the owner of the decision is identified;
  • the decision is linked to model elements affected by the decision;
  • there is rationale linked to the decision;
  • constraints and assumptions that influence the decision are identified;
  • alternatives that have been considered, and their potential consequences, are recorded;
  • consequences of the decision (relating to other decisions) are recorded;
  • timestamps record when the decision was made, when it was approved and when it was changed;
  • citations to sources of additional information are provided.

There may be a number of reasons why an architectural decision was made:

  • Traceability to higher level modelling (could be textual safety requirements e.g. no single failure…, implementation requirements specifying a solution)
  • Group Safety Policies
  • Lessons Learnt from previous projects
  • Design Rules
  • Processes and guidance material
  • In-Service Experience
  • Technical Reports
  • Trade Studies/ Further Analysis

My question is:
How have you captured or linked out to this rationale within your model?

  • Have you used specific modelling elements e.g. PVMT, custom add-ins, Requirements Plug in with a specified type? Notes on each diagram? Description fields?

Out of scope of discussion is the modelling of alternatives, this has been discussed else where such as here: How to use Capella to evaluate alternatives

Edit, just noticed a similar question was asked here: Create Rationales for actors (human and system) of the system all interfaces between the system and each actor of all system functions just 20hours ago (no responses yet) but this topic I think is much broader. @HUP_71

Thank you

2 Likes