Durante muito tempo, a promessa do SaaS foi bem simples.

Você usa o software. Nós cuidamos do resto.

Nós operamos a aplicação, escolhemos a infraestrutura, hospedamos o banco de dados, garantimos os backups e fazemos o produto evoluir.

O cliente compra um serviço pronto.

Essa promessa continua valendo. Mas, nas conversas com as grandes corporações, vejo aparecer cada vez mais pedidos que a transformam.

"Os dados podem ficar no nosso ambiente Azure?"

"Dá para usar o nosso próprio SQL Server?"

"Dá para usar as nossas próprias chaves de criptografia?"

"Dá para gerenciar os usuários e as permissões deles a partir do nosso IAM?"

"Dá para usar o nosso contrato e o nosso provedor de LLM?"

"Dá para usar o nosso provedor de e-mail ou de SMS?"

"Dá para enviar os eventos de segurança para o nosso SIEM?"

Esses pedidos podem parecer muito diferentes entre si.

Na prática, eles costumam contar a mesma coisa.

As grandes corporações querem continuar comprando SaaS, mas querem retomar o controle de alguns blocos.

E essa mudança não é só técnica ou regulatória.

Ela também é cultural.

Quando a cultura do cliente vira um componente do produto

Pense num pedido bem simples:

"Quero saber quem se conecta à aplicação."

Tecnicamente, isso não é necessariamente uma funcionalidade espetacular.

Mas por trás dessa frase podem estar uma auditoria ISO, uma política de segurança, um time de cibersegurança, um SIEM central, um procedimento de investigação ou simplesmente uma cultura corporativa na qual cada acesso precisa deixar rastro.

A mesma coisa acontece com a gestão de usuários.

O cliente pode não querer administrar permissões dentro de cada SaaS que compra. Ele quer que as identidades, os grupos e às vezes as permissões sejam conduzidos a partir do próprio IAM.

Poderíamos olhar alguns desses pedidos e concluir que eles não criam nenhum valor de negócio.

E isso seria verdade.

Mas seria também passar ao largo do assunto.

O produto que construímos para resolver o problema de negócio do cliente é apenas uma parte do que ele realmente compra.

É aí que a distinção entre core product e whole product se torna útil.

O core product concentra o que de fato constrói o nosso valor: o nosso conhecimento do negócio, as nossas regras, os nossos workflows, a nossa orquestração, a nossa capacidade de resolver um problema melhor do que uma alternativa.

O whole product corresponde a tudo o que precisa existir em volta desse valor para que um cliente específico consiga efetivamente comprar, implantar e operar o produto.

O SSO provavelmente não é a nossa diferenciação.

O SIEM também não.

A residência dos dados também não.

A capacidade de usar o IAM do cliente também não.

Mas a ausência de um desses elementos pode bastar para impedir uma venda.

Eles não criam necessariamente o valor.

Eles permitem que esse valor entre na empresa.

"Quero usar o seu SaaS, mas manter o meu banco aqui dentro"

O caso mais interessante é provavelmente o do banco de dados.

Imagine um software de folha de pagamento.

Todo mundo entende na hora a natureza dos dados envolvidos: salários, contratos, informações pessoais, organização da empresa.

No modelo SaaS clássico, o fornecedor opera o software e o banco que vem junto.

Agora imagine uma grande corporação nos dizendo:

Queremos a sua aplicação, mas os dados precisam ficar num banco SQL Server ou Azure SQL dentro do nosso ambiente Azure.

Não é um pedido absurdo.

E, no nosso caso, ele é até coerente com o mercado que queremos atender: a imensa maioria dos nossos clientes-alvo já vive no ecossistema Microsoft.

O motor do SaaS continuaria operado pelo fornecedor.

Mas o banco dele poderia ficar hospedado no ambiente do cliente.

Por que um cliente pediria isso se sabemos perfeitamente bem hospedar um banco?

Porque a pergunta dele não é necessariamente:

"Vocês são capazes de hospedar bem os meus dados?"

Ela pode ser:

"Os meus dados continuam sob o controle da minha organização?"

Às vezes o cliente quer que o recurso fique na assinatura Azure dele.

Ele quer aplicar as regras de rede dele.

