API led connectivity: cos'è e perché adottarla in azienda

Api Led Connectivity: il modello a tre livelli e la composable architecture

La connotazione e il ruolo delle API è drasticamente cambiato nell’era della Digital Transformation: le API sono ora il nuovo modello di business, non sono più utilizzate esclusivamente all’interno di un’organizzazione, ma sono esposte ad utenti esterni in tutto il mondo.

Per questo è necessario parlare di API-led connectivity, ossia un nuovo metodo di connettere i dati con le applicazioni tramite API riutilizzabili e mirate. Questo approccio cambia il modo in cui opera l’IT e promuove l’accesso decentralizzato a dati e funzionalità, senza compromettere la governance.

Gli applicativi comunicano tra loro tramite API e questo non è una novità: il modello classico di integrazione tra applicativi prevede infatti connessioni punto punto tramite chiamate API o RPC, nella direzione necessaria. Questo però crea una fittissima rete di connessioni, difficile da gestire, piuttosto inefficiente e costosa da mantenere. Data la frequenza delle modifiche necessarie all’interno dei sistemi IT, sia per accogliere nuove tecnologie, sia per ridurre il time to market e rimanere competitivi, questo tipo di struttura risulta limitante e obsoleta. Qualsiasi modifica infatti richiede una notevole quantità di tempo e di investimento economico.

Per superare i limiti imposti da questo approccio, la soluzione ideale è quella di implementare una strategia di integrazione basata su tre livelli di API ed abbracciare quindi l’approccio API-led connectivity. Le API devono soddisfare alcuni requisiti poiché pensate per essere riutilizzate:

• essere rilevabili e accessibili,
• essere prodotte e progettate per un facile consumo,
• essere gestibili per la scalabilità, le prestazioni e la sicurezza.

Le API sono raggruppate quindi in tre livelli, in base al loro effettivo utilizzo:

1. System API
2. Process API
3. Experience API.

Le System API vengono utilizzate per accedere ai sistemi principali e fornire un mezzo per isolare il cliente o il consumatore dalla complessità o da eventuali modifiche ai sistemi sottostanti. Una volta creato questo layer, molti utenti possono accedere ai dati senza la necessità di apprendere i sistemi sottostanti e possono riutilizzare queste API in più progetti.

Una System API definisce il contratto RAML/WSDL per descrivere come interagire con il dominio. Ad esempio, una System API per un dominio di prodotto può contenere risorse con metodi come GET, POST, PUT e DELETE e i relativi schemi (XSD, JSON) e risposte (200, 400, 500 e così via).  Poiché queste API forniscono accesso diretto ai dati sensibili, la sicurezza è di fondamentale importanza in questo livello. Pertanto, è importante applicare la gestione degli accessi per ridurre i problemi di sicurezza e controllare il modo in cui gli utenti possono accedere ai dati.

Le Process API sono responsabili della modellazione dei dati: orchestrano i flussi di dati, chiamando più System API. L’orchestrazione prevede la raccolta, la divisione, il filtraggio e l’instradamento dei dati. Lo scopo principale delle Process API è incapsulare rigorosamente il processo aziendale indipendentemente dai sistemi di origine (System API) da cui provengono i dati.

Veniamo ora allo strato più alto, quello delle Experience API. A questo punto, abbiamo tutte le informazioni private di un’azienda esposte privatamente dalle System API e le Process API hanno già esposto la logica del processo aziendale. I dati vengono consumati da un’ampia gamma di consumatori con formati diversi, ad esempio l’API dell’ordine di acquisto (Process Layer) ha esposto i dati nel formato JSON, ma abbiamo un’applicazione consumer che accetta solo il formato CSV o XML o viceversa. In alcuni casi potremmo dover offrire dati filtrati per diverse applicazioni consumer. Tutta questa logica di trasformazione è implementata nell’Experience Layer e le implementazioni sono esposte tramite Experience API. Le Experience API rappresentano il modo in cui i dati possono essere manipolati per soddisfare le esigenze di più segmenti di pubblico.

Questa architettura consente di razionalizzare e centralizzare le funzionalità a servizio dei processi, grazie ad un modello standard di integrazione che:

• conferisce valore agli asset aziendali ed al loro riutilizzo;
• rende scalabile l’infrastruttura (e quindi il business) rispetto ai carichi di lavoro;
• abilita le evoluzioni dei processi e dei modelli di vendita velocizzando nuove integrazioni tra sistemi o servizi;
• garantisce informazioni integre, nonostante la presenza di sistemi eterogenei;
• massimizza la business continuity e garantisce una politica di zero message loss grazie a meccanismi di persistenza dei dati e retry nel caso di sistemi down.

Si parla di Composable Architecture, ovvero di un pattern architetturale secondo il quale l’architettura di integrazione è il risultato della composizione di diversi componenti software indipendenti: nuovi moduli possono essere aggiunti, i moduli esistenti possono essere aggiornati senza compromettere il resto del sistema, i moduli vengono orchestrati rendendoli interoperabili per costruire asset business di varia natura ed evadere le nuove iniziative business.