close

Alberto Lara Hernández · Director de tecnología, arquitecto de software y líder tecnológico en EdTech

Dirijo la tecnología educativa desde las decisiones de negocio y aprendizaje hasta la arquitectura y la operación.

Convierto objetivos educativos y de negocio en prioridades de inversión, arquitectura y datos. Diseño plataformas educativas a medida y sigo cerca de la ejecución: reviso con el equipo diseños, código e integraciones cuando necesito comprobar una decisión.

Ir a mis áreas de responsabilidad

Resumen profesional

Mis áreas de responsabilidad.

Forman parte del mismo trabajo. Cada enlace desarrolla las decisiones, el criterio técnico y las comprobaciones propias de ese ámbito.

  1. Estrategia y negocioConvierto objetivos de negocio y educativos en decisiones de inversión, principios tecnológicos y una hoja de ruta que el equipo puede ejecutar.
  2. Producto EdTechDefino el problema, el colectivo, el resultado y la forma de comprobarlo antes de ordenar las prioridades y la evolución del producto.
  3. Arquitectura y plataformaDecido cómo debe evolucionar la plataforma para crecer sin multiplicar la deuda ni poner en riesgo las integraciones, los datos, la seguridad, el rendimiento o la continuidad.
  4. Diseño de soluciones a medidaDiseño la solución desde las personas, los recorridos, los datos, las integraciones y las excepciones, y decido qué conviene configurar, integrar o construir.
  5. Entrega y operaciónLlevo las decisiones hasta producción y preparo con el equipo los despliegues, la observabilidad, la reversión, la respuesta ante incidentes y las evidencias de auditoría.
  6. Dirección de equiposComparto con el equipo el contexto, las prioridades y los criterios que necesita para decidir, entregar con calidad y resolver problemas con más autonomía.
  7. Cercanía técnicaReviso diseños y código, pruebo integraciones e investigo problemas de rendimiento cuando una decisión necesita una comprobación directa.
  8. Especialización educativaRelaciono la tecnología con el aprendizaje, la evaluación, la accesibilidad, la adopción y las restricciones propias de cada institución.
  9. IA aplicadaLlevo cada uso de IA desde la prueba hasta una función evaluable y operable, con fuentes autorizadas, permisos definidos y criterios para medir la calidad, la latencia y el coste.
  10. Interlocución ejecutivaExplico las alternativas y sus consecuencias a quienes responden del negocio, del producto, del ámbito académico, de la tecnología y de la auditoría, además de a los proveedores.

El trabajo, por dentro

La dirección tecnológica reúne estrategia, producto, arquitectura, ingeniería y operación.

Una hoja de ruta solo es viable cuando relaciona el negocio, el aprendizaje, la arquitectura y la capacidad de entrega. Estos ámbitos muestran el trabajo que hay detrás.

Dirección, estrategia y negocio

Convierto el rumbo de la organización en decisiones de inversión y en una hoja de ruta viable.

Antes de decidir si algo se construye, se compra o se integra, valoro el coste total, las dependencias, el riesgo y la capacidad disponible. La misma pregunta vale para lo que ya existe: qué se mantiene y qué conviene retirar.

A partir de ese análisis, priorizo las inversiones y la evolución del producto, y defino una secuencia de trabajo que puede explicarse ante la dirección de negocio y ejecutarse con el equipo.

Producto y especialización EdTech

Defino el producto desde el problema educativo, la adopción y el resultado que debe demostrar.

Antes de priorizar una función, preciso para quién es, qué cambio debe producir, cómo se comprobará y qué coste tendrá operarla. La hoja de ruta relaciona valor, aprendizaje, datos y capacidad de entrega.

Trabajo con el equipo de producto y con los responsables académicos para definir el recorrido, la evaluación y la accesibilidad. Después delimito qué corresponde al LMS, a los contenidos y a los demás sistemas.

Arquitectura, plataforma y operación

Preparo la plataforma para crecer, responder bajo carga y recuperarse cuando algo falla.

Trabajo sobre los límites del sistema, el modelo de datos, la identidad, las integraciones, la seguridad, la nube y la observabilidad. Esas decisiones condicionan también la disponibilidad y el rendimiento.

Un tiempo de carga alto, una inscripción duplicada o una caída pueden empezar en sitios distintos. Reviso consultas, cachés, almacenamiento, contratos y tráfico antes de decidir dónde actuar.

Diseño de soluciones a medida

Diseño la solución completa antes de decidir qué parte se configura, se integra o se construye.

Empiezo por las personas, los roles, el recorrido, los estados, las excepciones y las evidencias. A partir de ahí reparto responsabilidades entre el LMS, la identidad, los contenidos, los datos y los sistemas de negocio.

La respuesta puede combinar capacidades estándar, integraciones, desarrollo propio, automatización e inteligencia artificial. Los límites y los contratos permiten probarla, operarla y evolucionarla.

Inteligencia artificial aplicada

Llevo cada uso de IA desde la prueba hasta una función que puede evaluarse y operarse.

Cada caso necesita una finalidad, fuentes autorizadas, permisos definidos y criterios para medir la calidad, la latencia y el coste. También necesita una persona que responda del resultado y sepa cuándo debe revisarlo.

Trabajo sobre sistemas de conocimiento, ayuda contextual, contenidos y automatización. Si las fuentes no bastan o la acción tiene consecuencias relevantes, la solución debe detenerse o derivar el caso a la persona responsable.

Ingeniería, equipos y entrega

Las decisiones llegan a producción con contexto, pruebas y capacidad de reversión.

Comparto prioridades y criterios para que el equipo pueda decidir y resolver problemas con autonomía. Mantengo la cercanía técnica: reviso diseños y código, pruebo integraciones y participo en despliegues e incidencias.

