Qué es un middleware y cómo saber si tu negocio necesita uno

Una marca de calzado con 1.800 referencias factura unos 90.000 € al mes entre su tienda online y tres puntos de venta. El ERP es un Sage antiguo que el gestor no piensa tocar. La tienda es un PrestaShop. El almacén trabaja con un SGA que instaló el operador logístico. Y el TPV de las tiendas es de otro proveedor más. Cada uno de esos cuatro sistemas guarda el stock de la misma zapatilla. Ninguno de los cuatro habla el idioma de los otros tres.

Lo que suele pasar en ese escenario es que alguien —normalmente la persona de administración, a veces el propio dueño un domingo— exporta un CSV, lo abre en Excel, cambia cabeceras, y lo sube a mano. Dos veces por semana. Cuando se pone malo, no se sube. Y el lunes hay tres pedidos vendidos de un par que no existe.

El middleware es la pieza que hace ese trabajo sin que nadie abra Excel. Nada más. Y nada menos.

Qué es un middleware, sin metáforas raras

Middleware significa literalmente "software del medio". Es un programa que se sitúa entre dos o más sistemas y se encarga de tres cosas: recoger los datos de uno, transformarlos al formato que entiende el otro y entregarlos, comprobando que han llegado.

La palabra "traducir" es la que mejor lo describe. Tu ERP dice que la referencia ZAP-4471-38 tiene 12 unidades en el almacén 01. Tu tienda online no conoce esa nomenclatura: para ella ese producto es el ID 3402 con la combinación "talla 38", y no sabe qué es un almacén 01. Alguien tiene que hacer esa correspondencia. O la hace una persona, o la hace un middleware.

Si te han hablado de APIs en algún presupuesto, la relación es esta: la API es la puerta de cada sistema, el sitio por donde se entra a pedir o dejar datos. El middleware es quien llama a esas puertas, en el orden correcto, a la hora correcta, y se ocupa de qué pasa cuando una de ellas no abre.

Lo que hace un middleware que no hace un conector "a pelo"

Mucha gente ha pagado por una "integración" que era un script que corría cada noche y volcaba un fichero. Funciona seis meses. Luego el proveedor cambia una cabecera del CSV y el script deja de funcionar en silencio. Nadie se entera hasta que un cliente reclama.

Un middleware que merezca ese nombre hace, como mínimo, esto:

• Traducción de formatos y códigos. Mapea referencias, tallas, tarifas, códigos de impuesto, estados de pedido. Tu ERP llama al pedido "servido", la tienda lo llama "shipped" y el cliente quiere ver "enviado".
• Cola y reintentos. Si el ERP está caído a las 3:00 porque está haciendo el cierre, el mensaje no se pierde: se queda en cola y se reintenta a las 3:05, a las 3:15, a las 3:30.
• Idempotencia. Palabra fea, idea simple: que si el mismo pedido llega dos veces por un fallo de red, no se cree dos veces en el ERP. Es el error que más caro sale y el que más se olvida.
• Registro de todo. Poder mirar un pedido concreto y ver a qué hora entró, qué se le mandó al ERP, qué contestó el ERP y qué pasó después. Sin esto no puedes discutir con nadie de quién es la culpa.
• Alertas. Que alguien reciba un aviso cuando 40 mensajes llevan una hora atascados, en vez de enterarse por un cliente cabreado.

Puedes tener las cinco cosas sin llamarlo middleware. Lo importante no es la etiqueta, es que alguien se haya hecho cargo de los casos en los que las cosas salen mal, que son la mayoría de los casos interesantes.

Señales de que te hace falta uno

No hay un umbral limpio, pero sí hay síntomas bastante reconocibles. Si te ves en tres o más de estos, la conversación merece la pena:

1. Tienes tres o más sistemas que comparten los mismos datos. ERP, tienda, TPV, marketplace, almacén, facturación. Con dos sistemas suele bastar una conexión directa. A partir del tercero, el número de conexiones posibles crece rápido: tres sistemas son tres enlaces, cinco sistemas son diez. Ahí es donde el punto central deja de ser un lujo.
2. Alguien de tu equipo dedica horas semanales a mover datos a mano. Ponle número. Si son seis horas a la semana de una persona de administración, son unas 300 horas al año. A coste interno, entre 4.000 y 7.000 € anuales, según convenio y perfil. Y eso sin contar los errores.
3. El stock nunca cuadra y ya nadie se fía de ninguna cifra. Es el síntoma más común. Tiene su propia casuística y lo tratamos aparte en por qué tu stock nunca cuadra entre el ERP y la tienda online, pero el patrón es siempre el mismo: dos fuentes de verdad y nadie ha decidido cuál manda.
4. Vas a añadir un canal. Amazon, un marketplace vertical, una segunda tienda para otro país, un B2B para distribuidores. Si cada canal nuevo obliga a escribir otra conexión punto a punto contra el ERP, el ERP acaba con seis integraciones distintas colgando y nadie sabe cuál rompe qué.
5. Ya te ha pasado dos veces que un fallo pasó desapercibido varios días. Esto no es un problema de conexión, es un problema de visibilidad. Y la visibilidad es exactamente lo que aporta la capa intermedia.
6. Tu ERP es viejo o cerrado y no lo vas a cambiar. Muchos ERPs españoles de los que siguen funcionando estupendamente en 2024 no tienen API moderna: tienen una base de datos SQL, unos ficheros de intercambio y poco más. El middleware es lo que te permite dejarlo en paz y seguir creciendo por fuera.

