Portalen, subaccounts en geneste organisaties: de multi-tenantvraag voor opleiders

Wanneer een opleider een klant wint die een eigen gebrande academie wil, bepaalt de architectuur van het platform eronder of dat een middag inrichten is of een project van zes weken. Er worden drie verschillende dingen verkocht als multi-tenancy: portalen, subaccounts, en werkelijk geneste organisaties. Alleen het derde geeft een klant een eigen domein, eigen beheerders, eigen rapportage, en een datagrens die ook standhoudt wanneer een ontwikkelaar een filter vergeet.

Het onderscheid leest als leveranciersdetail tot een klant om iets vraagt wat het model niet kan uitdrukken. Dan wordt het een commercieel probleem, want wat u kunt verkopen wordt begrensd door wat u kunt scheiden.

Waar een klant werkelijk om vraagt

Kleed het programma van eisen uit en er blijven vier verzoeken over. Ze komen ongeveer in deze volgorde, en bijna elke klant die u betaalt om zijn mensen op te leiden, vraagt erom.

1. Een eigen domein. `learn.acmecorp.com`, niet `yourcompany.lms-vendor.com/acme`. Met een certificaat waar de browser niet over klaagt.
2. Eigen beheerders. Iemand aan de kant van de klant die gebruikers kan toevoegen, een cursus kan publiceren en een rapportage kan ophalen zonder u eerst te mailen.
3. Eigen rapportage. Cijfers over hun mensen en niemand anders, in een vorm die zij aan hun eigen directie kunnen voorleggen.
4. Hun data gescheiden van die van andere klanten. Meestal gesteld als beveiligingsvraag, altijd de vraag die inkoop escaleert.

Elke architectuur beantwoordt sommige hiervan en faalt op andere. De mislukkingen zijn voorspelbaar zodra u weet op welk model u staat.

Drie architecturen, drie plafonds

De drie modellen hieronder zijn geen volwassenheidsladder. Het zijn verschillende producten voor verschillende kopers, en elk heeft een specifiek punt waarop het ophoudt.

Portalen

Een portaal is een aparte voordeur naar een gedeelde stapel content en gebruikers. U definieert een doelgroep — medewerkers, partners, één klantbedrijf — geeft die een URL en een thema, en wijst er mensen aan toe. Meerdere corporate platforms zijn rond deze vorm gebouwd; LearnUpon is het duidelijkste voorbeeld, met levering via meerdere portalen als kern van het product.

Portalen beantwoorden het eerste verzoek goed. Een klant krijgt een voordeur die eruitziet als de zijne, en cursisten die inloggen zien de andere doelgroepen nooit. Voor een bedrijf dat medewerkers, partners en klanten vanuit één account opleidt, is dat vaak precies genoeg structuur.

De lijst met portalen is plat, en daar houdt het op. Een klant met drie regio's en een opleidingsdirecteur op groepsniveau is niet één portaal, en het zijn ook niet drie losstaande portalen. Aanbieders op een plat model coderen de ontbrekende hiërarchie uiteindelijk in namen — `Acme`, `Acme - EMEA`, `Acme - APAC` — en zetten het groepsbeeld daarna elk kwartaal met de hand in een spreadsheet weer in elkaar. Beheerdersrollen hebben hetzelfde probleem: rechten worden per portaal toegekend, dus de groepsdirecteur krijgt drie toekenningen die niemand zich herinnert in te trekken wanneer een regio sluit.

Subaccounts

Subaccounts komen meestal uit het facturatiesysteem in plaats van uit het datamodel. Eén betalend account bezit een aantal onderliggende accounts, normaal gesproken één niveau diep, met een gedeelde gebruikerstabel, een gedeeld abonnement en vaak één domein met een pad per onderliggend account. TalentLMS is er open over dat dit een lichtere scheiding is dan volledige multi-tenancy met eigen domeinen per tenant, en voor een klein team dat personeel opleidt is die lichtheid een pluspunt, geen gebrek.

