Qué debe permanecer en el LMS
El marco distingue la capacidad educativa propia del LMS de aquello que pertenece a la identidad, los contenidos, los datos o el negocio.
Arquitectura de referencia
Arquitectura de referencia para un ecosistema de aprendizaje
Un LMS cubre solo una parte de las necesidades del aprendizaje digital. La arquitectura del ecosistema debe integrar los canales de experiencia, los procesos formativos, los sistemas de negocio, los datos y la infraestructura. También debe prever la operación necesaria para mantener los servicios disponibles.
Idea central
La arquitectura se decide al asignar responsabilidades y definir la relación entre las distintas partes del ecosistema.
Cuando el ecosistema se diseña como una suma de aplicaciones sin responsabilidades ni contratos comunes, pueden duplicarse las identidades, perderse el significado de los datos y proliferar las excepciones de integración. Este marco permite leer el sistema por capas y localizar dónde debe vivir cada responsabilidad.
El modelo
Seis capas de decisión
Las seis capas ayudan a decidir qué responsabilidad pertenece a cada sistema y qué dependencias deben seguir visibles entre ellas.
- 01
Experiencia y canales
Esta capa reúne los puntos en los que estudiantes, docentes, autores, tutores, responsables y clientes interactúan con el sistema.
- Web y móvil
- Portales
- Aula virtual
- Asistentes
- Experiencias accesibles
- 02
Procesos de aprendizaje y negocio
Aquí se relacionan la captación, la orientación, la matriculación, el aprendizaje, la evaluación, la certificación, el soporte y la relación con otras organizaciones.
- B2B, B2C y B2G
- Programas y cohortes
- Evaluación
- Acreditación
- Atención
- 03
Productos educativos
En esta capa conviven el sistema de gestión del aprendizaje (LMS), la plataforma de experiencia de aprendizaje (LXP), el catálogo, las herramientas de autoría, los contenidos, la evaluación, el vídeo, las credenciales y otras aplicaciones especializadas.
- Moodle y otros LMS
- Plataformas de experiencia de aprendizaje (LXP)
- Gestión de contenidos de aprendizaje (LCMS) y de activos digitales (DAM)
- Repositorios
- Herramientas de autor
- 04
Integración, datos e inteligencia
La identidad, las API, los eventos, los estándares, la analítica, el conocimiento y la IA conectan las distintas partes del ecosistema.
- Inicio de sesión único (SSO) y SCIM
- LTI y xAPI
- API y eventos
- Almacén de registros de aprendizaje (LRS) y analítica
- Generación aumentada por recuperación (RAG) y agentes
- 05
Ingeniería de plataforma
Esta base permite construir, probar, desplegar, observar y proteger el producto durante toda su vida útil.
- Nube
- Contenedores
- Infraestructura como código (IaC)
- Integración y entrega continuas (CI/CD)
- DevSecOps
- 06
Fiabilidad y evolución
En esta capa, la arquitectura se revisa a partir de los datos sobre capacidad, rendimiento, disponibilidad, recuperación y coste, y de lo aprendido durante la operación.
- Pruebas de carga
- Alta disponibilidad
- Objetivos de nivel de servicio (SLO)
- Observabilidad
- Continuidad
Secuencia de trabajo
Para diseñar la arquitectura, parto del propósito y termino por definir las condiciones de operación y evolución.
El análisis documenta los supuestos para los equipos que diseñarán, construirán y operarán el ecosistema o asumirán su gobierno.
- Paso 1
Partir del proceso
Primero identifico qué debe conseguir cada persona y qué resultado necesita la organización.
- Paso 2
Asignar responsabilidades
Después decido qué sistema conserva el registro principal de cada dato, qué aplicación ejecuta cada proceso y qué canal presenta cada experiencia.
- Paso 3
Diseñar los contratos
A continuación defino la identidad, la semántica, las API, los eventos, los estándares y el comportamiento ante fallos.
- Paso 4
Diseñar la operación
Por último, incorporo la entrega, la seguridad, la observabilidad, la capacidad y la recuperación antes de poner el sistema en producción.
Decisiones
Estas son las decisiones que el marco ayuda a tomar.
Cada decisión debe poder explicarse, ejecutarse y revisarse cuando cambien los datos o el contexto.
Qué sistema conserva cada dato y quién responde de él
El análisis identifica el sistema que conserva los datos de usuarios, programas, matrículas, competencias, activos y resultados, y el equipo que responde de su calidad y evolución.
Qué conviene comprar o construir
La comparación tiene en cuenta las capacidades, la dependencia, el coste de integración y la capacidad operativa de la organización.
Cómo evolucionar sin detener el servicio
El resultado hace visible una secuencia de modernización compatible con la operación existente.
Cómo lo aplico
Un mapa para conversar con negocio, producto e ingeniería sobre el mismo sistema
Lo utilizo para que negocio, producto e ingeniería acuerden qué responsabilidad corresponde a cada sistema y qué dependencias deben mantenerse visibles.
Referencias y contexto
Estándares y fuentes primarias utilizados en el marco.
- Comisión Europea: European Higher Education Interoperability Framework (febrero de 2025; consulta: 28/07/2026)
- 1EdTech: Learning Tools Interoperability (LTI) 1.3 y LTI Advantage · consulta: 28/07/2026
- IEEE 9274.1.1-2023: xAPI using JSON serialization and RESTful data transport · consulta: 28/07/2026
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2, Recomendación de 12/12/2024 · consulta: 28/07/2026
Desarrollo editorial
El blog examina con más detalle las decisiones de cada marco.
El proyecto editorial independiente amplía los patrones, los estándares y los casos de uso con fuentes y ejemplos.
Ir a blog.albertolarah.comConversación profesional
Si necesitas aplicar este marco a un sistema real, hablemos del contexto.
Empezaremos por el problema, las responsabilidades y las decisiones que la organización necesita mantener en el tiempo.
Abrir una conversación