Standalone conceptMethodChapter III · Evolution · Building block 4 of 15

ARID

An early design may not show whether developers can implement tasks consistently.

  1. Intermediate designIntermediate design: A still-evolving design is examined.
  2. TaskTask: Participants actively use the design.
  3. FeedbackFeedback: Gaps in understanding lead to concrete revision.

Context

Why this is important

Check early designs for clear implementation guidance.

Check early designs for clear implementation guidance.

Shop example · Mapping

ARID: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. Before implementing a new invoicing function within the existing invoice module, the team presents its intermediate design and asks two developers to work through a typical task: store invoice status after successful payment. They find that the transaction boundary, failure path, and retry ownership are missing. The team adds these points to the architecture decision and repeats the task. The review improves implementability before coding begins.

This is how you read the picture

  1. Intermediate design Intermediate design
  2. Task Task
  3. Feedback Feedback
ARID: inspect the decision
ConceptMeaningReview question
Intermediate designA still-evolving design is examined.Who exercises the intermediate design?
TaskParticipants actively use the design.Which observation indicates a design gap?
FeedbackGaps in understanding lead to concrete revision.What remains open after a successful ARID session?
Die Review richtet sich auf Nutzbarkeit und Verständlichkeit des Entwurfs und liefert Rückmeldung, solange Änderungen noch günstig sind. Sie ersetzt keine breite Qualitätsanalyse wie ATAM und bewertet nur die Aufgaben und Beteiligten im Workshop. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Check early designs for clear implementation guidance.
  • Involve implementation representatives with realistic tasks.

Boundaries

  • A small review group does not automatically represent every user role.
  • ARID checks an intermediate design for task clarity and implementability, not overall system quality.

In practice

  1. Give developers the intermediate design and a representative invoicing task, then ask them to carry it out using the described interfaces.
  2. Observe where terminology, responsibilities, data flows, or error handling are missing; capture concrete questions instead of prescribing solutions during the exercise.
  3. Revise the design based on observed blockers and repeat the task with a second person to check whether the interfaces are clear and complete.
Read the detailed explanation

ARID combines an active design review with an early intermediate stage of architecture development. Participants work through representative tasks using the design and check whether it provides enough guidance for implementation.

The review focuses on usability and clarity of the design and returns feedback while changes are still inexpensive. It does not replace broad quality analysis such as ATAM and evaluates only the tasks and participants included in the workshop.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. Before implementing a new invoicing function within the existing invoice module, the team presents its intermediate design and asks two developers to work through a typical task: store invoice status after successful payment. They find that the transaction boundary, failure path, and retry ownership are missing. The team adds these points to the architecture decision and repeats the task. The review improves implementability before coding begins. review and lasr help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Who exercises the intermediate design?

    View the solution with justification

    Developers work through a concrete invoice task and report obstacles.

  2. ApplyingTransferred to a new situation

    Which observation indicates a design gap?

    View the solution with justification

    Several developers interpret rules or responsibilities differently.

  3. EvaluateWeighing an alternative

    What remains open after a successful ARID session?

    View the solution with justification

    Coverage of other tasks, user roles, and system qualities.

Continue on the learning path

Next in Evolution & assessment: SAAM.

15 Building blocks

Continue withSAAM