Skip to main content

La trasformazione digitale cui stiamo assistendo ha provocato una forte accelerazione di tutti i processi di mercato. Per stare al passo le aziende devono essere in grado di evolvere le proprie proposizioni di business in modo rapido e quasi continuo. Questo impone anche all’IT un’evoluzione costante dei propri applicativi per rispondere alle nuove esigenze del business. Ma qual è l’architettura IT perfetta per il mercato di oggi e, possibilmente, di domani?

L’Architettura IT definitiva non esiste

Le aziende oggi sono alla costante ricerca della struttura IT perfetta per sostenere il cambiamento e facilitare lo sviluppo di applicativi moderni, nel tentativo di disegnare una soluzione capace di conciliare i sistemi esistenti con le necessità del mercato.

Tuttavia, questa ricerca non è così semplice e in più parte da un presupposto errato: l’idea che esista una “ultimate architecture” da trovare, che rappresenterà il punto di arrivo di tutti i nostri sforzi. Proprio qui sta l’errore: in un mercato rapido e in continua evoluzione come quello di oggi, l’architettura IT definitiva non esiste.

Se l’obiettivo dunque è senz’altro condivisibile – rispondere alle esigenze del mercato, senza però mettere a repentaglio la continuità di business e gli asset esistenti – la strada da perseguire dev’essere un’altra: non si tratta di disegnare un’architettura perfetta, ma di disegnare un’architettura capace per design di rispondere in modo rapido e incrementale all’esigenza di continua evoluzione che il mercato richiede.

In questo articolo vedremo quali sono le difficoltà che stanno riscontrando oggi le aziende che cercano di affrontare la trasformazione digitale con architetture legacy e qual è la soluzione per abbracciare il cambiamento ed evolvere con esso.

Sopravvivere in un mare di legacy

Anche se oggi siamo nel pieno di questa trasformazione, c’è già abbastanza esperienza per trarre alcune conclusioni su quanto visto fino ad ora e su come si sono mosse, e si stanno muovendo, le aziende.

Le aziende che hanno applicazioni monolitiche – spesso rispecchiate da un’organizzazione aziendale a silos – sono quelle che stanno facendo più fatica ad adattarsi al cambiamento. Questo perché:

  1. Le applicazioni monolitiche sono difficili da far evolvere. Un monolite contiene in sé tutta la base di codice che riguarda sia le logiche sottostanti, sia i dati, sia il frontend. Questo le rende: poco manutenibili, perché ogni aggiornamento va ad appesantire la base di codice; lente ad evolvere, perché una singola modifica impatta tutto il sistema; poco scalabili, perché ogni nuovo rilascio impone il deploy dell’intera applicazione; poco affidabili, perché un’implementazione potrebbe compromettere tutto il funzionamento dell’applicazione.
  2. L’architettura definitiva non esiste. Le aziende sono alla ricerca della soluzione definitiva per risolvere tutti i problemi e cavalcare l’onda della trasformazione digitale. Non si rendono conto però, che nel costruire il sistema definitivo rallentano i loro processi di digitalizzazione e il time-to-market. L’architettura che oggi ci sembra perfetta, domani potrebbe non esserlo più.
  3. I vecchi approcci metodologici non riescono a stare al passo col cambiamento. È necessario adottare metodologie che supportino le aziende ad adattarsi al cambiamento costante, a rilasciare velocemente e a ridurre il più possibile il margine di errore. Nuovi approcci allo sviluppo richiedono dunque anche un cambio di paradigma organizzativo, e impattano non solo sulle tecnologie ma anche sui processi e sulla comunicazione fra le persone e le diverse aree aziendali.

La soluzione: le Architetture Evolutive

Abbiamo parlato di architetture perfette che non esistono e della ricerca di soluzioni che permettano alle aziende di stare al passo con i cambiamenti imposti dal mercato. Soluzioni, quindi, a prova di futuro.

Ma quali sono queste soluzioni? Oggi possiamo affermare che sono a prova di futuro le cosiddette Architetture Evolutive: Architetture IT in grado di evolvere nel tempo by design, che possano operare su qualsiasi infrastruttura, che possano essere scritte con tecnologie e linguaggi differenti a seconda dei contesti d’uso, e che possano scalare in ragione del business. Architetture che possano, in generale, essere già pronte per modificarsi in poco tempo, senza un aumento spropositato di costi e in modo sicuro.

