Centro de conocimiento
Moodle como plataforma de aprendizaje, sistema de gestión y servicio en producción
He reunido aquí lo que he ido aprendiendo en más de 22 años de trabajo con plataformas de aprendizaje: no cómo se usa Moodle, que eso está en su documentación, sino cómo se decide. Muchas preguntas de arquitectura y gobierno se repiten en Totara y Open LMS por su relación con Moodle, pero los mecanismos concretos varían según el producto, la versión y las personalizaciones. Explico qué problema aparece cuando la plataforma lleva años funcionando, por qué se produce, qué alternativas hay, qué consecuencias tiene cada una y qué debería exigirse en una solución profesional. En las páginas de análisis uso, según el problema, matrices de decisión, listas de comprobación y fuentes, y declaro el alcance de las afirmaciones.
Según lo que necesites
Responsabilidades desde las que he trabajado con Moodle
Las tres capacidades conviven en mi trabajo, pero responden a necesidades distintas y por eso las explico por separado.
01
Consultor Moodle
Cuando hay un problema o una duda y todavía no está claro si es funcional, académico, organizativo o técnico. El trabajo empieza por entenderlo y ordenar la decisión.
↗02Arquitecto Moodle
Cuando hay que diseñar o hacer evolucionar la plataforma: sus límites, su capacidad, sus integraciones, su continuidad y su camino de evolución.
↗03Tech Lead Moodle
Cuando el diseño ya existe y lo que falta es dirección técnica: qué se construye, con qué criterio se revisa y cómo se entrega sin acumular dependencias invisibles.
↗El mapa
El mapa completo
Cinco ámbitos. Casi ninguna consulta llega clasificada: empieza en uno y termina tocando otro, que es justamente el motivo de que estén enlazados entre sí.
Ámbito 01
Aprendizaje, evaluación y gestión del catálogo
Las decisiones que parecen académicas y acaban condicionando la arquitectura: cómo se estructuran los cursos, cómo crece el material y cómo se gobierna la evaluación.
Ámbito 02
Arquitectura, capacidad y continuidad
Lo que decide si la plataforma aguanta el día importante y si se puede recuperar cuando no aguanta.
- Rendimiento y escalabilidadDónde está el cuello de botella antes de ampliar infraestructura y cómo se diagnostica.
- Pruebas de carga y capacidadQué aguanta la plataforma el día de la convocatoria, medido antes de que llegue, y qué se decide con esa medida.
- Arquitectura multitenant y multiinstanciaUna instalación con varias organizaciones o varias instalaciones: qué se aísla, quién administra y cuánto cuesta operarlo.
- Copias y continuidadQué copiar, cómo garantizar la coherencia y por qué una copia sin restauración probada no demuestra que el servicio pueda recuperarse.
- ObservabilidadQué medir para enterarse de los problemas antes de que llame un usuario.
- Arquitectura de plataformasFuera del clúster MoodleLas mismas decisiones cuando el sistema va más allá de Moodle.
- Infraestructura y operaciónFuera del clúster MoodleNube, despliegue y operación de la infraestructura sobre la que corre la plataforma.
Ámbito 03
Ingeniería y evolución
Qué se construye, con qué criterio se juzga y cómo se evita que la plataforma quede bloqueada dentro de tres años.
- Desarrollo de extensionesQué distingue una extensión que sobrevive a la siguiente versión, y las cuatro preguntas previas a escribir código.
- Calidad del códigoLas seis dimensiones de una revisión seria y qué debería comprobar una máquina en lugar de una persona.
- Pruebas automatizadasQué merece la pena probar, qué no, y cómo se reconoce una suite que no protege de nada.
- Integración y despliegueLas cinco piezas que hacen que desplegar deje de dar miedo, incluida la vuelta atrás.
- Actualización y migraciónPor qué actualizar se convierte en un proyecto y qué hay que inventariar antes de empezar.
- Desarrollo a medidaFuera del clúster MoodleQué he construido cuando la configuración del núcleo ya no llegaba.
- Auditoría técnicaFuera del clúster MoodleRevisar con reglas explícitas el código que ya está en producción.
Ámbito 04
Integraciones, datos e inteligencia artificial
Moodle casi nunca está solo. Aquí es donde se decide qué sistema manda sobre cada dato y qué información sale de la organización.
- IntegracionesQuién responde de cada dato, identificador estable, idempotencia, reintentos y reconciliación.
- Inteligencia artificialEl subsistema de IA de la plataforma, qué fuentes puede consultar, qué sale hacia terceros y cómo se evalúa.
- Interoperabilidad y estándaresFuera del clúster MoodleIdentidad, integraciones y estándares educativos como contratos operativos.
- IA aplicada al aprendizajeFuera del clúster MoodleEl mapa completo de casos de uso a lo largo del ciclo de aprendizaje.
Ámbito 05
Contratación y gobierno
Lo que hay que dejar escrito para poder exigirlo después, y lo que cambia según el tipo de organización.
- Moodle, Totara y Open LMSQué comparten, en qué se separaron y qué decisión técnica cambia según cuál tengas.
- Requisitos para un pliegoCómo se escribe un requisito exigible, con su evidencia y su criterio de aceptación, apartado por apartado.
- Sectores y contextosFuera del clúster MoodleCómo cambian estas decisiones en universidad, empresa, formación profesional y Administración pública.
- Ver cómo separo soluciones, marcos y trabajo documentadoFuera del clúster MoodleCon qué nivel de evidencia cuenta cada pieza publicada.
- Marcos propiosFuera del clúster MoodleLos modelos de decisión que uso para ordenar arquitectura, integraciones, madurez de IA y automatización.
En preparación
Páginas previstas cuyo contenido todavía se está preparando.
Ya tienen un lugar definitivo en el mapa, pero no se publicarán ni se indexarán hasta desarrollar el problema, las alternativas, los criterios y las fuentes.
Análisis funcional y técnicoDe los requisitos a la arquitectura y los criterios de aceptación. PersonalizaciónPersonalización visual, funcional y por roles. Plataforma a medidaMoodle como núcleo de una plataforma propia. Alta disponibilidad y escalabilidadCapacidad, concurrencia, arquitectura y continuidad.
Criterio editorial
Cómo está escrito esto
Cuatro reglas que me he impuesto para que estas páginas sirvan para decidir y no para captar visitas.
- 01
Una página por decisión, no por término de búsqueda
No hay una página para «experto Moodle» y otra para «especialista Moodle»: son la misma intención y viven juntas. Las páginas nuevas aparecen cuando hay un problema distinto que explicar, no cuando hay un sinónimo que ocupar.
- 02
Cada página aporta algo que no está en otro sitio
Una matriz de decisión, un árbol de diagnóstico, una lista de comprobación o una tabla de requisitos con criterios de aceptación. Si una página no tiene nada propio, no la publico.
- 03
Las fuentes se distinguen de la opinión
Lo que dice la documentación oficial va enlazado y fechado. Lo que es criterio mío formado en plataformas concretas va declarado como tal, incluso cuando ambas cosas coinciden.
- 04
Afirmaciones con alcance y evidencia declarados
Cuando publico una cifra procedente de un caso sin identificar al cliente, indico que la medición es interna y si la página no permite reproducirla. No publico nombres de organizaciones ni resultados que no pueda acreditar. Al contar un caso, explico qué asumí, qué decidí y qué quedó entregado.
Blog
Las preguntas concretas se responden en el blog.
Estas páginas explican decisiones estables. El blog desarrolla los casos particulares, las pruebas y las novedades que no encajan en una página de referencia.
Ir a blog.albertolarah.comContacto
¿Tenéis delante una de estas decisiones?
Contadme el contexto y qué está bloqueado. No hace falta que lleguéis con el problema clasificado: buena parte del trabajo consiste precisamente en averiguar si lo que duele es la configuración, la arquitectura, el proceso o el equipo.
hola@albertolarah.comLinkedIn ↗