Best of Breed y ESB: el mejor software para cada área… y todos los marrones de integración que vienen detrás

01 Best of Breed: estupendo para el negocio, bastante menos sencillo para la DSI

Tomemos un ejemplo muy concreto: la gestión de la flota de vehículos. Habéis encontrado un programa especializado magnífico. Al responsable de la flota le encanta. Gestiona vehículos, tarjetas de combustible, contratos, empresas de renting, talleres, kilometrajes y probablemente la presión del neumático trasero izquierdo del Clio de Michel. Muy bien. Ahora, vuestro responsable de flota necesita conocer a los empleados de la empresa.

No vais a pedirle que cargue manualmente todos los días un archivo con la lista de empleados. También necesita conocer sus ausencias, por ejemplo para detectar un uso anómalo de las tarjetas de combustible durante las vacaciones. Puede necesitar datos contables. Y la propia aplicación puede estar conectada con empresas de renting, talleres y otros proveedores. El famoso «mejor software del mercado» termina poco a poco en medio de una telaraña.

Por supuesto, existe otra solución. Podéis contratar personas para introducir datos sin parar. Funciona. Con algunos errores de tecleo, información actualizada tres días tarde, archivos Excel circulando por correo, extracciones manuales y gente que empieza el día importando quince CSV. Personalmente, no es precisamente lo que me hace soñar.

Sobre todo porque el parque de aplicaciones cambia constantemente. Llega un programa, desaparece otro, un tercero cambia de proveedor y un cuarto decide de repente que su API v1 está obsoleta y que deberíais pasar a la v3 antes del viernes. Bienvenidos al Best of Breed.

02 Ahora hay que conseguir que todo esto se comunique

Una vez definida la visión Best of Breed, necesitábamos una solución técnica para comunicar las distintas aplicaciones. Así empezamos a interesarnos por los ESB. Un ESB, siglas de Enterprise Service Bus, es una plataforma de integración que permite centralizar y orquestar los intercambios entre diferentes aplicaciones. En lenguaje humano:

Recoge un dato en algún sitio, puede transformarlo y después lo envía a otro lugar.

Evidentemente, un ESB hace bastante más: orquestación, supervisión, gestión de errores, transformaciones, conectores, llamadas API, procesamiento asíncrono, etc. Pero si estáis empezando, quedaos primero con esa frase.

03 ¿Por qué no desarrollarlo nosotros mismos?

En aquella época teníamos un equipo interno de unos cuatro desarrolladores. Técnicamente, nada nos impedía desarrollar nuestros propios flujos. Un servicio en .NET, Java, Python o cualquier tecnología que dominara el equipo podía recuperar los empleados de una aplicación y enviarlos a otra. Así que hicimos I+D. Y, como cualquier buen equipo de desarrollo al que se pregunta si es mejor comprar una solución o construirla, tuvimos unos debates especialmente tranquilos y moderados.

Por supuesto.

Pero nuestra principal preocupación no era implementar el flujo.

Hacer un flujo es relativamente sencillo. Hacer uno que siga funcionando durante diez años es otra historia. Cuando el sistema falla, hacen falta logs. Hay que saber qué dato ha fallado. Hay que poder reprocesarlo. Hacen falta alertas, correos o notificaciones. Hay que supervisar el sistema. Y hay que entender seis meses después por qué Michel añadió aquella condición tan improbable al código. Sobre todo, todo debe seguir funcionando cuando Michel dimita, cambie de departamento o se jubile.

Podéis desarrollar un flujo en tres días y dedicar después diez años a su MCO, es decir, a mantenerlo operativo. Ahí es donde una solución especializada empieza a tener mucho sentido: estandarizar cómo se desarrollan, supervisan y mantienen los flujos. Aquel estudio se realizó hace unos cuatro años. Y hoy introduciría un matiz importante.

Con la evolución tan rápida de las herramientas de desarrollo asistido por IA y del vibe coding, no estoy seguro de recomendar automáticamente la misma arquitectura si tuviera que empezar desde cero. Con un buen equipo de desarrollo y agentes capaces de analizar el código, mantener documentación, generar pruebas y supervisar una arquitectura moderna, desarrollar una plataforma de integración propia vuelve a ser una pregunta interesante. Todavía no tengo una respuesta definitiva.

