Portales, subcuentas y organizaciones anidadas: la cuestión del multiinquilino para proveedores de formación

Cuando un proveedor de formación gana un cliente que quiere su propia academia con marca propia, la arquitectura de la plataforma que hay debajo decide si eso es una tarde de configuración o un proyecto de seis semanas. Se venden como multiinquilino tres cosas distintas: portales, subcuentas y organizaciones realmente anidadas. Solo la tercera le da a un cliente su propio dominio, sus propios administradores, sus propios informes y una frontera de datos que sigue aguantando cuando un desarrollador se olvida de un filtro.

La distinción parece una curiosidad de proveedores hasta que un cliente pide algo que el modelo no puede expresar. Entonces se convierte en un problema comercial, porque lo que usted puede vender está limitado por lo que puede separar.

Qué pide un cliente en realidad

Reduzca el pliego de requisitos y quedan cuatro peticiones. Llegan más o menos en este orden, y casi todo cliente que le paga por formar a su gente las pide.

1. Su propio dominio. `learn.acmecorp.com`, no `suempresa.proveedor-lms.com/acme`. Con un certificado que no haga protestar al navegador.
2. Sus propios administradores. Alguien del lado del cliente que pueda dar de alta usuarios, publicar un curso y sacar un informe sin escribirle antes a usted.
3. Sus propios informes. Números sobre su gente y sobre la de nadie más, en un formato que puedan poner delante de su propio consejo.
4. Sus datos separados de los datos de otros clientes. Se suele plantear como pregunta de seguridad, y siempre es la que el departamento de compras escala.

Cada arquitectura responde a algunas de estas y falla en otras. Los fallos son predecibles una vez que se sabe sobre qué modelo está usted de pie.

Tres arquitecturas, tres techos

Los tres modelos de abajo no son una escalera de madurez. Son productos distintos para compradores distintos, y cada uno tiene un punto concreto en el que se detiene.

Portales

Un portal es una puerta de entrada separada a un mismo montón compartido de contenido y usuarios. Se define una audiencia —empleados, partners, una empresa cliente—, se le da una URL y un tema, y se le asignan personas. Varias plataformas corporativas están construidas en torno a esta forma; LearnUpon es el ejemplo más claro, con la entrega multiportal como núcleo del producto.

Los portales responden bien a la primera petición. Un cliente obtiene una puerta de entrada con su aspecto, y los alumnos que inician sesión no ven nunca las demás audiencias. Para una empresa que forma a empleados, partners y clientes desde una sola cuenta, esa suele ser la cantidad justa de estructura.

La lista de portales es plana, y ahí es donde se detiene. Un cliente con tres regiones y un director de formación a nivel de grupo no es un portal, y tampoco son tres portales sin relación entre sí. Los proveedores sobre un modelo plano acaban codificando la jerarquía que falta en los nombres —`Acme`, `Acme - EMEA`, `Acme - APAC`— y luego rehaciendo a mano la vista de grupo en una hoja de cálculo cada trimestre. Los roles de administrador tienen el mismo problema: los permisos se conceden por portal, así que el director de grupo recibe tres concesiones que nadie se acuerda de revocar cuando cierra una región.

Subcuentas

Las subcuentas suelen venir del sistema de facturación y no del modelo de datos. Una cuenta que paga posee unas cuantas cuentas hijas, normalmente con un solo nivel de profundidad, que comparten una tabla de usuarios, una suscripción y a menudo un único dominio con una ruta por cada hija. TalentLMS es franco al reconocer que esto es una separación más ligera que un multiinquilino completo con dominios personalizados por inquilino, y para un equipo pequeño que forma a su plantilla esa ligereza es una virtud, no un defecto.

La pregunta que merece la pena hacer es dónde se impone la frontera. Si una subcuenta es una columna de una fila, entonces la separación es aquello por lo que el código de la aplicación se acuerde de filtrar.

-- Una frontera que vive en el código de la aplicación
select * from enrolments where account_id = :current_account;

-- Una frontera que vive en la base de datos
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

La primera consulta es correcta justo hasta que alguien construye un nuevo endpoint de exportación y se deja fuera la cláusula `where`. La segunda sigue siendo correcta de todas formas, porque la base de datos se niega a devolver las filas. Esa distancia es lo que el departamento de compras está tanteando cuando pregunta cómo se mantienen aparte los datos de los clientes, aunque lo pregunte con el vocabulario de las certificaciones y las auditorías.

Organizaciones anidadas

En el tercer modelo la organización es un registro de primera clase, y una organización puede tener una matriz. La marca, el dominio, los usuarios, los roles, el contenido, las matrículas y los informes cuelgan todos de ella. Su empresa de formación es una organización. Cada cliente es una organización dentro de la suya. Las regiones del cliente son organizaciones dentro de la suya, tan en profundidad como llegue su estructura real.

Su empresa de formación            usted lo administra todo lo de abajo
├── Acme Corp                      learn.acmecorp.com
│   ├── Acme EMEA                  admin regional, solo datos EMEA
│   └── Acme APAC
├── Borden Group                   training.bordengroup.com
│   └── Borden Manufacturing
└── Catálogo público               matrícula abierta, su marca

De ahí se siguen dos cosas que un modelo plano no puede darle. La primera es que la forma propia de un cliente se puede representar sin convenciones de nombres: no está codificando jerarquía en cadenas de texto. La segunda es el alcance: un rol concedido en un nodo se aplica a todo lo que hay bajo ese nodo. El director de formación de Acme ve Acme y las dos regiones. El responsable de EMEA ve EMEA. Usted lo ve todo. Nadie de Borden ve nada de ello, y nada de eso es un informe que alguien haya escrito a mano.

También cambia lo que significa dar de baja a un cliente. Cuando un cliente se va de un sistema plano, alguien recorre una lista de comprobación de portales, usuarios, grupos e informes esperando que la lista esté completa. Cuando un cliente es un subárbol, se borra el subárbol, y todo lo que colgaba de él se va con él.

Cómo responde cada modelo a las cuatro peticiones

• Su propio dominio. Portales: normalmente sí, uno por portal, a veces con coste añadido. Subcuentas: a menudo una ruta o un subdominio del dominio del proveedor y no del propio cliente. Organizaciones anidadas: un dominio por organización, a cualquier profundidad, si la plataforma emite certificados automáticamente.
• Sus propios administradores. Portales: sí, pero acotados a ese portal, así que un administrador a nivel de grupo necesita una concesión por portal. Subcuentas: normalmente los administradores de la matriz con una vista filtrada. Organizaciones anidadas: un administrador en cualquier nodo, con permisos que se propagan a todo lo que hay debajo.
• Sus propios informes. Portales: por portal, con agregados entre portales según el producto. Subcuentas: normalmente un informe con un filtro, lo cual va bien hasta que un cliente pide verlo él mismo. Organizaciones anidadas: cada nodo es un ámbito de informes, así que la vista de grupo y la vista regional son la misma consulta a distinta altura.
• Sus datos separados. Portales y subcuentas: tan separados como los haga el código de la aplicación. Organizaciones anidadas: tan separados como imponga la plataforma por debajo de la aplicación; pregunte, en concreto, si la regla está en la base de datos.

Nada de esto hace que los portales estén mal. Los convierte en un producto distinto para un comprador distinto. El error es comprar un modelo de portales porque la demostración enseñaba un cambio de logotipo, y descubrir el techo el día en que firma a un cliente que tiene regiones.

Cinco preguntas para plantear a un proveedor

