Durante mucho tiempo, la promesa del SaaS fue bastante sencilla.

Tú usas el software. Nosotros nos ocupamos del resto.

Operamos la aplicación, elegimos la infraestructura, alojamos la base de datos, garantizamos las copias de seguridad y hacemos evolucionar el producto.

El cliente compra un servicio terminado.

Esa promesa sigue en pie. Pero, en las conversaciones con los grandes grupos, veo aparecer cada vez más peticiones que la desplazan.

«¿Pueden quedarse los datos en nuestro entorno Azure?»

«¿Podemos usar nuestro propio SQL Server?»

«¿Podemos usar nuestras propias claves de cifrado?»

«¿Podemos gestionar los usuarios y sus permisos desde nuestro IAM?»

«¿Podemos usar nuestro contrato y nuestro proveedor de LLM?»

«¿Podemos usar nuestro proveedor de correo o de SMS?»

«¿Podemos enviar los eventos de seguridad a nuestro SIEM?»

Estas peticiones pueden parecer muy distintas.

En realidad, a menudo cuentan lo mismo.

Los grandes grupos quieren seguir comprando SaaS, pero quieren recuperar el control de ciertos bloques.

Y ese cambio no es solo técnico ni reglamentario.

También es cultural.

Cuando la cultura del cliente se convierte en un componente del producto

Tomemos una petición muy sencilla:

«Quiero saber quién se conecta a la aplicación.»

Técnicamente, no es necesariamente una funcionalidad espectacular.

Pero detrás de esa frase puede haber una auditoría ISO, una política de seguridad, un equipo de ciberseguridad, un SIEM central, un procedimiento de investigación o simplemente una cultura de empresa en la que cada acceso debe quedar trazado.

Lo mismo ocurre con la gestión de usuarios.

El cliente puede no querer administrar los permisos dentro de cada SaaS que compra. Quiere que las identidades, los grupos y a veces los permisos se piloten desde su propio IAM.

Uno podría mirar algunas de esas peticiones y concluir que no crean ningún valor de negocio.

Y sería cierto.

Pero sería perder de vista el asunto.

El producto que construimos para resolver el problema de negocio del cliente es solo una parte de lo que él compra en realidad.

Ahí es donde la distinción entre core product y whole product resulta útil.

El core product concentra lo que constituye realmente nuestro valor: nuestro conocimiento del negocio, nuestras reglas, nuestros workflows, nuestra orquestación, nuestra capacidad de resolver un problema mejor que una alternativa.

El whole product es todo lo que hace falta alrededor de ese valor para que un cliente concreto pueda efectivamente comprar, desplegar y explotar el producto.

El SSO probablemente no es nuestra diferenciación.

El SIEM tampoco.

La residencia de los datos tampoco.

La capacidad de usar el IAM del cliente tampoco.

Pero la ausencia de cualquiera de esos elementos puede bastar para impedir una venta.

No crean necesariamente el valor.

Permiten que ese valor entre en la empresa.

«Quiero usar vuestro SaaS, pero mantener mi base de datos en casa»

El caso más interesante es probablemente el de la base de datos.

Imaginemos un software de nóminas.

Todo el mundo entiende de inmediato la naturaleza de los datos en juego: salarios, contratos, información personal, organización de la empresa.

En el modelo SaaS clásico, el fabricante opera el software y la base de datos que lo acompaña.

Ahora, imaginemos un gran grupo que nos dice:

Queremos vuestra aplicación, pero los datos deben permanecer en una base SQL Server o Azure SQL situada en nuestro entorno Azure.

No es una petición absurda.

Y, en nuestro caso, hasta es coherente con el mercado al que queremos servir: la inmensa mayoría de los clientes a los que nos dirigimos ya se mueven dentro del ecosistema Microsoft.

El motor del SaaS lo seguiría operando el fabricante.

Pero su base de datos podría estar alojada en el entorno del cliente.

¿Por qué pediría eso un cliente, si sabemos perfectamente alojar una base de datos?

Porque su pregunta no es necesariamente:

«¿Sois capaces de alojar bien mis datos?»

Puede ser:

«¿Siguen mis datos bajo el control de mi organización?»

El cliente quiere a veces que el recurso esté en su suscripción de Azure.

Quiere aplicar sus reglas de red.

