Informazione e decisione: due livelli

Per un certo periodo, l'architettura ha trattato la creazione di un documento come la fine di un processo.

Era una semplificazione utile. Era anche sbagliata.

Un documento può registrare, comunicare o dimostrare qualcosa. La conseguenza — approvare, pagare, pubblicare o rifiutare — appartiene al processo che lo utilizza. Confondere i due fa apparire un sistema completo prima che la decisione importante sia realmente avvenuta.

La differenza sembra piccola. In pratica, cambia dove collocare la validazione, l'autorità, il giudizio umano e il recupero dagli errori.

Dove il modello ha fallito

Il problema è diventato visibile in un'integrazione contabile. La sequenza prevista era prudente: preparare le informazioni in un sistema, rivederle e solo allora consentire un'azione esterna con conseguenze fiscali.

La documentazione pubblica dell'interfaccia non permetteva inizialmente di dimostrare che esistesse una pausa significativa prima della finalizzazione. Diverse implementazioni sembravano possibili, ma nessuna era verificata.

Questa incertezza ha definito il primo confine di produzione. Il sistema poteva caricare i dati locali autorevoli, verificare permessi e coerenza, preparare il riferimento esterno e indicare se le informazioni erano pronte. Non poteva scrivere nel sistema esterno.

Non era automazione incompleta mascherata da architettura. Era un confine esplicito: procedere con ciò che era noto e fermarsi dove il contratto esterno rimaneva incerto.

L'errore è arrivato dopo. Ho trasformato un controllo progettato per un'integrazione con conseguenze in un modello generale per tutti i documenti.

Il modello non si adattava bene agli altri casi. Un contratto, un rapporto operativo, un estratto importato e una nota interna sono tutti documenti, ma non creano gli stessi obblighi né richiedono gli stessi controlli.

Il caso era una prova utile. Non era la categoria.

Due responsabilità, non un unico ciclo di vita

Il modello rivisto separa due responsabilità.

La prima riguarda l'informazione stessa:

Che cos'è questo oggetto?
Qual è la versione attuale?
Da dove proviene l'informazione?
Chi può accedervi o modificarla?
Per quanto tempo deve essere conservata?

La seconda riguarda la decisione che la utilizza:

Chi ha l'autorità per procedere?
Che cosa deve essere verificato prima?
Quale evento crea la conseguenza reale?
Che cosa accade se il risultato viene rifiutato o rimane incerto?
Come confermiamo ciò che un sistema esterno ha realmente fatto?

I due livelli sono collegati, ma non avanzano insieme. Un contratto può raggiungere la quarta versione mentre la revisione legale è ancora aperta. Un rapporto può essere definitivo come documento mentre la decisione operativa che lo utilizza rimane in sospeso. Un PDF può conservare la prova di un'approvazione senza essere l'approvazione stessa.

Questa separazione è coerente con gli standard consolidati di gestione documentale e di processo. ISO 15489 si concentra sulla creazione e gestione dei documenti. W3C PROV distingue informazione, attività e responsabilità. BPMN separa i dati utilizzati da un processo dalle attività e decisioni che compongono quel processo.

Gli standard convalidano la distinzione. Non devono dominare la progettazione.

Che cosa è cambiato nell'architettura

Il primo modello sembrava rassicurante nella sua linearità: l'informazione entrava, superava la validazione, riceveva l'approvazione e produceva un documento finale.

Il lavoro reale era meno ordinato. Una decisione poteva attendere, fallire, tornare indietro per una correzione o dipendere da una risposta esterna che non arrivava mai. Il documento poteva cambiare senza riaprire la decisione; la decisione poteva cambiare senza produrre un nuovo file.

L'architettura rivista parte quindi da tre domande:

Quali informazioni devono rimanere affidabili?
Quale decisione crea la conseguenza e chi ne è responsabile?
Quali prove e quale recupero servono quando il risultato è incerto?

I controlli derivano dalle risposte. Una doppia approvazione può essere giustificata per un rischio e inutile in un altro contesto. Una firma può dimostrare chi ha firmato senza provare che il contenuto sia corretto. Un nuovo tentativo automatico può essere sicuro quando il servizio esterno impedisce i duplicati e pericoloso quando non lo fa. Conservare tutte le versioni può agevolare un audit e, allo stesso tempo, contraddire un legittimo obbligo di cancellazione.

Il controllo non definisce l'architettura. L'architettura spiega perché il controllo esiste e dove smette di essere utile.

Il cambiamento professionale

Le versioni precedenti del mio lavoro diventavano spesso più elaborate con l'aumentare dell'incertezza. Più stati, più verifiche e più componenti facevano sembrare la progettazione più sicura.

Questo caso ha cambiato quell'istinto. Quando un'ipotesi non può essere verificata, aggiungere meccanismi attorno ad essa non la rende vera. Un confine più piccolo può essere la progettazione più responsabile.

È questa l'evoluzione che vale la pena mostrare: non una sequenza di funzionalità consegnate, ma un cambiamento nel modo in cui viene distribuita la responsabilità. L'informazione deve rimanere comprensibile. Le decisioni devono avere responsabili. Le conseguenze devono essere osservabili. L'incertezza deve fermare il sistema nel punto giusto.

La maturità architetturale non si vede nel numero di riquadri in un diagramma. Si vede nella precisione dei loro confini.

Fonti

TOConline, Documenti di vendita — API attuale — https://api-docs.toconline.pt/apis/vendas/documentos-de-venda (consultato il 14 settembre 2026).
TOConline, Documenti di vendita — Versioni precedenti — https://api-docs.toconline.pt/apis/versoes-anteriores/vendas/documentos-de-venda (consultato il 14 settembre 2026).
ISO, ISO 15489-1:2016 — Records management: Concepts and principles — https://www.iso.org/standard/62542.html (versione attuale confermata da ISO nel 2021).
W3C, PROV-O: The PROV Ontology — https://www.w3.org/TR/prov-o/ (Raccomandazione W3C, 2013).
Object Management Group, Business Process Model and Notation 2.0.2 — https://www.omg.org/spec/BPMN/2.0.2/PDF (2014).
IETF, RFC 9110 — HTTP Semantics, §9.2.2 Idempotent Methods — https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2 (2022).
Unione europea, Regolamento (UE) 2016/679 — GDPR, articolo 5(1)(e) — https://eur-lex.europa.eu/eli/reg/2016/679/oj.