La mayoría de las empresas funcionan con varios sistemas que no se comunican entre sí. Su programa de contabilidad guarda las facturas. Su CRM guarda los clientes. Su web recibe los pedidos. Alguien copia los datos de uno a otro a mano, y la copia llega tarde o está mal.
Una integración es el software que hace que esos sistemas compartan datos por sí solos. Este artículo explica qué es una API, qué implica una integración, qué determina el coste y por qué las estimaciones de este tipo de trabajo fallan más a menudo que las de una aplicación nueva.
Qué es una API
Una API (interfaz de programación de aplicaciones) es un conjunto de reglas que publica un programa para que otros programas puedan comunicarse con él. En lugar de una pantalla para una persona, ofrece una puerta para un programa. Un programa pide los pedidos de un cliente, o le dice al otro que cree una factura, y la respuesta vuelve en un formato estructurado que una máquina puede leer.
La mayoría de los sistemas modernos tienen una. Las herramientas de contabilidad, los procesadores de pagos, las empresas de transporte, los CRM y las plataformas de marketing publican API. Algunas son buenas: documentación clara, comportamiento estable, un entorno de pruebas. Otras son escasas, están mal documentadas o cambian sin previo aviso. La calidad de la API del otro lado es el factor que más pesa en cuánto dura el trabajo, y usted no la controla.
Qué es una integración
Una integración es el código que se sitúa entre dos o más sistemas y usa sus API para mover datos. Tiene varias partes:
- Un disparador: un evento, como un pedido nuevo, o una programación, como cada hora
- Una correspondencia: el campo X del sistema A pasa a ser el campo Y del sistema B, con formatos, unidades y códigos convertidos
- Gestión de errores: qué ocurre cuando un sistema está caído, rechaza un registro o devuelve algo inesperado
- Registro y alertas: para que sepa qué se ha movido, qué no y por qué
La correspondencia parece la parte difícil. Normalmente no lo es. La gestión de errores es donde está la mayor parte del trabajo, y es la parte que más gente deja fuera del presupuesto.
Dónde encaja el cumplimiento normativo
Algunas integraciones existen porque una norma lo exige. Las declaraciones fiscales, las presentaciones de nóminas, los registros financieros y las comprobaciones de identidad vienen con reglas sobre qué datos deben moverse, adónde, en qué formato y qué constancia debe guardar de ello. Para esto construimos software de cumplimiento normativo: la integración más la pista de auditoría y los controles que la norma exige. El mecanismo es el mismo que el de cualquier otra integración. La diferencia es que el fallo tiene un coste legal, así que el registro y la gestión de errores deben ser más sólidos, y eso se nota en la estimación.
Qué determina el coste
Cuando definimos el alcance de una integración, hay unas pocas cosas que importan más que nada.
- Cuántos sistemas y en cuántas direcciones. Un solo sentido de A a B es lo más sencillo. La sincronización bidireccional, en la que cualquiera de los dos lados puede cambiar un registro, duplica aproximadamente la lógica y añade reglas para los conflictos.
- La calidad de cada API. Con una API documentada y con sandbox se trabaja rápido. Una sin entorno de pruebas, con límites de peticiones estrictos o con un comportamiento raro cuesta tiempo de exploración antes de escribir código de verdad.
- Volumen y ritmo. Unos pocos registros al día es un problema distinto de miles por minuto. El tiempo real es más difícil que un lote nocturno.
- Lo limpios que están los datos. Si dos sistemas guardan al mismo cliente con nombres y direcciones distintos, alguien tiene que decidir cuál es el correcto, y el código tiene que aplicar esa decisión.
- Qué debe pasar cuando algo falla. Reintentar, omitir, retener para revisión o detenerlo todo. Cada respuesta supone una cantidad de trabajo distinta.
Por qué fallan las estimaciones
Las estimaciones de integraciones fallan por motivos concretos.
El otro sistema no está bajo su control. En una aplicación nueva, el comportamiento lo fija su propio código. Una integración depende de software que construyó otra persona, y solo se sabe cómo se comporta de verdad al usarlo. La documentación describe lo que la API debería hacer. La realidad difiere en pequeños detalles, y cada diferencia cuesta tiempo.
Los casos límite se esconden en los datos antiguos. Los primeros cien registros pasan. El registro ciento uno tiene una fecha en un formato que nadie esperaba, o un campo que se reutilizó discretamente para otra cosa hace años.
El alcance crece campo a campo. ¿Podemos enviar también el código de descuento? Cada petición es pequeña. Diez de ellas son otro proyecto.
Nadie es responsable de las reglas de negocio. Cuando dos sistemas no coinciden, ¿cuál gana? Si nadie sabe responder, el desarrollador adivina, la suposición es errónea y se descubre en producción.
Probar es más difícil. No se puede probar a la ligera contra un sistema de contabilidad en producción. Si no hay sandbox, se construye un sustituto o se prueba con mucho cuidado contra el sistema real.
Cómo conseguir una estimación mejor
- Enumere todos los sistemas implicados y si cada uno tiene una API documentada y un entorno de pruebas
- Extraiga una muestra de datos reales, incluidos registros antiguos, no solo los recientes y limpios
- Decida qué sistema es la fuente de verdad para clientes, productos, pedidos y pagos
- Anote los casos de fallo y a quién hay que avisar
- Empiece con una dirección y un tipo de registro, y después añada el resto
Obtener una cifra
Nuestro estimador da un rango de precio en minutos a partir de la tarifa vigente. Muestra el coste de construcción, los costes mensuales, el esfuerzo por perfil, un calendario y todas las suposiciones que hay detrás de la cifra. Las suposiciones son lo que más importa en las integraciones, porque ahí es donde está el riesgo. Léalas y díganos cuáles son erróneas.
Los costes mensuales también importan aquí. Una integración nunca está del todo terminada. Las API cambian, los sistemas se actualizan y los datos se desvían. Un precio fijo funciona cuando los sistemas y el alcance se conocen. Un bloque mensual de horas, con un tiempo de respuesta garantizado, funciona para mantener la integración en marcha una vez que está en producción. Hacemos ambas cosas, y ahora mismo aceptamos proyectos.