Sus políticas de seguridad.

Sus claves.

Sus mecanismos de inventario.

Sus controles.

Sus estándares internos.

Y, sobre todo, poder decirle a su CISO, a su auditor o a su organización:

«Estos datos se quedan en casa.»

No siempre es una obligación reglamentaria.

Puede ser simplemente una condición para que la empresa acepte el producto.

Controlar dónde están los datos no significa controlar el producto

Dar más control al cliente introduce, sin embargo, una frontera que hay que preservar.

El motor de negocio se queda en casa del fabricante.

Su propiedad intelectual se queda en casa del fabricante.

Y, sobre todo, su capacidad de hacer evolucionar el producto debe quedarse en casa del fabricante.

Tomemos las migraciones de base de datos.

Supongamos que añadimos una funcionalidad que exige una nueva columna, un índice o un cambio de esquema.

Si cada puesta en producción obliga a enviar un procedimiento al equipo del cliente, esperar una validación, reservar una ventana de mantenimiento y comprobar después a mano que la migración se ha aplicado, el modelo no se sostiene.

Ya es difícilmente compatible con un SaaS que entrega varias veces por semana.

Y lo será aún menos mañana.

El desarrollo de software asistido por IA ya aumenta nuestra capacidad de producir, probar y modificar software. Es razonable pensar que la cadencia de entrega seguirá subiendo.

Construir hoy una arquitectura que exija más intervenciones humanas en casa de cada cliente en cada cambio iría exactamente en el sentido contrario.

Enseguida, un cliente aplica la migración el martes.

Otro espera al viernes.

Un tercero la aplaza al mes siguiente.

Acabamos con varias versiones del motor, varios estados del esquema y una complejidad que crece en cada release.

Terminamos por perder una de las ventajas estructurales del SaaS: hacer evolucionar en continuo un producto común para todos los clientes.

Ahora bien, el cliente que pide conservar sus datos en su entorno no pide necesariamente gestionar nuestras migraciones.

Quiere el control sobre dónde viven sus datos.

No sobre la manera en que evoluciona nuestro producto.

La frontera queda entonces bastante clara:

el cliente controla dónde viven sus datos; el fabricante controla cómo evoluciona el producto.

El BYO-Database solo es realmente compatible con el SaaS, por tanto, si las migraciones pueden seguir automatizadas y pilotadas por el fabricante, dentro de un marco de seguridad aceptado por el cliente.

El control desplaza también las responsabilidades

Mover la base de datos al entorno del cliente tiene otra consecuencia.

Una parte de la infraestructura de la que depende nuestro servicio deja de estar del todo bajo nuestro control.

Y el día en que la aplicación se cae, esa distinción se vuelve muy concreta.

¿Es nuestro motor?

¿La base SQL Server del cliente?

¿Azure?

¿Una regla de red que acaban de cambiar?

¿Un certificado?

¿Una configuración de IAM?

¿Una saturación de conexiones?

¿Una cuota?

¿Un problema de latencia?

Decir:

«La base de datos está en casa del cliente, no es problema nuestro»

no funciona.

Para el usuario, es nuestro SaaS el que ha dejado de funcionar.

El BYO impone por tanto una exigencia que me parece innegociable: tenemos que poder monitorizar la base de datos y su conectividad lo suficiente para entender de dónde viene una incidencia.

Eso no quiere decir administrar toda la infraestructura en lugar del cliente.

Quiere decir disponer de las señales necesarias: disponibilidad, latencia, errores de conexión, saturación, estado de salud, eventos útiles para el diagnóstico.

Esa observabilidad es imprescindible desde el punto de vista operativo.

Pero también lo es desde el punto de vista contractual.

Si nuestro SLA excluye las caídas provocadas por un recurso bajo control del cliente, tenemos que ser capaces de determinar objetivamente que la incidencia venía efectivamente de ese recurso.

El reparto de responsabilidades solo existe de verdad si podemos atribuir las incidencias.

El cliente paga su base de datos. Y aun así su SaaS puede salirle más caro.

Aquí es donde aparece una paradoja interesante.

El cliente puede pagar directamente su Azure SQL o su SQL Server.

Cabría pensar entonces:

Ya que paga él mismo la base de datos, nuestro SaaS debería costar menos.

