Estimación del coste de la sustitución de una API de terceros

La API del nuevo proveedor parece idéntica hasta que se empieza a migrar los datos.

El argumento para cambiar de proveedor es siempre el mismo: la nueva API es más limpia, más rápida y más barata. La trampa reside en que las peculiaridades de la API antigua son fundamentales para el funcionamiento del sistema. El código fuente acumula dos años de casos como «esto es una cadena, pero en realidad es una fecha en su formato», «esto devuelve null cuando en realidad significa cero» o «esto limita la frecuencia de llamadas de forma silenciosa». Un cambio limpio implica reproducir cada una de esas peculiaridades adaptándolas al comportamiento del nuevo proveedor, que difiere en aspectos que nadie ha documentado.

El presupuesto debe tener en cuenta la fase de funcionamiento paralelo: el proveedor antiguo y el nuevo funcionando simultáneamente, con una comparación de resultados, hasta que el equipo tenga la certeza de que el nuevo ofrece los mismos resultados. Esa fase suele ser más larga que la propia implementación. Los proyectos que no lo tienen en cuenta en su presupuesto implementan el nuevo proveedor y descubren las deficiencias la próxima vez que los datos de un cliente se enfrenten a un caso extremo.

Lo que se dice en la sala

Backend: «El nuevo SDK es mejor. Las llamadas básicas se realizan una al día cada una».

Entrada: «¿Y qué hay de los datos históricos que tienen en nuestro poder?»

SRE: «¿Vamos a tener ambos proveedores en funcionamiento al mismo tiempo o vamos a realizar la transición?»

Backend: «Su formato de webhook es diferente. Lo mismo ocurre con la autenticación».

Pregunta de control de calidad: «¿Cómo verificamos la equivalencia? ¿Comparando las respuestas a lo largo de una semana?»

Preguntas que conviene plantearse antes de votar

• ¿Hay datos históricos en el antiguo proveedor que debamos transferir a nuestra empresa?
• ¿Diferencias en la autenticación: claves API, OAuth, solicitudes firmadas?
• Webhooks: ¿se asignan los eventos de forma clara o es necesario traducirlos?
• Período de funcionamiento paralelo: ¿cuánto tiempo dura y qué se considera «suficientemente bueno» para realizar la transición?
• ¿Los límites de tarifa y el modelo de precios del nuevo proveedor serán iguales o diferentes?
• ¿Es posible dar marcha atrás si resulta que el nuevo proveedor es peor?

Las llamadas básicas son sencillas; lo complicado es la demostración de equivalencia. Si tanto la ejecución dual como el movimiento de datos son reales, eso ya es otra historia: separarlas y evaluar la verificación independientemente de la implementación.

Presupueste la ejecución dual y la comprobación de equivalencia. La API de aspecto limpio es la parte más económica.

Al igual que la estimación de una migración de base de datos, el código se ejecuta rápidamente y el trabajo reside en la implementación. Consulte los demás ejemplos prácticos de estimación, o inicie una sesión gratuita de «planning poker» una vez esbozado el plan de ejecución dual.