Cosa intendiamo per API e che cosa sono?
Ogni volta che abbiamo a che fare con questo termine abbiamo in mente l’interfaccia utente per il testing con Swagger, piuttosto che una visione architetturale con ad esempio Amazon con il suo Gateway e le lambda function o più in generale una parte del mio programma.
Partiamo dalla definizione:
Una API, Application Programming Interface, è un intermediario software che consente a due applicazioni di dialogare tra loro. E’ un insieme di funzioni che consente di creare applicazioni che accedono alle funzionalità o ai dati di un’altra applicazione o servizio.
Oggi sono molto di più, ovvero sono una sorta di chiave di accesso ad un universo di concetti, strumenti, architetture ed in generale un ecosistema che raccoglie sforzi ed iniziative sempre più avanzate.
La vera svolta si ebbe nel 2002, grazie a Jeff Bezos e il suo mandato.
Jeff Bezos’ Big Mandate
Il Jeff Bezos’ Big Mandate del 2002, più volte poi riportato come Bezos moment per indicare tutti quei CEO che decidono di colpo di virare il business verso le API, ha avuto una valenza notevole per il business di Amazon.
Bezos si tolse il cappello dell’architect per indossarne uno da imprenditore, rendendosi conto dell’aumento dei costi dei team interni (mancanza di modi coerenti e ben gestiti di scambiare dati e capacità tra loro) e dal conseguente rallentamento delle pianificazioni di business.
Il Bezos Mandate ci ricorda i seguenti concetti cardine:
- Connubio tra Business e IT.
- Esposizione di dati e funzionalità.
- Fondarsi sulla comunicazione tramite interfacce e standardizzare le interazioni dei dati.
- Essere agnostici dal punto di visto delle Tecnologie usate.
- Progettare per “l’Esterno” come paradigma.
Per chi volesse approfondire sul Bezos Mandate, Stefano consiglia la lettura dell’articolo “Have you had your Bezos moment? What you can learn from Amazon” [1].
MVP e VPI
Secondo Deloitte Consulting le API sono passate dall’iniziale stato di tecnica di sviluppo ad un driver del modello di business. Le risorse principali di un’organizzazione possono essere riutilizzate, condivise, e monetizzate tramite API che possono estendere la portata dei servizi esistenti o fornire nuovi flussi di entrate. Dovrebbero essere gestite come un prodotto, costruito su una tecnica complessa improntata ad includere sistemi e dati legacy e di terze parti.
Avere un prodotto vuol dire quindi collocarlo sul mercato al momento giusto. Il contesto attuale che vede un mercato in continua e rapida evoluzione, le aziende si sono organizzate di conseguenza definendo un nuovo modello, l’MVP ovvero Minimum Viable Product. Brevemente un MVP è una versione di un prodotto con caratteristiche appena sufficienti per essere utilizzabile dai primi clienti che possono quindi fornire feedback per lo sviluppo futuro. Concentrarsi sul rilascio di un MVP significa che gli sviluppatori potenzialmente evitano il lavoro lungo e non necessario.
Le API quindi diventano prodotto, API as Product, e portano al concetto di VPI, ovvero Value Proposition Interface. Non sono più orientate all’applicativo ma vengono progettate insieme al business per offrire un prodotto che esprima la Value Proposition aziendale.
Per ulteriori approfondimenti, Stefano ci consiglia il libro “API Product Management – Product Strategy and Execution for the Digital Economy” [2].
API Economy
Un prodotto collocato in un mercato determina un’economia. Con API Economy ci riferiamo al modo in cui questi software possono positivamente influire sulla redditività di un’azienda, consentendo di scalare rapidamente grazie all’accesso a dati e servizi di terze parti o trasformare i propri servizi e dati in una piattaforma che attrae partner su cui costruire nuovi servizi e che porta nuovi clienti.
Si distinguono due categorie:
- Micro-Economy: le API usate all’interno di aziende per capire le attività/centri di costo che funzionano meglio sfruttando i loro analitici.
- Macro-Economy: le API di terze parti che permettono alle aziende di comunicare con il resto del mondo.
Non possiamo inoltre non parlare di marketplace: con un’API sul mercato un’azienda può avere altri obiettivi oltre quello delle vendite. Altri obiettivi riguardano la ricerca di altri partner, fare innovazione, oppure trovare altre API con il quale integrarsi.
API Platform
Un provider di API è un’organizzazione che espone dati e/o funzionalità tramite un servizio consumabile a livello di codice con una o più API. Un’azienda passa da fornitore a piattaforma quando:
- Consentono l’accesso alla value-proposition fondamentale dell’organizzazione.
- Sono scalabili sia tecnicamente che per il business.
- Consentono ai consumatori di creare valore condiviso.
- Sono determinanti per garantire la posizione dell’organizzazione come leader di mercato.
- Sono viste dal top management come critiche per l’azienda
API Management
Un’organizzazione che fa delle API il suo business deve essere opportunamente strutturata, quindi avremo:
- API Registry: un vero e proprio inventario. Consente ai consumatori di consultare le API disponibili, ed è di aiuto all’azienda per la gestione del loro ciclo di vita (catalogazione delle versioni, promozione ecc.).
- API Gateway: il componente responsabile dell’esposizione e dell’organizzazione delle API ai diversi consumatori. Copre le seguenti aree fondamentali: Pubblicazione, Sicurezza, Standardizzazione, Controllo dell’Erogazione, Logging & Data Capture.
- Developer Portal: fornisce l’interfaccia umana alle API di un’organizzazione, fornisce un’esperienza utente di qualità (sia all’interno che per le terze parti), strumenti e risorse utili per la creazione di applicazioni che utilizzano le API. Inoltre, il portale fornisce le strutture agli sviluppatori per gestire il loro coinvolgimento con l’organizzazione (documentazione, notifiche, metriche).
Data l’importanza del tema, Stefano consiglia la lettura di alcuni libri interessanti [3] [4] [5].