Zwei Figuren aus Haftnotizen schließen Kabel an Kästen mit den Aufschriften „Quelle“ und „Ziel“ an, während eine dritte hinter ihnen eine Wandsteckdose überprüft.

Abschätzung des Aufwands für den Wechsel zu einer API eines Drittanbieters

So schätzen Sie den Aufwand für den Wechsel zu einer API eines Drittanbieters ein: semantische Lücken, Parallelbetrieb und die Annahmen, die in den Eigenheiten des bisherigen Anbieters verankert sind. Die neue API sieht lediglich identisch aus.

Die API des neuen Anbieters sieht zunächst identisch aus, bis Sie mit der Datenmigration beginnen.

Das Verkaufsargument für einen Anbieterwechsel ist immer dasselbe: Die neue API ist übersichtlicher, schneller und kostengünstiger. Die Falle besteht darin, dass die Eigenheiten der alten API tragende Elemente des Systems sind. Der Quellcode enthält seit zwei Jahren Fälle wie „das ist zwar eine Zeichenkette, aber eigentlich ein Datum in deren Format“, „das gibt null zurück, obwohl es Null bedeutet“ oder „das führt stillschweigend eine Ratenbegrenzung durch“. Ein sauberer Wechsel bedeutet, jede einzelne dieser Eigenheiten im Verhalten des neuen Anbieters nachzubilden – und dieses unterscheidet sich in Punkten, die niemand dokumentiert hat.

In der Kostenvoranschlag muss der Parallelbetrieb berücksichtigt werden: Der alte und der neue Anbieter laufen nebeneinander, wobei die Ergebnisse verglichen werden, bis das Team davon überzeugt ist, dass der neue Anbieter die Anforderungen erfüllt. Diese Phase dauert oft länger als die Implementierung. Bei Projekten, bei denen dies nicht einkalkuliert wurde, wird der neue Anbieter eingeführt, und die Lücken werden erst entdeckt, wenn die Kundendaten das nächste Mal einen Grenzfall erreichen.

Was in dem Raum gesagt wird

Backend: „Das neue SDK ist besser. Die grundlegenden Aufrufe dauern jeweils einen Tag.“

Einleitung: „Was ist mit den historischen Daten, die sie für uns aufbewahren?“

SRE: „Betreiben wir beide Anbieter gleichzeitig oder führen wir eine Umstellung durch?“

Backend: „Das Webhook-Format unterscheidet sich. Das gilt auch für die Authentifizierung.“

Frage: „Wie überprüfen wir die Gleichwertigkeit – indem wir die Antworten eine Woche lang vergleichen?“

Fragen, die man sich vor der Stimmabgabe stellen sollte

  • Gibt es beim bisherigen Anbieter historische Daten, die wir mitnehmen müssen?
  • Unterschiede bei der Authentifizierung: API-Schlüssel, OAuth, signierte Anfragen?
  • Webhooks: Lassen sich die Ereignisse direkt zuordnen, oder müssen wir sie umwandeln?
  • Zeitraum des Parallelbetriebs: Wie lange dauert er, und ab wann ist der Übergang „gut genug“?
  • Ratenbegrenzungen und Preismodell beim neuen Anbieter: identisch oder unterschiedlich?
  • Rücknahme: Können wir den Vorgang rückgängig machen, falls sich der neue Anbieter als schlechter erweisen sollte?

Die grundlegenden Aufrufe sind einfach; der Gleichwertigkeitsnachweis ist die eigentliche Arbeit. Wenn sowohl der duale Durchlauf als auch die Datenverschiebung real sind, handelt es sich um mehr als eine Aufgabe: Teilen Sie diese auf und dimensionieren Sie die Verifizierung getrennt von der Implementierung.

Planen Sie die Kosten für die doppelte Ausführung und die Äquivalenzprüfung ein. Die übersichtliche API ist der kostengünstige Teil.

Ähnlich wie bei der Schätzung einer Datenbankmigration ist der Code schnell erstellt, während die eigentliche Arbeit in der Umsetzung liegt. Sehen Sie sich die anderen Beispiele für Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Plan für den dualen Ablauf skizziert ist.