Ho già parlato della trasformazione digitale qualche giorno fa. Questo post si può considerare una continuazione.

Oggi mi soffermo sulla tendenza a considerare le iniziative IT o di trasformazione digitale come binarie: si fa una cosa o si fa una cosa diversa. O è bianco oppure è nero.

Questo potrebbe non essere efficace per un paio di ragioni: in primo luogo, perché a volte si può scegliere di fare più di una cosa contemporaneamente.
In secondo luogo, perché non si tratta di cambiare un solo fattore - diversi tipi di cambiamento possono richiedere diversi cambiamenti fondamentali o possono dipendere da cambiamenti culturali e di processo.
Niente accade nel vuoto. Ci sono in ballo diverse realtà che si influenzano reciprocamente.

Può essere più costruttivo considerare la trasformazione digitale come un continuum, con fasi diverse lungo il percorso e che consentono il successivo stadio di evoluzione.

Di seguito uno schema con le fasi ideali attraverso le quali si snoda il percorso di Digital Trasformation.

  1. DevOps e i cambiamenti di processo. Riorganizzare i propri sistemi in una logica
  2. Infrastruttura self-service. Gestire le attività sistemistiche in funzione delle richieste del cliente ed in tempo reale.
  3. Costruire per l'automazione e l'orchestrazione. Automatizzare buona parte dei processi di gestione sistemistica tramite programmi open standard come Ansible+
  4. Continuous Integration / Continuous Delivery (CI/CD). Gestire in continuum le attività di CI (Continuous Integrations) e CD (continuous delivery)
  5. Implementare avanzate tecniche di deployment applicativo
  6. Microservizi (“per far volare l’elefante”)

DevOps e i cambiamenti di processo

Il fondamento dell'evoluzione digitale è DevOps. Le applicazioni, così come la strategia di business, sono una sintesi del lavoro di team e della comunicazione tra i team che hanno portato alla loro creazione. DevOps, o cambiamenti di processo simili, coinvolge più stakeholder nelle discussioni sullo sviluppo del software e consente di avere una visione più ampia su come le operations mantengono il software e l'infrastruttura. Crea un ciclo di feedback più stretto tra i team e richiede linee di comunicazione aperte. Questa comunicazione aperta è la base per qualsiasi altro stadio di evoluzione lungo il percorso della digital trasformation nella tua azienda.

Infrastruttura self-service

Questa fase è un cambiamento incentrato sulla tecnologia, che introduce efficienze tipicamente associate alle moderne piattaforme tecnologiche. I contenitori e i cataloghi self-service consentono agli sviluppatori, ai tester e ai gruppi operativi di creare ambienti coerenti molto rapidamente, in alcune organizzazioni, riducendo il lead time per le nuove istanze da giorni a minuti. Perché un tecnologo dovrebbe aspettare giorni per una risorsa informatica?

Costruire per l'automazione e l'orchestrazione

Costruire l'automazione è un cambiamento in due parti. C'è un angolo di tecnologia, con motori di distribuzione avanzati come Red Hat® Ansible o Puppet, ma richiede anche un cambiamento di processo. Molte organizzazioni hanno in atto processi rigorosi per quanto riguarda il cambiamento e la gestione del rischio; senza adattare questi processi in metodologie più agili, non sarebbe possibile sfruttare i vantaggi della nuova tecnologia.

Continuous Integration / Continuous Delivery (CI/CD)

La delivery continua è un impegno ad apportare sostanziali modifiche alle metodologie di delivery del software in modo rapido ed iterativo. L'idea di una pipeline è che ci sono processi e tecnologie in atto che riducono il rischio che il codice di scarsa qualità (o rotto) passi dalla produzione alla distribuzione. Questo livello mostra la maturità delle fasi precedenti: comunicazione aperta tra i team, processi in atto intorno alle fasi di test e di build, e test e deployment automatizzati. Quando tutte queste fasi sono consolidate, allora è possibile far passare rapidamente il codice attraverso tutte le fasi della pipeline.

Percorsi di distribuzione avanzata del software

Una volta che i processi e l'infrastruttura sono pronti per una rapida implementazione, è possibile iniziare a utilizzare i sistemi di implementazione come un modo per mitigare i rischi derivanti dagli aggiornamenti, valutare l'efficacia delle funzionalità e fornire un terreno di prova reale per nuove idee. Questo può includere la separazione degli ambienti e il bilanciamento del carico tra di essi durante le implementazioni, l'utilizzo di due ambienti diversi per testare l'interazione dell'utente, o l'introduzione di aggiornamenti per piccole percentuali di utenti.

Microservizi (o sistemi distribuiti)

Un microservizio è una piccola applicazione che svolge una funzione discreta e singolare. L'architettura complessiva dell'applicazione può aver bisogno di eseguire decine o centinaia di funzioni diverse, e ognuna di queste funzioni verrebbe definita e orchestrata in un microservizio. Un'architettura di microservizi (o qualsiasi architettura di calcolo distribuito) è allo stesso tempo complessa e semplice. I singoli servizi sono molto più semplici e più facili da mantenere, aggiungere e dismettere, eppure l'architettura complessiva è più complessa. Se fatto bene, un "microservice-based design è la manifestazione finale di tutto ciò che si è appreso su una buona progettazione applicativa ". Questa architettura altamente distribuita consente percorsi più facili da scalare, rende più facile introdurre nuovi servizi o aggiornamenti e riduce il rischio di un guasto a livello di sistema. Questa elasticità all'interno dell'architettura è il motivo per cui i microservizi sono ampiamente associati a società innovative come Netflix e Google.

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.

Potrebbe interessarti anche: