Portale, subkonta i zagnieżdżone organizacje: pytanie o wielodostępność dla firm szkoleniowych

Gdy firma szkoleniowa zdobywa klienta, który chce własnej akademii pod własną marką, to architektura platformy pod spodem przesądza, czy będzie to popołudnie konfiguracji, czy sześciotygodniowy projekt. Jako wielodostępność sprzedaje się trzy różne rzeczy: portale, subkonta i naprawdę zagnieżdżone organizacje. Tylko ta trzecia daje klientowi własną domenę, własnych administratorów, własne raportowanie i granicę danych, która trzyma także wtedy, gdy programista zapomni o filtrze.

Rozróżnienie czyta się jak ciekawostkę z folderu dostawcy, dopóki klient nie poprosi o coś, czego model nie potrafi wyrazić. Wtedy staje się problemem handlowym, bo to, co można sprzedać, jest ograniczone tym, co można rozdzielić.

O co klient naprawdę prosi

Po sprowadzeniu dokumentu wymagań do rzeczy zostają cztery prośby. Przychodzą mniej więcej w tej kolejności i prosi o nie prawie każdy klient, który płaci Państwu za szkolenie swoich ludzi.

1. Własna domena. `learn.acmecorp.com`, a nie `yourcompany.lms-vendor.com/acme`. Z certyfikatem, na który przeglądarka nie narzeka.
2. Właśni administratorzy. Ktoś po stronie klienta, kto może dodać użytkowników, opublikować kurs i pobrać raport, nie pisząc wcześniej do Państwa.
3. Własne raportowanie. Liczby o ich ludziach i o niczyich innych, w kształcie, który da się położyć przed własnym zarządem.
4. Ich dane oddzielone od danych innych klientów. Zwykle zadawane jako pytanie o bezpieczeństwo, zawsze to, które dział zakupów eskaluje.

Każda architektura odpowiada na część z nich i zawodzi przy pozostałych. Te porażki są przewidywalne, gdy tylko wiadomo, na którym modelu Państwo stoją.

Trzy architektury, trzy sufity

Trzy poniższe modele nie są drabiną dojrzałości. To różne produkty dla różnych kupujących i każdy z nich ma konkretny punkt, w którym się kończy.

Portale

Portal to osobne wejście frontowe do wspólnej sterty treści i użytkowników. Definiują Państwo grupę odbiorców — pracowników, partnerów, jedną firmę klienta — nadają jej adres URL i motyw graficzny, a potem przypisują do niej ludzi. Kilka platform korporacyjnych jest zbudowanych wokół tego kształtu; LearnUpon jest najczystszym przykładem, z dostarczaniem przez wiele portali jako rdzeniem produktu.

Portale dobrze odpowiadają na pierwszą prośbę. Klient dostaje wejście frontowe, które wygląda jak jego, a logujący się uczestnicy nigdy nie widzą pozostałych grup odbiorców. Dla firmy szkolącej z jednego konta pracowników, partnerów i klientów jest to często właściwa ilość struktury.

Lista portali jest płaska i tu się to kończy. Klient z trzema regionami i dyrektorem szkoleń na poziomie grupy nie jest jednym portalem ani trzema niepowiązanymi. Dostawcy pracujący na płaskim modelu kończą na zakodowaniu brakującej hierarchii w nazwach — `Acme`, `Acme - EMEA`, `Acme - APAC` — a potem co kwartał składają widok grupowy ręcznie w arkuszu. Role administratorów mają ten sam problem: uprawnienia nadaje się osobno na każdy portal, więc dyrektor grupy dostaje trzy nadania, których nikt nie pamięta odebrać, gdy region się zamyka.

Subkonta

Subkonta zwykle biorą się z systemu rozliczeń, a nie z modelu danych. Jedno konto płacące posiada kilka kont podrzędnych, zwykle na jeden poziom w głąb, dzielących tabelę użytkowników, subskrypcję i często jedną domenę ze ścieżką dla każdego konta podrzędnego. TalentLMS mówi otwarcie, że jest to rozdzielenie lżejsze niż pełna wielodostępność z własnymi domenami dla każdego tenanta, a dla małego zespołu szkolącego pracowników ta lekkość jest zaletą, a nie wadą.