De vraag die het waard is te stellen, is waar de grens wordt afgedwongen. Is een subaccount een kolom op een rij, dan is de scheiding precies datgene waar de applicatiecode aan denkt te filteren.

-- A boundary that lives in application code
select * from enrolments where account_id = :current_account;

-- A boundary that lives in the database
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

De eerste query is correct tot precies het moment waarop iemand een nieuw exportendpoint bouwt en de `where`-clausule weglaat. De tweede blijft hoe dan ook correct, omdat de database weigert de rijen terug te geven. Dat gat is waar inkoop naar tast wanneer het vraagt hoe klantdata gescheiden wordt gehouden, ook wanneer het die vraag stelt in het vocabulaire van certificeringen en audits.

Geneste organisaties

In het derde model is de organisatie een eersteklas record, en kan een organisatie een ouder hebben. Huisstijl, domein, gebruikers, rollen, content, inschrijvingen en rapportage hangen er allemaal aan. Uw opleidingsbedrijf is een organisatie. Elke klant is een organisatie binnen die van u. De regio's van de klant zijn organisaties binnen die van hen, zo diep als hun werkelijke structuur gaat.

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

Daaruit volgen twee dingen die een plat model u niet kan geven. Het eerste is dat de eigen vorm van een klant weer te geven is zonder naamgevingsafspraken — u codeert geen hiërarchie in tekenreeksen. Het tweede is bereik: een rol die op een node wordt toegekend, geldt voor alles onder die node. De opleidingsdirecteur van Acme ziet Acme en beide regio's. De EMEA-manager ziet EMEA. U ziet het geheel. Niemand bij Borden ziet er iets van, en niets daarvan is een rapportage die iemand met de hand heeft geschreven.

Het verandert ook wat offboarding betekent. Verlaat een klant een plat systeem, dan loopt iemand een checklist af van portalen, gebruikers, groepen en rapportages, in de hoop dat de lijst compleet is. Is een klant een deelboom, dan verwijdert u de deelboom, en alles wat eraan hing gaat mee.

Hoe elk model de vier verzoeken beantwoordt

• Een eigen domein. Portalen: meestal wel, één per portaal, soms tegen meerkosten. Subaccounts: vaak een pad of een subdomein van het domein van de leverancier in plaats van dat van de klant zelf. Geneste organisaties: een domein per organisatie, op elke diepte, als het platform automatisch certificaten uitgeeft.
• Eigen beheerders. Portalen: ja, maar afgebakend tot dat ene portaal, dus een beheerder op groepsniveau heeft een toekenning per portaal nodig. Subaccounts: meestal de beheerders van de ouder met een gefilterd beeld. Geneste organisaties: een beheerder op elke node, met rechten die doorwerken naar alles eronder.
• Eigen rapportage. Portalen: per portaal, met totalen over portalen heen afhankelijk van het product. Subaccounts: doorgaans één rapportage met een filter, wat prima is tot een klant hem zelf wil zien. Geneste organisaties: elke node is een rapportagebereik, dus het groepsbeeld en het regiobeeld zijn dezelfde query op verschillende hoogtes.
• Hun data gescheiden. Portalen en subaccounts: zo gescheiden als de applicatiecode ze maakt. Geneste organisaties: zo gescheiden als het platform onder de applicatie afdwingt — vraag specifiek of de regel in de database zit.

Niets hiervan maakt portalen verkeerd. Het maakt ze een ander product voor een andere koper. De fout is een portaalmodel kopen omdat de demo een logowissel liet zien, en het plafond ontdekken op de dag dat u een klant met regio's tekent.

Vijf vragen om aan een leverancier te stellen

1. Kan een organisatie een andere organisatie bevatten, en hoe diep gaat dat?
2. Als ik iemand een beheerdersrol op één node toeken, geldt die dan voor alles eronder, of ken ik hem op elk niveau opnieuw toe?
3. Wordt de tenantgrens afgedwongen in de database of in de applicatiecode?
4. Kan elke klant een eigen domein en een eigen certificaat hebben, of alleen een submap van dat van u?
5. Wanneer een klant vertrekt, wat verwijdert het weghalen van die klant dan precies — en kunt u dat laten zien?

