Portais, subcontas e organizações aninhadas: a questão do multi-inquilino para entidades formadoras

Quando uma entidade formadora ganha um cliente que quer a sua própria academia com marca própria, é a arquitetura da plataforma por baixo que decide se isso é uma tarde de configuração ou um projeto de seis semanas. Vendem-se três coisas diferentes com o nome de multi-inquilino: portais, subcontas e organizações genuinamente aninhadas. Só a terceira dá a um cliente o seu próprio domínio, os seus próprios administradores, os seus próprios relatórios, e uma fronteira de dados que se aguenta mesmo quando um programador se esquece de um filtro.

A distinção lê-se como trivialidades de fornecedores até um cliente pedir alguma coisa que o modelo não consegue exprimir. Aí passa a ser um problema comercial, porque aquilo que consegue vender é limitado por aquilo que consegue separar.

O que um cliente pede na realidade

Reduza o caderno de requisitos ao osso e sobram quatro pedidos. Chegam mais ou menos por esta ordem, e quase todos os clientes que lhe pagam para formar as suas pessoas os fazem.

1. O seu próprio domínio. `learn.acmecorp.com`, não `yourcompany.lms-vendor.com/acme`. Com um certificado que não faça o navegador queixar-se.
2. Os seus próprios administradores. Alguém do lado do cliente que possa adicionar utilizadores, publicar um curso e extrair um relatório sem lhe enviar primeiro um email.
3. Os seus próprios relatórios. Números sobre as suas pessoas e de mais ninguém, num formato que possam pôr à frente da sua própria administração.
4. Os seus dados separados dos dados dos outros clientes. Normalmente pedido como uma questão de segurança, sempre aquele que a área de compras escala.

Cada arquitetura responde a alguns destes pontos e falha noutros. As falhas são previsíveis assim que se sabe em cima de que modelo se está.

Três arquiteturas, três tetos

Os três modelos abaixo não são uma escada de maturidade. São produtos diferentes para compradores diferentes, e cada um tem um ponto específico onde para.

Portais

Um portal é uma porta de entrada separada para um monte partilhado de conteúdos e utilizadores. Define-se uma audiência — colaboradores, parceiros, uma empresa cliente —, dá-se-lhe um URL e um tema, e atribuem-se-lhe pessoas. Várias plataformas empresariais são construídas em torno deste formato; a LearnUpon é o exemplo mais claro, com a entrega multi-portal no centro do produto.

Os portais respondem bem ao primeiro pedido. Um cliente fica com uma porta de entrada que parece dele, e os formandos que iniciam sessão nunca veem as outras audiências. Para uma empresa que forma colaboradores, parceiros e clientes a partir de uma só conta, essa é muitas vezes a quantidade certa de estrutura.

A lista de portais é plana, e é aí que para. Um cliente com três regiões e um diretor de formação ao nível do grupo não é um portal, e também não são três portais sem relação entre si. As entidades formadoras assentes num modelo plano acabam por codificar a hierarquia em falta nos nomes — `Acme`, `Acme - EMEA`, `Acme - APAC` — e depois por remontar a vista do grupo à mão, numa folha de cálculo, todos os trimestres. Os papéis de administrador têm o mesmo problema: os direitos são atribuídos por portal, pelo que o diretor do grupo recebe três atribuições que ninguém se lembra de revogar quando uma região fecha.

Subcontas

As subcontas vêm normalmente do sistema de faturação e não do modelo de dados. Uma conta pagadora possui algumas contas-filhas, normalmente com um só nível de profundidade, a partilhar uma tabela de utilizadores, uma subscrição e muitas vezes um único domínio com um caminho por filha. O TalentLMS é franco quanto a esta ser uma separação mais leve do que um multi-inquilino completo com domínios personalizados por inquilino, e para uma equipa pequena que forma o seu próprio pessoal essa leveza é uma funcionalidade, não um defeito.

