L'Event Storming come punto di partenza

Riscrivere un prodotto partendo dal codice esistente significa copiare i suoi errori con tecnologia più recente. Il problema non cambia se invece di riscrivere si vuole integrare: partendo dalle applicazioni che già ci sono, il massimo che si ottiene è una versione più ordinata dei problemi di sempre. Il punto di partenza non è mai il software. È il dominio, e va fatto emergere insieme a chi quel dominio lo vive ogni giorno.

Ho visto questa strada da due punti di partenza opposti. In viteSicure il dominio non era mai stato modellato e bisognava riscrivere tutto. In PharmaLink il dominio era già modellato, ma il modello viveva fuori dal software che avrebbe dovuto guidare. In entrambi i casi lo strumento è stato lo stesso: l’Event Storming. Usato in modi diversi.

viteSicure: far emergere un dominio mai modellato

viteSicure è il brand con cui Bridge Insurance Services vende polizze online. Il backend legacy fatturava, ma era nato attorno a un solo prodotto e lo mostrava in ogni sua parte. Riscriverlo partendo da quel codice avrebbe significato portare nella nuova applicazione i limiti della vecchia.

A novembre 2022 ho facilitato un Event Storming strategico insieme a Luca Giovenzana, fractional CTO. Nella stanza c’erano tutta viteSicure e i due consulenti che allora mantenevano l’applicazione. Il codice racconta come si è evoluto il software, non come funziona il business: per questo non siamo partiti da lì. Da quella sessione sono usciti i bounded context, diventati i moduli del nuovo backend.

PharmaLink: un dominio già modellato, scollegato dal software

PharmaLink, nome fittizio per un laboratorio farmaceutico del Benelux, aveva il problema opposto. Nei due anni precedenti Max, un coach lean, aveva modellato il processo produttivo con Value Stream Mapping e un Event Storming Big Picture, tutti modelli validati nel tempo. Mancava però la relazione tra quel modello e le applicazioni: ogni dipartimento aveva i suoi strumenti e le sue parole, e la pianificazione viaggiava su email e fogli Excel.

Prima osservare, poi modellare

Lo sprint di discovery del 2025 non è iniziato con i post-it. Nei primi tre giorni il team di sviluppo si è diviso e ha fatto affiancamento nei dipartimenti, per vedere quali software venivano usati davvero e come. Il quarto giorno è servito a condividere e riordinare le idee internamente. Prima si osserva come le persone lavorano, poi si modella insieme a loro.

Quattro Event Storming, non uno

I tre giorni seguenti sono stati dedicati a quattro Event Storming Process Level su parti diverse del processo. La prima mezza giornata è andata al Big Picture già esistente, seguita da tre sessioni da mezza giornata e una da una giornata intera. Il processo era troppo vasto per una sessione unica, e spezzarlo in modo razionale è stato possibile solo perché il lavoro di Max aveva già disegnato i confini. Non esiste “l’Event Storming” al singolare: se ne fa uno per ogni parte da esplorare, quando serve.

In tutte le sessioni, Big Picture compreso, abbiamo riportato sui modelli i software usati nelle varie parti del processo. Non fa parte della notazione classica dell’Event Storming, ma per noi era indispensabile: l’obiettivo non era solo capire il flusso, era capire come il flusso attraversa le applicazioni esistenti. Quell’aggiunta è diventata una parte importante degli artefatti finali.

L’ultimo giorno il team di sviluppo, con Max e me, ha sintetizzato ciò che era emerso: le parti che richiedevano attenzione immediata, quelle più critiche e quelle ancora poco chiare.

Chi deve stare nella stanza

Ogni sessione toccava una sola parte del flusso e coinvolgeva due o tre dipartimenti. Erano sempre presenti tutti i membri del team di sviluppo, i responsabili dei dipartimenti o un loro delegato che conoscesse i processi interni, e due persone operative per ogni dipartimento coinvolto. Anche con questa selezione, nella stanza c’erano oltre 15 persone.

Per ridurre il carico cognitivo abbiamo ristretto il flusso di ogni sessione, mai la rappresentanza. È la regola che decide se un Event Storming serve a qualcosa: se business e operativi non sono nella stanza, il workshop diventa teatro. Chi modella senza chi il processo lo vive produce il diagramma elegante di un’azienda che non esiste.