Pero tanto si compráis un ESB como si desarrolláis vuestra plataforma, la necesidad sigue existiendo. Hace falta una capa de integración.

04 Nuestra elección: Phoenix de Blueway

Una vez identificada la necesidad, estudiamos varias soluciones. Finalmente elegimos Phoenix de Blueway. Desde entonces, Blueway ha sido adquirida por SoftProject. Había varios aspectos que nos gustaron. Primero, las capacidades para desarrollar flujos. Después, la facilidad de aprendizaje. Y también algo que puede parecer secundario y que, visto con perspectiva, no lo era: todo se hacía desde la misma interfaz web. Habíamos estudiado otras soluciones con:

• un cliente de escritorio para desarrollar;
• otra interfaz para desplegar;
• un portal web para explotación;
• y otra herramienta más para administración.

Seguramente funcionan muy bien en organizaciones grandes. Pero para un equipo de integración de menos de cinco personas, teníamos sobre todo la impresión de que íbamos a multiplicar las herramientas y, por tanto, la complejidad. Phoenix parecía mucho más adaptado al tamaño de nuestro equipo. El presupuesto también importaba, naturalmente. Porque, al contrario de lo que parecen pensar algunos comerciales, no todos tenemos una mina de litio debajo del departamento de informática.

05 Ahora toca convertir a vuestros desarrolladores en integradores

Y aquí empieza una fase especialmente divertida. Tendréis que explicar a vuestros desarrolladores que ahora son integradores. Van a pasar de su IDE favorito a una especie de interfaz low-code. Y probablemente les parecerá absolutamente horrorosa. Es normal. Pasan de una libertad casi total a ir haciendo clic en botones. Antes:

«Voy a hacer un bucle, una clase, dos funciones, un pequeño objeto intermedio y resolverlo exactamente como quiero».

Ahora:

«¿Cómo que tu cacharro solo tiene un bucle WHILE?».

Observaréis varias fases. Negación. Ira. Negociación. Ganas de reescribir el ESB durante la pausa de la comida. Y quizá alguna dimisión. En cierto modo, esa frustración es una buena señal. Significa que tenéis verdaderos desarrolladores y que les gusta su profesión. La sensación se parece a la de un pájaro al que acabáis de meter en una jaula.

«¿Por qué ya no puedo hacer lo que quiero?»

Después pondrán su primer flujo en producción. Seis meses más tarde descubrirán que, si no hicieron demasiado mal el análisis y el diseño, apenas han tenido que tocarlo. Y entonces suele llegar esto:

«Bueno… al final no está tan mal».

06 Antes de integrar nada: cambiad las reglas

Al adoptar esta lógica también tuvimos que imponer algunas reglas en la empresa. Si un área de negocio quiere comprar un programa nuevo, debe consultar a la DSI. Bueno… en teoría. Sobre todo, decidimos que la DSI necesitaba un auténtico derecho de veto técnico. Un software puede ser excepcional desde el punto de vista funcional y un desastre absoluto de integrar. Un usuario os dice:

«Es genial, hace exactamente todo lo que necesitamos».

Y entonces preguntáis:

«¿Tiene API?».

Silencio.

«¿Exportación automática?».

Silencio.

«¿Webhooks?».

Más silencio.

«¿Documentación técnica?».

El comercial mira al techo. Y poco a poco entendéis que su famosa «integración completa con vuestro sistema de información» consiste en dejar un Excel en un FTP cada domingo a las dos de la mañana.

07 Sí, he desarrollado una ligera obsesión por las API

Algunos os dirán que los archivos planos funcionan perfectamente. Tienen razón. Otros os dirán que SOAP sigue funcionando. También tienen razón. Personalmente, cuando es posible, prefiero trabajar con API HTTP modernas, generalmente REST/JSON u OData según la solución. Es una decisión de arquitectura. Y seguramente también un capricho del técnico que llevo dentro. Ya que voy a poner en marcha una integración nueva, prefiero empezar con una tecnología ampliamente utilizada, documentada y fácil de manejar.

