Stima dei costi relativi alla 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, più economica. La trappola sta nel fatto che le peculiarità della vecchia API sono fondamentali per il funzionamento del sistema. Il codice presenta due anni di 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» — e una sostituzione completa comporta la riproduzione di ciascuna di queste peculiarità in base al comportamento del nuovo fornitore, che è diverso in modi 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 implementano il 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 loro formato di webhook è diverso. Lo stesso vale per l’autenticazione.”

Domanda: «Come si verifica l’equivalenza? Confrontando le risposte di una settimana?»

Domande che vale la pena porsi prima di votare

• Esistono dati storici presso il precedente fornitore che devono essere trasferiti alla nostra azienda?
• Differenze relative alle autenticazioni — Chiavi API, OAuth, richieste firmate?
• Webhook: gli eventi corrispondono in modo univoco o 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 parte complessa è la dimostrazione di equivalenza. Se sia l’esecuzione duale che lo spostamento dei dati sono reali, si tratta di più di un unico caso — separateli e valutate la verifica indipendentemente dall’implementazione.

Prevedete un budget per l’esecuzione doppia e 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 sta nell’implementazione. Si vedano gli altri esempi di stime già elaborate, oppure si avvii una sessione gratuita di Planning Poker una volta delineato il piano di esecuzione in due fasi.