Che caratteristiche hanno le Architetture Evolutive?

  1. Sono basate sullo stile architetturale a microservizi: oggi questo è lo stile di sviluppo che meglio si adatta alla costruzione di architetture che possano evolvere facilmente. Lo sviluppo a microservizi permette di separare le logiche di business secondo bounded context ben definiti, responsabilità chiare e processi indipendenti. In questo modo, se abbiamo necessità di apportare un cambiamento a una logica, possiamo lavorare solo su quella, senza andare a toccare l’intera architettura o altre logiche, che rischierebbero così di venire compromesse.
  2. Sono basate su tecnologie cloud-native e containerizzazione: un’applicazione pensata in maniera “futuribile” è in grado di operare su cloud differenti, pubblici o privati, disaccoppiando così il software dall’hardware e sfruttando la massima flessibilità in termini di gestione delle risorse. Grazie a sistemi di orchestrazione come Kubernetes, le architetture cloud-native sono in grado di automatizzare compiti come la distribuzione e la gestione dei container che contengono le applicazioni.
  3. Lasciano libertà di scelta sui linguaggi di sviluppo: costruire un’architettura basata sullo stile architetturale a microservizi permette di utilizzare il linguaggio più adatto per lo sviluppo della singola logica di business e del singolo microservizio. Questo ci permette di non avere vincoli tecnologici in futuro: se un nuovo linguaggio sarà più adatto alla nuova logica di business che vogliamo implementare, non dovremo preoccuparci di come abbiamo sviluppato le logiche in precedenza. Allo stesso tempo, questa libertà consente di valorizzare al meglio le competenze presenti all’interno del team di sviluppo.
  4. Comunicano in modo “standard”: API – in particolar modo, REST e GraphQL – ed eventi rappresentano due tasselli fondamentali per costruire architetture IT in grado di evolvere nel tempo, garantendo sempre una comunicazione efficace e controllata tra servizi all’interno di sistemi distribuiti e complessi.

L’impatto sul business, un esempio concreto

Per capire quando un’Architettura Evolutiva possa rispondere al meglio alle esigenze di oggi, immaginiamo una società di trasporti che raccoglie i dati di affluenza dei passeggeri sui propri mezzi e li mostra in un’app dedicata al personale. Questo dato serve alla società per organizzare meglio i trasporti, le corse, ecc.

Con il cambiare delle esigenze degli utenti, e l’ampliarsi dell’offerta digitale della società, questo dato diventa un’informazione importante anche per i passeggeri stessi, che se potessero consultarlo potrebbero pianificare ancora meglio il proprio viaggio.

Improvvisamente quindi, un dato che veniva consultato da poche persone deve diventare fruibile da una nuova app che potrebbe avere picchi di utenza molto diversi con milioni di utilizzatori.

Se questa logica e questo dato sono depositati in un monolite, questo significa che dovremo far scalare l’intero monolite, andando a toccare molte altre logiche sottostanti, mettendo a rischio l’intera infrastruttura, con rischi e costi spropositati.

Grazie allo stile architetturale a microservizi avremmo invece tutte le logiche ben isolate tra di loro e tutti i canali disaccoppiati dai gestionali e dai sistemi sottostanti. In questo contesto, agganciare i dati a un nuovo canale risulta veloce e con un basso impiego di tempo e risorse economiche.

Digital Integration Hub, il miglior esempio di Architettura Evolutiva

Uno dei migliori esempi concreti di Architettura Evolutiva lo ha probabilmente razionalizzato Gartner nel suo paper “Turbocharge Your API Platform With a Digital Integration Hub”.

Il Digital Integration Hub è una API Platform sviluppata a microservizi e alimentata da un layer di Fast Data, in grado di aggregare in tempo reale i dati dai sistemi gestionali, aggregarli in Single View di business e servirli ai canali in tempo reale 24/7.

L’adozione di un Digital Integration Hub porta con sé numerosi benefici:

  • Riduzione dei costi: vengono ridotti i costi di mantenimento della piattaforma, del time-to-market dei nuovi rilasci e di accesso alle API;
  • Migliore Customer Experience: le esperienze utente sono responsive e real time su tutti i dispositivi dell’utente;
  • Modernizzazione delle applicazioni: il disaccoppiamento dei sistemi permette di avviare una trasformazione che va a sostituire i sistemi legacy in modo graduale;
  • Insight in tempo reale: grazie a un approccio data driven e basato sugli eventi è possibile ottenere dati analitici avanzati;
  • Nuove opportunità di business: senza dover più pensare ai sistemi IT sottostanti, le aziende possono concentrarsi sullo sviluppo di nuove partnership, agevolate da una API Platform orientata al business.

Le potenzialità insite nelle Architetture Evolutive hanno portato alla formazione della partnership tra Intesys e Mia-Platform, per portare sul mercato una soluzione end-to-end di tipo Digital Integration Hub e offrire un modello architetturale scalabile, flessibile e performante in grado di attuare e governare la trasformazione digitale delle aziende.

Vuoi sapere di più su questo tema? Lo abbiamo approfondito nell’evento: “Headless & API date 2020: attuare e governare la trasformazione digitale con le architetture IT”

Guarda la registrazione dell'evento

No Article rating
0 Reviews
Cosa ne pensi dell'articolo?
  1. Amazing
  2. Good
  3. Bad
  4. Meh
  5. Pff
NEWSLETTER