Pytanie, które warto zadać, brzmi: gdzie egzekwowana jest granica. Jeśli subkonto jest kolumną w wierszu, to rozdzielenie jest dokładnie tym, o czym kod aplikacji pamięta przy filtrowaniu.

-- Granica, która mieszka w kodzie aplikacji
select * from enrolments where account_id = :current_account;

-- Granica, która mieszka w bazie danych
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

Pierwsze zapytanie jest poprawne dokładnie do chwili, w której ktoś zbuduje nowy punkt eksportu i pominie klauzulę `where`. Drugie pozostaje poprawne mimo to, bo baza danych odmawia zwrócenia wierszy. To właśnie tej różnicy szuka po omacku dział zakupów, gdy pyta, w jaki sposób dane klientów są trzymane osobno — nawet wtedy, gdy pyta słownikiem certyfikacji i audytów.

Zagnieżdżone organizacje

W trzecim modelu organizacja jest pełnoprawnym rekordem, a organizacja może mieć rodzica. Identyfikacja wizualna, domena, użytkownicy, role, treści, zapisy i raportowanie — wszystko wisi przy niej. Państwa firma szkoleniowa jest organizacją. Każdy klient jest organizacją wewnątrz Państwa. Regiony klienta są organizacjami wewnątrz jego organizacji, tak głęboko, jak sięga jego prawdziwa struktura.

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

Wynikają z tego dwie rzeczy, których płaski model dać nie może. Pierwsza: własny kształt klienta da się przedstawić bez konwencji nazewniczych — nie kodują Państwo hierarchii w ciągach znaków. Druga to zasięg: rola nadana w węźle obowiązuje wszystko pod tym węzłem. Dyrektor szkoleń w Acme widzi Acme i oba regiony. Kierownik EMEA widzi EMEA. Państwo widzą całość. Nikt w Borden nie widzi z tego nic, i nic z tego nie jest raportem, który ktoś napisał ręcznie.

Zmienia to również znaczenie odłączania klienta. Gdy klient odchodzi z płaskiego systemu, ktoś przechodzi listę kontrolną portali, użytkowników, grup i raportów, licząc na to, że jest kompletna. Gdy klient jest poddrzewem, usuwają Państwo poddrzewo, a wszystko, co przy nim wisiało, znika razem z nim.

Jak każdy model odpowiada na te cztery prośby

• Własna domena. Portale: zwykle tak, jedna na portal, czasem za dopłatą. Subkonta: często ścieżka albo subdomena domeny dostawcy, a nie własna domena klienta. Zagnieżdżone organizacje: domena dla każdej organizacji, na dowolnej głębokości, jeśli platforma wystawia certyfikaty automatycznie.
• Właśni administratorzy. Portale: tak, ale w zasięgu jednego portalu, więc administrator na poziomie grupy potrzebuje nadania na każdy portal z osobna. Subkonta: zwykle administratorzy konta nadrzędnego z przefiltrowanym widokiem. Zagnieżdżone organizacje: administrator w dowolnym węźle, z uprawnieniami spływającymi na wszystko pod nim.
• Własne raportowanie. Portale: dla każdego portalu osobno, a zbiorcze zestawienia w poprzek portali zależą od produktu. Subkonta: zwykle jeden raport z filtrem, co wystarcza do chwili, w której klient poprosi, by zobaczyć go samodzielnie. Zagnieżdżone organizacje: każdy węzeł jest zasięgiem raportowania, więc widok grupowy i widok regionalny to to samo zapytanie na różnych wysokościach.
• Ich dane oddzielone. Portale i subkonta: oddzielone na tyle, na ile robi to kod aplikacji. Zagnieżdżone organizacje: oddzielone na tyle, na ile egzekwuje to platforma poniżej aplikacji — proszę zapytać konkretnie, czy reguła siedzi w bazie danych.

Nic z tego nie czyni portali błędem. Czyni je innym produktem dla innego kupującego. Błędem jest kupienie modelu portalowego dlatego, że prezentacja pokazała podmianę logo, i odkrycie sufitu w dniu podpisania klienta, który ma regiony.

Pięć pytań do zadania dostawcy

