Portali, sotto-account e organizzazioni annidate: la questione multi-tenant per gli enti di formazione

Quando un ente di formazione si aggiudica un cliente che vuole la propria academy brandizzata, è l'architettura della piattaforma sottostante a decidere se sarà un pomeriggio di configurazione o un progetto di sei settimane. Tre cose diverse vengono vendute come multi-tenancy: i portali, i sotto-account e le organizzazioni davvero annidate. Solo la terza dà a un cliente un proprio dominio, propri amministratori, una propria reportistica e un confine sui dati che tiene anche quando uno sviluppatore si dimentica un filtro.

La distinzione sembra un dettaglio da fornitori finché un cliente non chiede qualcosa che il modello non riesce a esprimere. A quel punto diventa un problema commerciale, perché quello che può vendere è limitato da quello che riesce a separare.

Che cosa chiede davvero un cliente

Se riduce all'osso il documento dei requisiti, restano quattro richieste. Arrivano più o meno in quest'ordine, e le fa quasi ogni cliente che la paga per formare le proprie persone.

1. Un proprio dominio. `learn.acmecorp.com`, non `yourcompany.lms-vendor.com/acme`. Con un certificato che non fa protestare il browser.
2. Propri amministratori. Qualcuno dalla parte del cliente che possa aggiungere utenti, pubblicare un corso ed estrarre un report senza prima scriverle una email.
3. Una propria reportistica. Numeri sulle proprie persone e su nessun altro, in una forma che possano mettere davanti al proprio consiglio.
4. I propri dati separati da quelli degli altri clienti. Di solito viene posta come una domanda di sicurezza, ed è sempre quella che l'ufficio acquisti fa salire di livello.

Ogni architettura risponde ad alcune di queste e fallisce sulle altre. I fallimenti sono prevedibili, una volta che sa su quale modello sta poggiando.

Tre architetture, tre soffitti

I tre modelli qui sotto non sono una scala di maturità. Sono prodotti diversi per acquirenti diversi, e ciascuno ha un punto preciso in cui si ferma.

Portali

Un portale è una porta d'ingresso separata su un deposito condiviso di contenuti e utenti. Si definisce un pubblico — i dipendenti, i partner, una singola azienda cliente — gli si dà un URL e un tema, e gli si assegnano delle persone. Diverse piattaforme corporate sono costruite attorno a questa forma; LearnUpon è l'esempio più chiaro, con l'erogazione multi-portale al centro del prodotto.

I portali rispondono bene alla prima richiesta. Il cliente ottiene una porta d'ingresso che sembra la sua, e i discenti che entrano non vedono mai gli altri pubblici. Per un'azienda che forma dipendenti, partner e clienti da un solo account, spesso è la quantità di struttura giusta.

L'elenco dei portali è piatto, ed è lì che si ferma. Un cliente con tre aree geografiche e un direttore della formazione a livello di gruppo non è un portale, e non sono nemmeno tre portali slegati tra loro. Gli enti che stanno su un modello piatto finiscono per codificare nei nomi la gerarchia mancante — `Acme`, `Acme - EMEA`, `Acme - APAC` — e poi per ricostruire a mano la vista di gruppo in un foglio di calcolo ogni trimestre. I ruoli di amministratore hanno lo stesso problema: i diritti si assegnano per portale, quindi il direttore di gruppo riceve tre assegnazioni che nessuno si ricorda di revocare quando un'area chiude.

Sotto-account

I sotto-account di solito arrivano dal sistema di fatturazione e non dal modello dei dati. Un account pagante possiede alcuni account figli, normalmente su un solo livello, che condividono una tabella utenti, un abbonamento e spesso un unico dominio con un percorso per ogni figlio. TalentLMS è franco sul fatto che questa è una separazione più leggera della multi-tenancy piena con domini personalizzati per tenant, e per un piccolo team che forma il proprio personale quella leggerezza è un pregio, non un difetto.

La domanda che vale la pena fare è dove viene imposto il confine. Se un sotto-account è una colonna su una riga, allora la separazione è quello che il codice applicativo si ricorda di filtrare.

