Il tuo sistema funziona alla grande. Finché lavora la persona che sa perché.
L'azienda ha un sistema che è stato realizzato in sette anni. Funziona. Gestisce i clienti. Si integra con altri sistemi. Esegue processi senza i quali l'azienda praticamente non potrebbe funzionare normalmente.
In questi sette anni al progetto hanno lavorato cinque sviluppatori. Inoltre due freelance e un'agenzia. Parte della documentazione si trova in Confluence, parte su Google Drive, parte nei ticket. Da qualche parte c'è ancora un vecchio documento relativo a una delle integrazioni. E quando qualcuno chiede perché una determinata parte del sistema funzioni proprio in quel modo, la risposta è: "Forse se lo ricordava Michał."
Michał se n'è andato tre anni fa.
Ed è proprio allora che inizia il vero problema.
Non perché il sistema sia scritto male. Non perché abbia improvvisamente smesso di funzionare. Il problema è che l'azienda ha smesso di possedere una conoscenza completa del proprio sistema.
Il sistema funziona, ma l'azienda potrebbe non controllarlo
Questa è una delle forme più sottovalutate di debito tecnologico.
Quando parliamo di debito tecnologico, di solito pensiamo a codice vecchio, librerie non aggiornate, errori architetturali, mancanza di test o soluzioni che un tempo erano rapide ma oggi ostacolano lo sviluppo.
Nel frattempo esiste un altro tipo di debito. Debito di conoscenza.
Nasce quando il sistema dipende da informazioni che non si trovano nella documentazione, nel repository, nelle procedure o nell'organizzazione, ma solo nelle teste di persone specifiche.
E finché queste persone sono disponibili, tutto può sembrare normale.
Il problema emerge con un cambio di team, l'uscita di uno sviluppatore, la fine della collaborazione con una software house, un guasto al server, il cambio dell'amministratore oppure la necessità di implementare rapidamente una nuova soluzione.
All'improvviso si scopre che l'azienda ha il codice, ma non ha la conoscenza.
Ha il server, ma non sa chi ha gli accessi.
Ha un'integrazione, ma non sa con quale account sia stata creata.
Ha la documentazione, ma non sa quale versione sia attuale.
Ha un processo, ma non sa perché sia stato progettato proprio così.
E allora sorge molto rapidamente la domanda: chi è davvero il proprietario di questo sistema?
Bus factor, cioè cosa succede se scompare una persona?
Nel mondo IT esiste il concetto di bus factor. In parole semplici, indica il numero di persone la cui indisponibilità può far sì che il team non sia più in grado di sviluppare o mantenere efficacemente il progetto.
Naturalmente non si tratta di un evento letterale. È un modo di pensare alla concentrazione della conoscenza.
Se solo una persona sa come funziona un'integrazione critica, il bus factor per quella conoscenza è uno.
Se solo un amministratore ha accesso alla produzione, il bus factor è uno.
Se solo una persona sa perché il sistema esegue un determinato processo ogni notte, il bus factor può essere uno.
Se l'azienda collabora con una software house esterna e dal lato cliente nessuno comprende l'architettura della soluzione, nasce un problema ancora più grande: la conoscenza può trovarsi al di fuori dell'organizzazione.
Questo non significa che ogni azienda debba avere cinque esperti per ogni parte del sistema.
Si tratta di qualcosa di molto più semplice: l'azienda dovrebbe sapere dove si trova la conoscenza critica e se riesce a recuperarla senza una persona specifica.
Il codice dice come. Non sempre dice perché.
Uno sviluppatore può leggere il codice e capire cosa fa una certa funzione.
Non sempre saprà però perché sia stata scritta proprio in quel modo.
È una differenza enorme.
Si può trovare il frammento responsabile dell'invio dei dati a un sistema esterno. Si può analizzare l'endpoint, i parametri, l'autenticazione e la gestione degli errori.
Ma il codice non risponderà necessariamente alle domande:
- Perché inviamo i dati alle 2:00 di notte?
- Perché questo stato specifico viene ignorato?
- Perché dopo un errore il sistema riprova esattamente tre volte?
- Perché un valore viene ricalcolato prima dell'invio?
- Perché non si può cambiare l'ordine di queste operazioni?
- Perché questa integrazione usa un account specifico?
La risposta può trovarsi nella storia del progetto, in un vecchio ticket, in un'email di sei anni fa oppure - peggio ancora - solo nella memoria della persona che non lavora più in azienda.
Per questo una buona documentazione non dovrebbe essere solo un manuale su "cosa cliccare".
Dovrebbe conservare anche il contesto e le decisioni.
Il problema più grande può essere un'integrazione che nessuno ricorda più
Un sistema moderno quasi mai funziona completamente da solo.
Si collega a un sistema ERP. CRM. Gateway di pagamento. Fornitore di SMS. Sistema di corriere. API del partner. Servizio cloud. Piattaforma analitica. Sistema contabile. Meccanismo di autenticazione.
Ogni tale collegamento è parte di una catena tecnologica.
E ogni parte di questa catena può avere un proprio proprietario, account, chiave API, certificato, contratto, limite, versione API e ciclo di vita.
Dopo alcuni anni, nessuno potrebbe più ricordare chi abbia creato un dato account.
E allora basta la scadenza di un certificato o un cambiamento dell'API perché il sistema smetta di funzionare.
Ancora peggio, se l'azienda non sa nemmeno che una determinata dipendenza esiste.
Per questo, in un approccio maturo ai sistemi, assume sempre più importanza la provenienza del software, la gestione delle dipendenze e la trasparenza della supply chain del software. Il NIST, nei suoi materiali attuali sulla sicurezza della supply chain, indica tra le altre cose l'importanza delle informazioni sui componenti, sulla loro origine, sul loro ciclo di vita e sulle dipendenze. SBOM, cioè Software Bill of Materials, è uno degli strumenti che consentono di ordinare la conoscenza di quali componenti compongono il software.
Non è più un tema soltanto per il team di sicurezza.
È anche un tema per il management.
Perché se l'azienda non sa da cosa è costruito il suo sistema, le è più difficile valutare il rischio, il costo di manutenzione e le conseguenze delle modifiche.
La documentazione non è un costo. È una polizza.
In molte aziende la documentazione viene trattata come qualcosa che "si farà più tardi".
Prima la funzionalità.
Poi il rilascio.
Poi le correzioni.
Poi il progetto successivo.
E la documentazione?
"Quando ci sarà tempo."
Il problema è che il tempo per la documentazione arriva di solito quando è già troppo tardi.
La documentazione dovrebbe funzionare come un'assicurazione aziendale. Non perché qualcuno la leggerà ogni giorno. Anzi - auspicabilmente sarà necessaria il meno possibile in una situazione di emergenza.
Ma quando si verifica un problema, l'azienda dovrebbe poter rispondere alle domande fondamentali:
- Come funziona il sistema?
- Da cosa è composto?
- Dov'è l'ambiente di produzione?
- Chi ha accesso?
- Quali sono le integrazioni critiche?
- Quali account e servizi esterni vengono utilizzati?
- Quali sono le dipendenze?
- Come vengono eseguiti i backup?
- Com'è il processo di deployment?
- Cosa succede durante un guasto?
- Quali elementi sono critici per il business?
- Perché sono state prese le principali decisioni architetturali?
- Chi può subentrare nella manutenzione del sistema?
Questo non deve per forza significare centinaia di pagine di documentazione.
Una buona documentazione deve essere soprattutto utile, aggiornata e accessibile alle persone giuste.
"Non tocchiamolo, perché funziona" non è sempre una cattiva decisione
C'è ancora un altro problema molto comune.
Il sistema funziona da anni, quindi l'azienda adotta la regola: "Non tocchiamo nulla. Funziona."
E a volte è assolutamente ragionevole.
Non ogni vecchia tecnologia richiede una sostituzione immediata. Non ogni vecchia parte di codice va riscritta. Non ogni libreria significa catastrofe. Non ogni architettura di qualche anno fa è sbagliata.
Il problema inizia quando "non tocchiamo nulla" significa anche:
- "Non analizziamo."
- "Non documentiamo."
- "Non verifichiamo le dipendenze."
- "Non chiediamo chi ha accesso."
- "Non controlliamo se abbiamo ancora tutti gli account."
- "Non definiamo cosa succederà se l'attuale fornitore non sarà più disponibile."
Allora l'assenza di cambiamenti non è una strategia.
È rimandare il rischio.
A volte la migliore decisione tecnica è davvero non ricostruire nulla.
Ma questa decisione dovrebbe derivare dalla conoscenza del sistema, non dalla mancanza di conoscenza del sistema.
Cosa dovrebbe includere un audit di un sistema ereditato?
Quando un'azienda prende in carico un sistema da un altro software house, da un freelancer o da un team interno, il primo passo non dovrebbe essere la riscrittura automatica di tutto.
Prima bisogna capire che cosa è stato effettivamente preso in consegna.
L'audit dovrebbe rispondere ad almeno alcune aree fondamentali.
Architettura. Com'è costruito il sistema? Quali sono i suoi componenti principali? Dove si trovano i dati? Come comunicano tra loro i singoli elementi?
Codice e repository. L'azienda possiede il codice sorgente completo? Si sa quale branch e quale versione sono in produzione? Il processo di build e deployment è riproducibile?
Infrastruttura. Dove gira la produzione? Com'è l'ambiente di test? Chi ha accesso? Com'è il monitoraggio e il backup?
Integrazioni. Con cosa comunica il sistema? Quali API utilizza? Chi è il proprietario dei singoli account e delle chiavi?
Dipendenze. Quali librerie, framework e componenti esterni vengono utilizzati? Sono aggiornati? Presentano problemi di sicurezza noti? Com'è il loro ciclo di vita?
Processo di deployment. Una nuova persona è in grado di preparare, testare e rilasciare una modifica senza chiamare il vecchio sviluppatore?
Conoscenza. Cosa si trova nella documentazione e cosa esiste ancora solo nelle teste delle persone?
Rischio di business. Cosa succede se un determinato componente smette di funzionare per un'ora, un giorno o una settimana?
L'approccio contemporaneo alla sicurezza della supply chain del software sottolinea sempre più proprio la necessità di conoscere componenti, fornitori, dipendenze, la loro provenienza e il loro ciclo di vita. NIST indica inoltre l'importanza della due diligence verso i fornitori tecnologici e della valutazione della resilienza e del rischio legato all'intera supply chain.
L'audit non significa "riscriviamo il sistema da zero"
Questo è importante, perché l'audit tecnico viene spesso erroneamente confuso con una ricostruzione.
Nel frattempo, l'audit può concludersi con una constatazione molto semplice: "Il sistema va bene. Bisogna solo mettere ordine nella conoscenza e rimuovere alcuni rischi."
Può anche risultare che il sistema richieda una modernizzazione solo in un'area.
Oppure che il problema più grande non sia il codice, ma la mancanza di accesso all'infrastruttura.
Oppure che l'applicazione sia scritta bene, ma nessuno abbia una conoscenza aggiornata del processo di deployment.
Oppure che tutto funzioni, ma l'azienda sia dipendente da un unico fornitore esterno.
Per questo una buona analisi di un progetto ereditato dovrebbe rispondere alla domanda: "Cosa va davvero cambiato e cosa non va toccato?"
Solo allora si possono prendere decisioni di investimento.
E se cambi software house?
È uno dei momenti in cui il problema del debito di conoscenza invisibile emerge chiaramente.
L'azienda termina la collaborazione con il fornitore.
Il nuovo partner riceve il repository.
E inizia a fare domande:
- "Dov'è la produzione?"
- "Come avviare il progetto in locale?"
- "Quale versione è attuale?"
- "A cosa serve questo servizio?"
- "Chi possiede l'account di questa API?"
- "Cosa fa questo cron?"
- "Perché questo processo si avvia a quest'ora?"
- "Da dove prendiamo questo parametro?"
- "Cosa succede se lo disattiviamo?"
Se la risposta alla maggior parte delle domande è "non lo sappiamo", il nuovo software house non prende in consegna il progetto. Prima deve scoprirlo.
E scoprire il sistema costa tempo. Tempo che poi paga il cliente.
Per questo il passaggio di progetto tra team dovrebbe essere un processo, non il caricamento di uno ZIP con il codice e la password di un unico account.
Il sistema deve sopravvivere alle persone
Questa è probabilmente la regola più importante.
Le persone cambiano. Gli sviluppatori cambiano lavoro. I freelancer terminano la collaborazione. Le software house cambiano clienti. Gli amministratori passano ad altre aziende. I consigli di amministrazione cambiano.
Il sistema resta.
Per questo il sistema dovrebbe essere progettato in modo tale che la conoscenza necessaria per la sua manutenzione possa essere recuperata.
Questo non significa che ogni dipendente debba sapere tutto.
Significa che l'organizzazione dovrebbe disporre di un meccanismo di conservazione della conoscenza:
- Repository.
- Documentazione.
- Registro delle integrazioni.
- Informazioni sull'infrastruttura.
- Accessi gestiti dall'azienda.
- Descrizione dei processi chiave.
- Storico delle decisioni importanti.
- Informazioni sulle dipendenze.
- Procedure di emergenza.
- E soprattutto - persone che sappiano utilizzare questa documentazione.
Le linee guida attuali del NIST sulla pianificazione della sicurezza dei sistemi sottolineano inoltre la definizione formale delle responsabilità, dello stato operativo del sistema e dei ruoli delle persone che lo gestiscono, lo supportano o vi hanno accesso.
Questo mostra un cambiamento più ampio nel modo di pensare alla tecnologia.
Un sistema non è solo codice. Un sistema è anche persone, processi, infrastruttura, dipendenze, dati, accesso e responsabilità.
In Web24 spesso iniziamo proprio dalla domanda: "Cosa abbiamo qui, esattamente?"
L'acquisizione di un progetto esistente non dovrebbe iniziare con la promessa che tutto sarà riscritto da zero.
Dovrebbe iniziare dalla comprensione della situazione:
- Cosa funziona?
- Cosa non funziona?
- Cosa è critico?
- Cosa è obsoleto?
- Dove sono i rischi maggiori?
- Cosa manca nella documentazione?
- Quali dipendenze sono invisibili?
- Si può sviluppare in sicurezza il sistema esistente?
- Serve una modernizzazione, oppure solo una riorganizzazione?
Solo dopo si può decidere se il progetto va sviluppato, ricostruito, riscritto in parte oppure semplicemente documentato bene.
Questo è particolarmente importante nei progetti che nel corso degli anni sono stati sviluppati da persone e aziende diverse.
Perché un buon partner tecnologico non dovrebbe essere necessario solo perché è l'unico a sapere come funziona il sistema.
Dovrebbe essere necessario perché sa sviluppare, mettere in sicurezza e trasmettere il sapere su questo sistema.
L'errore più pericoloso può essere una persona che se n'è già andata
Non sempre il problema è il codice vecchio.
Non sempre il problema è una tecnologia obsoleta.
Non sempre il problema è la mancanza del framework più recente.
A volte il rischio maggiore è un'informazione che nessuno ha scritto.
Una parola chiave.
Una decisione architetturale.
Una integrazione.
Un'eccezione nel processo.
Una persona che per anni sapeva come funzionava tutto.
E poi se n'è andata.
Per questo vale la pena porsi oggi una domanda molto semplice: Se domani dalla vostra azienda sparisse la persona che conosce meglio il vostro sistema, sareste ancora in grado di gestirlo?
Se la risposta è "sì" - fantastico.
Se è "non lo so" - vale la pena controllare.
E se è "decisamente no" - probabilmente avete appena individuato una delle aree di rischio tecnologico più importanti nella vostra azienda.
Il sistema dovrebbe essere più grande della memoria di una sola persona.
