{"id":8179,"date":"2020-10-21T15:53:36","date_gmt":"2020-10-21T13:53:36","guid":{"rendered":"https:\/\/www.intesys.it\/journal\/?p=8179"},"modified":"2022-06-01T12:37:46","modified_gmt":"2022-06-01T10:37:46","slug":"architetture-evolutive-la-soluzione-it-prova-futuro","status":"publish","type":"post","link":"https:\/\/www.intesys.it\/journal\/information-technology\/architetture-evolutive-la-soluzione-it-prova-futuro\/","title":{"rendered":"Architetture Evolutive, la soluzione IT a prova di futuro"},"content":{"rendered":"

Indice dei contenuti<\/span>
  1. L’Architettura IT definitiva non esiste<\/a><\/li>
  2. Sopravvivere in un mare di legacy<\/a><\/li>
  3. La soluzione: le Architetture Evolutive<\/a><\/li>
  4. L’impatto sul business, un esempio concreto<\/a><\/li>
  5. Digital Integration Hub, il miglior esempio di Architettura Evolutiva<\/a><\/li><\/ol><\/div><\/div><\/p>[vc_row type=”in_container” full_screen_row_position=”middle” column_margin=”default” column_direction=”default” column_direction_tablet=”default” column_direction_phone=”default” scene_position=”center” text_color=”dark” text_align=”left” row_border_radius=”none” row_border_radius_applies=”bg” overflow=”visible” overlay_strength=”0.3″ gradient_direction=”left_to_right” shape_divider_position=”bottom” bg_image_animation=”none”][vc_column column_padding=”no-extra-padding” column_padding_tablet=”inherit” column_padding_phone=”inherit” column_padding_position=”all” column_element_spacing=”default” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” column_border_radius=”none” column_link_target=”_self” column_position=”default” gradient_direction=”left_to_right” overlay_strength=”0.3″ width=”1\/1″ tablet_width_inherit=”default” tablet_text_alignment=”default” phone_text_alignment=”default” animation_type=”default” bg_image_animation=”none” border_type=”simple” column_border_width=”none” column_border_style=”solid”][vc_column_text]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<\/strong>. Questo impone anche all\u2019IT un\u2019evoluzione costante dei propri applicativi per rispondere alle nuove esigenze del business. Ma qual \u00e8 l\u2019architettura IT perfetta per il mercato<\/strong> di oggi e, possibilmente, di domani?<\/p>\n

    L’Architettura IT definitiva non esiste<\/h2>\n

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

    Tuttavia, questa ricerca non \u00e8 cos\u00ec semplice e in pi\u00f9 parte da un presupposto errato: l\u2019idea che esista una \u201cultimate architecture<\/strong>\u201d da trovare, che rappresenter\u00e0 il punto di arrivo di tutti i nostri sforzi. Proprio qui sta l\u2019errore: in un mercato rapido e in continua evoluzione come quello di oggi, l\u2019architettura IT definitiva non esiste<\/strong>.<\/p>\n

    Se l\u2019obiettivo dunque \u00e8 senz\u2019altro condivisibile – rispondere alle esigenze del mercato, senza per\u00f2 mettere a repentaglio la continuit\u00e0 di business e gli asset esistenti – la strada da perseguire dev\u2019essere un\u2019altra: non si tratta di disegnare un\u2019architettura perfetta, ma di disegnare un\u2019architettura capace per design di rispondere in modo rapido<\/a> e incrementale all\u2019esigenza di continua evoluzione che il mercato richiede.<\/p>\n

    In questo articolo vedremo quali sono le difficolt\u00e0 che stanno riscontrando oggi le aziende<\/strong> che cercano di affrontare la trasformazione digitale con architetture legacy e qual \u00e8 la soluzione per abbracciare il cambiamento ed evolvere con esso.<\/p>\n

    Sopravvivere in un mare di legacy<\/h2>\n

    Anche se oggi siamo nel pieno di questa trasformazione, c\u2019\u00e8 gi\u00e0 abbastanza esperienza per trarre alcune conclusioni su quanto visto fino ad\u00a0ora e su come si sono mosse, e si stanno muovendo, le aziende.<\/p>\n

    Le aziende che hanno applicazioni monolitiche – spesso rispecchiate da un\u2019organizzazione aziendale a silos – sono quelle che stanno facendo pi\u00f9 fatica ad adattarsi al cambiamento. Questo perch\u00e9:<\/p>\n

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

      La soluzione: le Architetture Evolutive<\/h2>\n

      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.<\/p>\n

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

      Che caratteristiche hanno le Architetture Evolutive?<\/p>\n

        \n
      1. Sono basate sullo stile architetturale a microservizi<\/strong>: oggi questo \u00e8 lo stile di sviluppo che meglio si adatta alla costruzione di architetture che possano evolvere facilmente. Lo sviluppo a microservizi<\/a> permette di separare le logiche di business<\/strong> secondo bounded context<\/em> ben definiti, responsabilit\u00e0 chiare e processi indipendenti. In questo modo, se abbiamo necessit\u00e0 di apportare un cambiamento a una logica, possiamo lavorare solo su quella, senza andare a toccare l\u2019intera architettura o altre logiche, che rischierebbero cos\u00ec di venire compromesse.<\/li>\n
      2. Sono basate su tecnologie cloud-native e containerizzazione<\/strong>: un\u2019applicazione pensata in maniera \u201cfuturibile\u201d \u00e8 in grado di operare su cloud differenti, pubblici o privati, disaccoppiando cos\u00ec il software dall\u2019hardware e sfruttando la massima flessibilit\u00e0 in termini di gestione delle risorse. Grazie a sistemi di orchestrazione come Kubernetes<\/a>, le architetture cloud-native<\/strong> sono in grado di automatizzare compiti come la distribuzione e la gestione dei container che contengono le applicazioni.<\/li>\n
      3. Lasciano libert\u00e0 di scelta sui linguaggi di sviluppo<\/strong>: costruire un\u2019architettura basata sullo stile architetturale a microservizi permette di utilizzare il linguaggio pi\u00f9 adatto per lo sviluppo della singola logica di business e del singolo microservizio. Questo ci permette di non avere vincoli tecnologici in futuro<\/strong>: se un nuovo linguaggio sar\u00e0 pi\u00f9 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\u00e0 consente di valorizzare al meglio le competenze presenti all\u2019interno del team di sviluppo.<\/li>\n
      4. Comunicano in modo \u201cstandard\u201d<\/strong>: API – in particolar modo, REST e GraphQL – ed eventi rappresentano due tasselli fondamentali per costruire architetture IT in grado di evolvere nel tempo<\/a>, garantendo sempre una comunicazione efficace e controllata tra servizi all\u2019interno di sistemi distribuiti e complessi.<\/li>\n<\/ol>\n

        L’impatto sul business, un esempio concreto<\/h2>\n

        Per capire quando un\u2019Architettura Evolutiva possa rispondere al meglio alle esigenze di oggi, immaginiamo una societ\u00e0 di trasporti<\/strong> che raccoglie i dati di affluenza dei passeggeri sui propri mezzi e li mostra in un\u2019app dedicata al personale. Questo dato serve alla societ\u00e0 per organizzare meglio i trasporti, le corse, ecc.<\/p>\n

        Con il cambiare delle esigenze degli utenti<\/strong>, e l\u2019ampliarsi dell\u2019offerta digitale della societ\u00e0, questo dato diventa un\u2019informazione importante anche per i passeggeri stessi, che se potessero consultarlo potrebbero pianificare ancora meglio il proprio viaggio.<\/p>\n

        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<\/strong>.<\/p>\n

        Se questa logica e questo dato sono depositati in un monolite, questo significa che dovremo far scalare l\u2019intero monolite, andando a toccare molte altre logiche sottostanti, mettendo a rischio l\u2019intera infrastruttura, con rischi e costi spropositati.<\/p>\n

        Grazie allo stile architetturale a microservizi<\/strong> 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<\/strong> risulta veloce e con un basso impiego di tempo e risorse economiche.<\/p>\n

        Digital Integration Hub, il miglior esempio di Architettura Evolutiva<\/h2>\n

        Uno dei migliori esempi concreti di Architettura Evolutiva lo ha probabilmente razionalizzato Gartner nel suo paper \u201cTurbocharge Your API Platform With a Digital Integration Hub<\/a>\u201d.<\/p>\n

        Il Digital Integration Hub <\/a>\u00e8 una API Platform<\/a> sviluppata a microservizi e alimentata da un layer di Fast Data<\/strong>, 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.<\/p>\n

        L\u2019adozione di un Digital Integration Hub porta con s\u00e9 numerosi benefici:<\/p>\n