Eso no significa que REST sea mágico. Tampoco significa que un CSV sea necesariamente malo. Además, no os vais a librar de ellos. Siempre habrá archivos planos. Los archivos SEPA, por ejemplo. Algunos intercambios bancarios. Socios que no ofrecen otra opción. Sistemas antiguos cuyo servidor nadie se atreve a tocar porque cuentan que alguien lo reinició en 2007 y tardó tres días en volver. Pero para objetos de negocio como:

• empleados;
• clientes;
• proveedores;
• presupuestos comerciales;
• pedidos;
• facturas;

si existe una API seria, la elegiré de forma natural.

08 Por qué prefiero el tiempo real o casi real

Durante muchísimo tiempo, muchas interfaces se ejecutaban de noche. Y sigue ocurriendo. El proceso empieza a la una. Algo falla a las 2:17. Si el desarrollador original hizo bien su trabajo, se habrá enviado una alerta. Si no, a las 9:04 una contable abre un ticket:

«Buenos días, ¿dónde están mis facturas?».

Y ya estamos otra vez. Antes también había que encajar estos procesos en las ventanas de copia de seguridad, especialmente cuando las bases de datos se respaldaban en frío. El desarrollador negociaba su horario con infraestructura. Infraestructura decía que no. El desarrollador insistía. Infraestructura seguía diciendo que no. Y, en algún lugar intermedio, una factura intentaba desesperadamente cambiar de aplicación. Hoy, siempre que se puede, prefiero trabajar en tiempo real o casi real. Unos segundos. Unos minutos.

Tiene varias ventajas: datos recientes, carga más repartida e información actualizada para los usuarios. Y, sobre todo, cuando aparece un problema, vuestro equipo probablemente sigue en la oficina. Resulta bastante más agradable corregir un fallo a las 14:32 que descubrir a las siete de la mañana que no se han cargado 60.000 filas durante la noche.

09 El archivo de 40.000 filas que falla por un punto y coma

Los procesos basados en archivos tienen otra característica especialmente agradable. Recibís 40.000 filas. De ellas, 39.999 son perfectas. Pero Gérard ha conseguido meter un punto y coma en una descripción sin que nadie hubiera previsto el caso. O un carácter de escape. O una etiqueta XML sin cerrar. O un retorno de carro incomprensible. Y a veces:

¡BUM!

Se rechaza todo el archivo. Una arquitectura API que procesa los eventos individualmente suele permitir aislar los errores mucho mejor. ¿Un dato da problemas? Ese dato falla. Los demás siguen su camino. Evidentemente, no es una propiedad mágica de las API: podéis construir perfectamente una API batch que rechace 10.000 objetos porque el número 8.542 es incorrecto. Pero en nuestra arquitectura intentamos, siempre que podemos, construir flujos unitarios o con una gestión de errores suficientemente detallada.

10 Y ahora: bienvenidos al mundo de los webhooks

Vuestros antiguos desarrolladores, convertidos en integradores de forma más o menos voluntaria, tendrán que aprender un vocabulario nuevo. En particular, los webhooks. Un webhook permite que una aplicación avise automáticamente a otra cuando ocurre un evento. Por ejemplo, se modifica un empleado en el software de RR. HH. En lugar de que el ESB consulte la API cada cinco minutos:

«¿Hay algo nuevo?».

«No».

«¿Y ahora?».

«Sigue sin haber nada».

«¿Y ahora?».

la aplicación de RR. HH. llama directamente a una URL que le habéis proporcionado:

https://monentreprise.com/webhook

El mensaje puede limitarse a decir:

«Se ha modificado el empleado 123456».

El ESB puede recibir esa información, depositarla temporalmente en una cola de mensajes o Data Queue y, unos segundos o minutos después, hacer un GET a la API para recuperar los datos completos. Es muy práctico. Y cambia considerablemente la manera de pensar las interfaces.

11 GET, POST, PUT, PATCH, DELETE… bienvenidos a las API

El equipo también tendrá que dominar los principales métodos HTTP.

Bueno, el nombre ya da una pista sobre este último. Después descubriréis que la teoría y la realidad de las API son mundos diferentes. Algunos proveedores han hecho las cosas con inteligencia. Otros, bastante menos. Para modificar un dato, algunos os obligan a:

1. hacer un GET;
2. recuperar el objeto entero;
3. modificar vuestro campo;
4. enviar un PATCH.

