I SILO: MALE NECESSARIO O LEVA STRATEGICA?

Ogni volta che si menziona la parola “silo” nel contesto dello sviluppo del software, i manager e dirigenti più accorti rizzano le orecchie.

L’argomento è importante perché i silo sono omnipresenti in organizzazioni e aziende con un numero di addetti che supera la decina. 

Sono omnipresenti perché, per propria natura, un silo vincola il tipo e numero di scambi di informazioni volti a coordinare l’attività delle varie persone. Infatti i silo vengono creati proprio per evitare che chiunque in azienda debba parlare con chiunque altro: se si dovesse fare così, il costo della comunicazione sarebbe dell’ordine di N^2 (su un insieme di N persone). Ovviamente non gestibile.

Un silo è una struttura all’interno di un’azienda che raggruppa una parte degli addetti a seconda di vari criteri: esigenze organizzative (es. il reparto “sicurezza IT”), economiche-finanziarie (es. “marketing”), funzionali (es. Quality Assurance - testing), logistiche (l’ufficio di Udine piuttosto che quello di Pune), e possono essere anche politiche.

Caratteristica importante del silo è la sua modalità di interazione con altri silo. Chi parla con chi? per scambiarsi cosa? chi dipende da chi? quanto granulare è lo scambio? con che frequenza? come vengono gestite eccezioni? che protocollo viene seguito? Si tratta di un protocollo rigido? Evolve nel tempo? Sono questi gli aspetti che caratterizzano la relazione di interazione tra coppie di silo. E quindi, a livello strategico, la definizione di certi silo può essere proficua oppure estremamente dannosa, con benefici e danni che solitamente si notano solo sul lungo periodo.

In un recente articolo sul New York Times ("As Ukrainian Attack Looms, Putin Faces Setbacks and Disunity in Russian Forces", https://www.nytimes.com/2023/05/16/world/europe/putin-russia-military-prigozhin.html?smid=url-share) il giornalista descrive una ragione a favore e una contraria alla creazione di silo. Per il presidente russo, a livello politico, è importante creare dei silo tra i suoi sottoposti in modo che ciascun silo bilanci gli altri e nessuno sia in grado di minacciare il capo. E questo vale anche per i militari, esercito regolare da una parte e milizie Wagner dall’altra. D’altro canto, sul fronte questa separazione porta a mancanza di coordinazione e supporto reciproco, che può condurre solo a disastri. Ecco che gli stessi silo, da una rospettiva consentono di ottenere un risultato desiderato, ma da un’altra invece no.

Tornando al software, si vedono spesso silo tra gli analisti di business e gli sviluppatori, tra gli sviluppatori e i tester, tra gli sviluppatori e Operations (quelli incaricati di installare e mantenere in funzione il sistema), tra il reparto sicurezza e Operations. 

In quest’ultimo caso, ad esempio, succede che Operations metta in piedi delle procedure più o meno automatizzate per gestire il funzionamento del sistema, per monitorarne i log, per aggiornarne i pacchetti, per ripulire o riorganizzare il file system o le basi di dati. E Operations farà questo secondo le proprie politiche, per perseguire i propri obiettivi di affidabilità, di efficenza, di risposta al cliente. Diverse sono invece le politiche e gli obiettivi di Security, che invece attua procedure più o meno automatizzate per monitorare e controllare gli accessi, quali configurazioni vengono cambiate e da chi, controllare il traffico dati in ingresso e uscita tra il sistema e il mondo esterno, chi può accedere al sistema attraverso quale protocollo e che porte di accesso, etc. 

Sebbene sia facile capire che alla fine entrambe queste politiche hanno senso e servono, è altrettanto facile capire che se attuate male portano a disfunzioni notevoli.

La procedura automatizzata che Operations aveva attuato e che viene eseguita ogni giorno, alla fine di ogni settimana viene regolarmente vanificata perché in maniera automatica Security ripristina una configurazione di default su quando e come certi file possono essere scritti. L’effetto è un malfunzionamento critico del sistema che richiede interventi manuali. Operations dedicherà tempo e persone a capire la natura del problema, lo segnalerà a qualche persona di livello intermedio, la quale lo segnalerà ai pari di Security, i quali lo trasmetteranno a chi effettivamente poi farà le cose, che alla fine realizzeranno una soluzione, che verrà notificata a Operations. Il successo viene alla fine conseguito sempreché tutti questi passaggi non degradino l’informazione e sempreché queste persone siano disponibili ad agire quanto prima.

In generale l’impatto negativo dei silo lo si vede in:

• tempo perso da parte delle persone, e quindi allungamento del time-to-market e aumento dei costi.
• Lavoro inutile, nel caso in cui le persone non si capiscano, intraprendano delle iniziative solo per capire alla fine che la cosa non andava fatta in quel modo; di nuovo maggiori time-to-market e costo.
• Errori, di nuovo nel caso in cui le persone non si capiscano e non realizzino in tempo che la soluzione attuata non è quella giusta. Questo porta a delle soluzioni informatiche che non risolvono il problema per cui sono state concepite (cioè non si costruisce il sistema giusto).
• Demotivazione delle persone, che si accorgono della futilità ed eccessiva burocratizzazione del meccanismo, smettono di combatterlo e cessano di essere creativi e proattivi. 

Tutti questi aspetti sono ostacoli enormi all’agilità di business, che consente all’azienda di pilotare lo sviluppo del software in modo da cogliere al meglio e prima possibile ogni variazione interessante del mercato. Uno degli obiettivi stategici aziendali più importanti al momento attuale per chi vive del software che produce. 

È per questo che il capire quali silo sono presenti di fatto, e che impatto essi abbiano rispetto a obiettivi di business è il primo passo da svolgere a livello strategico. Quello successivo è di individuare una diversa strutturazione dei silo, o perlomeno nuovi schemi di interazione tra i silo esistenti, che consentano di conseguire meglio quegli obiettivi.

Ne parleremo più avanti.

Pubblicato originariamente come Articolo LinkedIn.