El middleware no resuelve un problema de conexión. Resuelve un problema de gobierno: quién manda sobre cada dato y qué pasa cuando algo falla.

Señales de que estás matando moscas a cañonazos

Esta parte se cuenta menos, porque no la vende nadie. Hay casos claros en los que montar una capa intermedia es tirar el dinero:

• Solo tienes dos sistemas y existe un conector oficial. Si vendes en Shopify y facturas con Holded, y hay un conector nativo mantenido por uno de los dos, úsalo. Cuesta 30-60 € al mes y lo mantiene otro. Un desarrollo a medida solo se justifica cuando el nativo se queda corto en algo concreto que puedas nombrar.
• Mueves menos de 30 o 40 pedidos al día y el proceso es estable. Automatizar tiene coste fijo. Con volúmenes bajos, media hora diaria de una persona sale más barata que un sistema que hay que mantener, monitorizar y actualizar. Cambia cuando el volumen crece o cuando esa persona se va.
• El problema real es que tus datos maestros están sucios. Si tienes 3.000 referencias y 400 tienen el EAN mal o duplicado, el middleware no lo va a arreglar: va a propagar el desastre más rápido y a más sitios. Primero se limpia el catálogo. Es aburrido, no lo quiere hacer nadie, y es lo que toca.
• Estás a punto de cambiar el ERP o la plataforma. Construir una integración contra un sistema que sale en ocho meses es pagar dos veces. Aguanta con el proceso manual y monta la capa buena después.
• No tienes a nadie que pueda mirarlo. Un middleware sin dueño es una caja negra que un día deja de funcionar y nadie sabe entrar. Si no hay ni una persona interna ni un contrato de mantenimiento, mejor una herramienta de las que se configuran con el ratón.

Las tres formas de montarlo

No todo middleware es un desarrollo a medida. Hay un abanico bastante amplio y la elección depende más del volumen y de la rareza de tus reglas que del tamaño de tu empresa.

Las cifras son órdenes de magnitud de proyectos habituales en pymes españolas, no tarifas. Un middleware que sincroniza stock y pedidos entre un ERP y una tienda está más cerca del extremo bajo. Uno que además reparte inventario entre tiendas físicas y online con un solo stock, gestiona reservas y habla con dos transportistas, está en el alto.

Lo que cuesta de verdad y nadie te cuenta en la reunión

El precio de construirlo es la parte fácil de estimar. Lo que se sale de presupuesto suele ser otra cosa:

El mapeo inicial. Decidir qué campo de aquí corresponde a qué campo de allá, referencia por referencia, tarifa por tarifa, es trabajo tuyo, no del proveedor. Nadie de fuera sabe que la familia "OUTLET-2" en realidad no se debe publicar. En un catálogo de 3.000 referencias con variantes, esta fase se lleva entre dos y cuatro semanas de ida y vuelta. Cuenta con ello.

El mantenimiento. Los sistemas que conectas cambian. La plataforma actualiza su API una vez al año y deprecia la versión anterior. El transportista cambia el formato de la etiqueta. Reserva entre un 15 % y un 20 % del coste de construcción al año solo para que siga funcionando. Si el proveedor te dice que no hay mantenimiento, es que lo pagarás igual, pero por sorpresa.

Un sistema más que vigilar. Añades una pieza que puede caerse. Necesita su servidor o su servicio en la nube, su copia de seguridad y alguien que reciba las alertas. Si las alertas van a un correo que nadie mira, no tienes alertas.

Cómo decidirlo esta semana

Cuatro preguntas y una hoja de cálculo. No hace falta más para saber por dónde vas:

1. ¿Cuántos sistemas guardan el mismo dato? Escríbelos. Si son dos, busca conector nativo antes que nada. Si son cuatro o más, la capa central se paga sola en organización, aunque el ahorro de horas fuera cero.
2. ¿Cuál manda? Para cada dato —stock, precio, cliente, pedido— decide una única fuente de verdad. Si no puedes contestarlo, ese es tu proyecto de este mes, no el middleware.
3. ¿Cuántas horas al mes se van en mover datos, y cuánto cuesta un error? Un pedido vendido sin stock cuesta el envío, la gestión de la incidencia y a veces el cliente. Ponle un número aunque sea a ojo.
4. ¿Quién lo va a mirar cuando falle? Si la respuesta es "nadie", elige la opción más simple que puedas, aunque no sea la más elegante.

El error más caro que se ve en este terreno no es elegir mal la herramienta. Es montar la integración sin haber decidido antes quién manda sobre cada dato. Se puede migrar de Make a un servicio propio en unas semanas. Deshacer seis meses de stock corrompido en cuatro sistemas a la vez lleva bastante más.