No necesariamente.

Nuestro coste de servicio no se limita al precio de la infraestructura.

Dar soporte a bases de datos alojadas en los entornos de los clientes puede obligarnos a gestionar más variantes.

Versiones distintas.

Restricciones de red distintas.

Mecanismos de replicación.

Copias de seguridad.

Snapshots.

Restauraciones.

Permisos.

Monitorización.

Configuraciones específicas.

Y, sobre todo, más escenarios que entender cuando algo deja de funcionar.

Externalizar un recurso puede por tanto reducir nuestro coste directo de infraestructura y aumentar a la vez nuestro coste de servicio.

Las copias de seguridad ilustran bien ese reparto.

Si nos comprometemos a gestionar los backups y a garantizar la restauración de una base de datos situada en el entorno del cliente, asumimos una responsabilidad adicional.

Exige tecnología.

Pruebas.

Monitorización.

Procedimientos de recuperación.

Esa responsabilidad tiene por tanto un coste y debe facturarse.

En cambio, el cliente puede optar por gestionar él mismo sus copias de seguridad.

En ese caso, hace falta que las responsabilidades sean explícitas: la retención, la calidad de los backups, la restauración y las consecuencias de un backup inservible deben corresponderle a él.

El BYO no hace desaparecer las responsabilidades.

Simplemente obliga a decir con mucha más precisión quién asume cuáles.

No todos los bloques necesitan quedarse en nuestra casa

Una vez planteado este razonamiento, la base de datos aparece como el caso más difícil de un fenómeno más general.

Una pregunta sencilla permite pensar los demás bloques:

si sustituyo a ese proveedor por otro, ¿cambia el valor de mi servicio?

Tomemos el envío de correos.

Si sustituimos nuestro proveedor de correo por el del cliente, ¿cambia el valor de negocio de nuestro producto?

Probablemente no.

El mensaje se sigue enviando en el momento adecuado porque nuestro motor ha decidido que debía enviarse.

Lo mismo con un SMS.

Lo mismo, en ciertos casos, con un LLM.

Nuestro producto puede ofrecer por defecto un modelo de IA.

Pero un gran grupo puede preferir usar su propio contrato de Azure OpenAI, sus propias claves o un proveedor ya aprobado.

Si nuestro valor está en el workflow de negocio, el contexto, las reglas, los datos y la orquestación, cambiar el modelo de ejecución no debería desplazar el núcleo del producto.

Eso no quiere decir que todos los proveedores sean perfectamente intercambiables.

Un modelo puede rendir mejor que otro.

Un proveedor de correo puede tener mejor entregabilidad.

Pero la pregunta correcta sigue siendo:

¿es ese bloque el que sostiene el valor por el que el cliente compra nuestro producto?

Si sustituir a un proveedor destruye el valor del servicio, probablemente esté demasiado cerca de nuestro core product para ser libremente sustituible.

Si su sustitución no cambia el valor de negocio fundamental, puede convertirse en candidato a la configuración, a la sustitución o al BYO.

No todas las sustituciones cuestan lo mismo

Queda una diferencia importante.

Un gateway de correo es relativamente stateless.

Lo mismo para un proveedor de SMS.

Y un LLM también puede serlo, siempre que la memoria duradera, el contexto de negocio y las decisiones se queden en nuestro producto.

Una base de datos es distinta.

Contiene el estado duradero del sistema.

No se pasa de un SQL Server a otro cambiando simplemente una clave de API.

Hay que migrar los datos.

Garantizar su coherencia.

Prever la recuperación.

Gestionar las copias de seguridad.

A veces la replicación.

La sustituibilidad no es, por tanto, binaria.

Es un gradiente.

Un bloque puede no ser diferenciador para nuestro producto y ser al mismo tiempo enormemente importante desde el punto de vista operativo.

Eso vale de forma muy particular para la base de datos.

No convertir el whole product en un catálogo

A partir de ahí, la tentación podría ser construir todas las posibilidades.

Azure.

AWS.

GCP.

SQL Server.

PostgreSQL.

Oracle.

Cinco proveedores de IA.

Tres proveedores de correo.

Cuatro gateways de SMS.

Probablemente sería un error.

La pregunta correcta no es:

«¿A qué podemos dar soporte técnicamente?»

Sino:

