Cómo evaluar una herramienta de #DataGovernance con 20 indicadores

Seguimos con los artículos sobre Data Governance, hoy nos ocupamos de cómo analizar las diferentes herramientas presentes en el mercado y elegir la más adecuada a nuestro entorno.

Muchas veces las grandes empresas para “no arriesgarse” eligen herramientas y tecnologías guiándose por el Magic Quadrant de Gartner, sin saber que esto no es sinonimo de garantía de buen funcionamiento y fácil implementación.

En el panorama del Data Governance existen: grandes vendors que incorporan una herramienta de gobierno dentro en su ecosistema, empresas que siguen levantando ronda de capitales sin tener realmente clientes, y otras realidades quizá más específicas, poco conocidas y a veces muy eficaces. Estár en Gartner es algo parecido a las estrellas Michelin de los restaurantes, ganarla supone estar debajo de una lupa y actuar para mantenerse en el puesto olvidando la satisfacción de los comensales.

El dato es el mayor activo de nuestras empresas, hay que gestionarlo o como me gusta decir “meta gestionarlo” por ello si aun no habeis pensado en una herramienta de DG es el momento de mirar alrededor pero sin guiarse exclusivamente con Gartner, Barc etc..

Como experto, recomiendo mirar un poco más allá y os propongo una serie de indicadores para poder evaluar la mejor herramienta de Data Governance, por vosotros mismos.

Al finalizar el articulo os dejo con una sencilla hoja excel para poder hacer la evaluación.

Aquí os relato cuales son los indicadores que deberían guiarnos en la elección de la herramienta perfecta.

1. Multitenencia. El término «multi arrendamiento de software» se refiere a una arquitectura de software en la que una única instancia de software se ejecuta en un servidor y sirve a varios arrendatarios. Un límite muy importante en una herramienta de Gobernanza de Datos es no poder gestionar más de una instancia y la multiplicidad de roles y de proyectos. En tema de Roles a veces el Data Owner de un determinado proyecto tiene el rol de Data Steward en otro o en otro dominio. Una herramienta de DG debe tener un enfoque Multi Tenencia si o si.

2. Despliegue en Cloud. ¿La herramienta permite un despliegue en Cloud? Aunque su sistema no necesite este despliegue hay que pensar a futuro. ¿Es compatible con AWS, Azure, Google Cloud? ¿Es compatible con sus sistemas de almacenamiento?

3. ¿Con Licencia o Open Source?. Hasta hace unos años,el hecho de tener que pagar una licencia y su mantenimiento eran sinónimo de solvencia. Hoy en día muchas empresa prefieren apostar por herramientas open source junto con unos servicios profesionales especializados, ya que muchas veces estas herramientas son igual de solventes y no tan cerradas como las herramientas comerciales.

4. ¿Sistema abierto o ecosistema cerrado? Muchas veces la tecnología nos marca nuestras elecciones en término de software, generando el problema del Ghost TI. Aunque sea natural intentar mantener un marco global tecnológico esto es imposible de asumir en grandes corporaciones. Cuanto más intenten presionar el sistema cuanto más el fenómeno del ghost IT se presenta con todos los problemas de seguridad que ello conlleva. Realmente no sabemos si el ecosistema tecnológico actual va ser el mismo dentro de 5 años. Los expertos recomiendan que una herramienta de Governance sea completamente independiente del resto de tecnología, tampoco necesita grandes recursos ya que trabaja con metadatos y no con todos los datos. Es perfectamente factible por ejemplo que su eco sistema SAP tenga una herramienta diferente.

5. Usabilidad del Business Glossary. Es necesario evaluar si el software de gobierno de datos le permite crear taxonomías, gestionar términos de negocio, importar términos de negocio en masa. La mayoría de las empresas tienen trabajo desarrollado en Excel u otra herramienta como Confluence razón para averiguar que todo el trabajo previo se pueda recuperar. Si este trabajo aún no se ha desarrollado es mejor optar por una herramienta fácil e inmediata que no necesite por ejemplo, formación o certificaciones para poder usarse.

