Creare opportunità di business con un approccio strategico alle API

Per massimizzare la capacità di un’azienda di rispondere alle mutevoli richieste del mercato, la struttura IT sottostante deve essere organizzata per favorire flessibilità, scalabilità e manutenibilità. Le API rivestono un ruolo chiave nel facilitare l’allineamento tra business e IT. Secondo il paradigma API first, infatti, le API vengono messe al centro della strategia di integrazione di dati e applicativi, in cui gli asset tecnologici vengono progettati e integrati per essere riutilizzabili e per soddisfare le esigenze dei loro utilizzatori secondo un’ottica user-centered.

Adottare un approccio strategico nell’integrazione di un’Architettura IT consente alle aziende di capitalizzare gli investimenti IT, creando valore per il business. Per farlo è importante anticipare alla fase di prototipazione e implementazione delle API una fase di analisi e di Design in cui definire quali API progettare e in che modo interrogare i sistemi sottostanti in modo efficiente ed efficace.

API: il valore di un approccio strategico per il business

Le API (Application Programming Interface) sono il linguaggio condiviso da un insieme di applicativi, che definiscono la grammatica della conversazione tra software. Ma a livello di business il valore delle API va oltre, consentendo alle organizzazioni di:

• Abilitare funzionalità applicative in grado di alimentare la creazione di nuovi servizi e nuovo valore per clienti e prospect.
• Integrare risorse aziendali interne ed esterne, producendo valore di business.
• Massimizzare il valore degli asset tecnologici esistenti, ottimizzando gli investimenti IT.
• Ridurre le barriere all’innovazione, dando maggiore flessibilità di adattamento senza intervenire sui sistemi legacy.
• Se sviluppate come veri e propri prodotti ad hoc, produrre profitti.

Le API sono degli elementi strategici che consentono di acquisire agilità per affrontare le sfide del processo di Trasformazione Digitale, ma prima di essere implementate devono essere pensate per essere utili allo scopo degli utilizzatori (in forma generica e non specifica per un singolo progetto) e all’interno di un disegno architetturale strategico.

Scopri il funzionamento di una API oriented Architecture in 2 minuti, guarda il video!

Le 6 fasi per la progettazione strategica delle API

Dato il valore che le API contribuiscono a creare a livello di business, è importante chiarire gli obiettivi strategici prima di iniziare il loro sviluppo, definendo:

1. le risorse che desiderano esporre e in quali modalità,
2. le esigenze concrete dei loro utilizzatori con una progettazione user-centered delle API.

Nello sviluppo di API la vera sfida sta nella capacità di offrire valore concreto e reale per il business dell’azienda, progettando API con un approccio outside-in che consente di identificare i bisogni degli utilizzatori in modalità generica e indipendente dai sistemi sottostanti.

Fatta questa fondamentale premessa, ecco quali sono i tipici passi per la progettazione di API, partendo dal design fino ad arrivare alla pubblicazione e alla successiva manutenzione delle stesse.

Fase 1 e 2

Analisi del dominio. In questa fase vengono chiarite le esigenze degli utilizzatori in tutte le possibili casistiche, cercando di rendere le API generiche e non specifiche per l’esigenza di un singolo progetto.
L’analisi delle risorse del dominio applicativo alle API, la definizione di un glossario univoco, le relazioni tra le risorse e le transizioni di stato di ogni risorsa sono passi fondamentali per ottenere un disegno pulito, semplice, completo e omogeneo delle API. Il risultato di questa fase è la descrizione dell’architettura delle informazioni relativa alle API in base all’analisi di tutti gli scenari di utilizzo.

Disegno architetturale delle API. In questa fase viene definito il front-end, ossia “le forme” dei metodi esposti, dei parametri, della documentazione e lo stile architetturale delle API (spesso REST style). Per farlo viene utilizzato un linguaggio di definizione delle API, che consente di strutturarle, definirle e descriverle per consentire la chiamata di terzi nel momento in cui vengono pubblicate. Nel caso REST il tipico linguaggio per la descrizione delle API è Swagger/OpenAPI. Attraverso questo linguaggio il designer ha uno strumento condiviso con cui lavorare e produrre il disegno delle API adottando il paradigma design first. Il risultato di questa fase è un artefatto standard utile sia agli sviluppatori che implementeranno nelle fasi successive le API, che ai futuri utilizzatori delle stesse.

In queste prime due fasi, le aziende hanno l’opportunità di approcciare strategicamente lo sviluppo delle API partendo dalle esigenze emerse dall’analisi degli scenari di utilizzo per progettare un set di API omogenee, con un unico glossario omogeneo, semplici da capire e da adottare
La sfida di questa fase del progetto è insita proprio nella mancanza o debolezza delle stessa a causa dell’adozione di un approccio alla progettazione inside-out o per mancanza di know-how.

Fasi 2 e 4

Prototipazione delle API, anche in forma parziale, con tecniche di “mocking” per poterne testare l’usabilità, le chiamate e valori che ne risultano. Il prototipo delle API deve corrispondere alla description concordata e usare possibilmente dati reali estratti dai back-end. L’utilizzo di linguaggi come Swagger/OpenAPI consente di generare in maniera automatica parti del codice scheletro necessari allo sviluppo della API.
Il principale risultato di questa fase è verificare la bontà, l’efficacia e le validazioni delle API.

Implementazione per la produzione. L’obiettivo di questa fase è ingegnerizzare lo sviluppo delle API (ad esempio l’utilizzo di pattern, la re-fattorizzazione di librerie utilizzate dal tutto il portfolio delle API, etc..) per rispettare l’analisi funzionale. È fondamentale considerare in questa fase anche l’implementazione di tutti gli aspetti non funzionali: sicurezza, performance, alta disponibilità, come pure applicare politiche di caching e rating limitation.

In queste fasi, la corretta ingegnerizzazione delle API, rispetto alla fase di analisi, consente di ottenere un prodotto facilmente utilizzabile, sicuro e scalabile in coerenza alle esigenze degli utilizzatori delle API.

Fasi 5 e 6

Pubblicazione della API e relativa documentazione. Dopo aver pubblicato le API, inizia l’analisi del loro utilizzo e dei relativi pattern. Spesso i sistemi di API management mettono a disposizione strumenti per la pubblicazione delle API e la relativa documentazione (come il Developer Portal) e strumenti di analisi quali dashboard, report e strumenti di monitoraggio, call time report, up-time response etc. È possibile identificare anche metriche per calcolare il ROI e il valore di business della API.

Manutenzione. Una volta pubblicata l’API, la relativa “description tecnica” deve essere congelata per evitare potenziali errori nelle applicazioni che la utilizzano. Dato che gli utilizzatori conteranno sulla affidabilità e longevità della API, le operazioni di manutenzione dovranno avvenire di conseguenza, senza modifiche per garantire la sua relativa retro compatibilità.

Diventa prioritario quindi gestire il ciclo di vita della API e gli scenari di evoluzione, definendo delle strategie di cambiamento che tengano conto delle esigenze degli utilizzatori attuali e nuovi. L’obiettivo? Garantire continuità agli applicativi, evitando malfunzionamenti e problemi dovuti ad aggiornamenti o problematiche delle API.

L’adozione di un approccio strategico alle API per integrare la propria Architettura IT è un progetto sfidante per le aziende, ma consente di ottimizzare gli investimenti IT e creare valore di business.

Scopri di più sulle API Architecture