Durante mucho tiempo, la promesa del SaaS era 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 siendo válida. Pero, en las conversaciones con grandes empresas, veo aparecer cada vez más peticiones que la hacen evolucionar.

"¿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 email o de SMS?"

"¿Podemos enviar los eventos de seguridad a nuestro SIEM?"

Estas peticiones pueden parecer muy distintas.

En realidad, cuentan a menudo lo mismo.

Las grandes empresas quieren seguir comprando SaaS, pero quieren recuperar el control de ciertos bloques.

Y ese cambio no es solo técnico o regulatorio.

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 pueden esconderse 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 ser trazable.

Lo mismo ocurre con la gestión de usuarios.

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

Podríamos mirar algunas de estas peticiones y concluir que no crean ningún valor de negocio.

Y sería cierto.

Pero sería pasar de largo por el tema.

El producto que construimos para resolver el problema de negocio del cliente es solo una parte de lo que realmente compra.

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

El core product concentra lo que constituye de verdad 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 corresponde a todo lo que hace falta alrededor de ese valor para que un cliente concreto pueda 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 uno de estos 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 conservar mi base en mi 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 implicados: salarios, contratos, información personal, organización de la empresa.

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

Ahora, imaginemos una gran empresa que nos dice:

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

No es una petición absurda.

Y, en nuestro caso, es incluso coherente con el mercado al que queremos servir: la inmensa mayoría de nuestros clientes objetivo se mueven ya en el ecosistema Microsoft.

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

Pero su base podría alojarse en el entorno del cliente.

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

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 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 regulatoria.

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

Controlar la ubicación de 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 el editor.

Su propiedad intelectual se queda en el editor.

Y sobre todo, su capacidad de hacer evolucionar el producto debe quedarse en el editor.

Tomemos las migraciones de base.

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

Si cada puesta en producción exige enviar un procedimiento al equipo del cliente, esperar una validación, reservar una ventana de mantenimiento y luego verificar manualmente 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á todavía menos mañana.

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

Construir hoy una arquitectura que exija más intervenciones humanas en casa de cada cliente con cada evolución iría exactamente en sentido contrario.

Muy pronto, 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 con cada release.

Terminamos perdiendo 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 cómo evoluciona nuestro producto.

La frontera se vuelve entonces bastante sencilla:

el cliente controla dónde viven sus datos; el editor 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 editor, dentro de un marco de seguridad aceptado por el cliente.

El control también desplaza las responsabilidades

Mover la base al entorno del cliente produce otra consecuencia.

Una parte de la infraestructura de la que depende nuestro servicio ya no está enteramente 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 se acaba de modificar?

¿Un certificado?

¿Una configuración IAM?

¿Una saturación de las conexiones?

¿Una cuota?

¿Un problema de latencia?

Decir:

"La base está en casa del cliente, no es nuestro problema"

no funciona.

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

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

Eso no significa administrar toda la infraestructura en lugar del cliente.

Significa 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 indispensable en lo operativo.

Pero también lo es en lo contractual.

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

El reparto de responsabilidades solo existe de verdad si se pueden atribuir los incidentes.

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

Aquí es donde aparece una paradoja interesante.

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

Podríamos pensar entonces:

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

No necesariamente.

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

Dar soporte a bases en entornos de 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 de infraestructura directo y aumentar al mismo tiempo 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 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.

A la inversa, el cliente puede optar por gestionar él mismo sus copias de seguridad.

En ese caso, las responsabilidades deben ser explícitas: retención, calidad de los backups, restauración y 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 carga con 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 este proveedor por otro, ¿cambia el valor de mi servicio?

Tomemos el envío de emails.

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

Probablemente no.

El mensaje sigue enviándose 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 proporcionar por defecto un modelo de IA.

Pero una gran empresa puede preferir usar su propio contrato 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 corazón del producto.

Eso no significa que todos los proveedores sean perfectamente intercambiables.

Un modelo puede rendir mejor que otro.

Un proveedor de email puede tener mejor entregabilidad.

Pero la buena pregunta sigue siendo:

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

Si sustituir un proveedor destruye el valor del servicio, está probablemente 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.

Una gateway de email es relativamente stateless.

Lo mismo con 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 simplemente cambiando 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 es especialmente cierto en el caso de la base.

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 email.

Cuatro gateways de SMS.

Sería probablemente un error.

La buena pregunta no es:

"¿Qué podemos soportar técnicamente?"

Sino:

"¿Qué tenemos que soportar para los clientes que hemos decidido servir?"

Si el 90 % de las grandes empresas a las que apuntamos están ya estructuradas 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.

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

A la inversa, soportar una base o un cloud que nadie de nuestro segmento pide no añade necesariamente valor.

La amplitud del soporte tecnológico 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 que hemos decidido servir puedan comprarlo de verdad?

Entender la necesidad detrás de la petición

Eso no significa que haya que responder literalmente a cada petición de cliente.

Cuando una gran empresa 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 regulatoria?

¿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 quedarse bajo control directo de la empresa?

La solución puede depender de esa respuesta.

Una región dedicada puede bastar a veces.

Una Customer Managed Key puede bastar a veces.

Un entorno single-tenant puede bastar a veces.

En otros casos, habrá que alojar realmente la base 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 las grandes empresas, su cultura de gobernanza forma parte del mercado.

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

No es una estrategia de infraestructura

Este 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 reales.

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 las grandes empresas a las que queremos servir tienen una cultura fuerte de control de sus datos, sus identidades, sus claves y 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 simple 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 soportar todas las tecnologías.

Tenemos sobre todo que identificar las restricciones que impiden realmente comprar nuestro producto a los clientes que hemos decidido servir.

Y luego decidir 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 ese no es el punto de partida.

El punto de partida sigue siendo el mercado.

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