Come decidere quali modifiche di processo richiedono una regola, una configurazione o uno sviluppo su misura

Quando un processo digitale cambia, la discussione viene spesso formulata in modo troppo semplice: «lo facciamo rapidamente con un parametro o dobbiamo svilupparlo?». Questa domanda nasconde una decisione progettuale più importante. Ogni modifica incorpora una regola di business, un'aspettativa operativa e un costo futuro di manutenzione. Risolvere tutto con il codice rallenta l'adattamento; risolvere tutto con opzioni di configurazione può rendere il prodotto imprevedibile, difficile da verificare e fragile.

La decisione corretta non dipende solo dallo sforzo iniziale. Dipende dalla stabilità della regola, da chi deve modificarla, dal rischio connesso e dal fatto che la modifica introduca una nuova capacità. L'obiettivo è far evolvere il processo senza trasformare ogni eccezione in una diramazione permanente né nascondere decisioni critiche in schermate di amministrazione ambigue.

Le tre alternative e il limite di ciascuna

Una stessa richiesta può essere espressa come regola fissa, configurazione o sviluppo su misura. Sono meccanismi diversi e devono avere responsabilità chiare.

Regola stabile implementata nel codice

Una regola nel codice è appropriata quando rappresenta un comportamento strutturale del prodotto: convalide obbligatorie, vincoli di sicurezza, calcoli con scarsa variabilità o decisioni che devono essere identiche per tutti i casi di uno stesso contesto. È inoltre una buona scelta se modificarla richiede la comprensione di dipendenze tecniche o se un errore avrebbe conseguenze gravi.

• Vantaggio: comportamento esplicito, versionato insieme al software e coperto da test automatizzati.
• Rischio: un piccolo adeguamento operativo richiede un rilascio e può creare dipendenza dal team tecnico.
• Segnale diagnostico: la regola rimane pressoché invariata per mesi e vi sono pochi motivi legittimi perché ogni unità possa modificarla.

Configurazione gestibile

La configurazione serve per le variazioni previste del processo. Per esempio, soglie di approvazione, destinatari delle notifiche, calendari operativi, categorie abilitate o sequenze di passaggi all'interno di un quadro già progettato. Non è un modo per evitare la progettazione: è una capacità di prodotto che richiede modello dati, autorizzazioni, convalide e un'interfaccia comprensibile.

• Vantaggio: business o operations possono rispondere a modifiche autorizzate senza attendere un ciclo di sviluppo.
• Rischio: troppi parametri generano combinazioni impossibili da comprendere o testare.
• Segnale diagnostico: la modifica è ricorrente, prevedibile e rientra nei limiti che il sistema può convalidare.

Sviluppo di una nuova capacità

Lo sviluppo su misura è necessario quando la richiesta modifica il modello del processo: introduce partecipanti, stati, decisioni, dati, integrazioni o eccezioni che prima non esistevano. Cercare di inserirla come parametro porta spesso a una logica condizionale dispersa e a un'interfaccia di configurazione che nessuno riesce a governare.

• Vantaggio: consente di progettare una soluzione coerente, osservabile e sostenibile.
• Rischio: trattare una necessità puntuale come una piattaforma generica e sovradimensionare l'ambito.
• Segnale diagnostico: per supportare la modifica occorre aggiungere campi, autorizzazioni, regole di instradamento o nuovi stati.

Le sei domande per classificare una modifica

Prima di stimare le attività, prodotto, business e tecnologia dovrebbero rispondere per iscritto alle domande seguenti. Le risposte riducono le decisioni basate solo sull'urgenza o sul costo apparente della prima implementazione.

1. Con quale frequenza cambia? Se può variare più volte all'anno per legittime decisioni operative, la configurazione merita una valutazione. Se è eccezionale e non si ripeterà, può essere preferibile una regola esplicita o una soluzione temporanea con una data di rimozione.
2. La variazione era prevista nel progetto? Configurare non deve significare accettare qualsiasi comportamento. Deve esistere un insieme delimitato di opzioni e regole di compatibilità.
3. Chi è il proprietario della decisione? Se deve cambiarla il team operations, questo necessita di un'esperienza sicura e di autorizzazioni appropriate. Se richiede un'interpretazione tecnica, deve rimanere nel codice.
4. Qual è l'impatto di un errore? Quanto maggiore è l'impatto finanziario, legale, sulla sicurezza o sulla continuità operativa, tanto maggiore deve essere il controllo: convalida, revisione, test e tracciabilità.
5. Influisce sul modello di dominio? Se compare una nuova entità, uno stato, un ruolo o una relazione, non si tratta solo di configurare; probabilmente vi è una capacità da progettare.
6. Come verrà verificata e annullata? Se non è possibile visualizzare in anteprima l'effetto, registrare la modifica e tornare indietro, la configurazione non è pronta per essere gestibile.