6. Atributos personalizados. ¿Cómo nombra y describe el software los atributos personalizados? Más allá de nombrar el atributo, es importante proporcionar una definición, una descripción corta (con un poco de fondo), una descripción larga (unos pocos párrafos de mayor profundidad), un ejemplo y una clasificación de seguridad (indicando el nivel de seguridad, por ejemplo, pública, interna o confidencial). Algunos software permiten trabajar templates de forma abierta y esta es una gran ventaja. Controle que su suite pueda trabajar con plantillas, esto agiliza mucho el trabajo.

7. Relaciones personalizadas. Al evaluar las relaciones personalizables, tenga en cuenta los acrónimos, las abreviaturas, los sinónimos, los reemplazos/sustituciones (que indican términos obsoletos), los activos asignados, los valores permitidos (vinculando el término comercial a los datos de referencia asociados) y las políticas y reglas de datos. Sobre todo compruebe que la herramienta tiene una gestión de versionado, es importante poder regresar o evaluar un término o una relación. Tiene que haber una trazabilidad total sobre los términos para saber “quién” ha cambiado el “qué” y “cuándo”.

8. Administración de datos. Los administradores de datos deben ser capaces de gestionar artefactos tales como términos de negocio, políticas de datos, estándares de datos, reglas de calidad de datos, métricas de calidad de datos, reglas de datos maestros, tareas de datos maestros (p. ej., duplicados) y cualquier otro artefacto que sea totalmente configurable (p. ej., regulación).

9. Roles personalizados. Las funciones personalizadas pueden incluir el propietario de los datos, el DGO, el Data Steward, las partes interesadas, los expertos en la materia y los responsables, los auditores externo etc. Elija una herramienta que no tenga roles cerrados y mejor aun que tenga plantillas de roles para poder crear nuevos criterios y reglas en cualquier momento.

10. Workflows de autorización. Es importante definir los workflows de autorización. Por ejemplo, puede incluir a los administradores regionales, los administradores mundiales y la tecnología de la información en el caso de un cambio de código de entrada multinacional. A veces alguna herramienta de DG presentan un verdadero BPMS para la definición de Workflows. ¿Este término del Glosario es el último? ¿Quién lo modificó? ¿Que se modificó? ¿Es una versión aprobada por el DGO? etc.

11. Reglas de datos maestros. Evalúe si la herramienta le permitirá crear reglas de enriquecimiento de datos, crear reglas de validación de datos, crear relaciones entre entidades, crear reglas de correspondencia de registros, establecer umbrales de confianza y crear reglas de consolidación de registros.

12. Linaje de datos. ¿La herramienta le permite documentar el linaje de datos, incluyendo los trabajos que se ejecutan en paralelo? ¿Permite una visualización gráfica del flujo de datos? ¿Tiene compliance RDA y GDPR?

13. Análisis de Impacto. ¿La herramienta creará un análisis de impacto, específicamente para los activos identificados en el linaje de datos? ¿Es posible visualizar gráficamente (con una base de datos de grafo) el impacto?

14. Jerarquía de los artefactos de datos. La herramienta debería permitirle vincular políticas, reglas, términos y datos de referencia, incluso debería generar de forma automática los informes a partir de los metadatos y de su manejo.

15. Elaboración de perfiles de diversas fuentes de datos. Esto incluye manuales (scripts SQL), automatizados (herramientas para proveedores) y diversas fuentes de datos. No solo datos estructurados sino también no-estructurados y sobre todo informes y reporting (SASMicrostrategy, etc). No podemos saber cómo será nuestro ecosistema tecnológico dentro de 5 años así que no podemos saber cuáles fuentes de datos vamos a utilizar. La solución más coherente sería tenerlo todo virtualizado con herramientas como C3Querona o Denodo