A pergunta que vale a pena fazer é onde é que a fronteira é imposta. Se uma subconta é uma coluna numa linha, então a separação é aquilo por que o código da aplicação se lembrar de filtrar.

-- Uma fronteira que vive no código da aplicação
select * from enrolments where account_id = :current_account;

-- Uma fronteira que vive na base de dados
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

A primeira consulta está correta até ao momento em que alguém constrói um novo ponto de exportação e deixa de fora a cláusula `where`. A segunda continua correta na mesma, porque a base de dados recusa devolver as linhas. É essa lacuna que a área de compras anda a apalpar quando pergunta como é que os dados dos clientes são mantidos separados, mesmo quando pergunta no vocabulário das certificações e das auditorias.

Organizações aninhadas

No terceiro modelo, a organização é um registo de primeira classe, e uma organização pode ter uma organização-mãe. Marca, domínio, utilizadores, papéis, conteúdos, inscrições e relatórios ficam todos pendurados nela. A sua empresa de formação é uma organização. Cada cliente é uma organização dentro da sua. As regiões do cliente são organizações dentro da dele, tão fundo quanto for a sua estrutura real.

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

Daqui decorrem duas coisas que um modelo plano não lhe pode dar. A primeira é que o formato próprio de um cliente é representável sem convenções de nomenclatura — não está a codificar hierarquia em cadeias de caracteres. A segunda é o âmbito: um papel atribuído num nó aplica-se a tudo o que está por baixo desse nó. O diretor de formação da Acme vê a Acme e as duas regiões. O gestor da EMEA vê a EMEA. Você vê tudo. Ninguém na Borden vê nada disto, e nada disto é um relatório que alguém tenha escrito à mão.

Muda também o que significa a saída de um cliente. Quando um cliente sai de um sistema plano, alguém percorre uma lista de verificação de portais, utilizadores, grupos e relatórios, na esperança de que a lista esteja completa. Quando um cliente é uma subárvore, apaga-se a subárvore, e tudo o que estava pendurado nela vai com ela.

Como cada modelo responde aos quatro pedidos

• O seu próprio domínio. Portais: normalmente sim, um por portal, por vezes com custo adicional. Subcontas: muitas vezes um caminho ou um subdomínio do domínio do fornecedor, em vez do domínio do próprio cliente. Organizações aninhadas: um domínio por organização, a qualquer profundidade, se a plataforma emitir certificados automaticamente.
• Os seus próprios administradores. Portais: sim, mas com âmbito num único portal, pelo que um administrador ao nível do grupo precisa de uma atribuição por portal. Subcontas: normalmente os administradores da conta-mãe com uma vista filtrada. Organizações aninhadas: um administrador em qualquer nó, com direitos que se propagam a tudo o que está por baixo dele.
• Os seus próprios relatórios. Portais: por portal, com agregações entre portais dependendo do produto. Subcontas: tipicamente um relatório com um filtro, o que serve até um cliente pedir para o ver ele próprio. Organizações aninhadas: cada nó é um âmbito de relatório, pelo que a vista do grupo e a vista regional são a mesma consulta a alturas diferentes.
• Os seus dados separados. Portais e subcontas: tão separados quanto o código da aplicação os fizer. Organizações aninhadas: tão separados quanto a plataforma impuser abaixo da aplicação — pergunte, especificamente, se a regra fica na base de dados.

Nada disto torna os portais errados. Torna-os um produto diferente para um comprador diferente. O erro é comprar um modelo de portais porque a demonstração mostrou uma troca de logótipo, e descobrir o teto no dia em que assina um cliente que tem regiões.

Cinco perguntas a fazer a um fornecedor

1. Uma organização pode conter outra organização, e até que profundidade?
2. Se eu atribuir a alguém um papel de administrador num nó, ele aplica-se a tudo o que está por baixo, ou tenho de o atribuir outra vez em cada nível?
3. A fronteira entre inquilinos é imposta na base de dados ou no código da aplicação?
4. Cada cliente pode ter o seu próprio domínio e o seu próprio certificado, ou apenas um subdiretório do vosso?
5. Quando um cliente sai, o que é que a remoção apaga exatamente — e podem mostrar-me?