Otros han previsto un upsert que permite, con una sola llamada, crear el recurso si no existe o actualizarlo si ya existe. Hay convenciones. Buenas prácticas. Estándares. Y luego está lo que el desarrollador del proveedor decidió hacer el martes por la mañana. Aprenderéis a convivir con ambas cosas.

12 OAuth y el maravilloso mundo de los Bearer Tokens

Después llegarán OAuth, los Client ID, los secretos, los scopes, los tokens, los refresh tokens y los Bearer Tokens. Y a veces documentación que explica durante cinco páginas cómo obtener un token sin deciros realmente qué URL hay que llamar. También forma parte del oficio. Y si el equipo está descubriendo las API, proporcionadle las herramientas adecuadas.

13 Postman se convierte rápidamente en vuestro mejor amigo

Para empezar a trabajar con una API, una herramienta especializada es prácticamente indispensable. Personalmente, utilizo mucho Postman. Hay alternativas, como Insomnia, Bruno o Hoppscotch. Pero Postman sigue siendo muy práctico durante las fases de análisis e integración. Permite organizar las llamadas en carpetas, crear entornos, guardar variables, probar rápidamente un GET, hacer un POST, modificar un payload y entender por qué se rechaza vuestro JSON. Y volver tres semanas después al mismo proyecto preguntándoos:

«¿Por qué hice seis versiones de esta llamada?».

Cuando seleccionéis una solución, pedid siempre la documentación de la API. Lo ideal es una especificación OpenAPI / Swagger. Si el proveedor está realmente organizado, también entregará un documento que relacione:

• el nombre del campo en la interfaz;
• su nombre técnico en la API.

Parece una tontería. Pero cuando «Centro de adscripción» se llama org_unit_ref_02 en la API, agradecéis muchísimo tener ese documento.

14 Comprar software estándar también significa dejar de personalizarlo todo

Los usuarios también deben cambiar algunas cosas. Si la estrategia de la empresa es dejar de desarrollar aplicaciones a medida para comprar soluciones del mercado, hay que aceptar las consecuencias de esa decisión. Compráis un producto estándar. No compráis un equipo de desarrollo dedicado a vuestra empresa. En preventa, algunos proveedores os ofrecerán:

«Ningún problema, eso os lo personalizamos».

Cuidado. No siempre es una buena noticia. Si la solución se diseñó desde el principio para admitir extensiones limpias y mantenibles, perfecto. Pero si personalizar significa crear una rama específica del software solo para vosotros, puede que estéis fabricando vuestro próximo desastre industrial.

El proveedor quiere vender. Es normal. Al principio todo funciona. Luego llega la siguiente versión y vuestra personalización deja de ser compatible. O se ha marchado el equipo que la desarrolló. O nadie sabe por qué existe esa rama. Mientras tanto, desde la DSI habéis seguido haciendo creer a los usuarios que pueden conservar el mismo nivel de desarrollo a medida que antes. No es coherente. En algún momento, el director de sistemas también tiene que defender la visión:

Hemos decidido comprar software estándar, y eso implica a veces adaptar ligeramente nuestra manera de trabajar al programa.

Si no, mejor seguir desarrollándolo nosotros mismos.

15 Primer proyecto real: empieza el billar a tres bandas

Bien. Habéis elegido el ESB. Habéis elegido el software nuevo. El proyecto empieza. Un usuario viene a veros:

«Necesito tener los pedidos en la aplicación».

Fácil. Claro. Coges el dato de allí y lo pones aquí. Sencillo, ¿no? Abrís la documentación de la API. Primera pregunta:

¿Existe siquiera un endpoint para crear un pedido?

Sí. Victoria. Segunda pregunta:

¿Qué datos necesita realmente el usuario?

El número de pedido. El proveedor. Las líneas. El importe. La obra. El centro. El comprador. El contrato. El color favorito del director financiero. En fin. Preparáis la lista. Volvéis a la documentación de la API y descubrís que faltan tres campos. O que uno existe, pero solo es de lectura. O que está en la interfaz, pero no en la API. Bienvenidos.

16 Y aquí empiezan las verdaderas preguntas de integración

