Conectar dos aplicaciones suele ser relativamente sencillo; el problema aparece cuando ese enlace se convierte en una dependencia que debes mantener durante años y otras aplicaciones empiezan a depender de él. Un intercambio de datos aparentemente simple puede acabar convertido en una red de APIs, procesos batch, scripts y automatizaciones cuya lógica cuesta reconstruir. Por eso, cuando estudias cómo integrar un ERP con recursos humanos, facturación y almacén, la decisión importante no consiste únicamente en mover datos: necesitas controlar el acoplamiento, definir contratos y saber qué ocurrirá cuando una operación falle o un sistema cambie.
Además, el back office moderno rara vez vive dentro de una única aplicación. Puedes mantener las operaciones económicas en el ERP, la logística en un WMS y determinados procesos laborales en aplicaciones especializadas. Si utilizas una herramienta de control de horario laboral, por ejemplo, los marcajes, jornadas e incidencias pueden permanecer en ese dominio mientras RR. HH., nómina o el ERP reciben exclusivamente la información necesaria para sus propios procesos.
A partir de ahí aparece la ingeniería de integración de verdad. Hay que decidir cuándo basta una conexión directa, cuándo conviene exponer una API, en qué situaciones middleware o iPaaS aportan valor y cuándo los eventos permiten reducir dependencias. También veremos identificadores, idempotencia, reintentos, colas, Dead Letter Queues, observabilidad y seguridad. Dicho en lenguaje de programador: conseguir que el happy path funcione es el principio; diseñar lo que ocurre cuando todo deja de ser happy es lo que hace mantenible la arquitectura.
Antes de conectar sistemas: qué debe decidir la arquitectura del back office
Antes de elegir API, middleware, iPaaS o eventos, necesitas delimitar qué responsabilidad pertenece a cada aplicación, qué información puede publicar y qué dependencias aceptará el resto del ecosistema. La tecnología viene después. Una arquitectura mantenible comienza diseñando fronteras claras entre sistemas y reduciendo el conocimiento innecesario entre ellos.
El ERP no tiene que gobernarlo todo
Un ERP puede ocupar una posición central dentro del back office sin convertirse en propietario universal de cada dato y cada proceso. Esa distinción parece menor hasta que una empresa intenta personalizar el ERP para que gestione turnos, ausencias, picking, nómina, expediciones, fiscalidad y cualquier otro requisito que aparezca en una reunión de operaciones.
En algunos entornos esa concentración tiene sentido. En otros, una arquitectura best-of-breed resulta más razonable: cada dominio utiliza una aplicación especializada y las fronteras entre sistemas se convierten en contratos de integración.
Una distribución posible sería:
- ERP → operaciones económicas, pedidos, compras y contabilidad.
- RR. HH. → información laboral y administrativa del empleado.
- Gestión de tiempo → jornadas, marcajes e incidencias.
- WMS → ejecución física del almacén y expediciones.
- Aplicación de facturación → documentos fiscales cuando funciona como sistema separado.
- Sistema de nómina → cálculo y tratamiento de conceptos salariales.
Esta separación no debe interpretarse como una plantilla universal. La responsabilidad exacta depende del software instalado, de los procesos de la empresa y de qué sistema tiene capacidad real para modificar cada entidad.
Desde el punto de vista arquitectónico, lo útil es pensar en límites de dominio. Un WMS debería poder gestionar una expedición sin necesitar conocer las tablas internas de nómina. Del mismo modo, una aplicación de vacaciones no debería modificar directamente registros internos del ERP mediante consultas SQL improvisadas.
La idea recuerda a una vieja virtud de UNIX: cada componente resulta más manejable cuando su responsabilidad está delimitada y se comunica mediante interfaces conocidas. Un back office empresarial es bastante más caótico que una tubería de comandos UNIX, aunque el principio de reducir conocimiento innecesario sigue funcionando sorprendentemente bien.
Cuando analizas cómo integrar un ERP con recursos humanos, conviene comenzar por ese mapa de responsabilidades. Si decides primero la tecnología, puedes terminar diseñando la organización alrededor de las posibilidades del conector disponible en vez de diseñar la integración alrededor del proceso.
Qué información debe cruzar cada frontera
Integrar aplicaciones no significa replicar sus bases de datos completas. Cada consumidor debería recibir únicamente los atributos que necesita para ejecutar su responsabilidad.
Arquitectura de integración · intercambio de datos
Qué información mantiene, publica y consume cada sistema
Separar estas tres responsabilidades ayuda a entender qué aplicación conserva cada dato, qué información pone a disposición del resto y qué necesita recibir para completar sus procesos.
Mantiene Información gestionada directamente por el sistema.
Publica Datos o estados que pueden compartirse con otras aplicaciones.
Consume Información externa necesaria para completar su función.
| Sistema | Información que mantiene | Información que publica | Información que consume |
|---|---|---|---|
| RR. HH. | |||
| Gestión de tiempo | |||
| Nómina | |||
| ERP | |||
| WMS | |||
| Facturación |
Lectura técnica: distinguir entre datos que un sistema mantiene, publica y consume permite detectar solapamientos y dependencias antes de diseñar una integración. Si dos aplicaciones mantienen el mismo dato sin una responsabilidad clara, aumenta el riesgo de duplicados, versiones contradictorias y correcciones manuales.
El diseño mejora cuando cada frontera responde cuatro preguntas concretas:
- ¿Qué entidad cruza el límite?
- ¿Qué campos necesita realmente el consumidor?
- ¿Quién puede modificar esa información?
- ¿Cómo se comunica un cambio posterior?
Un empleado ofrece un buen ejemplo. El sistema de nómina puede necesitar identificador, situación laboral, determinadas fechas y conceptos retributivos. Eso no implica que deba recibir toda la ficha mantenida por RR. HH. Cuantos más detalles internos expongas, más posibilidades habrá de que un cambio en el sistema de origen obligue a modificar consumidores.
En ingeniería de software, esconder detalles de implementación lleva décadas evitando dolores de cabeza. Cambian los lenguajes, cambian los frameworks y cambia la forma de desplegar; el encapsulamiento sigue teniendo bastante buena salud.
API, integración directa, middleware o eventos: qué patrón elegir
La documentación de IBM describe distintos mecanismos para integrar un ERP y señala que la elección depende de factores como las aplicaciones implicadas, la infraestructura, las necesidades de escalabilidad y los recursos tecnológicos disponibles (IBM, 2024). Microsoft plantea una idea compatible desde la perspectiva de arquitectura: una integración puede requerir llamadas API directas, mensajería asíncrona, eventos u orquestación según las características del flujo (Microsoft, 2026).
La conclusión práctica es poco glamurosa y bastante útil: elige el patrón más sencillo que resuelva correctamente el problema que tienes. Meter un message broker distribuido para sincronizar un CSV diario puede resultar tan discutible como conectar veinte aplicaciones mediante scripts que escriben directamente en bases de datos ajenas.
Integración de sistemas · punto a punto
De una conexión sencilla a una red difícil de mantener
La integración punto a punto puede funcionar perfectamente cuando intervienen pocas aplicaciones, el intercambio es sencillo y los procesos cambian poco. La dificultad aparece cuando empiezan a multiplicarse las conexiones específicas entre sistemas.
- Pocas aplicaciones El número de relaciones que hay que mantener sigue siendo reducido.
- Intercambio sencillo Los datos que deben pasar entre aplicaciones están bien delimitados.
- Pocos cambios Interfaces y procesos permanecen suficientemente estables.
Qué ocurre cuando se añaden más sistemas
Este escenario supone que cada aplicación necesita conectarse directamente con todas las demás. Mueve el selector para visualizar cómo aumenta el número de relaciones que habría que mantener.
Con 2 sistemas: una única conexión directa mantiene el modelo muy simple.
El número mostrado corresponde únicamente al escenario en el que todos los sistemas necesitan una conexión directa entre sí.
Un caso en el que el punto a punto puede ser suficiente
Un ERP debe enviar una exportación diaria al sistema de nómina. Si ambos productos ofrecen interfaces estables y la empresa acepta una actualización programada, introducir una plataforma de integración completa puede añadir administración sin resolver un problema real.
Con cinco aplicaciones completamente interconectadas pueden existir hasta diez relaciones distintas entre pares. Con diez sistemas, el máximo sube a 45. No todas las arquitecturas alcanzan una malla completa, por supuesto, aunque la fórmula ilustra por qué las dependencias crecen con rapidez.
El inconveniente no está en el punto a punto como concepto. Aparece cuando cada conexión implementa por su cuenta:
- transformaciones;
- autenticación;
- reintentos;
- reglas de negocio;
- registros de auditoría;
- conversiones de identificadores.
En ese momento tienes varios pequeños programas de integración que conocen demasiado sobre sus vecinos. El clásico spaghetti code ha salido de la aplicación y ahora vive entre aplicaciones.
API como contrato entre aplicaciones
Una API puede entenderse como un contrato de comunicación. Define qué recursos se exponen, qué operaciones están permitidas, qué datos debe enviar el consumidor y qué respuestas puede recibir.
Una API empresarial suele especificar elementos como:
- endpoints;
- recursos;
- métodos;
- mecanismo de autenticación;
- campos obligatorios y opcionales;
- códigos de respuesta;
- versionado;
- límites de uso o rate limits.
Supongamos que el ERP publica:
GET /api/v2/pedidos/84321
El consumidor debería depender del contrato documentado de ese recurso, no de que internamente el ERP almacene pedidos en una tabla llamada sales_orders_v9_final_final.
Aquí aparece una pregunta útil:
- Si cambia la API del ERP, ¿qué aplicaciones pueden verse afectadas?
Si conoces la respuesta y puedes identificar cada consumidor, tienes una dependencia controlable. Si nadie sabe quién utiliza un determinado endpoint, el problema ya pertenece a la arquitectura y no al protocolo HTTP.
Un webhook puede complementar este enfoque cuando el consumidor necesita conocer cambios sin consultar continuamente la API. El sistema de origen realiza una llamada cuando ocurre un hecho determinado y el receptor procesa la notificación.
Middleware e iPaaS
El middleware introduce una capa intermedia entre aplicaciones. Una plataforma iPaaS —Integration Platform as a Service— ofrece capacidades similares mediante un servicio gestionado orientado a integraciones.
Estas capas pueden encargarse de:
- transformar JSON, XML, CSV u otros formatos;
- validar esquemas;
- enrutar mensajes;
- convertir identificadores;
- coordinar varias aplicaciones;
- programar sincronizaciones;
- aplicar reintentos;
- registrar comunicaciones.
Por ejemplo:
RR. HH.
|
v
Middleware
|----> Nómina
|----> ERP
`----> BI
El beneficio aparece cuando la lógica compartida deja de estar repetida dentro de cada conexión. El coste es igualmente real: has incorporado otro componente que necesita configuración, permisos, monitorización, versionado y conocimientos operativos.
Una iPaaS puede reducir mucho código de pegamento en determinados entornos empresariales. También puede concentrar una cantidad considerable de lógica y convertirse en un nuevo punto de dependencia si se utiliza como vertedero universal de reglas de negocio.
Arquitectura orientada a eventos
En una arquitectura orientada a eventos, una aplicación publica que algo ha ocurrido y otras aplicaciones interesadas reaccionan.
El modelo básico contiene:
Productor -> Evento -> Broker -> Consumidores
AWS describe productores, intermediarios de mensajes y consumidores como piezas habituales de una arquitectura orientada a eventos, donde la comunicación asíncrona ayuda a reducir dependencias directas entre dominios (AWS, 2023).
Imagina este evento:
vacaciones.aprobadas
La aplicación que gestiona la solicitud lo publica. Después pueden reaccionar varios consumidores:
vacaciones.aprobadas
|
+----> RR. HH.
|
+----> planificación
|
`----> nómina
El productor no necesita llamar directamente a tres APIs diferentes ni conocer todos los procesos que ocurrirán después.
Además, si una solicitud pasa a estado aprobado en un gestor de vacaciones, ese cambio puede publicarse como evento de dominio para que planificación, RR. HH. o nómina actualicen sus propios procesos sin consultar continuamente a la aplicación de origen.
Este patrón introduce consistencia eventual: durante un intervalo, distintos sistemas pueden reflejar estados ligeramente diferentes hasta que cada consumidor procese el evento. Si tu proceso exige que todos los sistemas confirmen el cambio antes de continuar, tendrás que diseñar otra estrategia.
Los eventos desacoplan, aunque también exigen operar infraestructura de mensajería, controlar esquemas, observar consumidores y saber qué hacer cuando un mensaje no puede procesarse.
Arquitectura de integración · selección de patrón
Qué patrón de integración encaja mejor en cada escenario
No existe un único patrón válido para todos los intercambios. La elección depende de la latencia admisible, el número de aplicaciones, la necesidad de desacoplamiento y la complejidad que la organización puede mantener.
¿Necesitas respuesta inmediata? Una API puede encajar mejor cuando la operación debe completarse al momento.
¿Hay muchos sistemas? Middleware o iPaaS puede reducir lógica repetida y centralizar la integración.
¿La latencia es aceptable? Batch puede simplificar procesos que no necesitan información en tiempo real.
| Patrón | Cuándo utilizarlo | Principal ventaja | Riesgo o límite |
|---|---|---|---|
|
Directo
Punto a punto |
Pocas aplicaciones y flujos sencillos. | Simplicidad inicial. | Las dependencias crecen al añadir conexiones. |
|
Síncrono
API |
Consulta o modificación directa con respuesta inmediata. | Contrato claro y control de operaciones. | Dependencia temporal del servicio y mantenimiento de versiones. |
|
Orquestación
Middleware / iPaaS |
Varias aplicaciones, transformaciones y orquestación. | Centraliza integración y reduce lógica repetida. | Añade una capa que debe gobernarse. |
|
Asíncrono
Eventos |
Cambios de estado con varios consumidores y necesidad de desacoplamiento. | Productor y consumidores pueden evolucionar con mayor independencia. | Más complejidad operativa y consistencia eventual. |
|
Por lotes
Batch |
Procesos que admiten latencia y trabajan por lotes. | Sencillez y eficiencia para grandes conjuntos. | Información menos actualizada. |
1. Latencia ¿El proceso necesita respuesta inmediata o puede esperar?
2. Acoplamiento ¿Cuánto deben depender unas aplicaciones de la disponibilidad de otras?
3. Operación ¿Qué nivel de complejidad de integración puede mantener realmente la organización?
Lectura técnica: elegir un patrón de integración no consiste en seleccionar la opción más sofisticada. Punto a punto, API, middleware, eventos y batch resuelven problemas distintos. La decisión debe equilibrar inmediatez, desacoplamiento, número de aplicaciones y esfuerzo operativo, evitando introducir más infraestructura de la que el proceso necesita.
Cómo diseñar flujos fiables entre RRHH, nóminas, ERP y almacén
Aquí es donde una arquitectura que parecía limpia en PowerPoint se encuentra con la realidad del lunes por la mañana.
Las redes fallan. Las APIs devuelven errores. Un sistema tarda más de lo previsto. Un proceso se reinicia después de haber procesado un mensaje, pero antes de confirmar su recepción. Alguien despliega una nueva versión del ERP y un campo que antes era obligatorio pasa a comportarse de otra forma.
Diseñar el camino correcto implica asumir que esas situaciones ocurrirán.
Identificadores y contratos de datos
Considera un empleado llamado internamente mediante tres identificadores:
RRHH_ID = EMP-1844
NOMINA_ID = 73291
ERP_ID = WORKER-09818
Los tres pueden representar a la misma persona.
No es obligatorio que todas las aplicaciones compartan una única clave universal. Lo que sí necesitas es una forma fiable de saber qué identificadores corresponden a la misma entidad.
Ese mapeo puede mantenerse mediante una tabla de correspondencias, un servicio específico o mediante identificadores externos almacenados en cada sistema. La elección dependerá del stack.
El contrato debería definir además:
- nombre y tipo de cada campo;
- campos obligatorios;
- campos opcionales;
- formatos de fecha;
- unidades;
- estados admitidos;
- versión del esquema.
Supón que horas_trabajadas cambia de entero a decimal. Un consumidor que daba por hecho un entero podría fallar o truncar información. El versionado permite introducir modificaciones sin obligar a que cada sistema cambie exactamente al mismo tiempo.
Idempotencia y duplicados
Una operación es idempotente cuando repetirla produce el mismo estado final que ejecutarla una sola vez.
Ejemplo:
Evento recibido:
vacaciones.aprobadas
solicitud_id = VAC-7341
Si el mensaje llega dos veces, la segunda recepción no debería crear otra ausencia.
Una estrategia sencilla consiste en registrar un identificador único de operación:
idempotency_key = VAC-7341-APPROVED
Antes de ejecutar el cambio, el consumidor comprueba si ya procesó esa clave.
La idempotencia resulta especialmente útil porque los reintentos son habituales en sistemas distribuidos. Si una petición devuelve timeout, el emisor puede no saber si el receptor falló antes de ejecutar la operación o si la ejecutó y la respuesta se perdió durante el camino.
Sin idempotencia, reintentar una operación de reserva, facturación o actualización puede introducir duplicados.
Reintentos, colas y Dead Letter Queue
Imagina esta secuencia:
- RR. HH. publica una jornada consolidada.
- El sistema de nómina está temporalmente fuera de servicio.
- El mensaje permanece almacenado.
- La infraestructura intenta entregarlo de nuevo.
- Los nuevos intentos siguen fallando.
- Después de superar el umbral configurado, el mensaje pasa a una Dead Letter Queue.
- Se genera una alerta.
- Un proceso automático o un operador analiza la causa y recupera el mensaje.
Una Dead Letter Queue (DLQ) es una cola destinada a mensajes que no han podido procesarse después de los intentos previstos.
La DLQ evita dos extremos poco saludables: perder silenciosamente la operación o reintentar sin límite un mensaje defectuoso que nunca podrá procesarse.
También debes decidir cómo espaciar los reintentos. Repetir cien peticiones por segundo contra una API caída no acelera la recuperación; suele conseguir que el receptor tenga todavía más trabajo pendiente cuando vuelva.
Un detalle importante: la DLQ tampoco debería convertirse en /dev/null con interfaz gráfica. Si nadie revisa sus mensajes, has aplazado la pérdida de información en vez de resolverla.
Tiempo real frente a procesamiento por lotes
«Tiempo real» suena mejor en una demo comercial. Arquitectónicamente, no siempre es la elección adecuada.
Cada flujo tiene una tolerancia diferente a la latencia.
Integración de sistemas · frecuencia de intercambio
No todos los flujos necesitan actualizarse con la misma frecuencia
La cadencia de integración puede variar según el proceso: algunos intercambios requieren una actualización inmediata o casi inmediata, mientras que otros pueden ejecutarse de forma periódica, programada o por lotes.
- Inmediata Flujos que necesitan propagarse con muy poca demora.
- Periódica o programada Intercambios que pueden actualizarse en momentos definidos.
- Batch Procesamiento agrupado por lotes.
| Flujo | Frecuencia orientativa |
|---|---|
| Reserva de stock | Inmediata o casi inmediata |
| Confirmación de expedición | Inmediata o casi inmediata |
| Jornada consolidada | Periódica |
| Nómina | Batch |
| BI o reporting | Programada |
Lectura técnica: diseñar una integración no implica convertir todos los intercambios en tiempo real. Reserva de stock y confirmación de expedición pueden necesitar una cadencia muy corta, mientras que jornada, nómina o reporting admiten otros ritmos. La frecuencia debe definirse según la necesidad real de cada flujo.
Son ejemplos de diseño, no reglas universales.
Una reserva de inventario puede necesitar propagarse en segundos para evitar vender unidades inexistentes. La liquidación mensual de nómina puede ejecutarse mediante un proceso programado que reúne información previamente validada.
La integración batch también puede ser más fácil de auditar y recuperar cuando se procesan grandes conjuntos. El tiempo real aporta actualidad; a cambio, aumenta las dependencias temporales y la necesidad de gestionar fallos durante el flujo.
Una arquitectura madura no persigue la latencia mínima por principio. Busca la latencia que el proceso realmente necesita.
Qué hace mantenible una integración cuando cambia el back office
La mantenibilidad se pone a prueba cuando algo cambia.
Puede cambiar el ERP. Puede aparecer un nuevo sistema de nómina. El proveedor del WMS puede publicar una API distinta. Un requisito fiscal puede modificar la información intercambiada con facturación.
Si toda la arquitectura presupone que cada aplicación permanecerá intacta durante diez años, has diseñado sobre una condición bastante optimista.
Observabilidad y trazabilidad
Los logs responden a preguntas concretas sobre ejecuciones. Las métricas muestran comportamientos agregados. Las alertas avisan cuando una condición merece atención. Los identificadores de correlación permiten seguir una operación mientras atraviesa distintas aplicaciones.
Imagina la incidencia: La nómina del empleado EMP-1844 no ha recibido sus horas.
Una arquitectura observable debería permitir reconstruir algo parecido a esto:
correlation_id = 5f92c1
10:02:14 Gestión de tiempo
jornada consolidada
10:02:15 Middleware
validación correcta
10:02:16 Cola
mensaje publicado
10:02:18 Nómina
respuesta 422
campo centro_coste no válido
En lugar de abrir cuatro tickets con cuatro proveedores para preguntar «¿lo tenéis vosotros?», puedes localizar la frontera donde apareció el fallo.
La observabilidad convierte una integración distribuida en algo inspeccionable mientras está funcionando.
Conviene registrar información suficiente para reconstruir la operación sin almacenar indiscriminadamente datos personales o secretos en logs. El equilibrio entre trazabilidad y exposición de información también forma parte del diseño.
Seguridad entre aplicaciones
Una integración es otro cliente accediendo a recursos empresariales y debería tratarse como tal.
NIST establece en su arquitectura Zero Trust que la autenticación y la autorización deben evaluarse explícitamente y que la confianza no debe derivarse únicamente de que un recurso se encuentre dentro de la red corporativa (NIST, 2020).
Aplicado al back office, esto implica que las conexiones deberían trabajar con:
- credenciales identificables;
- permisos limitados;
- secretos almacenados fuera del código;
- autenticación apropiada;
- auditoría;
- caducidad y rotación cuando proceda.
También puede utilizarse RBAC, siglas de Role-Based Access Control o control de acceso basado en roles. Este modelo asigna permisos según funciones definidas.
Si una integración necesita consultar empleados, eso no significa automáticamente que deba poder modificar contratos, eliminar registros y acceder a cualquier recurso de RR. HH.
El principio de mínimo privilegio reduce el impacto de una credencial comprometida y ayuda a documentar qué puede hacer realmente cada integración.
Y sí: una contraseña escrita directamente dentro de integration_final_v3.py sigue siendo una contraseña escrita dentro del código, aunque el fichero esté en un repositorio privado.
Desacoplamiento y sustitución de aplicaciones
Hay una pregunta particularmente útil para medir el acoplamiento: Si mañana sustituyes el WMS, ¿cuántas integraciones necesitas modificar?
Supón este diseño:
ERP --------> WMS
CRM --------> WMS
Ecommerce --> WMS
BI ---------> WMS
Compras ----> WMS
Si cada consumidor conoce detalles específicos de la API del WMS, sustituirlo puede exigir modificar cinco integraciones.
Ahora imagina que determinadas comunicaciones pasan por un contrato estable:
ERP --------\
CRM ---------\
Ecommerce ----> Contrato logístico ---> WMS
BI ----------/
Compras -----/
El nuevo WMS deberá adaptarse al contrato o necesitarás modificar el adaptador correspondiente. El resto del ecosistema puede conservar gran parte de sus dependencias.
Eso no significa que una capa intermedia siempre mejore la arquitectura. Para dos sistemas sencillos podría introducir complejidad innecesaria.
El objetivo tampoco es alcanzar «acoplamiento cero». Dos aplicaciones que intercambian información mantienen alguna dependencia por definición. Lo razonable es saber qué dependencia existe, dónde está documentada y cuánto cuesta cambiarla.
Arquitectura de integración · revisión técnica
Checklist para revisar una arquitectura de integración
Antes de incorporar otra aplicación al back office, revisa si la arquitectura permite identificar contratos, rastrear operaciones, gestionar errores y mantener las integraciones sin extender dependencias innecesarias.
Progreso de revisión
0 de 10 puntos revisadosRevisión pendiente: marca cada punto a medida que compruebas la arquitectura.
Lectura técnica: una integración mantenible no depende únicamente de que los datos lleguen a destino. Contratos claros, identificadores rastreables, reintentos seguros, idempotencia, alertas, separación de credenciales y responsabilidades documentadas ayudan a entender qué sucede cuando un flujo funciona y, sobre todo, cuando falla.
Diseñar para el día en que algo falle o cambie
Cuando intentas resolver cómo integrar un ERP con recursos humanos, facturación y almacén, el diagrama inicial representa una parte pequeña del trabajo. La calidad arquitectónica aparece en los detalles: contratos versionados, identificadores rastreables, operaciones idempotentes, reintentos seguros, colas recuperables y telemetría suficiente para entender qué ocurrió.
También conviene aceptar que la complejidad debe ganarse. Dos aplicaciones estables pueden comunicarse directamente durante años sin mayores dramas. Cuando el ecosistema crece, aparecen múltiples consumidores o necesitas cambiar componentes con independencia, middleware, APIs desacopladas y eventos pueden justificar su coste operativo. La referencia aportada de Anthropic sobre agentic coding y el retorno persistente de la experiencia técnica encaja aquí como marco general: generar código de integración más rápido no elimina la necesidad de entender qué dependencias estás creando (Anthropic, s. f.).
Antes de añadir otra aplicación al back office, utiliza la checklist anterior y responde cinco preguntas: qué información producirá, quién la consumirá, mediante qué contrato circulará, qué ocurrirá cuando falle y cómo podrás reconstruir el recorrido después. Si esas respuestas están claras, la arquitectura tiene muchas más probabilidades de sobrevivir al siguiente cambio de ERP, WMS o proveedor sin convertirse en una excavación arqueológica de scripts olvidados.
Referencias consultadas:
- Amazon Web Services. (2023). Best practices for implementing event-driven architectures in your organization. AWS Architecture Blog.
- Anthropic. (s. f.). Agentic coding and persistent returns to expertise.
- IBM. (2024). What is ERP integration? IBM Think.
- Microsoft. (2026). Get started with integration architecture design. Microsoft Learn, Azure Architecture Center.
- National Institute of Standards and Technology. (2020). Zero Trust Architecture (NIST Special Publication 800-207). U.S. Department of Commerce.
