Portale, Unterkonten und verschachtelte Organisationen: die Frage der Mandantenfähigkeit für Weiterbildungsanbieter

Wenn ein Weiterbildungsanbieter einen Kunden gewinnt, der eine eigene gebrandete Akademie will, entscheidet die Architektur der Plattform darunter, ob das ein Nachmittag Konfiguration ist oder ein Projekt über sechs Wochen. Drei verschiedene Dinge werden als Mandantenfähigkeit verkauft: Portale, Unterkonten und echte verschachtelte Organisationen. Nur das dritte gibt einem Kunden eine eigene Domain, eine eigene Administration, eigenes Reporting und eine Datengrenze, die auch dann noch hält, wenn jemand in der Entwicklung einen Filter vergisst.

Die Unterscheidung liest sich wie Anbieter-Kleinkram, bis ein Kunde nach etwas fragt, das das Modell nicht ausdrücken kann. Dann wird sie ein kaufmännisches Problem, denn was Sie verkaufen können, ist begrenzt durch das, was Sie trennen können.

Worum ein Kunde tatsächlich bittet

Streicht man das Anforderungsdokument zusammen, bleiben vier Bitten übrig. Sie kommen ungefähr in dieser Reihenfolge, und fast jeder Kunde, der Sie für die Schulung seiner Leute bezahlt, äußert sie.

1. Eine eigene Domain. `learn.acmecorp.com`, nicht `yourcompany.lms-vendor.com/acme`. Mit einem Zertifikat, über das sich der Browser nicht beschwert.
2. Eine eigene Administration. Jemand auf Kundenseite, der Nutzer anlegen, einen Kurs veröffentlichen und einen Bericht ziehen kann, ohne Ihnen vorher zu schreiben.
3. Eigenes Reporting. Zahlen über die eigenen Leute und über niemanden sonst, in einer Form, die sie dem eigenen Vorstand vorlegen können.
4. Eigene Daten, getrennt von denen anderer Kunden. Meist als Sicherheitsfrage gestellt, und immer die Frage, die die Beschaffung eskaliert.

Jede Architektur beantwortet einige davon und versagt bei anderen. Die Fehlstellen sind vorhersehbar, sobald Sie wissen, auf welchem Modell Sie stehen.

Drei Architekturen, drei Decken

Die drei Modelle unten sind keine Reifeleiter. Sie sind verschiedene Produkte für verschiedene Käufer, und jedes hat einen bestimmten Punkt, an dem es endet.

Portale

Ein Portal ist eine eigene Eingangstür zu einem gemeinsamen Bestand an Inhalten und Nutzern. Sie definieren eine Zielgruppe — Beschäftigte, Partner, ein einzelnes Kundenunternehmen —, geben ihr eine URL und ein Theme und weisen ihr Menschen zu. Mehrere Unternehmensplattformen sind um diese Form gebaut; LearnUpon ist das klarste Beispiel, mit der Auslieferung über mehrere Portale als Kern des Produkts.

Portale beantworten die erste Bitte gut. Ein Kunde bekommt eine Eingangstür, die nach ihm aussieht, und Lernende, die sich anmelden, sehen die anderen Zielgruppen nie. Für ein Unternehmen, das Beschäftigte, Partner und Kunden aus einem Konto heraus schult, ist das oft das richtige Maß an Struktur.

Die Liste der Portale ist flach, und dort endet es. Ein Kunde mit drei Regionen und einer Schulungsleitung auf Gruppenebene ist nicht ein Portal, und drei zusammenhanglose sind es auch nicht. Anbieter auf einem flachen Modell kodieren die fehlende Hierarchie am Ende in Namen — `Acme`, `Acme - EMEA`, `Acme - APAC` — und bauen die Gruppensicht dann jedes Quartal von Hand in einer Tabelle zusammen. Bei Administrationsrollen gibt es dasselbe Problem: Rechte werden je Portal vergeben, die Schulungsleitung der Gruppe bekommt also drei Vergaben, an deren Rücknahme niemand denkt, wenn eine Region schließt.

Unterkonten

Unterkonten stammen meist aus dem Abrechnungssystem und nicht aus dem Datenmodell. Ein zahlendes Konto besitzt einige untergeordnete Konten, in der Regel eine Ebene tief, die sich eine Nutzertabelle, ein Abonnement und oft eine einzige Domain mit einem Pfad je Unterkonto teilen. TalentLMS sagt offen, dass dies eine leichtere Trennung ist als volle Mandantenfähigkeit mit eigenen Domains je Mandant, und für ein kleines Team, das die eigenen Beschäftigten schult, ist diese Leichtigkeit ein Vorzug und kein Mangel.

