Gobierno de Datos… cuando no hay Gobierno ni Datos

En el año 2006 durante la Conferencia de la Asociación Nacional de Anunciantes se utilizó por primera vez la frase: "Los Datos son el nuevo Petróleo (Clive Humby)"

Los Datos son el nuevo Petróleo (Clive Humby)

Fue el Matemático y Científico de Datos Clive Humby quien ‘acuñó’ esta frase para expresar que tanto los datos como el petróleo comparten puntos clave (Data as The New Oil Is Not Enough: Four Principles For Avoiding Data Fires) entre ellos un alto valor (que le otorga a las empresas ventajas competitivas significativas), sirven de materia prima (la cual debe ser procesada y analizada), impulsa el crecimiento (ayuda a la revolución digital), tiene el don de la ubicuidad (al ser crucial en varias industrias) y, finalmente pero no menos importante, representa riesgos y consideraciones (privacidad, seguridad, monopolización, entre otros).

En un escenario ideal podríamos suponer que las empresas están comenzando sus proyectos de datos y se puede proponer todo desde cero, siguiendo las mejores prácticas disponibles. Pero, ¿qué hacer cuando ya tienen datos y ya existen proyectos en curso? Incluso podría suceder que no tengan visibilidad sobre todos los datos e información que estén generando, y por ende, tampoco tengan una administración adecuada para acceder a estos datos.

Probablemente requieran de nuestro apoyo para poder obtener el mayor provecho de ellos, de la manera más eficiente posible en costos, y con una optimización constante. Con este objetivo en mente, un primer paso sería identificar a qué tipo de industria o vertical pertenece. Para hacer esta clasificación podríamos recordar que cada empresa comienza con uno o varios insumos, los cuales pueden o no someterse a procesos para generar productos que finalmente serán adquiridos por los clientes o usuarios finales. Con estos elementos en común, podríamos clasificar las empresas en las siguientes categorías (Manufacturing Supply Chains Explained | NetSuite): Productos/servicios, Proveedores y vendedores, Materias primas, Producción, Almacenamiento y depósito, Distribución / Transporte, Minoristas, Mantenimiento y reparación, o Reciclaje.

En este punto deberíamos poder identificar con claridad a qué industria o vertical pertenece la empresa que deseamos apoyar. El siguiente paso es confirmar si dicha empresa tiene visibilidad completa de sus datos. En otras palabras, ¿la empresa sabe qué datos tiene, cuáles le falta supervisar, y cuáles debería estar aprovechando? Para resolver estas inquietudes podríamos buscar datos en informes, dashboards, métricas, Indicadores Clave de Rendimiento (KPI), notificaciones/alertas, y objetivos corporativos.

Nuestro primer punto de contacto podrían ser los stakeholders o analistas BI dentro de la empresa. ¿Por qué ellos? Porque por lo general son ellos quienes tienen acceso a los datos ya procesados, son los que toman las decisiones o apoyan a quienes las toman, para que todo sea de la manera más informada posible.

En algunos casos este acceso a los datos se realiza a través de herramientas BI (como por ejemplo, Amazon QuickSight) o por consultas SQL (utilizando servicios como Amazon Athena).

Arquitectura Referencial de Consumo de Datos

Pero no podemos llegar simplemente a preguntarles, ya que dicha conversación no sería la más ‘amigable’ en un momento. Como consultores deberíamos evitar conversaciones como esta:

Consultor: ¿Qué dashboards tenemos?
Analista BI/Stakeholder: ¿Por qué? ¿Qué necesita?

Recordemos que no podemos encontrar las respuestas correctas si hacemos las preguntas equivocadas. En vez de tener la anterior conversación, podríamos seguir esta charla:

Consultor: Me gustaría ayudar a mejorar/optimizar nuestros procesos. ¿Dónde puedo encontrar información para comenzar? Especialmente la relacionada con los datos que recopilamos/procesamos. ¿Dónde debería revisar primero?
Analista BI/Stakeholder:
a) Usted debería preguntarle a …..
b) No puede, porque para eso usted debería pertenecer al equipo/área de…
c) Necesita autorización de…
d) Puede revisar en nuestra Intranet, revise en esta página….
Consultor: Listo, muchas gracias.

Comenzamos con un enfoque amigable, ‘nos ponemos en los zapatos’ de la persona, sabemos que estamos haciendo algo en bien de la empresa, pero no queremos que nos vean como un riesgo o peligro para nadie. En algunas circunstancias o empresas, cuando alguien hace este tipo de preguntas podría generar desconfianza y precisamente necesitamos ganarnos sinceramente la confiabilidad del equipo de trabajo. Además, siguiendo el último ejemplo el analista BI o stakeholder nos podría estar guiando (de manera natural y fluida) a uno o varios sponsors que requerimos para nuestras labores.

En otros casos, las respuestas a esta primera conversación podrían llevarnos directamente a los Propietario(s) Potencial(es) de los Datos ya Existentes, pudiendo ser el Personal de TI, Soporte o Mantenimiento. A ellos podríamos preguntarles cuáles Protocolos o Compliance ya se tienen implementados en la empresa, si existe un Perfilamiento de Usuarios, o incluso si tienen un Centro de Excelencia en la Nube (AWS Cloud Center of Excellence, Los principios del CoE - AWS Guía prescriptiva).

