Coniato qualche anno fa, il termine API economy evidenzia il ruolo centrale delle API nell’abilitare quella flessibilità, velocità e innovazione che consente alle applicazioni di rispondere ai requisiti della trasformazione digitale. Ma cosa sta dietro a questo termine? Come deve essere strutturata un’architettura applicativa orientata alle API o API first? Le API semplificano la comunicazione tra applicazioni, consentono di standardizzare i processi, permettono alle applicazioni legacy di esporre alcuni servizi all’esterno, in pratica abilitano l’allineamento tra IT e business, ma lo sviluppo di API per essere realmente efficace non può essere anarchico o improvvisato, richiede una metodologia e un processo che parte dal Design per arrivare alla Delivery sulla base di criteri e step ben precisi, altrimenti l’API economy si trasforma rapidamente in Caos economy. Per approfondire queste tematiche, Intesys ha realizzato qualche settimana fa, in collaborazione con Liferay, il workshop Headless & API date del quale riportiamo gli aspetti che riteniamo più interessanti.
Senza dilungarci troppo su una descrizione teorica dell’approccio di Intesys, che si evidenzierà nel concreto più avanti, riportiamo solo una breve premessa di Alessandro Caso, Digital Director di Intesys: “Dopo 20 anni di esperienza su architetture evolute, negli ultimi 5 abbiamo deciso di muoverci, con il supporto di Gartner, su un’architettura diversa che si basa sull’approccio bimodal elaborato dalla società di analisi: una modalità di approccio al mercato che integri il mode 1, orientato alle performance, robustezza, sicurezza, scalabilità degli applicativi, con il mode 2, espressione di agilità velocità innovazione. Abbiamo fatto nostro questo approccio strutturando un sistema di competenze legato al design user centrico, alle user interaction, al service design applicativo”. Si tratta di due mondi strettamente collegati tra loro e dove il dialogo, sebbene la relazione a volte non sia facile, deve essere continuo.
Who's Who
Alessandro Caso
“I nostri progetti – ha spiegato Ilario Gavioli, General Manager di Intesys – impattano sui cosiddetti touch point digitali, quindi l’utente è al centro dei nostri processi. Questa affermazione si concretizza con il processo Design to deliver dove stressiamo molto la fase di Service Design perché è da qui che parte il successo di un touch point”. Progettare un servizio orientato al cliente significa partire dall’osservazione delle persone e dei loro bisogni, capire insieme quali sono le necessità, per questo per Intesys sono fondamentali discipline e metodologie come il Co-design o il Design Thinking.
Who's Who
Ilario Gavioli
A questa fase segue quella di sviluppo del codice vero e proprio che viene suddivisa in due parti (figura 1): una dedicata allo sviluppo di applicazioni front end, la seconda riguarda invece il backend, quindi parliamo di Headless & API System, “è la parte che più impatta sull’IT ed è quella che chiede all’IT di modificare l’architettura applicativa per essere proattivi nel fornire ai propri clienti servizi che abilitino la trasformazione digitale”.
L’evento in questione è stato specificatamente dedicato a questa seconda parte, ma era importante inquadrala nel suo contesto più ampio.
Insieme agli approfondimenti tecnologici, sono stati illustrati alcuni casi come quello di un importante Gruppo Bancario spagnolo che sta avvicinando la propria Architettura IT al paradigma API first per offrire nuovi servizi al mercato, scalando rapidamente l’innovazione e accelerando il business per favorire l’integrazione con l’ecosistema dei partner della Banca. E quello di LU-VE Group, azienda del settore refrigerazione e condizionamento, che ha realizzato un configuratore con approccio API first: l’obiettivo era migliorare l’efficienza del processo di vendita attraverso una Single Page Application (SPA), che semplificasse il dialogo tra front-end, middleware e sistemi legacy dell’azienda. Una soluzione capace di costruire un progetto enterprise affidabile, resiliente e sicuro, che fornisce al contempo un’esperienza utente rapida, reattiva e fluida. Progetto che ha consentito a Intesys di arrivare tra i finalisti dei Digital360 Awards 2019.
Infine Rafael Lluis, Presales Lead Emea in Liferay, ha presentato il caso del CMS Headless Liferay che consente di centralizzare la gestione dei contenuti sui diversi canali, liberando dal vincolo tecnologico a livello front-end e garantendo massima flessibilità nella costruzione di interfacce utente, caratteristiche che, come vedremo, è alla base delle architetture headless.
Perché e come un’architettura IT orientata alle API risponde alle esigenze della digital transformation
Nuovi prodotti e servizi con time to market sempre più stringenti, multicanalità, ecosistemi tra partner molto diversi con la possibilità di utilizzare i reciproci servizi con estrema facilità, nuovi modelli di business che possono prevedere l’offerta di servizi di API: sono alcune delle sfide poste dalla trasformazione digitale e che, secondo Paolo Quaglia, API Strategist & IT Expert Intesys, un’architettura orientata alle API può aiutare a vincere.
Le soluzioni basate su API e i sistemi software headless
Quali sono le soluzioni che possono basarsi su API? “Le prime sono sicuramente quelle di enterprise integration; poi possiamo sviluppare applicazioni di front end utilizzando soluzioni headless che espongono uno strato di API che consente di sviluppare, appunto, il front end sulla base delle proprie esigenze senza alcun vincolo di prodotto; abbiamo poi lo sviluppo di applicazioni che sfruttano nuovi device (dalle smart TV ai wearable ecc.); soluzioni IoT”, l’elenco mostrato da Quaglia non è esaustivo, ma dà un’idea di quanto questo approccio sia flessibile.
Who's Who
Paolo Quaglia
Prima di proseguire, ci soffermiamo sul concetto di sistemi software headless perché fondamentale per comprendere l’approccio architetturale orientato alle API: sono quelle architetture che prevedono un disaccoppiamento netto tra backend e front end e dove i contenuti vengono erogati attraverso API con cui la componente di front end dialoga al fine di presentarli all’utente. Se le architetture tradizionali si caratterizzano per lo stretto legame tra backend e frontend (il codice di base è condiviso, quindi si tratta di due componenti della stessa applicazione), in un’architettura headless il backend diventa un modulo a sé stante con il compito di esporre API per accedere ai contenuti e le API verranno consumate da front end di varia natura (website, app, IoT), senza vincoli tecnologici.
I layer di un’architettura API
Un sistema headless si suddivide in 3 strati di API (figura 2) che, dal basso verso l’alto standardizzano le chiamate ai sistemi legacy e rendono i processi di creazione di nuovi servizi digitali più rapidi e flessibili.
“Una tipica azienda – ha ricordato Quaglia – ha al proprio sistemi core/legacy (CRM, ERP, gestione documentale ecc.) che hanno una logica molto verticale, ma offrono una serie di connettori per dialogare: un primo strato di API serve quindi per estrapolare l’informazione da questi applicativi dando, di fatto, l’accessibilità al dato da essi gestito. Al polo opposto abbiamo le Experience API, quelle che sono le vere e proprie API, ossia quelle che vengono esposte sul mercato e che servono alle applicazioni di front end”.
Tra i due vi è lo strato delle Process API, che l’esperto di Intesys definisce fondamentali: “Sono quelle che consentono di automatizzare i processi. Per rilasciare rapidamente una soluzione è fondamentale che i processi di un’azienda siano mappati e richiamabili tramite API univoche per quel processo: in questo modo lo sviluppo della prossima applicazione potrà richiamare l’API relativa alla parte di processo ripetitiva rispetto all’applicazione già rilasciata e questo ne accelererà il rilascio. Senza contare che utilizzando un processo già testato e in uso si riducono le possibilità di errore”.
Strutturare e definire il portfolio API
“Dobbiamo pensare alle Experience API come a veri e propri prodotti perché sono lo strumento con il quale si ‘vendono’ i propri servizi sul mercato e quindi è indispensabile strutturare un catalogo delle proprie API: capire quali e quante sono, quali sono le loro funzionalità, definire le policy di utilizzo. Per fare tutto ciò sono fondamentali due figure: Product manager, che si occupi di governare le API, soprattutto quelle esposte all’esterno, con il fine di definire una strategia generale, stabilire quali API esporre, prevedere il loro piano evolutivo o di ritiro, e l’API architect, che deve definire come farle, dando loro consistenza”, ha spiegato Quaglia che ha poi illustrato i due approcci allo sviluppo di API:
- inside out: ossia l’esposizione di una serie di servizi a partire dai sistemi sottostanti; tendenzialmente saranno API complesse perché, come ha detto Quaglia, “porto fuori la complessità del mio legacy”;
- outside in: ossia progettare le API considerando i bisogni degli utilizzatori, indipendentemente dai sistemi sottostanti; è l’approccio che consente veramente di cogliere i vantaggi dell’API economy.
Se è vero la figura dell’API architect è sempre fondamentale, con l’approccio outside in è irrinunciabile perché i dati non vengono modellati sulla base del modello già esistente nel legacy, ma in base a come li vorrebbe vedere un ipotetico cliente.
Who's Who
Denis Signoretto
In ogni caso l’API deve avere una certa consistenza, solo in questo modo possono essere riutilizzate: le API devono essere gestite all’interno di un disegno strategico che consenta di renderle semplici, utilizzabili, compatibili e ben documentante per chi deve consumarle. “Un buon design rende efficienti ed efficaci gli sviluppatori, sia in fase di prototipazione che nella fase di risoluzione dei problemi o di supporto”, ha sottolineato l’IT Architect di Intesys Denis Signoretto che ha specificato il “chi è” delle due figure:
- API Product Manager è colui che: comprende i bisogni degli utilizzatori in termini di funzionalità; assicura strumenti per garantire documentazione, facilità di utilizzo e integrazione; promuove l’adozione delle API nel sistema azienda; tiene sotto controllo e massimizza il ROI; si occupa di monitoring e valutazione KPI delle API.
- API Architect è colui che: comprende i bisogni operativi degli sviluppatori; introduce, fa comprendere e utilizzare gli strumenti di specifica; assicura tecnicamente qualità, documentazione, esempi; garantisce uniformità e adesione agli standard; garantisce la sicurezza; si occupa di monitoring ai fini delle performance e disponibilità delle API
Le piattaforme di API management
Sempre facendo riferimento alle Experience API, Quaglia ha quindi evidenziato l’importanza delle piattaforme di API management per gestire il “prodotto” API e ne ha riassunto le caratteristiche nella figura 3, sottolineando quelle più importanti: “Prima fra tutte il Development Portal che sta a una piattaforma di API management come la vetrina sta una negozio: questo è il tool dove i consumatori finali dell’API, ossia gli sviluppatori, trovano tutta la documentazione che le definisce, gli esempi, come richiamarle ecc.. Fondamentale è poi l’API gateway perché gestisce tutta una serie di sotto-funzionalità fondamentali come, per esempio, la sicurezza: abbiamo visto che spesso le nostre API sono collegate a sistemi legacy, se un client ‘impazzito’ lancia chiamate in numero esagerato alle API queste potrebbero impattare negativamente sul sistema core, gli API gateway dispongono di strumenti che possono limitare questa problematica, regolando il numero delle chiamate”.
Le 6 componenti strategiche dell’approccio headless
Signoretto nel suo intervento è poi tornato sul disegno strategico che consente di creare API semplici e intuitive, ma anche sicure, compliant, riusabili e ben documentate. Ecco allora quelli che l’IT Architect di Intesys definisce i “must have” per implementare un’architettura headless: “Per passare a un approccio headless non basta solo la tecnologia, ma è indispensabile un approccio strategico. Gli elementi abilitanti sono certamente le API, ma per evolvere un’infrastruttura IT verso un paradigma headless, non è sufficiente esporre API REST: serve definire una roadmap che supporti questa evoluzione, affrontando anche le sfide che il mondo dell’API Management richiede”.
Sono 6 le componenti strategiche identificate da Signoretto:
- Sicurezza: l’infrastruttura identificata deve offrire servizi di autenticazione delle API, adottando standard che assicurino un’integrazione semplice con livelli di sicurezza adeguati al contesto, e autorizzazione e accesso ai contenuti, governando visibilità e accessibilità ai dati e servizi aziendali in modo che vi possano accedere le sole persone autorizzate.
- Standard a supporto degli sviluppatori: per realizzare le interfacce utente, gli sviluppatori hanno bisogno di: protocolli standard; documentazione aggiornata; esempi funzionati e “sandbox” dove testare le proprie integrazioni; un set di API che siano tra loro omogenee nella definizione e che rispettino best practices riconosciute in ambito Rest.
- Evolvibilità delle API: per rispondere alle esigenze del business è indispensabile poter implementare modifiche mantenendo la compatibilità col pregresso. “Per gestire questa complessità e far evolvere le API agilmente intervengono non solo i sistemi di versioning e di deprecazione di servizi obsoleti, ma anche il disegno di API che supportano il cambiamento, GraphQL e Hypermedia risultano attualmente quelli di maggior risalto e questo è proprio uno degli aspetti più rivoluzionari rispetto all’era delle SOA”, ha specificato Signoretto.
- Monitoraggio di performance, scalabilità e resilienza: come abbiamo visto, l’integrazione con i sistemi legacy aziendali, innegabile vantaggio, può creare qualche problema, per questo è indispensabile presidiare l’infrastruttura in modo che sia in grado, anche predittivamente, di erogare servizi con qualità (e costi) compatibili con la tipologia di client che li consuma.
- Sistemi di auditing & governance: fondamentali per capire gli impatti, gli scenari di utilizzo e le previsioni sull’infrastruttura IT.
- Analisi del dominio e design delle API: è fondamentale che le API siano strutturate secondo un modello che rappresenti le entità del dominio, le proprie modalità di business, le depuri e le renda indipendenti dalle complessità dei sistemi legacy creando un adeguato strato di interfaccia che favorisca la riusabilità e isoli i client dalla complessità e dalle interdipendenze dei sistemi sottostanti.
.
