La tua holding ha 5 controllate. Vorresti una piattaforma BI per tutte ma con dati separati. Oppure sei un MSP che fornisce servizi IT a 30 clienti. O una software house che vorrebbe rivendere BI ai propri clienti. La soluzione comune: architettura multi-tenant. Vediamo come funziona.
Cosa è multi-tenant
Architettura dove una sola istanza software serve più "tenant" (aziende) con isolamento completo dei dati.
Vantaggi:
- Una sola installazione da manutenere.
- Aggiornamenti centralizzati.
- Costi infrastruttura ridotti per tenant.
- Provisioning rapido nuove aziende.
I 3 modelli di multi-tenancy
1. Database condiviso
Tutti i tenant condividono stesso database. Isolamento via id_azienda in ogni tabella.
Pro: efficiente, semplice gestione.
Contro: rischio di "leak" se bug software.
È il modello di ReportIA.
2. Database separati
Ogni tenant ha database dedicato. Isolamento fisico.
Pro: massima sicurezza.
Contro: gestione complessa, costoso.
3. Istanze separate
Ogni tenant = installazione completamente separata.
Pro: massima flessibilità.
Contro: aggiornamenti complessi, costoso.
Cosa va isolato
Per multi-tenant serio, isolamento totale di:
- Connessioni database (ogni tenant le sue).
- Query salvate.
- Dashboard.
- Cronologia.
- Conversazioni threaded.
- Utenti e ruoli.
- Impostazioni AI (glossario, KPI).
- API Key OpenAI (controllo costi separato).
- Audit log.
- Schedulazioni.
- Link pubblici.
Casi d'uso pratici
Holding multi-società
Holding "Bianchi Group" con 5 controllate:
- Tenant 1: Bianchi srl (commerciale).
- Tenant 2: Bianchi Industria (manifatturiero).
- Tenant 3: Bianchi Logistica.
- Tenant 4: Bianchi Real Estate.
- Tenant 5: Bianchi Finanza.
Ogni tenant ha:
- Suoi database, dashboard, utenti.
- Branding leggermente differenziato.
- Reportistica indipendente.
Holding super admin: vede statistiche consolidate.
MSP / consulenza IT
Studio consulenza che eroga BI a 30 clienti:
- 30 tenant (1 per cliente).
- Ogni cliente vede solo i propri dati.
- MSP super admin per supporto.
- Branding white-label per ogni cliente (logo cliente).
Software house OEM
Software house che integra BI nel proprio gestionale verticale (es. gestionale studi dentistici):
- Ogni studio cliente = tenant.
- BI integrata nel gestionale, brand del gestionale.
- Provisioning automatico al primo login.
Franchising
Catena franchising con 50 punti vendita:
- 1 tenant per franchisee.
- Casa madre vede dati aggregati di tutti.
- Ogni franchisee vede solo il suo.
Provisioning rapido
Aggiunta nuovo tenant in pochi minuti:
- Super admin: "Crea nuovo tenant".
- Inserisce nome, logo, email admin.
- Sistema crea infrastruttura isolata.
- Email di invito al cliente con link e password temporanea.
- Cliente fa login, configura database, inizia.
Tempo: 5-10 minuti.
API Key OpenAI separate
Punto cruciale: ogni tenant ha sua API Key OpenAI.
Vantaggi:
- Trasparenza costi: ogni cliente vede consumo reale.
- Limit budget: configurabile lato OpenAI.
- Compliance: dati cliente passano per la sua API Key.
In alternativa, per piattaforme SaaS centralizzate: API Key del fornitore con costi inclusi.
Super Admin trasversale
Per supporto e amministrazione:
- Vede lista tenant.
- Statistiche utilizzo per tenant.
- Può "entrare" in qualsiasi tenant per supporto.
- Sessione di impersonificazione con bandiera "SuperAdmin in [Nome]".
- Tasto "Torna SuperAdmin" sempre visibile.
- Audit log delle azioni come Super Admin.
Errori da evitare
1. Isolamento solo applicativo, non SQL
Bug software → leak tra tenant. Usa row-level security a livello SQL.
2. Non isolare configurazione AI
Glossario di tenant A non deve influenzare AI di tenant B.
3. Audit log condiviso
Ogni tenant deve avere il suo audit log. Eventualmente anche Super Admin con audit aggregato.
4. Branding non differenziato
Per OEM, branding deve essere completamente personalizzabile.
5. Onboarding complesso
Provisioning manuale per ogni tenant è insostenibile. Automatizza.
I moduli ReportIA correlati
Scopri ReportIA e gestisci più aziende su una sola piattaforma.