En este momento sería importante hacer una pausa. ¿Qué pasaría si alguien les pide que NO piensen en un cuadro rojo?

MUY probablemente lo primero que llegará a la mente es, precisamente, el cuadro rojo. Esto debido a que nuestro cerebro ante una negativa reacciona de manera diferente a lo que se pensaría (How Does “Not” Affect What We Understand? Scientists Find Negation Mitigates Our Interpretation of Phrases). Al decirle a alguien “que NO piense en un cuadro rojo”, el cerebro lo que hace es mitigar ese pensamiento, más que invertirlo. Dicho de otra forma, nuestro cerebro pensaría en un cuadro rojo, solo que más pequeño. Por esta razón es importante cuidar nuestra comunicación con otras personas (“No piense en los costos…” vs “Piense en las ventajas…”) e incluso con nosotros mismos (“Voy a aprender / comenzar / hacer…” vs “Estoy aprendiendo / comenzando / haciendo…”).

Podríamos comenzar a deducir que vamos a tener bastantes interacciones con el equipo de trabajo del cliente. Es decir, ¡preparémonos para reuniones!

Algunos puntos a considerar al momento de tener reuniones:

• Escuchar para entender, no para contestar. Además de ‘escuchar con los ojos’ (establecer y mantener un respetuoso contacto visual).
• Tomar notas (puede ser en hojas de papel), pero no tomar ‘dictados’, es decir, no escribir en teclado ya que esto en algunos momentos puede generar distracciones y dar la sensación al cliente de que no se le está escuchando apropiadamente. En este sentido es mejor pedir autorización para grabar la reunión.
• Obtener tanto contexto como sea posible antes de comenzar la reunión (quién es el cliente, de qué trata, cuáles son sus productos o servicios, sus posibles competidores…)
• En el transcurso de la reunión identificar si los asistentes de la reunión son de perfil administrativo, comercial/ventas, o técnico/desarrollo (o incluso, una combinación entre ellos).
• Para cada uno de los asistentes identificar también conocimiento del proyecto, negocio, necesidades o requerimientos; claridad en objetivos; nivel técnico
• BANT (Budget, Authority, Needs, Timing)

en donde podemos tener:

• Quién = Ejecutivos C-Level; Product Owners; Project Managers; Business Analysts; Dependencias Externas; Representantes de Ventas; Desarrolladores; Diseñadores; Arquitectos
• Por qué = Metas a nivel de compañía (H1, H2, Q1…); Optimización, Automatización, o Mejoras; Criterios de Éxito; Métricas o KPIs; SLAs

Si tenemos el “Quién” y el “Por qué”, de forma orgánica obtendremos el “Qué” para cada uno de los participantes. El “Cómo” vendrá más adelante.

Un error que se debe evitar al intentar identificar los datos (y su correspondiente gobierno) es postergar el contacto con el equipo netamente técnico. Esto podría crear una ‘resistencia o rechazo’ a colaborar en nuestro propósito de analizar los datos que pueden requerir un control más detallado. Por esto es importante involucrar al equipo de TI encargado de la observabilidad, mantenimiento, acceso y seguridad de la plataforma que estamos analizando. Algunos de los servicios que el equipo TI puede estar usando en sus tareas en AWS pueden ser IAM, CloudWatch, EventBridge y SNS.

Arquitectura Referencial Equipo TI

Si queremos descubrir qué datos pueden estar pasándose por alto, deberíamos dar respuesta a estas preguntas: ¿Existen métricas estándares en esa industria? ¿KPIs? Y para este punto podemos apoyarnos en instituciones, organizaciones, mejores prácticas de cada industria, entre otros. Algunos ejemplos pueden ser, según la industria:

• Financiera (15 Essential Financial Metrics for Advisors, Consultants, and Investors)
• Ciencias de la Salud (30 Healthcare KPIs & Metrics To Start Tracking Today)
• Software (7 SaaS Metrics Every SaaS Company Should Care About)
• Seguridad (18 Data Security Metrics & KPIs You Need To Track)

La meta es encontrar cuáles métricas no están siendo consideradas por el cliente.

Antes de comenzar a ‘tocar los datos’, vale la pena plantearse las siguientes preguntas relacionadas con la Seguridad (un tema que debería incluirse desde el ‘momento inicial’). Investigar si existen protocolos de seguridad y, en caso de que no existan, proponer uno en función de:

• ¿Qué datos se manipulan en la organización?
• ¿Por qué existen estos datos?
• ¿Quién es el propietario de los datos? ¿Quién debería ser su propietario?
• ¿Quién necesita acceder a qué datos?
• ¿Quién debería autorizar ese acceso?
• ¿Por cuánto tiempo se debe conceder este acceso?
• ¿Cómo se debe autorizar este acceso (correo electrónico, ticket...)?
• ¿Dónde se deben almacenar los datos?
• ¿Existen leyes de cumplimiento o regulaciones aplicadas a esos datos (locales, nacionales o mundiales)?
• ¿Cuáles son las acciones a tomar en caso de fuga o violación de datos?
• ¿Existen políticas de copia de seguridad o retención de datos?

