Crear una taxonomía de datos

La taxonomía es el eje del catálogo de GovFrame: proporciona el contexto para definir información, asignar responsabilidades, documentar controles y conectar el negocio con sus fuentes técnicas. Cada taxonomía pertenece a una empresa; sus nombres, descripciones y definiciones son contenido propio de esa empresa. La interfaz puede usar distintos idiomas, pero no traduce ni modifica automáticamente esos nombres de negocio.

GovFrame admite dos estructuras. La estándar sigue Dominio → Entidad → Atributo. La expandida incorpora un nivel opcional: Dominio → Subdominio → Entidad → Atributo. Un Dominio representa un ámbito de negocio y responsabilidad; una Entidad, un objeto o concepto de ese ámbito; y un Atributo, un elemento de información de la Entidad. El Subdominio solo se utiliza cuando está habilitado para la empresa y aporta una división útil del Dominio.

Antes de empezar

• Rol y alcance: un Administrador opera con alcance global en la empresa. Data Owners y Data Stewards necesitan la capacidad aplicable y el alcance de Dominio o Subdominio correspondiente. La consulta de un objeto no concede por sí misma permiso para modificarlo.
• Módulo y empresa: trabaje en una empresa activa y confirme que la operación de catálogo está disponible para ella. La configuración de módulos y las validaciones del backend limitan la operación, incluso si una persona conoce una ruta de la interfaz.
• Precondiciones: acuerde con el responsable del ámbito si se usará el modelo estándar o el expandido; defina nombres legibles, una descripción de negocio y quién responderá por cada Dominio. Decida qué información debe llegar al nivel de Atributo antes de crear reglas o asociaciones técnicas.

Ejemplo sintético: Atención a clientes → Solicitudes → Fecha de ingreso usa el modelo estándar. Si el negocio necesita separar canales, podría usar Atención a clientes → Canales digitales → Solicitudes → Fecha de ingreso en el modelo expandido.

Recorrido recomendado

1. Delimite el Dominio. Registre un ámbito que sea entendible por quienes gestionan el dato y que tenga una responsabilidad clara. Evite usar un Dominio como contenedor genérico de proyectos, aplicaciones o tablas técnicas.
2. Decida si el Subdominio aporta contexto. En el modelo expandido, úselo para una división de negocio estable. No duplique el Dominio en el nombre del Subdominio ni cree niveles alternativos fuera de la jerarquía disponible.
3. Modele Entidades y Atributos. Añada las Entidades que el ámbito necesita explicar y descienda a Atributos cuando deba documentarse significado, control de calidad, clasificación o correspondencia con un campo físico. Un Atributo conserva su contexto a través de la Entidad y, cuando existe, del Subdominio.
4. Asigne responsabilidad y alcance. Vincule Data Owners y Data Stewards a los nodos pertinentes y mantenga los scopes de las personas alineados con ese ámbito. Un rol de gobierno del catálogo no sustituye el perfil de sesión ni sus capacidades.
5. Revise relaciones antes de ampliar el catálogo. Compruebe que los Términos, campos del Diccionario técnico, Reglas, Productos y Contratos se conecten al nivel adecuado. El mapa de relaciones permite distinguir un vínculo registrado de una relación que solo parece probable por el nombre.
6. Mantenga el contexto al evolucionar. Las solicitudes de cambio de taxonomía forman parte de la operación de catálogo, pero esta guía no presupone etapas, aprobaciones ni estados para cada cambio. Documente la razón del ajuste de acuerdo con la práctica vigente de la empresa.

Resultado esperado

Al finalizar, la empresa dispone de una jerarquía de negocio coherente y aislada de las demás empresas: cada Atributo se puede recorrer hasta su Entidad y Dominio —y Subdominio, si aplica—; los responsables y scopes reflejan el ámbito real; y los objetos posteriores tienen un punto de asociación inequívoco.

La taxonomía no implica que todos los campos de una fuente técnica estén vinculados a todos sus Atributos. Tampoco convierte una asociación de alto nivel en una dependencia física. Estas distinciones son esenciales antes de interpretar cobertura, impacto o controles. Cuando un módulo relacionado esté desactivado, sus datos pueden conservarse, pero su operación no está disponible hasta que vuelva a habilitarse según la configuración de la empresa.

Para profundizar, consulte el modelo de objetos y relaciones, cómo leer el mapa de relaciones, roles, capacidades y alcance y módulos y dependencias.