Per molto tempo la promessa del SaaS è stata piuttosto semplice.

Tu usi il software. Al resto pensiamo noi.

Gestiamo l'applicazione, scegliamo l'infrastruttura, ospitiamo il database, garantiamo i backup e facciamo evolvere il prodotto.

Il cliente compra un servizio finito.

Questa promessa resta valida. Ma nelle discussioni con i grandi gruppi vedo comparire sempre più richieste che la fanno evolvere.

«I dati possono restare nel nostro ambiente Azure?»

«Possiamo usare il nostro SQL Server?»

«Possiamo usare le nostre chiavi di cifratura?»

«Possiamo gestire gli utenti e i loro diritti dal nostro IAM?»

«Possiamo usare il nostro contratto e il nostro fornitore di LLM?»

«Possiamo usare il nostro fornitore di email o di SMS?»

«Possiamo inviare gli eventi di sicurezza nel nostro SIEM?»

Queste richieste possono sembrare molto diverse tra loro.

In realtà raccontano spesso la stessa cosa.

I grandi gruppi vogliono continuare a comprare SaaS, ma vogliono riprendere il controllo di alcuni blocchi.

E questo cambiamento non è solo tecnico o normativo.

È anche culturale.

Quando la cultura del cliente diventa una componente del prodotto

Prendiamo una richiesta molto semplice:

«Voglio sapere chi si connette all'applicazione.»

Tecnicamente non è per forza una funzionalità spettacolare.

Ma dietro quella frase possono esserci un audit ISO, una policy di sicurezza, un team di cybersecurity, un SIEM centrale, una procedura di investigazione o semplicemente una cultura aziendale in cui ogni accesso deve essere tracciabile.

Lo stesso vale per la gestione degli utenti.

Il cliente può non voler amministrare i diritti dentro ogni SaaS che compra. Vuole che identità, gruppi e a volte diritti siano guidati dal suo IAM.

Si potrebbero guardare alcune di queste richieste e concludere che non creano alcun valore di business.

E sarebbe vero.

Ma sarebbe anche mancare il punto.

Il prodotto che costruiamo per risolvere il problema di business del cliente è solo una parte di ciò che lui compra davvero.

È qui che la distinzione tra core product e whole product diventa utile.

Il core product concentra ciò che costituisce realmente il nostro valore: la nostra conoscenza del dominio, le nostre regole, i nostri workflow, la nostra orchestrazione, la nostra capacità di risolvere un problema meglio di un'alternativa.

Il whole product è tutto ciò che serve intorno a quel valore perché un dato cliente possa effettivamente comprare, installare e usare il prodotto.

L'SSO probabilmente non è la nostra differenziazione.

Nemmeno il SIEM.

Nemmeno la residenza dei dati.

Nemmeno la capacità di usare l'IAM del cliente.

Ma l'assenza di uno solo di questi elementi può bastare a bloccare una vendita.

Non creano necessariamente il valore.

Permettono a quel valore di entrare in azienda.

«Voglio usare il vostro SaaS, ma tenermi il database in casa»

Il caso più interessante è probabilmente quello del database.

Immaginiamo un software di gestione delle buste paga.

Tutti capiscono subito la natura dei dati in gioco: stipendi, contratti, informazioni personali, organizzazione dell'azienda.

Nel modello SaaS classico, l'editore gestisce il software e il database che lo accompagna.

Ora immaginiamo un grande gruppo che ci dice:

Vogliamo la vostra applicazione, ma i dati devono restare in un database SQL Server o Azure SQL collocato nel nostro ambiente Azure.

Non è una richiesta assurda.

E nel nostro caso è perfino coerente con il mercato che vogliamo servire: la stragrande maggioranza dei clienti a cui puntiamo vive già nell'ecosistema Microsoft.

Il motore del SaaS resterebbe gestito dall'editore.

Ma il suo database potrebbe essere ospitato nell'ambiente del cliente.

Perché un cliente dovrebbe chiedere una cosa simile, se sappiamo benissimo ospitare un database?

Perché la sua domanda non è necessariamente:

«Siete capaci di ospitare bene i miei dati?»

Può essere:

«I miei dati restano sotto il controllo della mia organizzazione?»