As políticas de segurança dele.

As chaves dele.

Os mecanismos de inventário dele.

As verificações dele.

Os padrões internos dele.

E, acima de tudo, poder dizer ao CISO, ao auditor ou à organização dele:

"Esses dados continuam aqui dentro."

Nem sempre isso é uma obrigação regulatória.

Pode ser simplesmente uma condição para que a empresa aceite o produto.

Controlar onde os dados ficam não significa controlar o produto

Dar mais controle ao cliente cria, ainda assim, uma fronteira que precisa ser preservada.

O motor de negócio continua com o fornecedor.

A propriedade intelectual dele continua com o fornecedor.

E, principalmente, a capacidade de fazer o produto evoluir precisa continuar com o fornecedor.

Pense nas migrações de banco.

Suponha que a gente adicione uma funcionalidade que exige uma nova coluna, um índice ou uma mudança de esquema.

Se cada subida em produção exigir enviar um procedimento para o time do cliente, esperar uma aprovação, reservar uma janela de manutenção e depois verificar manualmente que a migração foi aplicada, o modelo não se sustenta.

Ele já é pouco compatível com um SaaS que entrega várias vezes por semana.

E vai ser ainda menos amanhã.

O desenvolvimento de software assistido por IA já aumenta a nossa capacidade de produzir, testar e modificar software. É razoável imaginar que a cadência de entrega vai continuar subindo.

Construir hoje uma arquitetura que exige mais intervenções humanas dentro de cada cliente a cada evolução iria exatamente na direção contrária.

Muito rápido, um cliente aplica a migração na terça.

Outro espera até sexta.

Um terceiro adia para o mês seguinte.

Aí passamos a ter várias versões do motor, vários estados do esquema e uma complexidade que cresce a cada release.

E acabamos perdendo uma das vantagens estruturais do SaaS: fazer evoluir continuamente um produto comum para todos os clientes.

Só que o cliente que pede para manter os dados no ambiente dele não está necessariamente pedindo para gerenciar as nossas migrações.

Ele quer o controle sobre onde os dados dele ficam.

Não sobre como o nosso produto evolui.

A fronteira fica, então, bastante simples:

o cliente controla onde os dados dele ficam; o fornecedor controla como o produto evolui.

O BYO-Database só é realmente compatível com o SaaS, portanto, se as migrações puderem continuar automatizadas e conduzidas pelo fornecedor, dentro de um quadro de segurança aceito pelo cliente.

O controle também desloca as responsabilidades

Mover o banco para o ambiente do cliente produz outra consequência.

Uma parte da infraestrutura da qual o nosso serviço depende não está mais inteiramente sob o nosso controle.

E no dia em que a aplicação cai, essa distinção fica bem concreta.

É o nosso motor?

O banco SQL Server do cliente?

O Azure?

Uma regra de rede que acabou de ser alterada?

Um certificado?

Uma configuração de IAM?

Uma saturação das conexões?

Uma cota?

Um problema de latência?

Dizer:

"O banco está no cliente, o problema não é nosso"

não funciona.

Para o usuário, é o nosso SaaS que parou de funcionar.

O BYO impõe, portanto, uma exigência que me parece inegociável: precisamos conseguir monitorar o banco e a conectividade dele o suficiente para entender de onde vem um incidente.

Isso não quer dizer administrar toda a infraestrutura no lugar do cliente.

Quer dizer ter os sinais necessários: disponibilidade, latência, erros de conexão, saturação, estado de saúde, eventos úteis para o diagnóstico.

Essa observabilidade é indispensável do ponto de vista operacional.

Mas também do ponto de vista contratual.

Se o nosso SLA exclui as quedas provocadas por um recurso sob controle do cliente, precisamos ser capazes de determinar objetivamente que o incidente veio mesmo desse recurso.

A divisão de responsabilidades só existe de verdade se conseguirmos atribuir os incidentes.

O cliente paga o banco dele. Ainda assim o SaaS dele pode sair mais caro.

É aqui que aparece um paradoxo interessante.

O cliente pode pagar diretamente o Azure SQL ou o SQL Server dele.

Poderíamos pensar, então:

Já que ele mesmo paga o banco, o nosso SaaS deveria sair mais barato.

