Diseño la arquitectura de plataformas Moodle™ con objetivos explícitos de estabilidad, integración y capacidad de evolución. Identifico y trato los límites previsibles de rendimiento, interoperabilidad y seguridad antes de producción.
Criterio profesional
Las cuatro proceden de haber visto qué ocurre cuando la decisión se toma en sentido contrario.
Cada necesidad nueva encuentra hueco dentro del LMS porque instalar una extensión es más rápido que discutir a quién corresponde. Con los años, la plataforma puede absorber responsabilidades ajenas al LMS y actualizarla puede resultar costoso o arriesgado.
Ante cargas concurrentes, la base de datos es un cuello de botella frecuente, pero no debe darse por supuesto. Obtengo una línea base, reproduzco la carga y localizo si el límite está en PHP, base de datos, cachés, almacenamiento, red, sesiones, tareas o integraciones antes de contratar más recursos.
He visto diseños correctos degradarse en pocos meses porque nadie conocía la regla que los mantenía. La arquitectura se aplica en las decisiones cotidianas de quien programa, más que en el diagrama.
Cuando una organización quiere cambiar de proveedor y descubre que no puede, el origen suele estar en que nunca se exigieron formatos abiertos, procedimientos reproducibles ni las decisiones por escrito.
Dónde se concentra la complejidad
Estas seis situaciones se repiten. Ninguna llega como «necesitamos una arquitectura»: llegan como una fecha, un pliego, una caída o una plataforma heredada que nadie se atreve a tocar.
Se pide una plataforma «escalable» sin decir cuántas personas activas, cuántas simultáneas, en qué franja y con qué tiempo de respuesta. Sin esas cifras no se puede diseñar ni comparar dos ofertas.
El comportamiento normal no basta para predecir lo que ocurrirá durante el pico. La concurrencia de una convocatoria es un régimen distinto y hay que diseñarlo aparte.
Una instalación Moodle LMS con espacios compartidos, la multitenencia nativa de un producto que la ofrezca —como Moodle Workplace— y las instalaciones separadas son modelos distintos. La separación por cursos o categorías no equivale por sí sola a un tenant: cambian el aislamiento, quién administra, cómo se actualiza y si los informes se pueden juntar.
Una sincronización pesada, un servicio externo que responde tarde o un dato del que nadie responde acaban condicionando el diseño entero de la plataforma.
Cuando resultan aplicables, el Esquema Nacional de Seguridad, la protección de datos y la accesibilidad —o los criterios de una auditoría concreta— exigen decisiones de arquitectura que no se pueden añadir al final.
Modificaciones del núcleo, extensiones sin mantenimiento e integraciones que dependen de comportamientos antiguos. Antes de proponer nada hay que saber qué se puede mover.
Dominios de decisión
No se recorren en orden ni se tratan todos con la misma profundidad en cada organización. Si alguno no se decide de forma explícita, los cambios acumulados terminan condicionando la arquitectura.
Qué responsabilidad permanece en Moodle, qué resuelve una integración, qué merece un servicio aparte y qué no debería existir. Es la decisión que más condiciona el resto y la que más veces se toma por omisión, porque cada extensión instalada sin discusión desplaza una frontera.
Patrón de carga real, caché, sesiones, base de datos, almacenamiento, tareas en segundo plano, balanceo y escalado. Dimensiono para el pico previsto y documentado. Si el único objetivo es absorber carga y la demanda prevista no lo exige, un clúster añade coste operativo y puntos de fallo sin aportar capacidad necesaria; aún puede estar justificado por requisitos de disponibilidad o mantenimiento.
Aislamiento lógico o físico, datos comunes, administración delegada, marca por organización, actualizaciones coordinadas, coste operativo y recuperación. Cuándo tiene sentido Moodle Workplace, cuándo una sola instalación y cuándo varias.
Identidad y acceso único, sistemas académicos, de personal, comerciales y analíticos. Contratos versionados, idempotencia, reintentos, reconciliación y trazabilidad. Las preguntas que ordenan el resto son qué sistema actúa como referencia de cada dato, qué equipo responde de su calidad y qué ocurre cuando el otro sistema no responde.
Roles y capacidades, segregación, protección de datos, gestión de vulnerabilidades, retención y supresión, auditoría y accesibilidad. Cuando el Esquema Nacional de Seguridad resulta aplicable, determino el alcance y la categoría y traduzco las medidas del anexo II del Real Decreto 311/2022 en decisiones concretas, incluida la arquitectura de seguridad prevista en la medida op.pl.2.
Copias consistentes entre base de datos y ficheros, restauraciones verificadas, tiempo objetivo de recuperación y de pérdida de datos asumible, alta disponibilidad, observabilidad, gestión de incidentes y vuelta atrás. Disponer de copias no equivale a poder recuperar el servicio en el plazo comprometido.
Actualizaciones, migraciones, deuda acumulada, extensiones heredadas, modificaciones del núcleo, arquitectura objetivo, coste total de propiedad y reversibilidad. Decidir qué merece la pena arreglar, qué conviene rehacer y qué hay que retirar aunque siga funcionando.
Proveedores y modelos, contexto autorizado, búsqueda en contenido propio, datos personales que salen o no salen, permisos por rol, evaluación de la respuesta, latencia, coste y supervisión humana. Minimizo los datos antes de enviarlos y distingo entre anonimización irreversible, seudonimización y simple retirada de identificadores directos. Compruebo el riesgo de reidentificación y sigo tratando los datos seudonimizados como personales. Aquí la decisión de arquitectura precede a la de producto: qué fuentes puede consultar el modelo y qué ocurre cuando se equivoca.
Responsabilidades concretas
De que las cifras estén, de que las fronteras entre sistemas estén dibujadas y escritas, y de que lo decidido siga siendo comprensible dentro de tres años para alguien que no estuvo en la sala.
Canales, Moodle, integraciones, identidad, datos corporativos, infraestructura y operación. Un diagrama que puedan discutir en la misma reunión la dirección y quien programa.
Usuarios activos y simultáneos, tiempo de respuesta acordado, crecimiento del almacenamiento y objetivos de recuperación. Sin cifras acordadas, el dimensionamiento se apoya en suposiciones.
Qué se decidió, qué se descartó, por qué y qué tendría que cambiar para revisarlo. Quien llegue después necesita entender el razonamiento, no solo el resultado.
Si el diseño no llega al equipo como criterios que pueda aplicar y verificar, se degrada en el primer trimestre.
Diseñar sin observar después el comportamiento real impide corregir el criterio y lleva a repetir el mismo error.
Matriz de decisión
Es una de las decisiones de arquitectura que con más frecuencia se resuelve por la vía rápida y se paga durante años. Estas son las seis dimensiones que separan las tres opciones.
En una instancia compartida, la base de datos, los ficheros y los procesos son comunes. La multitenencia nativa añade las garantías de separación que ofrezca el producto en esa versión, pero mantiene componentes compartidos. Las instalaciones separadas permiten un aislamiento mayor si también se segmentan la infraestructura, las credenciales, la red y la operación; a cambio, multiplican lo que hay que mantener.
En una instancia compartida de Moodle LMS, la delegación depende de roles, contextos y configuración. Con multitenencia nativa, como la que ofrece Moodle Workplace, puede delegarse la administración por organización dentro de los límites de esa versión. Con instalaciones separadas, cada organización puede administrar su entorno, con más autonomía y mayor riesgo de divergencia.
Una instancia compartida facilita reutilizar catálogos, cursos plantilla o bancos, pero exige controlar los permisos. La multitenencia nativa permite compartir lo que admita el producto sin eliminar la separación organizativa. Entre instalaciones separadas hay que decidir qué se copia, cuándo, con qué versión y quién mantiene la referencia.
Una instancia compartida y un producto con multitenencia nativa se actualizan de forma conjunta, dentro del calendario y las garantías del producto. Varias instalaciones permiten ritmos propios, pero crean divergencia de versiones y multiplican las pruebas y despliegues.
En una instancia compartida, un informe transversal puede evitar la consolidación si el modelo de datos y los permisos lo permiten. En multitenencia nativa, el alcance de los informes entre organizaciones depende del producto y la versión. Con instalaciones separadas suele hacer falta una consolidación externa y una identidad común entre entornos.
En una instancia compartida se concentran la operación y la recuperación, junto con su riesgo. La multitenencia nativa puede añadir licencias y controles propios, pero conserva una operación común. Las instalaciones separadas permiten recuperar o intervenir por organización y multiplican la vigilancia, los despliegues, las copias y el soporte. Comparo esos costes en el contexto concreto.
Casos de uso
Son relatos profesionales sin identificar al cliente. Sus cifras proceden de informes internos no incorporados a esta página: explican el método, pero no constituyen evidencia independiente, un valor de referencia ni una garantía para otra plataforma.
En una solución utilizada por alrededor de 25 empresas, marcas o unidades organizativas, cada alta obligaba a clonar y configurar manualmente una plataforma. El aprovisionamiento tardaba unos tres días, la desviación entre configuraciones se acercaba al 30 % y los despliegues ocupaban alrededor de seis horas. Parecía que aislar cada organización obligaba a mantener artesanalmente un Moodle distinto, y lo descarté porque alrededor del 85 % de la solución era común. No faltaba multitenencia: faltaba un modelo explícito para aprovisionar instancias aisladas, una por organización, sin mezclar configuración, marca y permisos con el código y las operaciones manuales. Propuse automatizar ese aprovisionamiento, diseñé el plan de configuración por organización y lo dejé documentado junto con las pruebas de aislamiento. Dentro del alcance definido, las pruebas de intrusión y las comprobaciones de posibles fugas en la capa de persistencia no detectaron cruces de datos entre organizaciones; esta página no publica el alcance ni el protocolo completos. En la prueba interna, el alta pasó a completarse en menos de una hora y las diferencias respecto a la configuración de referencia quedaron por debajo del 5 %, según el inventario de parámetros definido para la prueba; la serie y el protocolo no están publicados en esta página.
En una academia o universidad con cientos de miles de preguntas y numerosas versiones de cursos, analicé alrededor de 300.000 preguntas. La duplicidad se acercaba al 30 %, las copias de los cursos grandes ocupaban entre unos 20 y 40 GB y algunas importaciones tardaban varias horas. Parecía que Moodle no podía manejar un banco de ese tamaño, y lo descarté porque las pruebas aisladas funcionaban: el deterioro aparecía al multiplicar las copias y las versiones. En esa instalación de Moodle 3.9, las preguntas se gestionaban principalmente dentro de cada curso y carecían de un modelo común de gobierno, metadatos, versionado y ciclo de vida. Propuse un banco gobernado y reutilizable, diseñé el plan de deduplicación, versionado e integración con los cursos y lo dejé documentado. Según las mediciones internas, con ese modelo el tamaño total de las copias de seguridad se redujo alrededor de un 60 % y el tiempo necesario para reutilizar una pregunta en otro curso pasó de días a horas; esta página no incluye la serie ni el procedimiento necesarios para reproducir el resultado.
Cómo trabajo
Cuando ya existe una plataforma, trabajo en este orden. En una plataforma nueva, empiezo por la volumetría prevista, los recorridos críticos, las integraciones, los objetivos de servicio y las restricciones operativas.
Versiones, extensiones, modificaciones del núcleo, integraciones, volumetría, infraestructura y flujos críticos. Con acceso, no con una entrevista.
Carga real, consultas lentas, tareas que no terminan, comportamiento en el pico. El cuello de botella aparece con frecuencia en un componente que no se estaba revisando.
Dónde debería estar cada responsabilidad y qué distancia hay hasta ahí. No un modelo ideal, sino un destino alcanzable desde la situación actual.
Qué hay que mover primero porque bloquea lo demás, qué puede esperar y qué no compensa tocar. Con el coste de cada paso y el riesgo de no darlo.
Contrasto lo que se construye con lo que se decidió, y corrijo el diseño cuando la evidencia demuestra que era incorrecto.
Marcos propios
Sirven para discutir los límites entre sistemas con criterios de arquitectura, en vez de decidirlos por preferencia de herramienta o por lo que sea más rápido de instalar.
Ver la colección completaMarco de Alberto Lara para diseñar ecosistemas EdTech que conectan experiencia, LMS/LXP, contenidos, integraciones, datos, IA, nube, seguridad y operación.
Consultar la arquitectura del ecosistema de aprendizaje ↗Lista de evaluación de Alberto Lara para integraciones EdTech: responsabilidad, identidad, estándares, datos, seguridad, fiabilidad y operación.
Consultar el marco de integraciones EdTech ↗Trabajo propio relacionado
Las fichas documentan qué inventarío, qué mido y con qué criterio. El trabajo hecho para otras organizaciones no aparece por confidencialidad.
Varias plataformas gobernadas como un solo sistema.
Ver la ficha de Gobierno de ecosistemas multi-LMS ↗Plataforma y operaciónQué hay que medir para saber cómo se comporta una plataforma.
Ver la ficha de Telemetría de operación ↗IA y aprendizajeCómo evalúo una instalación antes de proponer una arquitectura.
Ver la ficha de Diagnóstico de plataformas ↗Blog
Análisis sobre capacidad, base de datos, caché, integraciones, continuidad y evolución de plataformas de aprendizaje, con los límites de cada afirmación declarados.
Ir a blog.albertolarah.comHablamos
Dimensionar una plataforma, decidir entre una instalación o varias, o defender una decisión ante quien la paga. Si estáis en ello, escríbeme.