Hay que controlar la longitud de los campos. El ERP puede permitir 100 caracteres y el software de destino solo 50. Muy bien. ¿Quién decide qué se recorta? Hay que cargar datos de referencia. El pedido referencia un centro que la aplicación de destino todavía no conoce. Después, ese centro referencia una sociedad. Y esa sociedad también debe existir previamente. Poco a poco descubrís una idea fundamental de un sistema integrado:

¿Qué sistema es maestro de cada dato?

Y, por tanto:

¿Qué sistema es esclavo?

Aquí empiezan los esquemas. Porque llega un momento en que mantener todo el sistema de información dentro de vuestra cabeza resulta algo complicado.

17 Y, por supuesto, las fechas tienen formatos distintos

Abrís Postman. Intentáis la primera inserción. Error. Volvéis a intentarlo. Error. Revisáis el payload y descubrís que el ERP entrega:

18/09/2026

mientras la API espera:

2026-09-18T00:00:00Z

Estupendo. Durante la formación del ESB nadie os enseñó a transformar una fecha. Y justo entonces entendéis que:

«Coges el dato de allí y lo pones aquí».

era una ligera simplificación del problema. Estáis hasta el cuello de mierda. Pero, sobre todo: no os desaniméis. Es completamente normal. Probablemente estáis aprendiendo a la vez:

• un ESB nuevo;
• un software de negocio nuevo;
• las API de ese software;
• a veces incluso un ámbito funcional nuevo.

Es mucho.

18 Vuestros desarrolladores empezarán a pasar mucho tiempo al teléfono

También descubriréis una transformación inesperada del oficio. Antes, el desarrollador recibía una necesidad y desarrollaba. Ahora, el integrador pasa el día entre:

• el usuario de negocio;
• el jefe de proyecto de la aplicación;
• el desarrollador del proveedor;
• el soporte del ESB;
• a veces el equipo de infraestructura;
• y él mismo, preguntándose por qué no abrió una panadería.

Para avanzar necesita respuestas constantemente. Y aquí probablemente descubriréis lo útil que resulta un AMOA, alguien que ayude a analizar y estructurar las necesidades del negocio. Alguien debe filtrar, aclarar y organizar las peticiones para que vuestro integrador no dedique el 50 % de su tiempo a organizar reuniones.

19 El flujo previsto en tres días acabará tardando tres semanas

También hay que prepararse para esto. Sobre el papel:

«¿El flujo? Tres días».

Técnicamente, quizá era verdad. Tres días de desarrollo. Pero entre esos tres días:

• esperáis una respuesta del negocio;
• el proveedor tiene que comprobar algo;
• falta un endpoint;
• el usuario cambia ligeramente la necesidad;
• hay que crear datos de referencia;
• el jefe de proyecto está de vacaciones;
• alguien tiene que abrir el firewall;
• el desarrollador del proveedor no está disponible hasta el martes siguiente.

20 Entre la preventa y la API real puede haber un mundo

Durante la preventa:

«Tranquilo, nuestra API puede hacerlo todo».

Tres meses después:

«Bueno, en realidad ese endpoint solo está disponible para nuestra aplicación móvil interna».

Muy bien. Empezáis a revisar la documentación con el proveedor. Y descubrís que allí nadie ha utilizado realmente algunas rutas. A veces aparece la extraña sensación de ser el beta tester de la API de un SaaS que estáis pagando. Sois a la vez:

• cliente;
• integrador;
• tester;
• casi consultor técnico del proveedor.

Y, por supuesto, la factura de la licencia llega puntualmente a final de mes. Os sentís un poco como el primo de la película. Una sensación interesante.

21 Después de unos años, la forma de seleccionar software cambia completamente

Con el tiempo cambiamos la manera de abordar proyectos nuevos. Hoy, ya desde la preventa, quiero saber:

¿Tenéis API?

Después:

Enseñadme la documentación.

Después:

¿Está disponible por API todo el perímetro funcional?

Después:

¿Cuántos clientes la utilizan realmente?

La última pregunta es importante. Hay una diferencia enorme entre:

«Sí, tenemos una API».

y:

«Trescientos clientes utilizan nuestra API a diario para sincronizar sus sistemas».

También intento hablar cuanto antes con alguien técnico del proveedor. No solo con el comercial. No solo con el jefe de proyecto. Con alguien capaz de abrir Swagger y hablar con el integrador. A veces eso evita varios meses de sufrimiento.

