Introduzione: perché parlare di API
Nell’industria moderna le aziende sono dotate di un numero sempre maggiore di sistemi per facilitare le operazioni e la gestione. Per questo motivo, sempre più sistemi devono scambiarsi informazioni in modo rapido e automatico.
Le API sono uno degli strumenti più adatti allo scopo, in quanto permette a due programmi diversi di “parlare” tra loro senza errori o interventi manuali. In questo articolo andremo a capire come funziona questa comunicazione e in che modo lo sviluppo di questo strumento può incidere nel costo di un progetto, usando esempi semplici e concreti.
Cos’è un’API? La metafora del cameriere
Un’API (Application Programming Interface) è come un cameriere in un ristorante. Prende la richiesta del cliente, la porta in cucina e riporta il piatto pronto secondo i requisiti espressi dal cliente. In informatica, l’API prende la richiesta di un programma, la passa al sistema che gestisce i dati, e ritorna la risposta pronta all’uso, evitando che chi chiede debba conoscere come funziona la cucina.
Sistemi che comunicano: cliente, ristorante e cameriere
In riferimento all’esempio, in informatica ognuno dei sistemi che si interfacciano può avere il ruolo di cliente o di ristorante: può chiedere dati o fornire dati. Per farlo in modo efficiente serve sempre un cameriere (l’API) che faccia da tramite. Se manca il cameriere o se non sa fare il suo lavoro, la comunicazione diventa difficile o impossibile.
Scenari di integrazione possibili tra due sistemi
Quando due sistemi devono comunicare, ci sono diversi casi possibili, a seconda di chi ha già le API pronte e di quanto sono complete. Nei prossimi casi spiegheremo i diversi scenari aiutandoci sempre con la metafora del ristorante e del cameriere calandoli sulla comunicazione tra il nostro portale The ASP e l’ERP di un potenziale cliente.
CASO 1 – Nessuno dei due sistemi ha il cameriere (nessuna API)
Sia The ASP che l’ERP sono ristoranti ma senza camerieri. Per questo motivo non possono né inviare né ricevere ordini.
Uno dei due deve creare un cameriere (API) per servire i propri dati, e l’altro deve imparare a fare richieste a quel cameriere. Potenzialmente ci sarà un costo di sviluppo piuttosto alto per entrambe le software house, perché occorrerà costruire tutto da zero: sia chi serve (la parte che quindi “espone” le API), sia chi ordina (la parte che invece “utilizzerà” le API).
CASO 2 – Entrambi hanno già i camerieri (API disponibili)
Sia The ASP che ERP sono ristoranti con i propri camerieri pronti.
Si tratta solo di decidere chi fa il cliente e chi fa il ristorante: chi chiede i dati e chi li fornisce.
In questo caso, il costo di sviluppo tenderà ad essere medio-basso per entrambe le software house, perché l’infrastruttura c’è già. Occorre solamente mettere in collegamento i due sistemi e definire i ruoli di ognuno.
In questo caso la scelta potrà essere lasciata al cliente, sulla base dei diversi fattori influenzanti il progetto (non da ultimo il preventivo di sviluppo presentato dalle software house).
CASO 3 – The ASP ha i camerieri (API), l’ERP no
The ASP è pronto a servire i dati, ma l’ERP non ha modo di fare richieste.
In questo caso l’ERP dovrà sviluppare la capacità di interagire con le API di The ASP. Il costo di sviluppo maggiore sarà in capo alla software house dell’ERP in quanto dovrà sviluppare la parte che consuma l’API (parte il cui sviluppo, comunque, non è eccessivamente oneroso). Il costo per 4eH sarà minore, in quanto si tratta solamente di configurare in dettaglio le API già esistenti.
CASO 4 – L’ERP ha i camerieri (API), The ASP no
L’ERP ha le API pronte a fornire dati, ma The ASP non sa come richiederli.
4eH dovrà sviluppare la parte di The ASP che consuma le API dell’ERP.
Il caso è analogo al precedente, sebbene invertito: in questo caso, infatti, il costo maggiore sarà sostenuto da 4eH, mentre la software house dell’ERP avrà un costo minore, dovuto principalmente alla configurazione.
CASO 5 – The ASP ha i camerieri (API), ma non portano tutti i piatti richiesti
The ASP ha API attive, ma quando l’ERP fa una richiesta, alcune informazioni o funzionalità non sono disponibili.
In questo caso le API di The ASP devono essere ampliate per coprire le funzionalità mancanti o per fare in modo che trasportino le informazioni aggiuntive necessarie.
Il costo, in questo caso, varia in base alla complessità delle funzionalità da aggiungere o delle informazioni da integrare.
Come nel caso 3, il costo maggiore ricadrà verosimilmente sulla software house dell’ERP, mentre 4eH dovrà valutare, in base al progetto, gli eventuali costi aggiuntivi da sostenere, che potranno essere anche non trascurabili in caso di ampliamenti importanti delle API.
CASO 6 – L’ERP ha i camerieri (API), ma non servono tutto il necessario
L’ERP ha le API, ma The ASP scopre che non tutte le richieste necessarie per la gestione dell’operatività possono essere soddisfatte con quelle disponibili.
In questo caso sarà necessario estendere le API dell’ERP per fornire tutte le informazioni richieste dall’operatività di The ASP e dai flussi concordati con il cliente.
Il costo può essere molto variabile e sarà legato all’entità delle estensioni da sviluppare. Come nel caso 4, il costo maggiore sarà a carico in questo caso di 4eH, che dovrà sviluppare la parte necessaria a inoltrare le richieste mediante le API dell’ERP, mentre la software house dell’ERP potrebbe avere costi aggiuntivi legati all’ampliamento delle API. Anche in questo caso, il costo sostenuto dalla software house dell’ERP dipende dal progetto e potrà essere non trascurabile in caso di modifiche o ampliamenti importanti delle API.
Conclusione
Per supportare il cliente nella scelta della soluzione migliore è fondamentale individuare lo scenario più vicino alla sua realtà. In base allo scenario che si presenta, sarà poi possibile fornire una consulenza mirata sui costi e sulle attività necessarie.
La decisione finale verrà presa dal cliente una volta chiaro lo scenario e una volta ricevuti i preventivi dettagliati da entrambe le software house. In questo modo, il cliente ha tutte le informazioni e la panoramica di soluzioni necessarie per valutare in modo in modo completo e consapevole i costi e i benefici, e selezionare la strada che più si addice alle proprie necessità e aspettative.
