Mark Schwartz, Enterprise Strategist di AWS, pone l’attenzione sulla scelta delle grandi organizzazioni di centralizzare attività, servizi, governance & finance.
Se eseguite male, le funzioni centralizzate possono diventare ostacoli e le interazioni tra servizi condivisi e team decentralizzati possono portare a sprechi di tipo amministrativo. In che modo le imprese dovrebbero decidere cosa centralizzare e come possono organizzare al meglio i servizi centralizzati e le loro interazioni con le unità decentralizzate al fine di ridurre gli sprechi?
In qualità di CIO di una delle agenzie componenti, il Department of Homeland Security (DHS), Mark Schwartz si è sempre considerato vittima di un gravoso accentramento. Ogni volta che necessitavano di nuovi server o modifiche al datacenter, dovevano rivolgersi all’organizzazione appaltatrice del DHS, che supervisionava l’appaltatore e che gestiva il datacenter.
L’infrastruttura di rete è stata perciò condivisa con altri componenti del DHS e gestita centralmente, quindi apportare anche piccole modifiche alla rete richiedeva revisioni e tempi molto lunghi. Per quanto riguarda i progetti IT, è stato necessario seguire i requisiti del quadro di supervisione del DHS MD-102, che è stato progettato per supervisionare la costruzione di motovedette della Guardia Costiera (la Anche Guard fa parte del DHS). Ha anche governato la fornitura di sistemi software ed è stato di conseguenza orientato su enormi investimenti di capitale e oggetti fisici. La centralizzazione sembrava ostacolare tutto ciò che Mark e il suo team volevano realizzare.
Centralizzare o decentralizzare?
Gli odierni metodi di lavoro digitali richiedono team decentralizzati, responsabilizzati e autonomi. Tuttavia, questo è difficile da conciliare con funzioni e governance centralizzate. D’altra parte, ci sono alcune funzioni che semplicemente non possono essere decentralizzate o che comportano inefficienze quando lo sono. Nel caso di AWS, la sede del DHS era responsabile della sicurezza dell’intera azienda e la negoziazione centralizzata dei contratti con i fornitori ha consentito di sfruttare il grande volume di acquisti per ottenere sconti migliori.
Secondo Mark Schwartz, la tensione tra centralizzazione e decentralizzazione è al centro dell’ambiente IT digitale di oggi. Per capire come gestire il compromesso, è necessario per le imprese partire dal principio che velocità e innovazione sono due elementi fondamentali nell’ambiente odierno. Essi sono facilitati al meglio dal decentramento dell’autorità, dal lavoro in quei team autonomi, autorizzati e interfunzionali.
I team possono rimanere vicini al cliente, percepire facilmente i cambiamenti nel mercato, incubare idee con la partecipazione interfunzionale ed eseguire il lavoro evitando inutili passaggi, ciò si traduce in una maggiore rapidità. Infatti, quando un team autonomo dipende da una funzione centralizzata, questa tende a rallentarlo, aggiungendo un notevole sovraccarico amministrativo e burocratico che tende a limitare l’innovazione.
In quali casi è necessario centralizzare le funzioni?
Questo è il punto di partenza secondo Mark Schwartz, ma la domanda richiede un ragionamento più complesso. In quali casi è necessario centralizzare le funzioni? La prima risposta è: solamente nel caso in cui la centralizzazione acceleri effettivamente quei team decentralizzati e ne supporti l’innovazione. Se l’organizzazione centralizzata è in grado di fornire servizi che altrimenti richiederebbero tempo ai team per fornirli in autonomia, e lo fa senza aggiungere un ulteriore sovraccarico amministrativo che rallenterebbe i team, allora è una scelta giusta.
Ad esempio, se si prende in considerazione la supervisione del DHS sul contratto per la gestione del data center, si può notare come al momento dell’impostazione, abbia causato un rallentamento dei team di AWS proprio nel momento in cui necessitavano di infrastrutture.
Tuttavia, se il team centralizzato avesse stipulato il contratto, rinegoziandolo, con processi rapidi per consentire ai team di ottenere la propria infrastruttura quando più ne avevano bisogno, AWS avrebbe risparmiato tempo prezioso per i propri team e sarebbe stato quindi più vantaggioso.
Centralizzare o decentralizzare, il cloud
Ovviamente questo non è più stato un problema dal momento in cui è stato introdotto il cloud. Basti pensare al team di una piattaforma cloud centralizzata che fornisce ai team di distribuzione del software un’infrastruttura preparata su cui poter lavorare. I team sarebbero in grado di fornire autonomamente qualsiasi infrastruttura di cui hanno bisogno, senza aspettare che lo faccia il team della piattaforma.
Invece, il team della piattaforma imposterebbe la piattaforma in modo tale che quando i team effettuano il provisioning automatico della propria infrastruttura, siano in grado di utilizzare automaticamente le risorse cloud che il team di sicurezza ha già verificato e configurato e che il team finanziario ha approvato per la loro efficienza in termini di costi.
A questo punto l’organizzazione della piattaforma centrale sta effettivamente rendendo le cose più veloci per i team di consegna, poiché non devono valutare la sicurezza di tali risorse, né devono effettuare alcun tipo di controllo di sicurezza supplementare e non devono giustificare l’efficacia in termini di costi delle risorse che stanno utilizzando. Tutto ciò non comporta costi amministrativi aggiuntivi, in quanto è possibile fornire autonomamente la propria infrastruttura.
Cosa centralizzare?
In questo caso, la funzione centralizzata ha effettivamente accelerato i team decentralizzati: un grande successo. È evidente il contrasto con i precedenti esempi di Mark Schwartz relativamente a DHS in cui le funzioni centralizzate causavano ritardi e frustrazione perché implicavano il gate keeping e un effettivo passaggio ad un altro team.
Quindi, è consigliabile centralizzare le funzioni nel momento in cui questo aggiunge velocità. Ma non solo. Un altro motivo per cui le organizzazioni si centralizzano è fornire governance e supervisione all’intera azienda. In DHS, il quartier generale aveva il compito di supervisionare la sicurezza e le spese, e quindi aveva organizzazioni centralizzate che si occupavano di questo tipo di attività.
In che modo possono essere soddisfatte queste esigenze senza che vi siano rallentamenti?
E’ necessario domandarsi se tale governo centrale sia davvero necessario. Nei suoi libri, Mark Schwartz consiglia cautela sull’impulso istintivo di standardizzazione nell’IT: spesso si presume che gli standard siano necessari, mentre un’attenta analisi mostrerebbe che il valore aziendale di tale standardizzazione potrebbe non giustificare il costo aggiuntivo o la lentezza dei meccanismi di governance che garantiscono il rispetto degli standard.
Mark Schwartz sottolinea l’importanza del compromesso tra supervisione attraverso la governance e supervisione attraverso la gestione. La governance fa regole e introduce meccanismi di attuazione, con conseguenti costi. Ma spesso è possibile ottenere risultati uguali o migliori semplicemente attraverso una buona gestione. La governance, ad esempio, potrebbe costringere i team ad utilizzare la piattaforma di distribuzione del software standardizzata. La direzione, d’altra parte, potrebbe richiedere ad un team che non utilizza una piattaforma standard il motivo per il quale lo fa. Non è necessario l’adozione di regole e l’applicazione di esse per ottenere un buon comportamento; spesso, una gestione competente è sufficiente a risolvere il problema.
Nel caso in cui ci fosse bisogno di una governance centralizzata?
La buona notizia è che oggi è possibile ottenerla attraverso l’automazione, in particolare, attraverso guardrail che non rallentino i team decentralizzati o aggiungano ulteriore sovraccarico ai team. Schwartz ha parlato di ’“automatizzare la propria burocrazia”. Oggi è possibile fare “compliance as code”, “policy as code” o “auditing as code”. La burocrazia non interferisce con la velocità e la creatività, contribuisce semplicemente ad allineare tutto.
Ecco un esempio di burocrazia automatizzata già fornito da Schwartz: il team della piattaforma che fornisce ai team soltanto risorse controllate da utilizzare nel loro self-provisioning. La governance del team di sicurezza è già incorporata nella selezione dei componenti disponibili. Non hanno bisogno di interferire ulteriormente. Un altro esempio: al team di sicurezza è stato chiesto di creare test automatizzati che verificassero la conformità con le proprie policy affinché tutti gli altri team IT potessero utilizzarli.
Assicurandosi che il loro codice superasse i test di sicurezza, i team di consegna potevano muoversi alla massima velocità in modo indipendente. Nel frattempo, attraverso i test, il team di sicurezza forniva la governance. Allo stesso modo, è possibile automatizzare i controlli finanziari, magari chiudendo le risorse che non vengono utilizzate, ed impedendo ai team di utilizzare risorse che non sono convenienti, o avvisare la finanza se un team ha intenzione di fare qualcosa di potenzialmente costoso. Tutti questi meccanismi automatizzati impongono controlli di governance determinati a livello centrale, ma non rallentano i team, non interferiscono con la loro creatività né aggiungono sovraccarico di tipo amministrativo.
Ecco i punti principali che, secondo Mark Schwartz, tutte le imprese dovrebbero seguire per migliorare il rapporto tra centralizzazione e decentralizzazione:
Decentralizzare per impostazione predefinita.
Centralizzare per velocizzare le unità decentralizzate.
Centralizzare quando è necessaria la governance, ma farlo in modo automatizzato in maniera tale da non creare dipendenze.
