Una integración parece sencilla. El sistema A tiene los datos, el sistema B los necesita y una API se sitúa en medio. En una pizarra, es una sola flecha.
En la práctica, esa flecha es donde se esconde la mayor parte del trabajo. Este artículo trata de lo que cuesta realmente una integración, de por qué las estimaciones de este tipo de trabajo fallan tan a menudo y de lo que usted puede hacer antes de empezar un proyecto para que la cifra sea más fiable.
Qué es lo que paga
Cuando construimos una integración, la llamada a la API es la parte más pequeña. El coste está en todo lo que la rodea:
- Mapeo de datos. El registro de un cliente en un sistema rara vez coincide con el del otro. Los campos tienen nombres, formatos y reglas distintos. Alguien tiene que decidir qué significa cada campo y qué ocurre cuando no encaja.
- Autenticación. Las claves, los tokens y los permisos hay que configurarlos, guardarlos de forma segura y renovarlos sin que nada se rompa.
- Gestión de errores. Las redes fallan. Los servicios se caen. Las solicitudes se rechazan. Una buena integración sabe qué reintentar, qué poner en cola y qué comunicar a una persona.
- Límites y tiempos. Muchas API limitan la frecuencia con la que se las puede llamar. Trasladar un gran volumen de registros acumulados es un trabajo distinto de sincronizar un cambio cada vez.
- Supervisión. Necesita saber cuándo deja de funcionar la conexión, a ser posible antes que sus clientes.
- Cumplimiento normativo. Si los datos incluyen información personal o financiera, puede que necesite registros de auditoría, controles de acceso y un historial claro de quién cambió qué. Es aquí donde se encuentran el trabajo de integración y el software de cumplimiento.
Ninguno de estos puntos aparece en el diagrama de la flecha. Todos aparecen al construir.
Por qué fallan las estimaciones
La mayoría de los problemas de estimación en las integraciones tienen el mismo origen. La mitad del trabajo depende de un sistema que usted no controla.
Se desconoce el otro lado
Podemos estimar bien nuestro propio código. No podemos ver el interior del sistema de un proveedor. La documentación puede estar desactualizada, incompleta o no existir. Un comportamiento que la documentación describe de una manera puede funcionar de otra en producción. Hasta que alguien hace llamadas reales al servicio real, una parte de la estimación es una conjetura.
Los datos están más desordenados de lo esperado
Los registros de muestra parecen limpios. Los registros reales tienen duplicados, campos vacíos, formatos antiguos y valores que nadie recuerda haber añadido. Limpiar y conciliar esos datos suele ser la partida más grande, y es invisible hasta que se mira.
No hay entorno de pruebas
Algunos servicios ofrecen un entorno aislado (sandbox) donde se puede probar con seguridad. Otros no, o el sandbox se comporta de forma distinta al sistema real. Sin él, las pruebas llevan más tiempo y exigen más cuidado.
El alcance crece por los bordes
«Sincronizar pedidos» se convierte en «sincronizar pedidos, reembolsos, reembolsos parciales y pedidos cancelados que luego se restablecieron». Cada caso es razonable. Juntos pueden cambiar el tamaño del trabajo.
La API cambia más adelante
Los proveedores actualizan sus API y retiran versiones antiguas. Una integración no está terminada el día en que se pone en marcha. Necesita mantenimiento, y ese coste continuo debe formar parte del plan.
Cómo obtener una estimación fiable
Puede reducir mucho el margen antes de escribir una sola línea de código.
- Indique los sistemas y el sentido de los datos. ¿Qué sistema es la fuente de verdad para cada tipo de registro? ¿Los datos fluyen en un solo sentido o en ambos?
- Comparta datos de muestra reales. Una exportación pequeña, sin los datos sensibles, nos dice más que una descripción.
- Compruebe pronto el acceso a la API. Confirme que puede obtener las credenciales, un sandbox si existe y la documentación vigente.
- Enumere los casos límite que ya conoce. Devoluciones, pagos fallidos, cuentas fusionadas. Todo lo que su equipo resuelve hoy a mano.
- Decida qué ocurre cuando falla. ¿Debe el sistema reintentar en silencio, avisar a alguien o detenerse? Es tanto una decisión de negocio como técnica.
- Anote las normas de cumplimiento. Si un auditor o un regulador va a hacer preguntas sobre estos datos, dígalo desde el principio.
Elegir una forma de trabajar
Lo que se desconoce debe condicionar cómo paga el trabajo. Ofrecemos tres formas de trabajar, y cada una se adapta a un grado distinto de certeza.
| Forma de trabajar | Es más adecuada cuando |
|---|---|
| Precio fijo para un alcance definido | Los sistemas, los datos y los casos límite se conocen y están por escrito |
| Un equipo por meses | Hay varias integraciones, o el alcance seguirá cambiando a medida que aprenda |
| Un bloque mensual de horas con un tiempo de respuesta garantizado | La integración ya está en marcha y necesita mantenimiento continuo cuando cambian las API |
Un precio fijo solo funciona bien cuando el alcance está realmente definido. Si el otro sistema sigue siendo un misterio, forzar una cifra fija suele significar un precio inflado o un cambio doloroso más adelante. A menudo es mejor resolver primero las incógnitas y fijar el precio después.
Vea el rango de su proyecto
Nuestro estimador le da un rango de precio en minutos a partir de nuestra tarifa vigente. Muestra el coste de desarrollo, los costes mensuales, el esfuerzo por roles, el calendario y cada supuesto que hay detrás de la cifra. Lea con atención los supuestos. En una integración, ahí es donde verá qué se conoce y qué no.
Si desea hablarlo con nosotros, Atheron Network Labs está abierta a nuevos proyectos. Traiga su lista de sistemas y le diremos con claridad dónde está el riesgo.
