Plataforma y operación

Gobierno de ecosistemas multi-LMS

Estoy desarrollando un plano de control para observar y gobernar varias plataformas Moodle desde un único sistema.

El problema

Cuando una organización opera varias instancias, cada una mantiene su propia configuración, sus permisos, sus alertas y su calendario de mantenimiento. Nadie ve el conjunto, y el equipo de operación acaba revisando instancia por instancia.

Coordinar varias plataformas exige diseñar un sistema común de gobierno.

La dificultad aparece cuando cada campus tiene versiones, extensiones, responsables y ventanas de cambio distintas. El plano de control debe dar una lectura común sin convertir todas las instancias en copias ni conceder a una consola central más poder del necesario.

Decisión principal

Separar gobierno central y autonomía local.

El contrato entre la plataforma de gobierno y cada Moodle fija qué puede observar el sistema, qué operaciones puede solicitar o ejecutar, cómo debe registrarlas y qué ocurre si una instancia queda aislada. Este reparto condiciona la seguridad, la recuperación y la evolución del conjunto.

Criterios de diseño

  1. 01

    Separo el plano de control de las plataformas gestionadas para evitar que toda la lógica quede concentrada en cada Moodle.

  2. 02

    El sistema recibe telemetría, conserva un registro de auditoría y coordina operaciones, mientras cada instancia mantiene su autonomía.

  3. 03

    La incorporación, la desconexión y la recuperación forman parte del funcionamiento habitual del producto.

Límites del producto

El modelo de gobierno central respeta la autonomía de cada plataforma.

El sistema no debe sustituir los procesos locales ni ocultar diferencias relevantes entre plataformas. Las operaciones remotas se reservan para acciones acotadas, reversibles y auditables. El resto necesita un responsable y un procedimiento en la instancia afectada.

Capacidades del sistema

  • 01Alta y verificación de instancias
  • 02Telemetría y estado consolidado
  • 03Alertas y auditoría
  • 04Operaciones remotas sujetas a controles

Criterio de validación

La prueba debe cubrir el ciclo completo de una instancia.

La evidencia debe cubrir el alta, la autenticación, la recepción de telemetría, la detección de la pérdida de comunicación, una ejecución controlada y la baja. La prueba también debe demostrar que un fallo del plano de control no interrumpe el aprendizaje en las plataformas gestionadas.

Evidencia descrita para el gobierno de ecosistemas multi-LMS

  • Plano de control operativo con telemetría propia
  • 12 tablas de datos documentadas
  • Pruebas automatizadas de las capacidades críticas
  • Integración mediante un conector propio para Moodle

Preguntas abiertas

Decisiones pendientes en el gobierno de ecosistemas multi-LMS.

Antes de ampliar el gobierno común, falta validar el alcance de las operaciones remotas, el aislamiento entre organizaciones y el modelo de permisos de cada instancia.

  • Modelo de permisos entre organizaciones e instancias
  • Objetivos de nivel de servicio (SLO) y retención de telemetría
  • Límites de las operaciones remotas
  • Portabilidad entre variantes de Moodle

Contextos en los que encaja

Quién necesita mirar varias plataformas a la vez

Me lo he encontrado siempre que una organización pasa de una instalación a varias sin haberlo decidido del todo.

01

Universidad con campus por facultad

Cada facultad monta el suyo con su ritmo de actualización. Nadie puede responder cuántas personas se han formado en toda la universidad sin pedir los datos facultad por facultad.

02

Equipo técnico con varias instalaciones a su cargo

Entra una a una a cada instalación para comprobar lo mismo. El tiempo se va en navegar, no en resolver.

03

Grupo con varias marcas formativas

Comparten equipo técnico y no comparten nada más: ni versión, ni extensiones, ni criterio de copias.

04

Administración con instancias por departamento

Cada una con su responsable y su nivel de exigencia, y una auditoría que llega para todas a la vez.

Decisiones de arquitectura

Decisiones que exige el diseño

Un plano de control se define por lo que decide no hacer.

  1. 01

    Observar sin intervenir por defecto

    El sistema consulta estado y métricas sin permiso de escritura. Las operaciones que cambian algo son un conjunto delimitado y explícito, cada una con su autorización. Descarté un acceso administrativo general porque convierte un fallo del panel en un incidente en todas las plataformas.

  2. 02

    Hablar por interfaces públicas

    La comunicación pasa por servicios web versionados, no por acceso directo a base de datos. Es más lento de construir y reduce el acoplamiento con el modelo interno, pero la compatibilidad del contrato también debe declararse y probarse en cada versión.

  3. 03

    Cada plataforma conserva su autonomía

    El plano de control observa y coordina; no impone versión ni configuración. Centralizar la operación habría convertido cada actualización en un proyecto de toda la organización.

  4. 04

    Excluir la actividad identificable de la telemetría central

    Es un objetivo que hay que comprobar, no una propiedad que se pueda presuponer. Inventario métricas, estado y configuración para detectar identificadores directos o indirectos; después aplico minimización, conservación limitada y aislamiento entre organizaciones. Cada tratamiento documenta su finalidad y su base jurídica. La actividad identificable permanece en la instancia salvo que una necesidad concreta y una base jurídica documentada justifiquen transferirla.

A escala

Qué cambia con la carga operativa del conjunto

  1. Trabajo manual cuyo coste medido es bajo

    Puede bastar un panel sencillo mientras comprobar manualmente el estado de cada plataforma consuma poco tiempo y no retrase las actuaciones.

  2. Heterogeneidad y trabajo recurrente

    Cuando la diversidad de versiones, extensiones y ventanas genera revisiones repetidas, conviene valorar un inventario consolidado.

  3. Operación manual que consume capacidad

    Las operaciones remotas solo se justifican cuando el trabajo repetido consume una parte significativa de la capacidad del equipo y sus riesgos pueden controlarse.

  4. Varias organizaciones distintas

    El aislamiento entre datos de cada una pasa a ser un requisito contractual que hay que poder demostrar.

Trabajo aplicado hasta ahora

Gobierno técnico para varias plataformas sin perder su autonomía

He separado el plano de control de cada instancia y he definido cómo reunir la telemetría y los registros de auditoría, así como la forma de acotar las operaciones. El modelo de permisos entre organizaciones e instancias sigue pendiente de validación.

  • 01Arquitectura de plataforma
  • 02Operación y observabilidad
  • 03Gobierno técnico
  • 04Integración entre el plano de control y las plataformas Moodle
Consultar Arquitectura del ecosistema de aprendizaje