22 Documentad. Haced esquemas. Mapead los campos.

Probablemente sea uno de los consejos más importantes que puedo dar. Documentad los flujos. Haced esquemas. Identificad claramente:

• el sistema maestro;
• el sistema de destino;
• el desencadenante;
• los datos intercambiados;
• las transformaciones;
• los datos de referencia necesarios;
• los endpoints;
• los posibles errores.

Y, sobre todo:

Mapead los campos.

Campo de origen. Campo de destino. Tipo. Longitud. Transformación. Valor obligatorio. Valor predeterminado. Al principio puede parecer largo. Pero cuando seis meses después alguien pregunte por qué el código de obra se envía en ContractId, agradeceréis tener el mapping.

23 Pensad las interfaces como medios flujos

Lo aprendimos progresivamente, y se vuelve muy potente cuando el sistema crece. Evitad pensar únicamente en:

Aplicación A → Aplicación B

Intentad pensar en medios flujos. Por ejemplo:

ERP → Pedido normalizado en el ESB

y después:

Pedido normalizado → Aplicación B

Ahora disponéis de un objeto «pedido» limpio dentro de la capa de integración. Mañana llega una aplicación C que también necesita los pedidos. No hay que reescribir toda la recuperación desde el ERP. Basta con desarrollar:

Pedido normalizado → Aplicación C

Después llega una aplicación D. Lo mismo. Y poco a poco empezáis a comprender por qué resulta interesante el ESB. El dato se recupera una sola vez del sistema maestro. Se transforma una sola vez a un formato controlado. Y después puede viajar hacia N aplicaciones. Dejáis gradualmente de copiar y pegar código oscuro para recuperar siempre la misma información. Y vuestro sistema empieza a convertirse de verdad en una arquitectura de integración.

24 Después, los webhooks y las colas aceleran todo el sistema

Añadid ahora los webhooks. El ERP modifica un pedido. Se envía un evento. Llega al ESB. Quizá lo guardáis unos segundos en una cola. El flujo recupera los datos, actualiza el objeto interno y alimenta los distintos sistemas suscritos. Unos segundos o minutos después del cambio:

El dato está en todas partes.

En ese momento algo cambia dentro de la empresa. Los usuarios dejan poco a poco de preguntar:

«¿Cuándo pasa la interfaz?».

Porque pasa todo el tiempo.

25 Y de repente la vida se vuelve casi agradable

Los datos circulan.

La supervisión está centralizada.

Cuando un flujo falla, lo veis.

Podéis intervenir durante el día.

Los integradores dejan de mantener 150 programas escritos en doce tecnologías distintas.

Los datos están actualizados.

El negocio está contento.

La contable que llevaba tres años sin hablaros empieza a preguntar cómo fueron las vacaciones.

Dormís mejor.

Aparecen unicornios en el cielo.

Empezáis a sospechar que alguien ha echado algo en vuestro café.

Y al final era exactamente lo que buscábamos al empezar esta aventura.

26 Entonces, ¿recomiendo Best of Breed?

Sí… pero no solo porque vayáis a comprar mejores aplicaciones. Best of Breed cambia el sistema de información de manera mucho más profunda. Cambia la arquitectura, los equipos, el trabajo de los desarrolladores, la selección de software, la relación entre la DSI y el negocio, y la manera de pensar los datos. Sobre todo, obliga a considerar la integración como un verdadero producto interno, no como un trozo de código que alguien hace entre dos tickets.

Hay que tener paciencia. Aceptar errores. Hacer muchos esquemas. Aprender API. Cuestionar a los proveedores. Documentar. Supervisar. Al principio probablemente habrá momentos en los que os preguntéis seriamente por qué empezasteis todo esto. Pero una vez colocadas las primeras piezas, aparece una aceleración. Cada flujo nuevo aprovecha los anteriores. Cada integración aumenta vuestro patrimonio técnico. Cada objeto de negocio bien normalizado puede reutilizarse. Poco a poco, el sistema de información deja de ser una colección de aplicaciones independientes.

Se convierte realmente en un sistema.

Y quizá eso sea, al final, lo más interesante del enfoque Best of Breed.