Este es un excelente momento para crear un diagrama de flujo del ciclo de vida de esos datos explicando el protocolo creado, y organizar reuniones para informar a las personas adecuadas. De nuevo, el involucrar a las personas en la gestión del gobierno de datos les da el tratamiento adecuado de respeto y consideración en las decisiones a tomar.

Una vez elaborado este ‘borrador de protocolo de seguridad en datos’, se puede continuar el análisis del flujo de los datos (de derecha a izquierda).

Arquitectura Referencial Seguridad

Siempre es bueno recordar que, como toda arquitectura a ser desplegada en AWS, debería ser guiada por los Conceptos Clave, Principios de Diseño y Mejores Prácticas de Arquitectura contenidos en el Marco de AWS Well-Architected, el cual incluye los siguientes pilares:

• Excelencia operativa
• Seguridad
• Fiabilidad
• Eficiencia del rendimiento
• Optimización de costos
• Sostenibilidad

En este punto podemos introducir el concepto de Gobernanza (Management and Governance on AWS) como “la capacidad de implementar políticas de la junta ejecutiva que su entorno de nube de AWS debe cumplir” (Guidance for Governance on AWS). El poder que tiene AWS es que este concepto no queda ‘sujeto’ o ‘restringido’ a un punto o área en particular, sino que se puede aplicar “en todo el ecosistema de AWS, incluyendo cuentas, infraestructura y entornos que se posean y operen en la nube de AWS” (Cloud Governance).

Arquitectura Referencial Gobernanza

¡Ahora es momento de darle la ‘bienvenida oficial’ al Área Técnica y Desarrollo!

Recordemos que debemos conservar la esencia del trabajo en equipo:

• stakeholders,
• equipo TI,
• seguridad,
• gobierno
• y ahora, desarrollo

Si entendemos quién es cada una de estas áreas, y por qué debería involucrarse en el gobierno de datos, podremos entender qué realmente le compete a cada área y, posteriormente, analizar la mejor forma de involucrarlos activamente en la generación del Gobierno de Datos.

Preguntar en cada área cómo se encuentran ahora (“As Is”), si existen diferencias con respecto a las metas que deberían tener ya cumplidas en ese instante (“To Be”), y cómo consideran que deberían estar (“Should Be”).

Probablemente en este análisis surjan las definiciones de stacks de tecnología, dependencias (tanto internas como externas), posibles automatizaciones, protocolos de documentación y pruebas. Recordar que “la Documentación es una carta de amor que ustedes escriben a sus futuros ustedes”.

Además tener presente esta sencilla ‘fórmula’:

Monitoreo + Alertas + Respuestas = Dormir bien

Esto va de la mano de confirmar si existen planes de recuperación ante desastres.

También confirmar si existen estándares corporativos para codificación, Mejores Prácticas a seguir, patrones; si se realizan charlas internas para compartir conocimientos (chapters).

Si en algún punto nos encontramos con que falta algo por implementar o crear, en lo posible proponerlo. Para resumir en una frase:

¡Sean disimuladamente disruptivos!

Siguiendo con nuestro análisis ‘de derecha a izquierda’, ahora bien podríamos plantearnos esta pregunta: ¿de dónde vamos a obtener (o ya estamos obteniendo) nuestros datos?

Para esto existe un conjunto de servicios de AWS representativos para tomar datos desde diferentes orígenes, los cuales podrían ‘catalogarse’ en una capa de ingesta de datos.

Arquitectura Referencial - Ingesta de Datos

Busquemos cuáles de estos servicios (o similares) se encuentran actualmente en uso, cuáles son los orígenes de datos a los que están conectados, y cuáles datos NO se están llevando hasta el consumo de los stakeholders o el equipo TI. Quizás estemos presenciando datos útiles no utilizados.

Cuando encontremos estos datos ‘huérfanos’ (se están ingestando pero no tienen un ‘padre o madre’ en el área de consumo), nos podremos encontrar con la última capa que vamos a revisar: el área de procesamiento de datos.

Arquitectura Referencial - Procesamiento de Datos

Si quisiéramos resumir el proceso mental para generar un gobierno de datos en empresas donde no lo tengan actualmente, involucrando datos que quizás hayan pasado desapercibidos hasta el momento, podríamos decir que necesitamos identificar:

• datos
• stakeholders
• componentes BI 

ya existentes, para posteriormente proponer:

• componentes BI faltantes
• protocolos requeridos
• automatización / optimización

En el transcurso de este análisis lo más importante es recordar siempre que se está tratando con un factor humano, susceptible a errores, sentimientos, objetivos propios y grupales. Con la mejor intención y voluntad posibles, siempre tener una empatía por todas y cada una de las personas que nos proporcionen su tiempo, experiencia y consejos para lograr construir un Gobierno de Datos eficaz y útil para la empresa.