1. ¿Puede una organización contener a otra organización, y hasta qué profundidad?
2. Si concedo a alguien un rol de administrador en un nodo, ¿se aplica a todo lo que hay debajo, o tengo que volver a concederlo en cada nivel?
3. ¿La frontera de inquilino se impone en la base de datos o en el código de la aplicación?
4. ¿Puede cada cliente tener su propio dominio y su propio certificado, o solo un subdirectorio del suyo?
5. Cuando un cliente se va, ¿qué borra exactamente su eliminación, y me lo pueden enseñar?

Pida las respuestas en un documento compartido y no en una llamada. La segunda pregunta en particular tiende a producir la demostración de una pantalla en lugar de una respuesta, y la diferencia entre ambas cosas es un año de concesiones manuales.

Por qué la respuesta decide qué puede vender

Si su plataforma solo puede personalizar el tema de una puerta de entrada, usted está vendiendo plazas en su sistema. El personal del cliente inicia sesión en su marca, el responsable de formación del cliente le pide a usted los números, y cada renovación es una conversación sobre el coste por usuario de su plataforma.

Si puede entregarle a un cliente un dominio, administradores, informes y una frontera que sobrevive a una revisión de seguridad, le está vendiendo su propia academia. Ese es otro contrato. Se renueva de otra manera, porque para entonces el cliente tiene dentro sus propios administradores con sus propias costumbres y su propio contenido, y sobrevive a un cambio de comprador en su lado.

La otra mitad es operativa. Los proveedores a los que se les queda pequeño un modelo plano acaban a menudo con una instalación por cliente. Moodle es explícito en que el multiinquilino no forma parte del producto base: separar campus u organizaciones cliente significa Moodle Workplace, un contrato con un partner o instalaciones paralelas. Instalaciones paralelas significan actualizaciones paralelas, copias de seguridad paralelas, parches de seguridad paralelos y una capa de informes que se reconstruye fuera de la plataforma. Funciona mientras tenga más personal que clientes.

Dónde se sitúa Lurno

Lurno está construido sobre el tercer modelo. Una organización puede contener suborganizaciones, cada una con su propia marca y su propio dominio personalizado con TLS automático. Dentro de una organización hay un segundo árbol de ramas, y un rol concedido en una rama se propaga hacia abajo, que es la respuesta a la segunda pregunta para proveedores de más arriba, y la razón por la que un director de formación de grupo es una sola concesión y no una por región.

La frontera se impone en Postgres y no en la aplicación: 868 políticas de seguridad a nivel de fila repartidas en 676 migraciones, de modo que un filtro que falte en un endpoint nuevo no devuelve nada en lugar de devolver los alumnos de otro. Esa es la afirmación que merece la pena comprobar con cualquier proveedor, el nuestro incluido: los detalles están en la página de seguridad, y el lado de la marca y los dominios, en marca blanca.

Dos formas que esto ya soporta, sin nombrar a nadie: una academia corporativa que imparte formación para 15 empresas cliente desde un solo inquilino, y una editorial K-12 que lleva 114 colegios en una sola plataforma. Ambas son la misma estructura a distinta anchura.

Dos límites que conviene decir sin rodeos, porque cambian la evaluación. Los pagos y el proceso de compra están en desarrollo: hoy se factura al cliente fuera de la plataforma, así que si necesita que los alumnos paguen con tarjeta en el momento de matricularse, eso es una conversación y no una función. Y el inicio de sesión de partner (SSO silencioso) está disponible, pero SAML y OIDC están en la hoja de ruta y no se han lanzado; si el departamento de informática de un cliente ya ha decidido cómo se van a autenticar sus empleados, pregunte por eso antes que por nada. El resto del modelo para proveedores que revenden formación está expuesto en la página para centros de formación.

La versión corta

Los portales le dan a un cliente una puerta de entrada. Las subcuentas le dan una vista filtrada. Las organizaciones anidadas le dan una frontera, y una frontera es lo que se puede poner en precio. Averigüe cuál está comprando antes de que un cliente le pida aquello que su modelo no sabe decir.