16. Cuadro de mando de la calidad de los datos. No subestime el valor de un cuadro de mando, que enumera las métricas de gobierno de la información, los objetivos, las actualizaciones periódicas de estado y la línea de base. Su herramienta tiene que tener la capacidad de utilizar reglas de calidad básica a nivel interno y poder conectarse con motores de calidad de datos externos. Si la herramienta no tiene un buen sistema de visualización de datos que por lo menos pueda utilizar frontends externos (como Power BI, Tableau) para ello.

17. Registro de los problemas y las alertas sobre datos. El registro de problemas de datos debe rastrear los problemas, el administrador asignado, los datos asignados, la fecha resuelta y el estado actual (por ejemplo, cerrado, el administrador hablando con el departamento de políticas, etc.). No se trata solo de generar un log sino un proceso de control de resolución de problema (con un sistema de ticketing o pudiendo relacionarse con herramientas externa como JiraConfluence o Slack.

18. Proceso de resolución de problemas de datos. Asegurar que el proceso de gestión y resolución de problemas esté completamente documentado. (además nos lo exige la regulación en muchos casos)

19. Apoyo a la auditoría interna/externa. Cada repositorio debe tener un propietario de datos y será auditado para verificar el cumplimiento de políticas específicas de gobierno de datos, tales como 1) la presencia de un diccionario de datos, 2) si las reglas han sido documentadas y 3) quién determina los controles de acceso. El software tiene que poder generar roles para auditores externos.

20. KPI de gobierno de datos

Hay muchos KPI posible en DG aquí algunas ideas: Glosario de negocios Número de términos del candidato, número de términos pendientes de aprobación, número de datos de referencia aprobados – Número de valores de código del candidato, número pendiente de aprobación, número de asuntos de datos aprobados Número de asuntos de datos pendientes, número de asuntos de datos resueltos en el último período de calidad de datos Índice de calidad de datos por aplicación, por elemento de datos críticos Vectores de información Por administrador de datos, propietario de datos, repositorio de datos, aplicación, dominio de datos.

Conclusiones

El dato es el mayor activo de nuestras empresas, hay que gestionarlo o como me gusta decir “meta gestionarlo” por ello si aun no habeis pensado en una herramienta de DG es el momento de mirar alrededor pero sin guiarse exclusivamente con Gartner, Barc etc..

Para facilitaros la labor hemos realizado un fichero excel con todo los indicadores, usted va a poder modificar los criterios y dar más o menos peso a las características que sean oportunas para su proyecto de Data Governance. Para descargar el fichero el el link es el siguiente. LINK.

Addendum

En estos días me he topado con lo que declara DAMA en su DMBook2 sobre la gestión de los meta-datos. Cito textualmente (la traducción es mia del original ingles):

«Un sistema de Gestión de Metadatos debe ser capaz de extraer Metadatos de muchas fuentes. Diseñar la arquitectura para que sea capaz de escanear las diversas fuentes de metadatos y actualizar periódicamente el repositorio. El sistema debe soportar las actualizaciones manuales de metadatos, solicitudes, búsquedas y búsquedas de metadatos por parte de varios grupos de usuarios.

Un entorno de metadatos gestionado debería aislar al usuario final de las diversas y dispares fuentes de metadatos. La arquitectura debe proporcionar un único punto de acceso para el repositorio de metadatos. El punto de acceso debe suministrar todos los recursos de metadatos relacionados de forma transparente al usuario. Los usuarios deben poder acceder a los metadatos sin ser conscientes de los diferentes entornos de las fuentes de datos. En las soluciones analíticas y de datos grandes, la interfaz puede tener funciones definidas por el usuario (UDF) para dibujar en varios conjuntos de datos, y la exposición de los metadatos al usuario final es inherente a esas personalizaciones. Con menos dependencia de UDF en las soluciones, los usuarios finales recopilarán, inspeccionarán y utilizarán los conjuntos de datos de forma más directa y, por lo general, los metadatos de soporte estarán más expuestos