El stewardship reúne el trabajo continuo que mantiene comprensible y responsable el catálogo: asignaciones de Owner y Steward, tareas, comentarios, favoritos, clasificaciones y certificaciones. No crea una taxonomía paralela. Cada intervención se resuelve sobre un objeto y su contexto, de modo que Dominio, Subdominio, Entidad o Atributo continúan siendo la referencia para navegación, responsabilidad y autorización.
El panel de stewardship permite seguir trabajo y cobertura. El dashboard agrega indicadores e historial de empresa y aplica los filtros de alcance que correspondan. Riesgos y Controles no son catálogos independientes: se representan mediante objetos existentes y sus relaciones.
Antes de empezar
- Rol: el Data Steward mantiene definiciones, tareas, comentarios, clasificaciones y certificaciones dentro de sus Dominios o Subdominios. El Data Owner aprueba decisiones cuando se requiere. Un Usuario participa en tareas permitidas. El Administrador tiene alcance global en su empresa; el Ingeniero de datos opera Repositorios bajo scope técnico, no por un alcance taxonómico implícito.
- Módulo: verifica que estén habilitados los módulos que exponen el objeto sobre el que se va a trabajar. Un módulo desactivado se oculta y rechaza su operación, aunque sus datos se conserven. La operación de stewardship tampoco omite esta validación.
- Precondiciones: identifica el objeto objetivo, su empresa y su relación taxonómica. Confirma la asignación de Owner o Steward cuando sea relevante, la capacidad necesaria y el alcance vigente. Una persona puede consultar más de lo que puede modificar o aprobar.
Un rol de gobierno expresa responsabilidad sobre objetos; el perfil de sesión, junto con capacidad y scope, determina si una persona puede realizar la acción.
Recorrido recomendado
- Parte del objeto y su contexto. Ubica el Dominio o Subdominio y desciende hasta el objeto que necesita atención. Para un Atributo, revisa reglas de calidad y campos técnicos; para un Repositorio, no asumas que todos sus campos estén asociados.
- Confirma quién debe actuar. Contrasta la responsabilidad de negocio registrada con el rol de sesión y el alcance efectivo. Un Steward puede preparar y mantener información; un Owner decide cuando el proceso requiere aprobación. Las asignaciones no permiten actuar fuera del ámbito autorizado.
- Convierte el pendiente en trabajo trazable. Crea o atiende la tarea permitida, registra un comentario cuando aporte contexto y usa favoritos para priorizar objetos de seguimiento. Si el trabajo requiere una decisión formal, relaciónalo con el Workflow o caso correspondiente, en vez de representar la decisión solo en un comentario.
- Mantén las señales de gobierno. Aplica o revisa clasificaciones y certificaciones conforme a la autorización. Aportan seguimiento, pero no sustituyen la asociación taxonómica ni prueban una condición física de la fuente.
- Aprueba y revisa. Cuando la gestión lo exija, el Owner u otra persona con
stewardship.approvetoma la decisión dentro de su alcance. Revisa el resultado desde el panel y, para investigar dependencias, usa el mapa de relaciones: una línea representa un vínculo registrado y su ausencia no debe suplirse con una inferencia. - Relaciona cobertura y mejora. Usa tareas, certificaciones y clasificaciones para orientar la cobertura. El SQL requiere campo físico asociado y dialecto configurado; su ejecución no es parte del stewardship documentado.
Ejemplo sintético. Un Steward detecta que un atributo relevante no tiene descripción suficiente. Revisa el contexto de la Entidad, deja un comentario de trabajo y prepara una actualización dentro de su Dominio. Si la empresa requiere confirmación, el Owner correspondiente aprueba la decisión y se registra la certificación aplicable. El ejemplo no presupone valores, estados ni una cadencia de certificación.
Resultado esperado
El objeto conserva contexto de negocio y señales verificables: responsables, tarea o intervención, comentarios, clasificaciones, certificaciones y, cuando procede, una aprobación o un caso de Workflow. La empresa sigue pendientes y cobertura sin confundir definición de negocio, relación técnica y decisión operativa.
Las acciones quedan dentro de la empresa y del alcance de quien interviene; los indicadores no exponen objetos fuera de la política aplicable; el backend conserva la decisión final sobre permisos.
Límites del comportamiento actual
- Esta guía no enumera estados de tareas o certificaciones, fechas de renovación, formularios, reglas de escalado ni frecuencias de revisión porque no están documentados como contrato común.
- Clasificar o certificar no crea por sí mismo una Regla de calidad, una Política ni un Control técnico. Riesgos y Controles no son catálogos independientes en el modelo actual.
- La agenda de sincronización de metadata puede ser manual, diaria, semanal o mensual y conserva snapshots versionados, pero su programación y automatización efectiva dependen de la configuración; no se deben asumir jobs productivos habilitados.
- El alcance técnico de un Ingeniero de datos es independiente de los scopes de Dominio o Subdominio. El trabajo sobre conectores, repositorios y metadata requiere la autorización técnica correspondiente.