Die Frage, die sich lohnt, ist, wo die Grenze durchgesetzt wird. Wenn ein Unterkonto eine Spalte in einer Zeile ist, dann ist die Trennung genau das, wonach der Anwendungscode zu filtern nicht vergisst.

-- Eine Grenze, die im Anwendungscode liegt
select * from enrolments where account_id = :current_account;

-- Eine Grenze, die in der Datenbank liegt
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

Die erste Abfrage ist genau so lange korrekt, bis jemand einen neuen Export-Endpunkt baut und die `where`-Klausel weglässt. Die zweite bleibt trotzdem korrekt, weil die Datenbank sich weigert, die Zeilen herauszugeben. Nach dieser Lücke tastet die Beschaffung, wenn sie fragt, wie Kundendaten auseinandergehalten werden — auch dann, wenn sie im Vokabular von Zertifizierungen und Audits fragt.

Verschachtelte Organisationen

Im dritten Modell ist die Organisation ein vollwertiger Datensatz, und eine Organisation kann eine übergeordnete haben. Branding, Domain, Nutzer, Rollen, Inhalte, Einschreibungen und Reporting hängen alle an ihr. Ihr Weiterbildungsunternehmen ist eine Organisation. Jeder Kunde ist eine Organisation innerhalb Ihrer. Die Regionen des Kunden sind Organisationen innerhalb seiner — so tief, wie seine tatsächliche Struktur reicht.

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

Daraus folgen zwei Dinge, die ein flaches Modell Ihnen nicht geben kann. Erstens lässt sich die eigene Form eines Kunden ohne Namenskonventionen abbilden — Sie kodieren keine Hierarchie in Zeichenketten. Zweitens der Geltungsbereich: Eine an einem Knoten vergebene Rolle gilt für alles unterhalb dieses Knotens. Die Schulungsleitung von Acme sieht Acme und beide Regionen. Die EMEA-Leitung sieht EMEA. Sie sehen alles. Niemand bei Borden sieht irgendetwas davon, und nichts davon ist ein Bericht, den jemand von Hand geschrieben hat.

Es ändert auch, was Offboarding bedeutet. Wenn ein Kunde ein flaches System verlässt, arbeitet jemand eine Liste aus Portalen, Nutzern, Gruppen und Berichten ab und hofft, dass die Liste vollständig ist. Wenn ein Kunde ein Teilbaum ist, löschen Sie den Teilbaum, und alles, was daran hing, geht mit.

Wie jedes Modell die vier Bitten beantwortet

• Eine eigene Domain. Portale: meist ja, eine je Portal, manchmal gegen Aufpreis. Unterkonten: oft ein Pfad oder eine Subdomain der Anbieterdomain statt der eigenen Domain des Kunden. Verschachtelte Organisationen: eine Domain je Organisation, in beliebiger Tiefe, sofern die Plattform Zertifikate automatisch ausstellt.
• Eine eigene Administration. Portale: ja, aber auf das eine Portal begrenzt, eine Administration auf Gruppenebene braucht also eine Vergabe je Portal. Unterkonten: meist die Administration der übergeordneten Ebene mit gefilterter Sicht. Verschachtelte Organisationen: eine Administration an jedem Knoten, mit Rechten, die nach unten auf alles darunter durchgereicht werden.
• Eigenes Reporting. Portale: je Portal, mit portalübergreifenden Zusammenfassungen je nach Produkt. Unterkonten: typischerweise ein Bericht mit einem Filter, was in Ordnung ist, bis ein Kunde ihn selbst sehen will. Verschachtelte Organisationen: Jeder Knoten ist ein Geltungsbereich fürs Reporting, die Gruppensicht und die Regionalsicht sind also dieselbe Abfrage auf verschiedenen Höhen.
• Getrennte Daten. Portale und Unterkonten: so getrennt, wie der Anwendungscode sie macht. Verschachtelte Organisationen: so getrennt, wie die Plattform es unterhalb der Anwendung durchsetzt — fragen Sie ausdrücklich, ob die Regel in der Datenbank liegt.

Nichts davon macht Portale falsch. Es macht sie zu einem anderen Produkt für andere Käufer. Der Fehler ist, ein Portalmodell zu kaufen, weil die Demo einen Logotausch gezeigt hat, und die Decke an dem Tag zu entdecken, an dem Sie einen Kunden mit Regionen gewinnen.

Fünf Fragen an einen Anbieter

1. Kann eine Organisation eine andere Organisation enthalten, und wie tief geht das?
2. Wenn ich jemandem an einem Knoten eine Administrationsrolle gebe: Gilt sie für alles darunter, oder vergebe ich sie auf jeder Ebene erneut?
3. Wird die Mandantengrenze in der Datenbank durchgesetzt oder im Anwendungscode?
4. Kann jeder Kunde eine eigene Domain und ein eigenes Zertifikat haben, oder nur ein Unterverzeichnis Ihrer Domain?
5. Wenn ein Kunde geht: Was genau löscht das Entfernen — und können Sie es mir zeigen?