-- Un confine che vive nel codice applicativo
select * from enrolments where account_id = :current_account;

-- Un confine che vive nel database
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

La prima query è corretta fino al momento esatto in cui qualcuno costruisce un nuovo endpoint di esportazione e si lascia fuori la clausola `where`. La seconda resta corretta comunque, perché è il database a rifiutarsi di restituire le righe. È questo scarto che l'ufficio acquisti sta cercando a tentoni quando chiede come vengono tenuti separati i dati dei clienti, anche quando lo chiede con il vocabolario delle certificazioni e degli audit.

Organizzazioni annidate

Nel terzo modello l'organizzazione è un record di prima classe, e un'organizzazione può avere un genitore. Brand, dominio, utenti, ruoli, contenuti, iscrizioni e reportistica pendono tutti da lì. Il suo ente di formazione è un'organizzazione. Ogni cliente è un'organizzazione dentro la sua. Le aree del cliente sono organizzazioni dentro quella del cliente, fino a dove arriva la sua struttura reale.

Your training company              you administer everything below
├── Acme Corp                      learn.acmecorp.com
│   ├── Acme EMEA                  regional admin, EMEA data only
│   └── Acme APAC
├── Borden Group                   training.bordengroup.com
│   └── Borden Manufacturing
└── Public catalogue               open enrolments, your brand

Ne seguono due cose che un modello piatto non può darle. La prima è che la forma propria del cliente è rappresentabile senza convenzioni di denominazione: non sta codificando una gerarchia dentro delle stringhe. La seconda è l'ambito: un ruolo assegnato su un nodo vale per tutto ciò che sta sotto quel nodo. Il direttore della formazione di Acme vede Acme e tutte e due le aree. Il responsabile EMEA vede EMEA. Lei vede tutto. Nessuno in Borden vede niente di tutto questo, e niente di tutto questo è un report che qualcuno ha scritto a mano.

Cambia anche che cosa significa l'uscita di un cliente. Quando un cliente lascia un sistema piatto, qualcuno scorre una lista di controllo di portali, utenti, gruppi e report sperando che la lista sia completa. Quando un cliente è un sottoalbero, si cancella il sottoalbero, e tutto quello che ci pendeva sotto se ne va con lui.

Come ciascun modello risponde alle quattro richieste

• Un proprio dominio. Portali: di solito sì, uno per portale, a volte a costo aggiuntivo. Sotto-account: spesso un percorso o un sottodominio del dominio del fornitore anziché il dominio del cliente. Organizzazioni annidate: un dominio per organizzazione, a qualunque profondità, se la piattaforma emette i certificati in automatico.
• Propri amministratori. Portali: sì, ma limitati al singolo portale, quindi un amministratore a livello di gruppo ha bisogno di un'assegnazione per ogni portale. Sotto-account: di solito gli amministratori del genitore con una vista filtrata. Organizzazioni annidate: un amministratore su qualunque nodo, con diritti che scendono a cascata su tutto ciò che sta sotto.
• Una propria reportistica. Portali: per portale, con aggregazioni tra portali che dipendono dal prodotto. Sotto-account: tipicamente un unico report con un filtro, il che va bene finché un cliente non chiede di vederlo da solo. Organizzazioni annidate: ogni nodo è un ambito di reportistica, così la vista di gruppo e la vista di area sono la stessa query a due altezze diverse.
• I propri dati separati. Portali e sotto-account: separati quanto li rende il codice applicativo. Organizzazioni annidate: separati quanto la piattaforma impone sotto il livello applicativo — chieda, esplicitamente, se la regola sta nel database.

Niente di tutto questo rende i portali sbagliati. Li rende un prodotto diverso per un acquirente diverso. L'errore è comprare un modello a portali perché la demo ha mostrato un cambio di logo, e scoprire il soffitto il giorno in cui firma un cliente che ha delle aree.

Cinque domande da porre a un fornitore

