Menu

Asset

Mappa degli artefatti architetturali

Una mappa pratica per scegliere l'artefatto in base alla domanda da risolvere, al pubblico, al momento del lavoro e al livello di dettaglio necessario, invece di partire da un catalogo fisso di deliverable.

Tipo
Pratica

L'artefatto deve ridurre un'incertezza concreta

La scelta dell'artefatto parte dalla domanda che deve trovare risposta, non dal template disponibile. Un artefatto utile rende una decisione, un confine, un contratto, un rischio o un percorso di transizione più comprensibile e verificabile.

Domanda e artefatto minimo

  • Capire problema e confini: problem statement, context map, scope, constraints.
  • Creare un modello mentale condiviso: System Context, Container, Component, interaction overview.
  • Confrontare alternative: options analysis, trade-off table, decision matrix.
  • Registrare una scelta: ADR o decision record.
  • Descrivere contratti e boundary: API/event contract, data schema, responsibility boundary.
  • Rendere visibili qualità e rischi: NFR view, security/resilience view, threat model, capacity assumptions.
  • Pianificare la transizione: transition architecture, migration plan, sequence of states.
  • Rendere il sistema operabile: runtime/deployment view, dependency map, runbook, failure scenarios.

Mappa che collega domande architetturali a famiglie di artefatto: problema, modello mentale, alternative, decisioni, contratti, qualità, transizione e operabilità.

L'artefatto si sceglie a partire dalla domanda da risolvere.

Scegliere anche il formato

  • Testo strutturato per rationale, assunzioni, vincoli e decisioni.
  • Diagrammi per relazioni, confini e flussi.
  • Tabelle e matrici per confronti, ownership e copertura.
  • Formati machine-readable per contratti verificabili.
  • Repository e versionamento per artefatti che evolvono con il software.
  • Workspace collaborativi per esplorazione e workshop.

Fermarsi alla minima evidenza sufficiente

Il luogo in cui nasce un artefatto e il luogo in cui deve vivere sono decisioni diverse. Un disegno può nascere su una whiteboard e diventare versionato solo quando stabilizza. La domanda finale è quale minima evidenza serve perché qualcun altro possa capire, implementare, verificare e mantenere la decisione.

Tag