Uso las pruebas, la telemetría y lo aprendido durante la operación para revisar la arquitectura y la hoja de ruta. La entrega no cierra la decisión: aporta información para la siguiente.

Decisiones técnicas

Así decido sobre dieciséis asuntos técnicos de una plataforma de aprendizaje.

Explico qué miro primero, qué descarto y qué consecuencias tiene cada decisión. Bajo a problemas concretos: capacidad en convocatorias, propiedad de preguntas, consistencia de copias, gobierno del dato, permisos, despliegues y actualizaciones.

Pruebas de carga y capacidad

Qué aguanta la plataforma el día de la convocatoria, medido antes de que llegue.

Rendimiento y diagnóstico

Por qué se degrada en exámenes y matrículas, y dónde está la causa.

Ediciones y copias de curso

Reiniciar, duplicar o trabajar con un curso maestro sin multiplicar el mantenimiento.

Banco de preguntas

Contextos, propiedad, versiones y permisos cuando hay miles de preguntas dentro.

Copias y continuidad

Qué copio, por qué la consistencia entre datos y ficheros es el punto crítico y cuánto tarda restaurar.

Varias organizaciones

Separación lógica, varias instalaciones o campus independientes: qué se comparte y qué se aísla.

Integraciones y datos

Identidad, sistemas académicos y analítica: qué sistema manda sobre cada dato.

Inteligencia artificial

Qué datos salen a terceros, con qué fuentes responde y quién responde del resultado.

Pliegos y licitaciones

Volumetría, rendimiento, seguridad, accesibilidad y continuidad, en requisitos comprobables.

Actualización y migración

Por qué actualizar se convierte en un proyecto y cómo evitar que la próxima vez pase igual.

Desarrollo de extensiones

Qué distingue una extensión mantenible de una que hipoteca la plataforma.

Revisión de código

Estándares, seguridad, permisos, carga y privacidad antes de aceptar una entrega.

Pruebas automatizadas

Qué se prueba de un desarrollo: lógica, integración, recorridos, permisos y errores.

Entrega continua

Comprobaciones automáticas y despliegues repetibles para reducir el riesgo de cada puesta en producción.

Observabilidad

Qué mido para enterarme de un problema antes de que alguien tenga que avisar.

Moodle, Totara y Open LMS

Qué comparten, dónde divergen y cómo cambia eso la arquitectura y el desarrollo.

Ver el centro de conocimiento completo

Criterio profesional

Cuatro dimensiones para evaluar decisiones EdTech.

Así comparo alternativas: una cifra aislada, una función suelta o un producto evaluado fuera de contexto no bastan para decidir. En cada dimensión añado la condición que permite valorar el resultado completo.

Cada dimensión, la lectura que se queda corta y la condición que añado antes de decidir
DimensiónLectura insuficienteCriterio que añado
Medida del resultadoContar solo descargas y registros.Incorporar también retención, resultado formativo y retorno de la inversión.
Papel de la IAAñadir un chatbot o una función aislada sin controles propios.Definir finalidad, fuentes, permisos, evaluación y una persona responsable.
IntegraciónConcentrar procesos y datos sin contratos explícitos.Decidir qué conviene integrar mediante estándares como LTI y contratos de API versionados.
Enfoque pedagógicoMedir el producto por la cantidad de contenido entregado.Diseñar los recorridos desde los resultados de aprendizaje y la forma de comprobarlos; incorporar adaptación solo cuando la necesidad y las pruebas lo justifiquen.

Interlocución

La misma decisión debe poder explicarse en cinco conversaciones distintas.

El criterio no cambia según el interlocutor, pero sí cambian las preguntas, las consecuencias y las pruebas que necesita cada responsable.

CEO o fundador
Relaciono la arquitectura y la hoja de ruta con el crecimiento, el margen y el ritmo de evolución del producto para que cada venta no abra una variante permanente de la plataforma.
CTO o CIO de grupo
Ante un CTO o CIO de grupo, explico cómo el aprendizaje, la evaluación, la accesibilidad, los estándares, los datos y las restricciones institucionales condicionan la arquitectura y qué decisiones deben coordinarse con el resto del grupo.
Dirección general u operaciones
Trato la continuidad, el coste, la trazabilidad y las evidencias de auditoría como condiciones del producto y de su operación diaria.
Transformación digital
Convierto el piloto en un plan para llegar a producción, con responsables, integraciones, seguridad, adopción, mantenimiento y criterios de aceptación.
Dirección académica
Parto del modelo pedagógico y de evaluación para decidir qué debe hacer la tecnología, qué no debe decidir y qué evidencias necesita conservar.
Ver sectores y contextos

Trayectoria

Más de 22 años en plataformas de aprendizaje.

Leer la trayectoria completa

Empecé programando y no lo he dejado del todo. Los primeros años fueron de desarrollo sobre plataformas de aprendizaje, cuando en muchas organizaciones todavía se discutía qué sentido tenía ofrecer un curso por internet.

Después llegaron los proyectos donde la plataforma ya no era el proyecto, sino la infraestructura de la que dependía todo lo demás: universidades, Administración pública y organizaciones con formación propia. Tres contextos que parecen el mismo problema y no lo son. Ahí aprendí a distinguir una restricción técnica de una restricción normativa disfrazada de técnica.

Hoy trabajo también sobre producto, equipos, inteligencia artificial y operación. Una decisión no termina cuando se aprueba: hay que explicarla ante quien responde por el coste, comprobarla con el equipo y conservar las evidencias que pedirá una auditoría.

Contacto

Aquí estoy.

Escríbeme si quieres contrastar una decisión tecnológica en educación, hablar de plataformas de aprendizaje o proponerme algo.