1. Un'organizzazione può contenere un'altra organizzazione, e fin dove si può scendere?
2. Se assegno a qualcuno un ruolo di amministratore su un nodo, vale per tutto ciò che sta sotto, o devo riassegnarlo a ogni livello?
3. Il confine tra tenant è imposto nel database o nel codice applicativo?
4. Ogni cliente può avere il proprio dominio e il proprio certificato, o solo una sottocartella del vostro?
5. Quando un cliente se ne va, che cosa cancella esattamente la sua rimozione — e me lo potete mostrare?

Chieda le risposte in un documento condiviso e non in una chiamata. La seconda domanda in particolare tende a produrre la demo di una schermata invece di una risposta, e la differenza tra le due cose è un anno di assegnazioni manuali.

Perché la risposta decide che cosa può vendere

Se la sua piattaforma sa personalizzare graficamente una sola porta d'ingresso, sta vendendo dei posti sul suo sistema. Il personale del cliente entra nel suo brand, il responsabile della formazione del cliente chiede i numeri a lei, e ogni rinnovo è una conversazione sul costo per utente della sua piattaforma.

Se può consegnare a un cliente un dominio, degli amministratori, una reportistica e un confine che sopravvive a una verifica di sicurezza, gli sta vendendo la sua academy. È un contratto diverso. Si rinnova in modo diverso, perché a quel punto il cliente ha dentro i propri amministratori con le proprie abitudini e i propri contenuti, e sopravvive a un cambio di referente dalla sua parte.

L'altra metà è operativa. Gli enti a cui un modello piatto sta stretto finiscono spesso per gestire un'installazione per cliente. Moodle dice esplicitamente che la multi-tenancy non fa parte del prodotto core: separare campus o organizzazioni clienti significa Moodle Workplace, un contratto con un partner, oppure installazioni parallele. Installazioni parallele significano aggiornamenti paralleli, backup paralleli, patch di sicurezza parallele e uno strato di reportistica che si ricostruisce fuori dalla piattaforma. Funziona finché ha più personale che clienti.

Dove si colloca Lurno

Lurno è costruito sul terzo modello. Un'organizzazione può contenere sotto-organizzazioni, ciascuna con il proprio brand e il proprio dominio personalizzato con TLS automatico. Dentro un'organizzazione c'è un secondo albero di rami, e un ruolo assegnato a un ramo scende a cascata lungo di esso — che è la risposta alla seconda domanda al fornitore qui sopra, e la ragione per cui un direttore della formazione di gruppo è una sola assegnazione e non una per area.

Il confine è imposto in Postgres e non nell'applicazione: 868 policy di sicurezza a livello di riga distribuite su 676 migrazioni, così un filtro mancante in un endpoint nuovo restituisce niente invece di restituire i discenti di qualcun altro. È l'affermazione che vale la pena verificare con qualsiasi fornitore, il nostro compreso: i dettagli sono sulla pagina sicurezza, e il lato brand e domini è su white-label.

Due forme che questo modello già regge, senza fare nomi: un'academy aziendale che gestisce la formazione per 15 aziende clienti da un solo tenant, e un editore K-12 che gestisce 114 scuole su un'unica piattaforma. Sono la stessa struttura a due larghezze diverse.

Due limiti che vale la pena dire chiaramente, perché cambiano la valutazione. I pagamenti e il checkout sono in sviluppo: oggi il cliente viene fatturato fuori dalla piattaforma, quindi se le serve che i discenti paghino con carta al momento dell'iscrizione, è una conversazione da fare e non una funzionalità. E l'accesso partner (silent SSO) è disponibile, ma SAML e OIDC sono in roadmap e non rilasciati; se l'ufficio IT di un cliente ha già deciso come si autenticherà il suo personale, chieda di questo prima di ogni altra cosa. Il resto del modello per gli enti che rivendono formazione è esposto sulla pagina per gli enti di formazione.

La versione breve

I portali danno a un cliente una porta d'ingresso. I sotto-account danno a un cliente una vista filtrata. Le organizzazioni annidate danno a un cliente un confine, ed è il confine la cosa a cui può mettere un prezzo. Capisca quale dei tre sta comprando prima che un cliente le chieda la cosa che il suo modello non sa dire.