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

L’API del nuovo fornitore sembra 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 e 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 casi del tipo «questa è una stringa, ma in realtà è una data nel loro formato», «questo restituisce null quando in realtà significa zero», «questo limita la frequenza in modo silenzioso». Una sostituzione completa comporta la riproduzione di 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, fino a quando 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 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 stanza

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 formato dei loro webhook è diverso. Lo stesso vale per l’autenticazione.”

Domanda: “Come si verifica l’equivalenza? Confrontando le risposte nel corso 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 in modo chiaro, oppure occorre effettuare una conversione?
• Periodo di funzionamento in parallelo: quanto dura e quali sono i criteri “sufficienti” per procedere al 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 maggior impegno. Se l’esecuzione duale e lo spostamento dei dati sono entrambi reali, si tratta di più di un unico caso: li si deve suddividere e valutare la verifica separatamente 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.

Proprio come nel caso della stima della migrazione di un database, il codice viene sviluppato rapidamente, mentre 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.