Una configurazione sana limita le decisioni all'interno di un progetto; non trasferisce all'utente la responsabilità di progettare il sistema.

Quando usare codice, configurazione o sviluppo

Una regola stabile nel codice è preferibile quando una richiesta non ammette variazioni per unità, quando protegge una condizione essenziale o quando la sua validità dipende da una logica complessa. Per esempio, impedire che una richiesta passi all'approvazione senza i dati minimi richiesti. Trasformare questa condizione in una casella modificabile può peggiorare la qualità del processo.

La configurazione è appropriata per decisioni operative che cambiano entro un intervallo noto. Un flusso di approvazione può consentire di definire l'importo oltre il quale è richiesta una seconda revisione, purché il sistema convalidi il valore, identifichi i responsabili ed eviti di lasciare il flusso senza approvatore. In questo caso, il prodotto non offre libertà assoluta: offre variabilità controllata.

Lo sviluppo su misura deve iniziare quando la modifica altera la natura del flusso. Se un'organizzazione richiede approvazioni parallele, delega temporanea, regole basate sugli attributi di più entità e un'escalation alla scadenza, probabilmente ha superato un parametro di soglia. È opportuno progettare una capacità di instradamento e decisione, anche se viene implementata in modo incrementale.

Rischi che rivelano una decisione errata

La parametrizzazione eccessiva è il rischio più comune. La si riconosce spesso perché la schermata contiene nomi tecnici, opzioni contraddittorie, dipendenze implicite e valori che nessuno osa modificare. Il team finisce per aver bisogno di uno sviluppatore che interpreti una configurazione che, in teoria, era gestita dal business.

Il problema opposto sono le eccezioni invisibili nel codice. Emergono quando ogni cliente, area o caso speciale aggiunge una condizione isolata. Nel tempo, due regole producono risultati diversi per situazioni che sembrano equivalenti e nessuno sa spiegare quale prevalga. Un segnale chiaro è che gli incidenti si risolvono chiedendo «quale condizione viene valutata per prima» invece di consultare una policy comprensibile.

Esiste anche il rischio di logica duplicata. Una soglia definita in un'interfaccia amministrativa, ripetuta in un servizio di integrazione e reinterpretata in un report genera divergenze. Per evitarlo, ogni decisione deve avere un'unica fonte di verità, un proprietario e un punto noto in cui viene valutata.

Come progettare una configurazione sicura e governabile

Una configurazione gestibile deve essere trattata come parte del prodotto, non come una tabella modificabile. Definite prima quali variazioni sono valide e quali no. Quindi, introducete controlli proporzionati all'impatto.

• Autorizzazioni per ruolo: separate chi può consultare, proporre, approvare e pubblicare le modifiche.
• Convalide di business: impedite combinazioni non valide prima del salvataggio, non quando il processo è già fallito.
• Cronologia verificabile: registrate cosa è cambiato, chi lo ha fatto, quando e quale fosse il valore precedente.
• Ambito esplicito: indicate chiaramente se la regola si applica all'intera organizzazione, a un'unità, a un tipo di richiesta o a un periodo.
• Test di scenario: consentite di verificare casi rappresentativi prima di attivare una modifica ad alto impatto.
• Ripristino: offrite un modo controllato per recuperare una versione precedente senza modificare manualmente più valori.

Le raccomandazioni di OWASP sull'autorizzazione e sulla convalida degli input sono particolarmente pertinenti quando utenti non tecnici gestiscono regole che incidono su autorizzazioni, importi o percorsi decisionali. L'interfaccia deve spiegare l'effetto di ogni modifica senza rivelare dettagli tecnici non necessari.

Esempio: l'evoluzione di un flusso di approvazione

Immaginate un flusso nel quale ogni richiesta superiore a un importo definito richiede l'approvazione di una persona responsabile. L'obbligo di indicare un importo e il divieto di approvare la propria richiesta sono regole stabili: devono rimanere nel codice ed essere coperte da test.

L'importo soglia e la persona responsabile possono essere configurabili se cambiano per unità operativa e il sistema convalida che esista sempre un responsabile attivo. La cronologia deve mostrare quale soglia fosse in vigore all'avvio di ogni richiesta, affinché una modifica successiva non riscriva il contesto di una decisione già presa.

Se in seguito viene richiesto che due aree approvino in parallelo, che la responsabilità dipenda da categoria e regione e che vi sia delega durante le assenze, il team deve fermarsi. Non è più ragionevole aggiungere caselle alla configurazione esistente. È il momento di definire una capacità di regole di instradamento, con priorità, conflitti, stati e osservabilità propri.

La decisione sostenibile non consiste nello scegliere sempre l'alternativa più rapida. Consiste nello scegliere il meccanismo che preserva la chiarezza del processo oggi e consente di evolverlo domani. Usate il codice per le invarianti, la configurazione per le variazioni previste e lo sviluppo per i cambiamenti del modello.