Contrato de integración
Qué datos circulan, en qué dirección, con qué frecuencia y cuál es la fuente de verdad de cada campo.
Solución
Integramos las plataformas que su operación ya usa para que el dato circule solo, en el momento adecuado y una sola vez — con gestión de fallos, reprocesamiento y registro de todo lo que pasó.
Qué datos circulan, en qué dirección, con qué frecuencia y cuál es la fuente de verdad de cada campo.
Consumo y publicación de APIs REST, con autenticación, versionado y límite de uso.
Webhooks y mensajería para que la información llegue en el momento en que ocurre.
Lo que falla no se pierde: entra en cola y se reprocesa con política de reintento.
Reglas para reconocer que dos fichas son la misma persona antes de duplicarla.
Rutina que compara ambos lados y señala la divergencia, en vez de esperar a que alguien la note.
Registro de cada mensaje intercambiado, con estado, intento y motivo del fallo.
Reenvío controlado de lo que falló, sin duplicar lo que ya entró.
La segunda columna es la que casi nadie publica. Existe porque un alcance con límite declarado es la única forma honesta de acordar precio y plazo.
Si uno de los sistemas está a punto de sustituirse, integrar ahora es construir sobre algo que se va. Si el volumen es de pocos registros por semana, la integración puede costar más que la digitación que sustituye. Y si los dos sistemas discrepan porque sus REGLAS de negocio son distintas, la integración no lo resuelve — solo propaga la divergencia más rápido.
Una integración de punta a punta entre dos sistemas con API madura suele llevar semanas, no meses. El plazo se dispara cuando la API del otro lado está mal documentada, es inestable o no existe — y eso se descubre en el diagnóstico, no a mitad del proyecto.
Calidad y estabilidad de las APIs implicadas.
Cuántas entidades hay que sincronizar (cliente, producto, pedido, factura).
Volumen y frecuencia de los intercambios.
Si la sincronización debe ser en tiempo real o por lotes.
Estado de los datos históricos en ambos lados.
Reglas de negocio divergentes entre los sistemas.
Una solución no es una caja aparte: es la aplicación de los mismos servicios a un problema concreto.
Una solución no se compra de catálogo. Empieza con un diagnóstico del proceso real, y solo después se convierte en alcance, plazo y propuesta.
Casi nunca. El tiempo real cuesta más, falla más y rara vez es lo que el negocio necesita. Preguntamos qué retraso es aceptable para cada dato — y buena parte de ellos tolera minutos u horas sin perjuicio alguno.
La integración se diseña asumiendo que va a ocurrir. Lo que no pasa entra en cola, se reintenta con espaciado creciente y genera alerta si persiste. Lo que no hacemos es prometer la disponibilidad de una API que no es nuestra.
Con cualquier sistema que ofrezca una forma documentada de intercambio. Cuando no hay API, evaluamos alternativas y decimos con claridad lo frágil que es cada una. Un sistema cerrado sin interfaz es un límite técnico real, no falta de voluntad.
Esa es la primera decisión del proyecto, no la última. Cada campo tiene una fuente de verdad declarada en el contrato de integración. Sin eso, la integración se convierte en una guerra silenciosa entre dos bases de datos.
En la mayoría de los casos, sí: la integración queda por fuera, consumiendo y publicando. Cuando hay que modificar algo dentro de uno de los sistemas, lo decimos antes de empezar.
El trabajo repetitivo sale de las manos de quien debería estar decidiendo.
Cambiar el motor con el coche en marcha — que es como ocurre de verdad.
IA que ejecuta dentro del proceso, con límite y registro.
Integración de Sistemas
La conversación inicial y el diagnóstico preliminar no tienen coste. Solo después llegan el alcance y la propuesta.