1. Czy organizacja może zawierać inną organizację i jak głęboko to sięga?
2. Jeśli nadam komuś rolę administratora w jednym węźle, czy obowiązuje ona wszystko poniżej, czy nadaję ją ponownie na każdym poziomie?
3. Czy granica tenanta jest egzekwowana w bazie danych, czy w kodzie aplikacji?
4. Czy każdy klient może mieć własną domenę i własny certyfikat, czy tylko podkatalog Państwa domeny?
5. Gdy klient odchodzi, co dokładnie usuwa jego usunięcie — i czy mogą to Państwo pokazać?

O odpowiedzi warto poprosić we wspólnym dokumencie, a nie na rozmowie. Zwłaszcza drugie pytanie zwykle wywołuje pokaz ekranu zamiast odpowiedzi, a różnica między jednym a drugim to rok ręcznych nadań.

Dlaczego odpowiedź przesądza, co można sprzedać

Jeśli Państwa platforma potrafi tylko nadać motyw graficzny jednemu wejściu frontowemu, sprzedają Państwo miejsca w swoim systemie. Pracownicy klienta logują się do Państwa marki, kierownik szkoleń u klienta prosi Państwa o liczby, a każde odnowienie jest rozmową o koszcie Państwa platformy na użytkownika.

Jeśli mogą Państwo wręczyć klientowi domenę, administratorów, raportowanie i granicę, która przechodzi przegląd bezpieczeństwa, sprzedają mu Państwo jego własną akademię. To inna umowa. Inaczej się odnawia, bo do tego czasu klient ma w niej własnych administratorów z własnymi nawykami i własne treści, i przeżywa ona zmianę osoby kupującej po jego stronie.

Druga połowa jest operacyjna. Dostawcy, którzy wyrastają z płaskiego modelu, często kończą na jednej instalacji na klienta. Moodle mówi wprost, że wielodostępności nie ma w podstawowym produkcie — rozdzielenie kampusów albo organizacji klienckich oznacza Moodle Workplace, umowę z partnerem albo równoległe instalacje. Równoległe instalacje oznaczają równoległe aktualizacje, równoległe kopie zapasowe, równoległe łatanie bezpieczeństwa i warstwę raportową odbudowywaną poza platformą. Działa to dopóty, dopóki mają Państwo więcej personelu niż klientów.

Gdzie w tym stoi Lurno

Lurno jest zbudowane na trzecim modelu. Organizacja może zawierać podorganizacje, każdą z własną identyfikacją wizualną i własną domeną z automatycznym TLS. Wewnątrz organizacji jest drugie drzewo gałęzi, a rola nadana na gałęzi spływa w dół — co jest odpowiedzią na drugie z powyższych pytań do dostawcy i powodem, dla którego dyrektor szkoleń na poziomie grupy to jedno nadanie, a nie jedno na region.

Granica jest egzekwowana w Postgresie, a nie w aplikacji: 868 polityk bezpieczeństwa na poziomie wierszy w 676 migracjach, więc brakujący filtr w nowym punkcie końcowym zwraca pustkę zamiast cudzych uczestników. To jest twierdzenie, które warto sprawdzić u każdego dostawcy, także u nas — szczegóły są na stronie o bezpieczeństwie, a strona marki i domen na white-label.

Dwa kształty, które już na tym działają, bez wymieniania nazw: akademia korporacyjna prowadząca szkolenia dla 15 firm klienckich z jednego tenanta oraz wydawca K-12 prowadzący 114 szkół na jednej platformie. Oba są tą samą strukturą o różnej szerokości.

Dwa ograniczenia warto powiedzieć wprost, bo zmieniają ocenę. Płatności i koszyk są w budowie — dziś klienta fakturuje się poza platformą, więc jeśli potrzebują Państwo, by uczestnicy płacili kartą w momencie zapisu, to temat na rozmowę, a nie funkcja. Logowanie partnerskie (silent SSO) jest dostępne, ale SAML i OIDC są na mapie drogowej i nie zostały wdrożone; jeśli dział IT klienta już zdecydował, w jaki sposób jego pracownicy będą się uwierzytelniać, warto zapytać o to przed wszystkim innym. Resztę modelu dla firm odsprzedających szkolenia opisuje strona dla firm szkoleniowych.

Wersja krótka

Portale dają klientowi wejście frontowe. Subkonta dają klientowi przefiltrowany widok. Zagnieżdżone organizacje dają klientowi granicę, a granica jest tym, na co można nałożyć cenę. Warto ustalić, którą z nich Państwo kupują, zanim klient poprosi o to, czego Państwa model nie potrafi powiedzieć.