Peça as respostas num documento partilhado em vez de numa chamada. A segunda pergunta, em particular, tende a produzir uma demonstração de um ecrã em vez de uma resposta, e a diferença entre as duas coisas é um ano de atribuições manuais.

Porque é que a resposta decide o que pode vender

Se a sua plataforma só consegue personalizar o tema de uma porta de entrada, está a vender lugares no seu sistema. Os colaboradores do cliente iniciam sessão na sua marca, o responsável de formação do cliente pede-lhe números, e cada renovação é uma conversa sobre o custo por utilizador da sua plataforma.

Se conseguir entregar a um cliente um domínio, administradores, relatórios e uma fronteira que sobrevive a uma revisão de segurança, está a vender-lhe a sua própria academia. Isso é um contrato diferente. Renova-se de outra forma, porque a essa altura o cliente já tem os seus próprios administradores com os seus próprios hábitos e os seus próprios conteúdos lá dentro, e sobrevive a uma mudança de comprador do lado dele.

A outra metade é operacional. As entidades formadoras que ultrapassam um modelo plano acabam muitas vezes a gerir uma instalação por cliente. O Moodle é explícito quanto ao facto de o multi-inquilino não fazer parte do produto base — separar campus ou organizações cliente significa Moodle Workplace, um contrato com um parceiro, ou instalações paralelas. Instalações paralelas significam atualizações paralelas, cópias de segurança paralelas, correções de segurança paralelas e uma camada de relatórios que se reconstrói fora da plataforma. Funciona enquanto tiver mais pessoal do que clientes.

Onde a Lurno se situa

A Lurno é construída sobre o terceiro modelo. Uma organização pode conter sub-organizações, cada uma com a sua própria marca e o seu próprio domínio personalizado com TLS automático. Dentro de uma organização há uma segunda árvore de ramos, e um papel atribuído num ramo propaga-se para baixo — que é a resposta à segunda pergunta ao fornecedor, acima, e a razão pela qual um diretor de formação de grupo é uma atribuição em vez de uma por região.

A fronteira é imposta no Postgres e não na aplicação: 868 políticas de segurança ao nível da linha ao longo de 676 migrações, pelo que um filtro em falta num novo ponto de acesso devolve nada em vez de devolver os formandos de outra pessoa. Essa é a afirmação que vale a pena verificar com qualquer fornecedor, connosco incluídos — os detalhes estão na página de segurança, e o lado da marca e dos domínios está em marca branca.

Dois formatos que isto já suporta, sem nomear ninguém: uma academia empresarial que dá formação a 15 empresas clientes a partir de um único inquilino, e uma editora K-12 que gere 114 escolas numa só plataforma. Ambos são a mesma estrutura com larguras diferentes.

Dois limites que vale a pena declarar de forma direta, porque mudam a avaliação. Os pagamentos e a finalização de compra estão em desenvolvimento — hoje um cliente é faturado fora da plataforma, pelo que, se precisar que os formandos paguem por cartão no momento da inscrição, isso é uma conversa e não uma funcionalidade. E o início de sessão via parceiro (silent SSO) está disponível, mas o SAML e o OIDC estão no roadmap e não foram lançados; se o departamento de informática de um cliente já decidiu como é que os seus colaboradores se vão autenticar, pergunte por isso antes de tudo o resto. O resto do modelo para entidades formadoras que revendem formação está exposto na página de entidades formadoras.

A versão curta

Os portais dão a um cliente uma porta de entrada. As subcontas dão a um cliente uma vista filtrada. As organizações aninhadas dão a um cliente uma fronteira, e uma fronteira é a coisa a que se pode pôr um preço. Descubra qual delas está a comprar antes de um cliente lhe pedir aquilo que o seu modelo não consegue dizer.