Não necessariamente.

O nosso custo de serviço não se limita ao preço da infraestrutura.

Dar suporte a bancos dentro dos ambientes dos clientes pode nos obrigar a lidar com mais variantes.

Versões diferentes.

Restrições de rede diferentes.

Mecanismos de replicação.

Backups.

Snapshots.

Restaurações.

Permissões.

Monitoramento.

Configurações específicas.

E, acima de tudo, mais cenários para entender quando alguma coisa para de funcionar.

Terceirizar um recurso pode, portanto, reduzir o nosso custo direto de infraestrutura e ao mesmo tempo aumentar o nosso custo de serviço.

Os backups ilustram bem essa divisão.

Se nos comprometemos a gerenciar os backups e a garantir a restauração de um banco que fica no ambiente do cliente, assumimos uma responsabilidade a mais.

Ela exige tecnologia.

Testes.

Monitoramento.

Procedimentos de recuperação.

Essa responsabilidade tem, portanto, um custo, e precisa ser cobrada.

Por outro lado, o cliente pode escolher cuidar dos próprios backups.

Nesse caso, as responsabilidades precisam ficar explícitas: retenção, qualidade dos backups, restauração e consequências de um backup inutilizável passam a ser dele.

O BYO não faz as responsabilidades desaparecerem.

Ele só obriga a dizer com muito mais precisão quem carrega quais.

Nem todos os blocos precisam ficar com a gente

Uma vez montado esse raciocínio, o banco de dados aparece como o caso mais difícil de um fenômeno mais amplo.

Uma pergunta simples ajuda a pensar os outros blocos:

se eu trocar esse provedor por outro, o valor do meu serviço muda?

Pense no envio de e-mails.

Se trocarmos o nosso provedor de e-mail pelo do cliente, o valor de negócio do nosso produto muda?

Provavelmente não.

A mensagem continua sendo enviada na hora certa porque o nosso motor decidiu que ela precisava ser enviada.

O mesmo vale para um SMS.

E o mesmo vale, em certos casos, para um LLM.

O nosso produto pode oferecer um modelo de IA por padrão.

Mas uma grande corporação pode preferir usar o próprio contrato Azure OpenAI, as próprias chaves ou um provedor já aprovado.

Se o nosso valor está no workflow de negócio, no contexto, nas regras, nos dados e na orquestração, trocar o modelo de execução não deve deslocar o coração do produto.

Isso não quer dizer que todos os provedores sejam perfeitamente intercambiáveis.

Um modelo pode ter desempenho melhor que outro.

Um provedor de e-mail pode ter uma entregabilidade melhor.

Mas a pergunta certa continua sendo:

é esse bloco que sustenta o valor pelo qual o cliente compra o nosso produto?

Se trocar um provedor destrói o valor do serviço, ele provavelmente está perto demais do nosso core product para ser livremente substituível.

Se a troca dele não muda o valor de negócio fundamental, ele pode virar candidato à configuração, à substituição ou ao BYO.

Nem toda substituição custa a mesma coisa

Resta uma diferença importante.

Um gateway de e-mail é relativamente stateless.

O mesmo vale para um provedor de SMS.

E um LLM também pode ser, desde que a memória durável, o contexto de negócio e as decisões continuem dentro do nosso produto.

Um banco de dados é diferente.

Ele guarda o estado durável do sistema.

Você não troca um SQL Server por outro mudando simplesmente uma chave de API.

É preciso migrar os dados.

Garantir a consistência deles.

Prever a recuperação.

Cuidar dos backups.

Às vezes da replicação.

A substituibilidade não é binária, portanto.

Ela é um gradiente.

Um bloco pode não ser diferenciador para o nosso produto e, ainda assim, ser extremamente importante do ponto de vista operacional.

Isso vale de forma especial para o banco.

Não transformar o whole product num catálogo

A partir daí, a tentação seria construir todas as possibilidades.

Azure.

AWS.

GCP.

SQL Server.

PostgreSQL.

Oracle.

Cinco provedores de IA.

Três provedores de e-mail.

Quatro gateways de SMS.

Isso provavelmente seria um erro.

A pergunta certa não é:

"A que conseguimos tecnicamente dar suporte?"

E sim:

"A que precisamos dar suporte para os clientes que escolhemos atender?"

Se 90% das grandes corporações que temos como alvo já estão estruturadas em torno da Microsoft e do Azure, começar por Azure e SQL Server faz sentido.

Não porque o SQL Server seja intrinsecamente melhor que outro banco.

Mas porque essa configuração é a que provavelmente maximiza a nossa capacidade de vender no mercado que visamos.

Por outro lado, dar suporte a um banco ou a uma cloud que ninguém no nosso segmento pede não acrescenta necessariamente valor.

A amplitude do suporte tecnológico não é um objetivo em si.

Ela precisa acompanhar o posicionamento comercial.

O whole product não é um checklist universal do "SaaS enterprise perfeito".

Ele é a tradução concreta da pergunta:

o que precisa ser acrescentado em volta do nosso core product para que os clientes que escolhemos atender consigam realmente comprar o produto?

Entender a necessidade por trás do pedido

Isso não quer dizer que a gente precise responder literalmente a cada pedido do cliente.

Quando uma grande corporação diz:

Quero os meus dados no meu Azure.

A resposta certa não é imediatamente:

Combinado, vamos construir o BYO-Database.

É preciso entender por quê.

É uma obrigação regulatória?

Uma exigência de residência?

Uma política do CISO?

Uma necessidade de controlar as chaves?

Uma restrição de auditoria?

Uma vontade de reversibilidade?

Ou simplesmente uma cultura segundo a qual os dados sensíveis precisam ficar sob controle direto da empresa?

A solução pode depender dessa resposta.

Uma região dedicada às vezes já basta.

Customer Managed Key às vezes já basta.

Um ambiente single-tenant às vezes já basta.

Em outros casos, vai ser realmente preciso hospedar o banco no tenant do cliente.

Entender por que o cliente pede controle permite oferecer o nível certo de controle.

Mas isso não muda a constatação do começo.

Se decidimos vender para as grandes corporações, a cultura de governança delas faz parte do mercado.

Não dá para querer os volumes, os orçamentos e os contratos delas e, ao mesmo tempo, tratar as restrições de auditoria, de segurança ou de controle delas como detalhes incômodos.

Isso não é uma estratégia de infraestrutura

Esse é provavelmente o ponto mais importante.

À primeira vista, esse assunto todo parece uma discussão de arquitetura.

Onde hospedar o SQL Server?

Como conectar o motor?

Como migrar o esquema?

Como monitorar?

Como cuidar dos backups?

São perguntas de verdade.

Mas elas vêm depois de outra:

quais clientes decidimos atender?

O core product cria o valor.

O posicionamento escolhe o mercado.

E o whole product torna o core product compatível com a realidade desse mercado.

Se as grandes corporações que queremos atender têm uma cultura forte de controle dos dados, das identidades, das chaves e dos provedores delas, então algumas dessas capacidades provavelmente precisam virar um componente do nosso whole product.

Não porque o BYO seja melhor que o full-managed.

O full-managed provavelmente deve continuar sendo a escolha padrão.

Ele continua mais simples de operar, mais homogêneo e mais fácil de fazer evoluir.

O BYO vira uma opção quando o mercado justifica.

E o perímetro dele precisa ser decidido da mesma maneira.

Não precisamos tornar cada componente intercambiável.

Não precisamos dar suporte a todas as tecnologias.

Precisamos, sobretudo, identificar as restrições que realmente impedem os clientes que escolhemos atender de comprar o nosso produto.

E depois decidir quais delas queremos derrubar.

O BYO não é, portanto, antes de mais nada uma estratégia de infraestrutura. É uma decisão de whole product e de posicionamento comercial.

A consequência técnica pode ser um SaaS mais modular.

O motor continua sob o nosso controle.

Alguns dados ficam no cliente.

Alguns provedores viram substituíveis.

Algumas responsabilidades mudam de mão.

Mas não é esse o ponto de partida.

O ponto de partida continua sendo o mercado.

Não buscamos dar todas as escolhas possíveis a todos os clientes. Buscamos construir o whole product que permite ao nosso core product ser comprado pelos clientes que decidimos atender.