Lassen Sie sich die Antworten in einem gemeinsamen Dokument geben statt im Gespräch. Vor allem die zweite Frage bringt eher die Demo eines Bildschirms hervor als eine Antwort, und der Unterschied zwischen beidem ist ein Jahr manueller Rechtevergabe.

Warum die Antwort entscheidet, was Sie verkaufen können

Wenn Ihre Plattform nur eine Eingangstür gestalten kann, verkaufen Sie Plätze auf Ihrem System. Die Beschäftigten des Kunden melden sich bei Ihrer Marke an, die Schulungsleitung des Kunden fragt Sie nach Zahlen, und jede Verlängerung ist ein Gespräch über die Kosten pro Nutzer Ihrer Plattform.

Wenn Sie einem Kunden eine Domain, eine Administration, Reporting und eine Grenze übergeben können, die eine Sicherheitsprüfung übersteht, verkaufen Sie ihm seine eigene Akademie. Das ist ein anderer Vertrag. Er verlängert sich anders, weil der Kunde bis dahin eine eigene Administration mit eigenen Gewohnheiten und eigene Inhalte darin hat, und er übersteht einen Wechsel der einkaufenden Person auf Kundenseite.

Die andere Hälfte ist operativ. Anbieter, die einem flachen Modell entwachsen, betreiben am Ende oft eine Installation je Kunde. Moodle sagt ausdrücklich, dass Mandantenfähigkeit nicht Teil des Kernprodukts ist — Campus oder Kundenorganisationen zu trennen bedeutet Moodle Workplace, einen Partnervertrag oder parallele Installationen. Parallele Installationen bedeuten parallele Upgrades, parallele Backups, parallele Sicherheits-Patches und eine Reporting-Schicht, die Sie außerhalb der Plattform neu bauen. Das funktioniert, solange Sie mehr Personal als Kunden haben.

Wo Lurno steht

Lurno ist auf dem dritten Modell gebaut. Eine Organisation kann Unterorganisationen enthalten, jede mit eigenem Branding und einer eigenen Domain mit automatischem TLS. Innerhalb einer Organisation gibt es einen zweiten Baum aus Zweigen, und eine an einem Zweig vergebene Rolle wird nach unten durchgereicht — das ist die Antwort auf die zweite Anbieterfrage oben und der Grund, warum eine Schulungsleitung auf Gruppenebene eine einzige Vergabe ist statt einer je Region.

Die Grenze wird in Postgres durchgesetzt und nicht in der Anwendung: 868 Row-Level-Security-Richtlinien über 676 Migrationen, sodass ein fehlender Filter in einem neuen Endpunkt nichts zurückgibt statt der Lernenden von jemand anderem. Das ist die Behauptung, die man bei jedem Anbieter prüfen sollte, bei uns eingeschlossen — die Einzelheiten stehen auf der Sicherheitsseite, und die Seite zu Branding und Domains ist White-Label.

Zwei Formen, die darauf bereits laufen, ohne jemanden zu nennen: eine Unternehmensakademie, die von einem Mandanten aus Schulungen für 15 Kundenunternehmen betreibt, und ein K-12-Verlag, der 114 Schulen auf einer einzigen Plattform betreibt. Beides ist dieselbe Struktur in unterschiedlicher Breite.

Zwei Grenzen, die klar gesagt gehören, weil sie die Bewertung verändern. Zahlungen und Checkout sind in Entwicklung — heute wird ein Kunde außerhalb der Plattform in Rechnung gestellt; wenn Sie also brauchen, dass Lernende bei der Einschreibung per Karte zahlen, ist das ein Gespräch und keine Funktion. Und die Partner-Anmeldung (Silent SSO) ist verfügbar, aber SAML und OIDC stehen auf der Roadmap und sind nicht ausgeliefert; wenn die IT-Abteilung eines Kunden bereits entschieden hat, wie ihre Beschäftigten sich authentifizieren, fragen Sie danach vor allem anderen. Der Rest des Modells für Anbieter, die Schulungen weiterverkaufen, ist auf der Seite für Weiterbildungsanbieter dargelegt.

Die Kurzfassung

Portale geben einem Kunden eine Eingangstür. Unterkonten geben einem Kunden eine gefilterte Sicht. Verschachtelte Organisationen geben einem Kunden eine Grenze, und eine Grenze ist das, worauf sich ein Preis setzen lässt. Finden Sie heraus, welches davon Sie kaufen, bevor ein Kunde Sie um das bittet, was Ihr Modell nicht sagen kann.