Stima dei costi per la sostituzione di un’API di terze parti

L’API del nuovo fornitore appare identica finché non si avvia la migrazione dei dati.

L’argomentazione a favore del cambio di fornitore è sempre la stessa: la nuova API è più pulita, più veloce, più economica. La trappola sta nel fatto che le peculiarità della vecchia API sono fondamentali per il funzionamento del sistema. Il codice accumula da due anni espressioni del tipo «questa è una stringa, ma in realtà è una data nel loro formato», «questo restituisce null quando in realtà indica zero», «questo applica un limite di frequenza in modo silenzioso». Una sostituzione completa implica riprodurre ciascuna di queste peculiarità in base al comportamento del nuovo fornitore, che presenta differenze che nessuno ha documentato.

Il preventivo deve tenere conto della fase di funzionamento in parallelo: il vecchio e il nuovo fornitore operano contemporaneamente, con un confronto dei risultati, finché il team non avrà la certezza che il nuovo fornitore sia all’altezza. Tale fase è spesso più lunga dell’implementazione. I progetti che non ne tengono conto nel preventivo procedono all’adozione del nuovo fornitore e scoprono le lacune solo quando i dati di un cliente si imbattono in un caso limite.

Ciò che viene detto nella sala

Backend: “Il nuovo SDK è migliore. Le chiamate di base richiedono un giorno ciascuna.”

Introduzione: “E i dati storici che conservano per noi?”

SRE: “Stiamo utilizzando entrambi i fornitori contemporaneamente o stiamo effettuando il passaggio?”

Backend: “Il loro formato di webhook è diverso. Lo stesso vale per l’autenticazione.”

Domanda: “Come si verifica l’equivalenza? Confrontando le risposte raccolte nell’arco di una settimana?”

Domande da porsi prima di votare

• Esistono dati storici presso il precedente fornitore che devono essere trasferiti alla nostra azienda?
• Differenze relative all’autenticazione: chiavi API, OAuth, richieste firmate?
• Webhook: gli eventi si allineano correttamente o occorre effettuare una conversione?
• Periodo di funzionamento in parallelo: quanto dura e quando si può considerare “sufficientemente stabile” per effettuare il passaggio definitivo?
• Limiti di velocità e modello di tariffazione del nuovo fornitore: identici o diversi?
• Ritorno alla situazione precedente: è possibile tornare indietro qualora il nuovo fornitore si rivelasse peggiore?

Le chiamate di base sono semplici; è la dimostrazione dell’equivalenza a richiedere il lavoro maggiore. Se l’esecuzione duale e lo spostamento dei dati sono entrambi reali, si tratta di una questione complessa: separarle e valutare la verifica indipendentemente dall’implementazione.

Prevedete un budget per l’esecuzione in doppia modalità e per la verifica di equivalenza. L’API dall’aspetto pulito è la parte meno costosa.

Come nel caso della stima della migrazione di un database, il codice è veloce e il vero lavoro consiste nell’implementazione. Si consultino gli altri esempi di stime già elaborati, oppure si avvii una sessione gratuita di Planning Poker una volta delineato il piano a doppio ciclo.