Il cliente a volte vuole che la risorsa si trovi nella sua sottoscrizione Azure.

Vuole applicare le sue regole di rete.

Le sue policy di sicurezza.

Le sue chiavi.

I suoi meccanismi di inventario.

I suoi controlli.

I suoi standard interni.

E soprattutto poter dire al suo CISO, al suo auditor o alla sua organizzazione:

«Questi dati restano da noi.»

Non è sempre un obbligo normativo.

Può essere semplicemente una condizione perché l'azienda accetti il prodotto.

Controllare dove vivono i dati non significa controllare il prodotto

Dare più controllo al cliente introduce però un confine da preservare.

Il motore di business resta all'editore.

La sua proprietà intellettuale resta all'editore.

E soprattutto la sua capacità di far evolvere il prodotto deve restare all'editore.

Prendiamo le migrazioni del database.

Supponiamo di aggiungere una funzionalità che richiede una nuova colonna, un indice o un'evoluzione dello schema.

Se ogni messa in produzione impone di inviare una procedura al team del cliente, aspettare una validazione, prenotare una finestra di manutenzione e poi verificare manualmente che la migrazione sia stata applicata, il modello non regge.

È già difficilmente compatibile con un SaaS che rilascia più volte a settimana.

E lo sarà ancora meno domani.

Lo sviluppo software assistito dall'IA sta già aumentando la nostra capacità di produrre, testare e modificare software. È ragionevole pensare che la cadenza di rilascio continuerà a crescere.

Costruire oggi un'architettura che richiede più interventi umani presso ogni cliente a ogni evoluzione andrebbe esattamente nella direzione opposta.

Molto presto un cliente applica la migrazione martedì.

Un altro aspetta venerdì.

Un terzo la rimanda al mese successivo.

Ci si ritrova con più versioni del motore, più stati dello schema e una complessità che cresce a ogni release.

Si finisce per perdere uno dei vantaggi strutturali del SaaS: far evolvere in continuo un prodotto comune a tutti i clienti.

Ma il cliente che chiede di tenere i propri dati nel suo ambiente non chiede necessariamente di gestire le nostre migrazioni.

Vuole il controllo su dove vivono i suoi dati.

Non su come evolve il nostro prodotto.

Il confine diventa allora piuttosto semplice:

il cliente controlla dove vivono i suoi dati; l'editore controlla come evolve il prodotto.

Il BYO-Database è quindi davvero compatibile con il SaaS solo se le migrazioni restano automatizzate e guidate dall'editore, dentro un perimetro di sicurezza accettato dal cliente.

Il controllo sposta anche le responsabilità

Spostare il database nell'ambiente del cliente produce un'altra conseguenza.

Una parte dell'infrastruttura da cui dipende il nostro servizio non è più interamente sotto il nostro controllo.

E il giorno in cui l'applicazione cade, quella distinzione diventa molto concreta.

È il nostro motore?

Il database SQL Server del cliente?

Azure?

Una regola di rete appena modificata?

Un certificato?

Una configurazione IAM?

Una saturazione delle connessioni?

Una quota?

Un problema di latenza?

Dire:

«Il database è dal cliente, non è un problema nostro»

non funziona.

Per l'utente è il nostro SaaS che non funziona più.

Il BYO impone quindi un requisito che mi sembra non negoziabile: dobbiamo poter monitorare il database e la sua connettività quanto basta per capire da dove arriva un incidente.

Questo non significa amministrare tutta l'infrastruttura al posto del cliente.

Significa disporre dei segnali necessari: disponibilità, latenza, errori di connessione, saturazione, stato di salute, eventi utili alla diagnosi.

Questa osservabilità è indispensabile sul piano operativo.

Ma lo è anche su quello contrattuale.

Se il nostro SLA esclude i guasti provocati da una risorsa sotto il controllo del cliente, dobbiamo essere in grado di stabilire oggettivamente che l'incidente veniva proprio da quella risorsa.

La condivisione delle responsabilità esiste davvero solo se si possono attribuire gli incidenti.

Il cliente paga il suo database. Eppure il suo SaaS può costare di più.

È qui che compare un paradosso interessante.

Il cliente può pagare direttamente il suo Azure SQL o il suo SQL Server.

Si potrebbe quindi pensare:

Dato che paga lui il database, il nostro SaaS dovrebbe costare meno.

Non necessariamente.

Il nostro costo di servizio non si limita al prezzo dell'infrastruttura.

Supportare database negli ambienti dei clienti può obbligarci a gestire più varianti.

Versioni diverse.

Vincoli di rete diversi.

Meccanismi di replica.

Backup.

Snapshot.

Ripristini.

Diritti.

Monitoring.

Configurazioni specifiche.

E soprattutto più scenari da capire quando qualcosa smette di funzionare.

Esternalizzare una risorsa può quindi ridurre il nostro costo infrastrutturale diretto aumentando però il nostro costo di servizio.

I backup illustrano bene questa divisione.

Se ci impegniamo a gestire i backup e a garantire il ripristino di un database che si trova nell'ambiente del cliente, ci prendiamo una responsabilità in più.

Che richiede tecnologia.

Test.

Monitoring.

Procedure di ripristino.

Quella responsabilità ha quindi un costo e va fatturata.

Al contrario, il cliente può scegliere di gestire da sé i propri backup.

In quel caso le responsabilità devono essere esplicite: retention, qualità dei backup, ripristino e conseguenze di un backup inutilizzabile devono ricadere su di lui.

Il BYO non fa sparire le responsabilità.

Obbliga semplicemente a dire molto più precisamente chi porta quali.

Non tutti i blocchi devono restare da noi

Una volta posto questo ragionamento, il database appare come il caso più difficile di un fenomeno più generale.

Una domanda semplice aiuta a ragionare sugli altri blocchi:

se sostituisco questo fornitore con un altro, il valore del mio servizio cambia?

Prendiamo l'invio delle email.

Se sostituiamo il nostro fornitore di email con quello del cliente, il valore di business del nostro prodotto cambia?

Probabilmente no.

Il messaggio parte sempre al momento giusto perché il nostro motore ha deciso che doveva partire.

Lo stesso vale per un SMS.

Lo stesso vale, in certi casi, per un LLM.

Il nostro prodotto può fornire di default un modello di IA.

Ma un grande gruppo può preferire usare il proprio contratto Azure OpenAI, le proprie chiavi o un fornitore già approvato.

Se il nostro valore sta nel workflow di business, nel contesto, nelle regole, nei dati e nell'orchestrazione, cambiare il modello di esecuzione non deve spostare il cuore del prodotto.

Questo non significa che tutti i fornitori siano perfettamente intercambiabili.

Un modello può essere più performante di un altro.

Un fornitore di email può avere una migliore deliverability.

Ma la domanda giusta resta:

è questo blocco a portare il valore per cui il cliente compra il nostro prodotto?

Se sostituire un fornitore distrugge il valore del servizio, quel fornitore è probabilmente troppo vicino al nostro core product per essere liberamente sostituibile.

Se sostituirlo non cambia il valore di business fondamentale, può diventare candidato alla configurazione, alla sostituzione o al BYO.

Non tutte le sostituzioni costano uguale

Resta una differenza importante.

Un gateway email è relativamente stateless.

Lo stesso vale per un provider SMS.

E anche un LLM può esserlo, a patto che la memoria durevole, il contesto di business e le decisioni restino nel nostro prodotto.

Un database è un'altra cosa.

Contiene lo stato durevole del sistema.

Non si passa da un SQL Server a un altro cambiando semplicemente una chiave API.

Bisogna migrare i dati.

Garantirne la coerenza.

Prevedere il ripristino.

Gestire i backup.

A volte la replica.

La sostituibilità non è quindi binaria.

È un gradiente.

Un blocco può non essere differenziante per il nostro prodotto ed essere comunque estremamente importante dal punto di vista operativo.

Vale in particolare per il database.

Non trasformare il whole product in un catalogo

A questo punto la tentazione potrebbe essere costruire tutte le possibilità.

Azure.

AWS.

GCP.

SQL Server.

PostgreSQL.

Oracle.

Cinque fornitori di IA.

Tre fornitori di email.

Quattro gateway SMS.

Sarebbe probabilmente un errore.

La domanda giusta non è:

«Che cosa possiamo supportare tecnicamente?»

Ma:

«Che cosa dobbiamo supportare per i clienti che abbiamo scelto di servire?»

Se il 90% dei grandi gruppi a cui puntiamo è già strutturato intorno a Microsoft e Azure, partire da Azure e SQL Server ha senso.

Non perché SQL Server sia intrinsecamente migliore di un altro database.

Ma perché quella configurazione è quella che massimizza, con ogni probabilità, la nostra capacità di vendere sul mercato che abbiamo scelto.

Al contrario, supportare un database o un cloud che nessuno nel nostro segmento chiede non aggiunge necessariamente valore.

L'ampiezza del supporto tecnologico non è un obiettivo in sé.

Deve seguire il posizionamento commerciale.

Il whole product non è una checklist universale del «SaaS enterprise perfetto».

È la traduzione concreta della domanda:

che cosa serve aggiungere intorno al nostro core product perché i clienti che abbiamo scelto di servire possano davvero comprarlo?

Capire il bisogno dietro la richiesta

Questo non significa che si debba rispondere alla lettera a ogni richiesta del cliente.

Quando un grande gruppo dice:

Voglio i miei dati nel mio Azure.

La risposta giusta non è subito:

D'accordo, costruiamo il BYO-Database.

Bisogna capire perché.

È un obbligo normativo?

Un requisito di residenza?

Una policy del CISO?

Un bisogno di controllare le chiavi?

Un vincolo di audit?

Una volontà di reversibilità?

O semplicemente una cultura secondo cui i dati sensibili devono restare sotto il controllo diretto dell'azienda?

La soluzione può dipendere da questa risposta.

A volte può bastare una regione dedicata.

A volte può bastare la Customer Managed Key.

A volte può bastare un ambiente single-tenant.

In altri casi bisognerà davvero ospitare il database nel tenant del cliente.

Capire perché il cliente chiede controllo permette di proporgli il giusto livello di controllo.

Ma questo non cambia la constatazione di partenza.

Se decidiamo di vendere ai grandi gruppi, la loro cultura di governance fa parte del mercato.

Non si possono volere i loro volumi, i loro budget e i loro contratti considerando al tempo stesso i loro vincoli di audit, sicurezza o controllo come dettagli fastidiosi.

Non è una strategia di infrastruttura

È probabilmente il punto più importante.

A prima vista tutto questo tema sembra una discussione di architettura.

Dove ospitare SQL Server?

Come collegare il motore?

Come migrare lo schema?

Come monitorare?

Come gestire i backup?

Sono domande vere.

Ma vengono dopo un'altra:

quali clienti abbiamo deciso di servire?

Il core product crea il valore.

Il posizionamento sceglie il mercato.

E il whole product rende il core product compatibile con la realtà di quel mercato.

Se i grandi gruppi che vogliamo servire hanno una cultura forte del controllo sui propri dati, sulle proprie identità, sulle proprie chiavi e sui propri fornitori, allora alcune di queste capacità devono probabilmente diventare una componente del nostro whole product.

Non perché il BYO sia migliore del full-managed.

Il full-managed deve probabilmente restare la scelta di default.

Resta più semplice da gestire, più omogeneo e più facile da far evolvere.

Il BYO diventa un'opzione quando il mercato lo giustifica.

E il suo perimetro va deciso allo stesso modo.

Non abbiamo bisogno di rendere ogni componente intercambiabile.

Non abbiamo bisogno di supportare tutte le tecnologie.

Dobbiamo soprattutto individuare i vincoli che impediscono davvero ai clienti che abbiamo scelto di servire di comprare il nostro prodotto.

E poi decidere quali vogliamo rimuovere.

Il BYO non è quindi prima di tutto una strategia di infrastruttura. È una decisione di whole product e di posizionamento commerciale.

La conseguenza tecnica può essere un SaaS più modulare.

Il motore resta sotto il nostro controllo.

Alcuni dati restano dal cliente.

Alcuni fornitori diventano sostituibili.

Alcune responsabilità cambiano di mano.

Ma non è il punto di partenza.

Il punto di partenza resta il mercato.

Non cerchiamo di dare tutte le scelte possibili a tutti i clienti. Cerchiamo di costruire il whole product che permette al nostro core product di essere comprato dai clienti che abbiamo deciso di servire.