L’architettura a quattro livelli separa ciò che deve rimanere stabile da ciò che cambia con cliente, progetto e tecnologia. [AR01 - Foundation] contiene principi, entità, relazioni e regole canoniche. [AR02 - Consulting Delivery System] traduce il metodo in servizi, workshop, attività, QA e gate. [AR03 - Toolkit] comprende workbook, canvas, checklist e template. [AR04 - Case Library] conserva applicazioni, pattern, anti-pattern e lesson.
Ogni livello ha un versioning distinto. Una correzione a un template non modifica automaticamente la foundation; una lesson di caso entra nella Case Library e diventa regola soltanto dopo una decisione esplicita. Questo evita che una tecnologia scelta per un progetto o una preferenza di un cliente diventi accidentalmente parte del metodo.
| ESEMPIO L’uso di un modello locale nel Buyer Assistant appartiene al case e all’architettura di implementazione. Il requisito di sovranità del dato può influenzare il target design; il prodotto specifico non diventa un elemento di AR01. |
|---|
| Livello | Contenuto | Versioning |
|---|---|---|
| [AR01 - Foundation Core] | Tesi, principi, pilastri, regole, scoring e concetti normativi | Release metodologica |
| [AR02 - Consulting Toolkit] | Workbook, canvas, template, workshop e guide | Allineato alla foundation |
| [AR03 - Evidence System] | Evidenze, osservazioni, gate, remediation e decision record | Snapshot per engagement |
| [AR04 - Case Library] | Esempi, pattern, anti-pattern, lesson e trasferibilità | Aggiornabile senza cambiare il core |
Comprendere — sintesi practitioner
La domanda di controllo è se l’engagement riesca davvero a separare foundation, delivery system, toolkit e case library mantenendo versioning coerente. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.
I quattro livelli collegano business, operating model, Digital Role e tecnologia senza invertire la dipendenza.
Applicare — sequenza minima
Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è separare foundation, delivery system, toolkit e case library mantenendo versioning coerente.
Congelare outcome/processo/decisioni prima del ruolo; congelare ruolo, memoria e controlli prima dell’architettura tecnica.
Vedere in pratica — Buyer Assistant
Il caso mostra come separare foundation, delivery system, toolkit e case library mantenendo versioning coerente senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.
Buyer Assistant valuta edge, cloud e ibrido solo dopo aver definito volumi, latenza, sovranità, aggiornamento e fallback.
Verificare — definition of done
La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile separare foundation, delivery system, toolkit e case library mantenendo versioning coerente; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.
Ogni requisito tecnico risale a un requisito operativo.
Dipendenze e exit sono trasparenti.
Il vendor non determina il metodo.