Vraag om de antwoorden in een gedeeld document in plaats van in een gesprek. Vooral de tweede vraag levert doorgaans een demo van een scherm op in plaats van een antwoord, en het verschil tussen die twee is een jaar aan handmatige toekenningen.

Waarom het antwoord bepaalt wat u kunt verkopen

Kan uw platform maar één voordeur van een thema voorzien, dan verkoopt u seats op uw systeem. De medewerkers van de klant loggen in op uw merk, de opleidingsmanager van de klant vraagt u om cijfers, en elke verlenging is een gesprek over de kosten per gebruiker van uw platform.

Kunt u een klant een domein, beheerders, rapportage en een grens overhandigen die een securityreview overleeft, dan verkoopt u hun een eigen academie. Dat is een ander contract. Het verlengt anders, want tegen die tijd heeft de klant er eigen beheerders in zitten met eigen gewoonten en eigen content, en het overleeft een wisseling van koper aan hun kant.

De andere helft is operationeel. Aanbieders die een plat model ontgroeien, draaien uiteindelijk vaak één installatie per klant. Moodle is er expliciet over dat multi-tenancy geen onderdeel is van het kernproduct — campussen of klantorganisaties scheiden betekent Moodle Workplace, een partnercontract, of parallelle installaties. Parallelle installaties betekenen parallelle upgrades, parallelle back-ups, parallelle securitypatches en een rapportagelaag die u buiten het platform opnieuw bouwt. Het werkt zolang u meer medewerkers dan klanten heeft.

Waar Lurno staat

Lurno is op het derde model gebouwd. Een organisatie kan suborganisaties bevatten, elk met een eigen huisstijl en een eigen domein met automatische TLS. Binnen een organisatie zit een tweede boomstructuur van vestigingen, en een rol die op een vestiging wordt toegekend werkt naar beneden door — dat is het antwoord op de tweede leveranciersvraag hierboven, en de reden dat een opleidingsdirecteur op groepsniveau één toekenning is in plaats van één per regio.

De grens wordt afgedwongen in Postgres in plaats van in de applicatie: 868 row-level security-policies verspreid over 676 migraties, zodat een ontbrekend filter in een nieuw endpoint niets teruggeeft in plaats van de cursisten van iemand anders. Dat is de claim die het waard is bij elke leverancier te controleren, de onze inbegrepen — de details staan op de beveiligingspagina, en de kant van huisstijl en domeinen staat op white-label.

Twee vormen die hier al op draaien, zonder namen te noemen: een bedrijfsacademie die vanuit één tenant training verzorgt voor 15 klantbedrijven, en een K-12-uitgever die 114 scholen op één platform draait. Beide zijn dezelfde structuur op verschillende breedtes.

Twee beperkingen die het waard zijn ronduit te noemen, want ze veranderen de evaluatie. Betalingen en checkout zijn in ontwikkeling — vandaag wordt een klant buiten het platform gefactureerd, dus heeft u nodig dat cursisten met een kaart betalen op het moment van inschrijven, dan is dat een gesprek en geen functie. En partneraanmelding (silent SSO) is beschikbaar, maar SAML en OIDC staan op de roadmap en zijn niet geleverd; heeft de IT-afdeling van een klant al besloten hoe hun medewerkers zich gaan authenticeren, vraag daar dan vóór al het andere naar. De rest van het model voor aanbieders die training doorverkopen staat op de pagina voor opleiders.

De korte versie

Portalen geven een klant een voordeur. Subaccounts geven een klant een gefilterd beeld. Geneste organisaties geven een klant een grens, en een grens is het ding waar u een prijs op kunt zetten. Zoek uit welke van de drie u koopt voordat een klant u vraagt om het ding dat uw model niet kan zeggen.