«¿A qué debemos dar soporte para los clientes a los que hemos decidido servir?»

Si el 90 % de los grandes grupos a los que nos dirigimos ya están estructurados en torno a Microsoft y Azure, empezar por Azure y SQL Server tiene sentido.

No porque SQL Server sea intrínsecamente mejor que otra base de datos.

Sino porque esa configuración es la que probablemente maximiza nuestra capacidad de vender en el mercado al que nos dirigimos.

En cambio, dar soporte a una base de datos o una nube que nadie de nuestro segmento pide no añade necesariamente valor.

La amplitud de las tecnologías a las que damos soporte no es un objetivo en sí.

Debe seguir al posicionamiento comercial.

El whole product no es una checklist universal del «SaaS enterprise perfecto».

Es la traducción concreta de la pregunta:

¿qué hay que añadir alrededor de nuestro core product para que los clientes a los que hemos decidido servir puedan comprarlo de verdad?

Entender la necesidad que hay detrás de la petición

Eso no quiere decir que haya que responder literalmente a cada petición del cliente.

Cuando un gran grupo dice:

Quiero mis datos en mi Azure.

La buena respuesta no es inmediatamente:

De acuerdo, construyamos BYO-Database.

Hay que entender por qué.

¿Es una obligación reglamentaria?

¿Una exigencia de residencia?

¿Una política del CISO?

¿Una necesidad de controlar las claves?

¿Una restricción de auditoría?

¿Una voluntad de reversibilidad?

¿O simplemente una cultura según la cual los datos sensibles deben permanecer bajo control directo de la empresa?

La solución puede depender de esa respuesta.

A veces basta con una región dedicada.

A veces basta con Customer Managed Key.

A veces basta con un entorno single-tenant.

En otros casos, habrá que alojar realmente la base de datos en el tenant del cliente.

Entender por qué el cliente pide control permite proponer el nivel de control adecuado.

Pero eso no cambia la constatación de partida.

Si decidimos vender a los grandes grupos, su cultura de gobernanza forma parte del mercado.

No se puede querer sus volúmenes, sus presupuestos y sus contratos y, al mismo tiempo, considerar sus restricciones de auditoría, de seguridad o de control como detalles molestos.

No es una estrategia de infraestructura

Es probablemente el punto más importante.

A primera vista, todo este tema parece una discusión de arquitectura.

¿Dónde alojar SQL Server?

¿Cómo conectar el motor?

¿Cómo migrar el esquema?

¿Cómo monitorizar?

¿Cómo gestionar los backups?

Son preguntas de verdad.

Pero vienen después de otra:

¿a qué clientes hemos decidido servir?

El core product crea el valor.

El posicionamiento elige el mercado.

Y el whole product hace que el core product sea compatible con la realidad de ese mercado.

Si los grandes grupos a los que queremos servir tienen una cultura fuerte de control de sus datos, de sus identidades, de sus claves y de sus proveedores, entonces algunas de esas capacidades deben convertirse probablemente en un componente de nuestro whole product.

No porque el BYO sea mejor que el full-managed.

El full-managed debe seguir siendo probablemente la opción por defecto.

Sigue siendo más sencillo de explotar, más homogéneo y más fácil de hacer evolucionar.

El BYO se convierte en una opción cuando el mercado lo justifica.

Y su perímetro debe decidirse de la misma manera.

No necesitamos hacer intercambiable cada componente.

No necesitamos dar soporte a todas las tecnologías.

Lo que debemos hacer, sobre todo, es identificar las restricciones que realmente impiden que los clientes a los que hemos decidido servir compren nuestro producto.

Y decidir después cuáles queremos levantar.

El BYO no es, por tanto, ante todo una estrategia de infraestructura. Es una decisión de whole product y de posicionamiento comercial.

La consecuencia técnica puede ser un SaaS más modular.

El motor sigue bajo nuestro control.

Ciertos datos se quedan en casa del cliente.

Ciertos proveedores se vuelven sustituibles.

Ciertas responsabilidades cambian de manos.

Pero no es el punto de partida.

El punto de partida sigue siendo el mercado.

No buscamos dar todas las opciones posibles a todos los clientes. Buscamos construir el whole product que permite que nuestro core product lo compren los clientes a los que hemos decidido servir.