Una arquitectura es un conjunto de decisiones
La arquitectura de datos de un club o una federación no es un diagrama con muchas cajas. Es el acuerdo sobre qué datos existen, quién los genera, dónde se conservan, cómo se relacionan, quién puede utilizarlos y qué ocurre cuando algo cambia.
En una organización deportiva pueden convivir datos de plantilla, rendimiento físico, vídeo, salud, disponibilidad, competición, scouting, administración y formación. No todos necesitan reunirse en una única base ni estar disponibles para las mismas personas. El objetivo es que cada uso autorizado reciba información suficiente, coherente y trazable sin ampliar el acceso por comodidad.
No existe una arquitectura universal. Un club pequeño puede trabajar bien con exportaciones controladas y una base gestionada. Una federación con múltiples selecciones, clubes y proveedores necesitará identidades compartidas, permisos más granulares y procesos de intercambio. Los principios son comunes; la escala cambia la implementación.
Empezar por decisiones y usuarios
Antes de elegir tecnología conviene enumerar decisiones reales:
- preparar el microciclo;
- revisar carga individual;
- coordinar club y selección;
- generar informes para cuerpo técnico;
- analizar evolución longitudinal;
- gestionar disponibilidad;
- responder a solicitudes de acceso o borrado;
- recuperar información tras un fallo.
Para cada decisión se identifica quién la toma, qué datos necesita, con qué frecuencia y qué retraso admite. Un panel en tiempo real no aporta valor si la decisión se toma una vez a la semana; aumenta coste y complejidad. Al contrario, una alerta durante una sesión no puede depender de una exportación nocturna.
Capas de una arquitectura posible
Fuentes
Las fuentes incluyen plataformas de rendimiento, sistemas médicos, vídeo, competición, hojas de cálculo, formularios y aplicaciones internas. El inventario debe registrar propietario funcional, proveedor, formato, frecuencia, identificadores disponibles, datos personales y mecanismo de acceso.
No debe asumirse que una API anunciada está incluida en todas las cuentas. Los permisos, módulos y contratos se confirman con cada proveedor y organización.
Ingestión
La ingestión lleva el dato desde la fuente hasta una zona controlada. Puede ser por API, archivo, webhook o carga manual validada. Su responsabilidad es autenticarse, recoger, registrar y conservar la entrada sin reinterpretarla. La comparación entre CSV, API y webhook ayuda a elegir el transporte según frecuencia, latencia y capacidad operativa.
Cada recepción debería incluir procedencia, instante, versión y resultado. Si falla, debe poder reintentarse sin duplicar. Si el proveedor corrige una sesión, la nueva versión no debería borrar silenciosamente la anterior.
Zona original
Conservar una copia inmutable o protegida de la entrada facilita auditoría y reprocesamiento. No tiene por qué ser accesible para análisis diario. Su función es responder qué entregó el sistema de origen en un momento determinado.
La conservación debe tener un plazo y una base legítima. “Guardar todo por si acaso” no es una política de datos.
Normalización
Esta capa traduce formatos a un modelo común: jugadores, equipos, sesiones, tareas, métricas, fechas y unidades. También registra qué transformaciones se aplicaron y qué filas se rechazaron.
La normalización no debe borrar el contexto del proveedor. Si dos métricas parecen equivalentes pero no comparten definición, se conservan separadas.
Almacenamiento de trabajo
Aquí viven los datos preparados para consultas e informes. Puede ser una base relacional, un almacén analítico o una combinación. La elección depende de volumen, frecuencia y equipo técnico; no es obligatorio desplegar una plataforma de datos compleja.
Un modelo relacional suele funcionar bien para entidades estables y relaciones claras. Un almacén orientado a análisis puede ser útil para históricos extensos y consultas agregadas. La decisión debe considerar restauración, coste y capacidad de mantenimiento.
Productos de datos
Dashboards, informes, exportaciones y APIs internas consumen datos preparados. Cada producto debería tener finalidad, propietario, audiencia, frecuencia y criterios de calidad. La arquitectura existe para estos usos; no para acumular datos.
Identificadores: la pieza menos visible
El mismo deportista puede tener un identificador en el proveedor GPS, otro en el sistema de competición y otro en una hoja médica. El nombre no es una clave fiable. Cambia de formato, puede repetirse y contiene errores.
Una capa de identidad asigna un identificador interno y mantiene correspondencias autorizadas. El mapeo inicial necesita revisión. Cuando un jugador cambia de club o selección, la relación histórica debe conservarse sin conceder automáticamente acceso a datos de otra entidad.
También necesitan identificador las sesiones, equipos, temporadas, competiciones y tareas. Una fecha no distingue dos entrenamientos del mismo día.
| Entidad | Identificador estable | Atributos que pueden cambiar |
|---|---|---|
| Deportista | ID interno | Nombre visible, dorsal, equipo |
| Sesión | ID de sesión | Título, etiquetas, estado |
| Equipo | ID de organización | Nombre comercial, categoría |
| Métrica | ID y versión de definición | Etiqueta de presentación |
| Fuente | ID de sistema y cuenta | Credenciales, endpoint, proveedor |
Permisos por finalidad y contexto
No todas las personas necesitan la misma vista. El personal de rendimiento puede requerir carga física; el cuerpo técnico, un resumen; administración, datos contractuales; y un proveedor externo, sólo el conjunto necesario para prestar su servicio.
Los permisos pueden combinar rol, equipo, temporada y tipo de dato. Conviene evitar una única cuenta compartida. Los accesos relevantes y las exportaciones sensibles deberían quedar registrados.
El RGPD establece principios como limitación de finalidad, minimización y conservación limitada para datos personales. La aplicación concreta requiere asesoramiento jurídico y conocimiento del tratamiento, pero la arquitectura debe permitir cumplir decisiones de acceso, rectificación, supresión y restricción; no bloquearlas por diseño.
Historial y temporalidad
Una arquitectura deportiva necesita responder “qué se sabía entonces”, no sólo mostrar el estado actual. Si cambia un umbral, una plantilla o la relación del jugador con un equipo, los informes históricos no deberían reinterpretarse sin aviso.
Para cada registro relevante conviene distinguir:
- momento al que corresponde el hecho;
- momento en que se recibió;
- versión de la fuente;
- periodo de vigencia;
- estado actual;
- motivo de corrección.
Esta temporalidad evita que una corrección posterior parezca haber estado disponible durante una decisión anterior.
Calidad del dato
La calidad no es una cifra única. Depende del uso. Un panel semanal puede tolerar algunos minutos de retraso, pero no jugadores sin identificar. Una alerta en directo prioriza oportunidad, pero también debe explicar interrupciones.
Controles habituales:
- completitud de campos obligatorios;
- unicidad de identificadores;
- validez de unidades y rangos;
- consistencia entre totales y tareas;
- puntualidad de las fuentes;
- correspondencia de jugadores;
- ausencia de duplicados;
- trazabilidad hasta el origen.
Cada control debe tener responsable y acción. Un panel de calidad que nadie atiende sólo documenta el deterioro.
Dashboards e informes
Un dashboard no debería consultar indiscriminadamente todas las tablas originales. Es preferible preparar conjuntos con definiciones acordadas y permisos aplicados. El panel muestra indicadores; la documentación explica qué significan.
Los informes deben indicar periodo, fuente, versión y fecha de actualización. Si un valor se recalcula, conviene distinguir la nueva versión de la distribuida originalmente.
La salida descargable sigue siendo útil para análisis ad hoc. Debe respetar los mismos permisos que la interfaz y evitar que una exportación masiva eluda controles.
Interoperabilidad sin equivalencias falsas
Interoperar no significa convertir todos los datos al mismo nombre. Significa poder intercambiarlos conservando significado. Un diccionario de métricas documenta definiciones, unidades, umbrales y nivel de agregación.
Cuando clubes y federaciones comparten información, necesitan además acordar identificadores, periodos, permisos y responsabilidad sobre correcciones. Las funciones de intercambio de un proveedor pueden ayudar, pero no sustituyen el acuerdo de gobierno.
La guía para integrar Catapult, STATSports, WIMU y CSV desarrolla estas precauciones en fuentes de rendimiento.
Copias y recuperación
Una copia de seguridad sólo es útil si puede restaurarse. El plan debe definir qué se copia, frecuencia, cifrado, separación respecto al sistema principal, retención y pruebas de recuperación. CISA recomienda respaldos frecuentes y almacenamiento seguro, incluida la separación que reduzca el riesgo de pérdida simultánea.
También hay que respaldar configuraciones, diccionarios, reglas y código. Recuperar datos sin saber cómo interpretarlos no restablece el servicio.
El objetivo de recuperación determina la solución: cuánta información puede perderse y cuánto tiempo puede estar indisponible el sistema. No todos los componentes necesitan el mismo nivel.
Tres niveles de madurez
Nivel 1: control básico
Inventario de fuentes, carpetas controladas, convenciones, copias, permisos individuales y validaciones de archivos. Puede ser suficiente para una organización pequeña.
Nivel 2: integración y modelo común
Conectores repetibles, zona original, identificadores internos, normalización, base de trabajo, control de versiones y productos de datos definidos.
Nivel 3: gobierno distribuido
Catálogo, trazabilidad automatizada, permisos por contexto, acuerdos entre entidades, monitorización de calidad y recuperación probada. Es apropiado cuando crecen equipos, proveedores y obligaciones.
Subir de nivel sólo tiene sentido si resuelve un problema observado.
Una hoja de ruta proporcionada
- Inventariar decisiones, usuarios y fuentes.
- Clasificar datos y permisos.
- Definir identificadores internos.
- Elegir un caso de uso y normalizarlo.
- Conservar originales y registrar versiones.
- Crear controles de calidad con responsables.
- Entregar un producto útil y medir su uso.
- Probar copia y restauración.
- Incorporar nuevas fuentes una a una.
La arquitectura correcta no es la que incluye más tecnología, sino la que permite responder con claridad de dónde viene un dato, qué significa, quién puede usarlo, cómo se corrige y cómo se recupera.