Quando il problema è la lingua

I problemi più eclatanti emersi nelle sessioni erano linguistici.

Le materie prime avevano tre nomi. L’ufficio acquisti usava i nomi commerciali, i reparti tecnici quelli chimici, la logistica dei nomignoli che erano diventati il suo linguaggio condiviso. Ogni dipartimento aveva il suo ubiquitous language locale, e nessuno coincideva con gli altri.

Le due linee di produzione usavano a volte lo stesso nome per procedimenti diversi. Alcuni processi della linea 2 erano vaghi o ignoti a chi gestiva la linea 1, e spostare carico da una linea all’altra era difficile anche per questo.

Alcuni processi potevano essere eseguiti sia in laboratorio sia in linea 2 e portavano lo stesso nome, perché erano sostanzialmente lo stesso processo realizzato in modo diverso. Cambiavano però accuratezza, precisione e materie prime lavorabili, e capire dove dovesse essere fatto un processo era tutt’altro che scontato.

Cosa ne è uscito

Le sessioni hanno prodotto un modello, e il modello è un artefatto di valore: è servito a prendere decisioni in quel momento e resta la base per quelle future. Il risultato più durevole è il mapping tra processi e software utilizzati, nato proprio dall’aggiunta dei software alla notazione classica. Da allora, cambiare o rifare uno strumento ha implicazioni leggibili su una mappa, invece di essere riscoperte ogni volta.

Dalle sessioni sono nate anche idee che si sono trasformate in decisioni. Il tool di mapping dei nomi è nato dentro una delle sessioni, ed è stato poi validato con gli altri stakeholder e integrato nella nuova applicazione centralizzata. La visualizzazione centralizzata delle informazioni era già stata ipotizzata in precedenza, e lo sprint ne ha validato la necessità e la forma.

Il Big Picture di Max è uscito dalle sessioni quasi intatto. Le uniche correzioni hanno riguardato punti del modello rimasti vaghi perché ancora ignoti. È un buon segno: il lavoro precedente era solido, e le sessioni lo hanno esteso dove serviva invece di rifarlo.

I punti di contatto

Due storie diverse, ma gli stessi principi.

• Mai partire dal codice esistente. In viteSicure perché era il modello del problema sbagliato. In PharmaLink perché il software era il posto dove il problema di linguaggio si manifestava, non quello dove nasceva.
• Non esiste “l’Event Storming” al singolare. In viteSicure uno strategico iniziale e uno dedicato arrivato dopo, quando è servito esplorare la parte finale del flusso. In PharmaLink quattro sessioni su parti diverse del processo.
• I modelli si raffinano nel tempo, non si indovinano il primo giorno. In viteSicure un bounded context è stato aggiunto dopo, spostando codice già scritto. In PharmaLink il Big Picture è stato rivisto e dettagliato nei punti che erano vaghi.
• Il business nella stanza, o è teatro. In viteSicure tutta l’azienda, compresi i consulenti uscenti. In PharmaLink responsabili e operativi di ogni dipartimento toccato, con il vincolo opposto da gestire: troppe persone, e si è ristretto il flusso invece della rappresentanza.
• Il lavoro preparatorio conta quanto il workshop. In PharmaLink i modelli di Max e i giorni di affiancamento nei dipartimenti. In viteSicure la facilitazione in coppia con il fractional CTO. Un Event Storming non improvvisa la conoscenza: la organizza e la rende condivisa.
• Il modello serve a decidere. In viteSicure i bounded context sono diventati i moduli da riscrivere uno alla volta. In PharmaLink il mapping tra processi e software guida le scelte sugli strumenti, e un’idea nata nella stanza è diventata un tool.

L’Event Storming funziona come punto di partenza perché è il primo momento in cui business e prodotto guardano lo stesso flusso e scoprono di chiamarlo con nomi diversi. Tutto il resto viene dopo: bounded context, architetture, strumenti. E regge solo se la lingua condivisa costruita in quella stanza continua a essere curata.

Approfondimenti

Le esperienze complete: viteSicure, la riscrittura senza fermare il business e PharmaLink, meno errori di pianificazione senza big bang. Il lato tecnico, dai bounded context al codice, è raccontato in due storie a confronto.