Siamo giunti all'ultimo capitolo di questa lunga analisi fatta sul processo di digital trasformation: nelle scorse settimane ho già pubblicato due articoli:
Trasformazione digitale: cosa sta succedendo nel mondo IT? e Una visione darwiniana della digital trasformation.

L'ultimo articolo l'avevo concluso con questa frase, che voglio riprendere, come punto di partenza per questo terzo post:

Una cosa critica da notare quando si affronta un percorso di digital trasformation è che non si tratta solo di un cambiamento di tecnologia.Si alternano cambiamenti di processo, di persone e cambiamenti infrastrutturali e cambiamenti culturali che risultano essere infinitamente più importanti.

È possibile creare il diagramma architetturale più bello che si desidera ma non basta. Una volta che si coinvolgono persone e processi si deve creare l'ambiente culturale che supporta l'erogazione continua e la disciplina architettonica, perché un cambiamento di processo o di struttura non basta e non rappresenta un cambiamento duraturo. Le persone non seguono le regole. Quindi il vero elefante nella stanza è la legge di Conway. Che cosa significa? Semplice, significa che le strutture organizzative legacy esistenti e consolidate in anni di attività e di gestione del potere decisionale distruggeranno la vostra bella architettura sempre e inesorabilmente.

La chiave per considerare il software o la tecnologia come un cambiamento evolutivo duraturo e permanente è che l'evoluzione diventi una funzione naturale del suo ambiente. In un'azienda, questa viene definita la cultura aziendale. I cambiamenti necessari per supportare il cambiamento evolutivo possono essere supportati dal management, ma non possono essere dettati dal management. Le persone devono voler cambiare. È una questione di libero arbitrio, non di forza.

Gartner ha dei numeri per questo: "Il 90% delle organizzazioni che tentano di usare i DevOps senza rivolgersi specificamente alle loro matrici culturali aziendali fallirà".

Cambiare l'infrastruttura o l'architettura dell'applicazione è facile. Per cambiare efficacemente ciò che si produce, è necessario cambiare prima di tutto la propria cultura.
La legge di Conway afferma che "qualsiasi organizzazione che progetta un sistema produrrà inevitabilmente un sistema la cui struttura è una copia della struttura di comunicazione dell'organizzazione".
Questa ha due interpretazioni correlate:

  • Cambiando la vostra architettura o infrastruttura non cambierà nulla a meno che non cambiate anche la vostra struttura di comunicazione, la cultura aziendale.
  • Modificare la struttura di comunicazione si tradurrà in processi e infrastrutture migliori, quasi indipendentemente dall'infrastruttura.

DevOps come primo passo

La metodologia Agile è un approccio alla progettazione del software che cerca di riunire tutte le parti coinvolte -gestione del prodotto, sviluppatori, manutentori... - in un gruppo più coeso.
L'idea si basa sul chiarire gli obiettivi tramite brevi iterazioni incentrate su compiti specifici che vengono espressi come obiettivi dell'utente (chiamate storie).
Questo ha rotto con il metodo tradizionale a cascata (waterfall) di sviluppo del software, che si basa su un principio dove una squadra svolgeva un compito e poi passava il tutto ad un'altra squadra.

Tuttavia, ciò riguardava ancora solo la metà del ciclo di vita effettivo di un'applicazione. Una volta che qualcosa è stato sviluppato, viene consegnato alle operations per il deploy e la manutenzione (di solito in una finestra di manutenzione nel fine settimana).
Il problema è che le operations non sempre sanno che cosa dovrebbe fare l'applicazione, il che significa che possono eseguire un deploy in modo inefficiente. Gli sviluppatori, dal loro punto di vista, possono non avere alcuna idea dell'ambiente operativo reale e possono creare/sviluppare un'applicazione che non funziona nell'ambiente di produzione.

DevOps è un cambiamento culturale che cerca di abbattere la separazione tra sviluppatori, operations e stakeholder aziendali. Le divisioni tra questi gruppi sono reali, ma, al tempo stesso, artificiali. Un team può includere più persone che condividono una funzione di lavoro; DevOps cerca di ridefinire il team per includere tutti coloro che condividono il ciclo di vita di un'applicazione e aprire la comunicazione tra le persone.
Il cambiamento culturale va anche più in profondità di DevOps o agile o altre metodologie. È un impegno a mettere effettivamente tutti nella stessa squadra. Se cambiate i vostri modelli di comunicazione, potete cambiare i vostri risultati.

In una recente analisi di IDC, Stephen Elliot ha scritto che prima di definire un'architettura, è necessario identificare chi è il cliente o l'utente finale, quali sono i valori di quel cliente, quali sono i risultati desiderati e come si misurerà il successo.
In altre parole, non si parte da come si vuole realizzare qualcosa o da quale architettura si vuole utilizzare. Si parte da quale sia il proprio obiettivo strategico e poi si progetta l'architettura che la supporta. Questo mette l'applicazione e la soluzione applicativa al primo posto.

Potrebbe interessarti anche: