El argumento a favor de la adquisición de software best-of-breed siempre ha sido convincente. En lugar de comprar una sola plataforma que haga todo de manera adecuada, compras el mejor CRM, el mejor ERP, el mejor sistema de inventario, la mejor herramienta de recursos humanos. Cada uno es líder en su categoría. Cada uno es mejorado constantemente por un proveedor cuya empresa entera depende de que ese producto sea mejor que la competencia. Evitas el lock-in. Mantienes la flexibilidad. Obtienes lo mejor.
Hay un sistema que este argumento olvida tener en cuenta. Es el que se construye en algún momento entre la tercera y la quinta suscripción SaaS, generalmente por un desarrollador que se suponía que debía estar haciendo otra cosa. Nadie lo presupuestó. Nadie definió su alcance. Nadie le dio un nombre. No tiene product manager, ni roadmap, ni más documentación que un README que era preciso en 2022.
Esta es la capa SaaS que nadie pidió, y en muchas organizaciones se ha convertido silenciosamente en la pieza más crítica de la infraestructura que operan.
Cómo empieza
El detonante es siempre un reporte que no se puede generar. Los datos de ventas viven en el CRM. Los ingresos viven en el software de contabilidad. El inventario vive en el sistema de gestión de almacenes. Un alto directivo quiere una vista única —pedidos, costos, márgenes, niveles de stock— y ninguno de los tres sistemas puede generarla por sí solo.
La primera respuesta es exportar archivos CSVs y combinarlos en una hoja de cálculo. Esto funciona. Funciona lo suficientemente bien como para que la hoja de cálculo se convierta en un artefacto semanal. La tarde de viernes de alguien queda reservada permanentemente para ejecutarlo. Cuando esa persona se va, el conocimiento de qué columnas extraer y en qué orden se va con ella.
Eventualmente alguien reemplaza la hoja de cálculo con un script. El script se ejecuta de forma programada. Extrae datos de la API del CRM, de la API de contabilidad y de la API del almacén, une los datos y los escribe en un lugar que todos puedan ver. Esto es una mejora notable. También es, sin que nadie lo haya decidido así, el primer componente de una plataforma de integración de datos de la que ahora depende la organización.
Cómo crece
El script resuelve el problema de los reportes. Pero una vez que existe, se convierte en una superficie para nuevas solicitudes. El correo electrónico de confirmación de pedido debe incluir el estado del inventario del sistema del almacén. El CRM debe actualizarse automáticamente cuando se paga una factura. Cuando un cliente es marcado como de alto riesgo en el ERP, el equipo de ventas debería ver esa marca en su dashboard del CRM.
Cada una de estas es una solicitud razonable. Cada una requiere leer de un sistema y escribir en otro. El desarrollador que creó el script original agrega la lógica. Luego agrega más. El script se convierte en un servicio. El servicio adquiere configuración. La configuración adquiere complejidad. En algún momento se convierte en algo que toma más de quince minutos explicar a un nuevo ingeniero.
Las organizaciones que rastrean cuidadosamente el gasto en software a menudo descubren que esta capa interna —sin presupuesto, sin licencia, sin nombre— está ejecutando más lógica de negocio real que varios de los productos SaaS que conecta. Reglas del ciclo de vida del cliente. Ajustes de precios. Triggers de cumplimiento. Retenciones de compliance. El software adquirido maneja el almacenamiento y la UI. La capa de pegamento maneja las decisiones.
El problema con el código pegamento
El código pegamento tiene una propiedad que es fácil pasar por alto cuando no hay mucho de él: soporta carga en proporción a cuántas cosas conecta. Una sola integración entre dos sistemas es una conveniencia. Cinco integraciones entre seis sistemas son infraestructura. Elimina cualquier componente y múltiples procesos de negocio se detienen.
La infraestructura requiere ser tratada como infraestructura. Necesita monitoreo de uptime. Necesita alertas cuando algo falla silenciosamente. Necesita versioning, de modo que cuando una API upstream cambie, puedas probar contra la nueva versión sin romper producción. Necesita documentación que un nuevo ingeniero pueda leer y entender sin tener que hacer shadowing a la persona que lo construyó. Necesita a alguien que sea responsable de ello un domingo por la mañana cuando un trabajo de procesamiento de pedidos se atasca y el equipo de operaciones no puede realizar envíos.
La mayoría de las capas SaaS internas no tienen ninguna de estas cosas, porque nunca fueron concebidas para convertirse en infraestructura. Crecieron hasta serlo accidentalmente. Y debido a que nunca fueron diseñadas deliberadamente, arrastran cada atajo tomado durante los catorce meses de adición de funcionalidades que siguieron al script original de la tarde de viernes.
Lo que los proveedores no te dicen
Los proveedores de SaaS empresarial tienen un término para la categoría de software que compite con la capa de pegamento interna: iPaaS, plataforma de integración como servicio. Zapier es la versión para consumidores. MuleSoft, Boomi y Workato son las versiones empresariales. El argumento de venta es que en lugar de construir tu propia capa de integración, compras una gestionada.
Esto resuelve parte del problema de infraestructura. Las plataformas iPaaS manejan el uptime, el versioning y el monitoreo. Pero no resuelven el problema de diseño. Una plataforma iPaaS construida sobre un modelo de datos mal entendido —donde el mismo registro de cliente existe en tres sistemas con tres identificadores diferentes— fallará exactamente de las mismas maneras que un script interno construido sobre la misma base. La plataforma tiene mejor ingeniería. La lógica de negocio sigue siendo incorrecta.
Los proveedores tampoco anuncian lo rápido que escala el costo de una suscripción iPaaS con la complejidad de lo que estás integrando. Un flujo de trabajo simple de trigger-action no cuesta casi nada. La sincronización bidireccional entre cinco sistemas con lógica condicional, manejo de errores y transformaciones personalizadas cuesta sustancialmente más, a menudo más que cualquier producto SaaS individual que conecte. En ese punto, la pregunta de si comprar o construir vuelve a ser genuinamente interesante.
La decisión de diseño que se esconde dentro de una decisión de adquisición
La adquisición best-of-breed no es un error. Hay casos genuinos en los que la respuesta correcta es comprar el mejor producto en cada categoría y aceptar el trabajo de integración posterior. Las organizaciones con necesidades inusuales en un solo dominio —una operación logística especializada, una institución de investigación con requisitos de datos específicos— a menudo no pueden encontrar un solo producto que maneje bien su dominio principal. El enfoque best-of-breed es la decisión correcta.
Pero es una decisión de diseño, y necesita ser tomada como tal. La capa de integración no es un overhead que ocurre después de la decisión de adquisición. Es un sistema que se construirá como consecuencia de la decisión de adquisición, y necesita ser presupuestado, contar con personal, tener responsables y ser diseñado con el mismo rigor que cualquier otro sistema.
Las organizaciones que manejan esto bien no descubren su capa de integración por accidente. La definen deliberadamente: estos son los sistemas que estamos comprando, estos son los datos que necesitamos mover entre ellos, este es el equipo responsable de la infraestructura que los mueve, así es como sabremos cuándo se rompe. El pegamento se convierte en arquitectura.
Las organizaciones que lo manejan mal terminan con un sistema crítico del que nadie es dueño, ejecutándose en un servidor que nadie está monitoreando, ejecutando lógica de negocio que nadie ha documentado. Descubren que existe cuando deja de funcionar.
Best-of-breed más una capa de integración accidental no es, en la práctica, best-of-breed. Es best-of-breed en las partes que evaluaste, más lo que haya sido más barato de construir en ese momento en las partes que olvidaste evaluar. Entender eso antes de la decisión de adquisición es la diferencia entre una arquitectura considerada y una sorpresa costosa.