GovFrame usa la taxonomía como columna vertebral. La taxonomía organiza el contexto de negocio; los demás objetos se relacionan con uno o más niveles para explicar qué significa un dato, quién responde por él, dónde vive, cómo se controla y cómo se publica.
Esta página responde dos preguntas:
- ¿En qué nivel taxonómico se relaciona cada objeto?
- ¿Cómo se conectan entre sí los objetos de negocio, técnicos y operativos?
1. La taxonomía es el eje de navegación
El tenant puede trabajar con uno de estos modelos:
Taxonomía estándar: Dominio → Entidad → Atributo
Taxonomía expandida: Dominio → Subdominio → Entidad → Atributo
| Nivel | Qué representa | Qué suele depender de él |
|---|---|---|
| Dominio | Gran ámbito de negocio y responsabilidad. | Alcance de usuarios, ownership, productos, contratos, políticas y objetos de alto nivel. |
| Subdominio | División opcional del dominio. | Alcance más preciso, entidades, productos, contratos, políticas y casos operativos. |
| Entidad | Concepto u objeto de negocio. | Atributos, términos, roles de gobierno, repositorios heredados y datos no estructurados. |
| Atributo | Elemento de información dentro de una entidad. | Reglas de calidad, campos del Diccionario técnico, clasificaciones y contratos. |
Un objeto puede tener una asociación directa con un nivel o llegar a él por una relación derivada. Por ejemplo, un campo técnico apunta directamente a un Atributo; el Dominio se obtiene atravesando Atributo → Entidad → (Subdominio) → Dominio.
2. Regla de asociación directa y heredada
- Directa: el registro guarda explícitamente el vínculo con el nivel taxonómico. Ejemplo: un Producto guarda
domainIdy, opcionalmente,subdomainId. - Por componente: el vínculo se guarda en una relación reutilizable que permite asociar un objeto a uno o varios nodos. Ejemplo: un Repositorio puede asociarse a varios Dominios o Subdominios.
- Heredada: el sistema calcula el contexto desde un objeto hijo. Ejemplo: una Regla de calidad hereda Dominio y Subdominio desde el Atributo al que pertenece.
- Derivada por composición: un Contrato puede llegar a atributos, reglas, campos y términos mediante sus tablas de asociación, aunque su alcance principal sea Dominio/Subdominio.
La asociación heredada no cambia el nivel original del objeto. Sirve para filtros, autorización, navegación, cobertura y análisis de impacto.
3. Matriz de objetos y nivel de relación
| Objeto | Asociación principal actual | Nivel de relación | Relaciones relevantes |
|---|---|---|---|
| Término de negocio | Dominio y enlaces a una o varias Entidades. | Dominio o Entidad; puede enlazarse mediante componentes a otros nodos. | Define lenguaje de negocio; puede formar parte de un Contrato y documentar un KPI. |
| Rol de gobierno | Dominio y enlaces a Entidades. | Dominio y Entidad. | Representa Owner/Steward u otra responsabilidad; puede ser responsable de Producto o Contrato. |
| Regla de calidad | Atributo. | Atributo, con contexto heredado de Entidad, Subdominio y Dominio. | Usa una Dimensión; se asocia a campos técnicos válidos y puede entrar en Contratos y Workflows. |
| Campo del Diccionario técnico | Atributo y Repositorio. | Atributo; el Repositorio aporta el contexto físico. | Guarda esquema, tabla, columna, tipo y características físicas; materializa un vínculo con la fuente. |
| Repositorio de datos | Uno o varios Dominios/Subdominios mediante asociaciones de alto nivel; puede conservar Entidad heredada. | Dominio/Subdominio; opcionalmente Entidad por compatibilidad o contexto legado. | Se conecta mediante un Conector; contiene metadata, snapshots y campos del Diccionario técnico; puede pertenecer a un Sistema. |
| Sistema de información | Uno o varios Dominios/Subdominios mediante asociaciones de alto nivel; puede conservar Entidad heredada. | Dominio/Subdominio; opcionalmente Entidad por contexto legado. | Se relaciona con Repositorios, Productos y Contratos. |
| Datos no estructurados | Entidad y/o asociación de componente. | Entidad, con Dominio/Subdominio heredado. | Puede ser un activo de arquitectura y participar en relaciones de gobierno. |
| Activo de datos | Dominio. | Dominio; puede recibir asociaciones adicionales de taxonomía. | Puede ser parte de un Producto y estar certificado, clasificado o comentado. |
| Producto de datos | Dominio y Subdominio opcional. | Dominio/Subdominio. | Agrupa Activos y se relaciona con un Owner y con Contratos. |
| Contrato de datos | Dominio, Subdominio y Owner. | Dominio/Subdominio. | Incluye Atributos, Reglas de calidad, Campos del Diccionario, Términos, Sistemas y Producto. |
| Política, Proceso y Procedimiento | Dominio/Subdominio opcionales. | Dominio/Subdominio. | Mantienen la jerarquía Política → Proceso → Procedimiento, versiones, responsables y aprobaciones. |
| Objetivo | Dominio/Subdominio opcionales. | Dominio/Subdominio. | Se relaciona con uno o varios KPI y mantiene mediciones y revisiones. |
| KPI o Key Result | Nivel primario explícito: Dominio, Subdominio, Entidad o Atributo. | Cualquiera de los cuatro niveles. | Puede tener enlaces secundarios a taxonomía y a Términos, Activos, Reglas, Diccionario, Repositorios, Sistemas, Productos y Contratos. |
| Workflow y caso | Dominio/Subdominio opcionales y objeto objetivo. | Contexto directo o derivado del objeto afectado. | Un caso puede apuntar a cualquier objeto del ecosistema; sus tareas, decisiones, evidencias y notificaciones dependen del caso. |
| Solicitud de acceso | Objeto solicitado y caso de Workflow. | Se deriva del objeto: tabla, dashboard, dataset u otro destino permitido. | Puede agrupar varias solicitudes, tener aprobación parcial, enmascaramiento y provisionamiento. |
| Stewardship | Asignaciones de Owner, scopes, clasificaciones, certificaciones, comentarios y tareas. | Se resuelve desde el objeto objetivo y su contexto taxonómico. | Añade responsabilidad y estado sin reemplazar la relación taxonómica del objeto. |
Riesgos y controles: precisión del modelo actual
En la implementación actual no existe un módulo de catálogo independiente llamado Riesgos o Controles con tablas propias equivalentes a Términos o Reglas. El control se representa mediante combinaciones de objetos existentes, por ejemplo:
- una Regla de calidad como control técnico;
- una Política/Procedimiento como control normativo;
- un Workflow, tarea o aprobación como control operativo;
- una Regla incluida en un Contrato como compromiso verificable;
- una clasificación, certificación o tarea de stewardship como seguimiento.
La interfaz puede mostrar riesgos, alertas o cobertura derivados del dashboard y de tareas, pero esta documentación no los presenta como un inventario independiente hasta que exista ese módulo y su contrato de datos.
4. Cómo se forma el ecosistema
El recorrido funcional típico es:
Taxonomía
↓
Responsables y alcance
↓
Términos de negocio ───────────────┐
↓ │
Entidades y Atributos │
↓ │
Diccionario técnico ← Repositorio ← Conector / fuente
↓
Reglas de calidad ────────────────┐ │
↓ │ │
Producto de datos ← Activos ←────┘ │
↓ │
Contrato de datos ← Términos, Atributos, Reglas, Campos, Sistemas
↓
Workflows, solicitudes, tareas, aprobaciones y auditoría
Los KPI y Objetivos cruzan el ecosistema: toman un nivel taxonómico primario y pueden documentar su fórmula, fuente de medición, control, evidencia, producto o contrato mediante enlaces tipados.
5. Cómo leer una relación en la interfaz
- Empieza por el Dominio o Subdominio para entender el contexto y el alcance.
- Baja a Entidad y Atributo para encontrar el significado preciso.
- Desde un Atributo, revisa Reglas de calidad y campos del Diccionario técnico.
- Desde el campo, identifica Repositorio, esquema, tabla, columna y Sistema cuando estén registrados.
- Recorre Productos y Contratos para entender qué se entrega, a quién y con qué compromisos.
- Usa Workflows, tareas y solicitudes para seguir decisiones pendientes, cambios y accesos.
El Explorador de relaciones tiene tres perspectivas: Panorama para descubrir, Impacto para analizar dependencias y Detalle técnico para seguir el vínculo entre taxonomía y fuentes físicas. La guía de uso está en Cómo leer el mapa de relaciones.
6. Límites importantes
- Todas las relaciones están aisladas por empresa y deben respetar el alcance del usuario.
- Los códigos técnicos identifican registros, pero las guías funcionales deben mostrar nombres legibles.
- Una asociación de alto nivel no implica que todos los campos de una fuente estén asociados a todos los atributos.
- Una Regla de calidad solo genera SQL cuando tiene asociaciones válidas a campos físicos.
- Desactivar un módulo oculta y bloquea su operación para el tenant, pero no elimina automáticamente sus datos.