La estructura organizativa ideal para DataOps

Las comunicaciones externas de una organización tienden a reflejar las internas. Eso es lo que nos enseñó Melvin Conway y se aplica a la ingeniería de datos. Si no tiene un equipo de operaciones de datos o "DataOps" claramente definido, las salidas de datos de su empresa serán tan desordenadas como sus entradas.

Las operaciones de datos son el proceso de ensamblar la infraestructura para generar y procesar datos, así como para mantenerlos. También es el nombre del equipo que hace (o debería hacer) este trabajo: operaciones de datos o DataOps. ¿Qué hace DataOps? Bueno, si su empresa mantiene pipelines de datos, crear un equipo con este nombre para gestionar dichos pipelines puede aportar un elemento de organización y control que, de otro modo, no existiría.

DataOps no es solo para empresas que venden sus datos. La historia reciente ha demostrado que se necesita un equipo de operaciones de datos sin importar la procedencia o el uso de esos datos. Cliente interno o externo, da lo mismo. Necesita un equipo para construir (o seamos sinceros, heredar y luego reconstruir) los pipelines. Deberían ser las mismas personas (o, en el caso de muchas organizaciones, persona) que implementan herramientas de observabilidad y seguimiento y monitorizan la calidad de los datos entre sus cuatro atributos.

Y, por supuesto, las personas que crearon el pipeline deberían ser las mismas personas que reciben la temida alerta de PagerDuty cuando un panel de control está abajo, no porque sea punitivo, sino porque es educativo. Cuando tienen la piel en el juego, las personas construyen de manera diferente. Es un buen incentivo y permite una mejor resolución de problemas y una resolución más rápida.

Por último, pero no menos importante, ese equipo de operaciones de datos necesita una misión, una que trascienda simplemente "mover los datos" del punto A al punto B. Y es por eso que la parte "operaciones" de su título es tan importante.

Las operaciones de datos están creando procesos resilientes para mover los datos para su propósito previsto. Todos los datos deben moverse por una razón. A menudo, esa razón son los ingresos. Si su equipo de operaciones de datos no puede trazar una línea clara desde ese objetivo final, como que los equipos de ventas tengan mejores previsiones y ganen más dinero, hasta sus actividades de gestión de pipeline, tiene un problema.

Sin operaciones, surgirán problemas a medida que escale:

• Duplicación de datos
• Colaboración problemática
• Espera por datos
• Tiritas que dejarán cicatrices
• Problemas de descubrimiento
• Herramientas desconectadas
• Inconsistencias en la información de registro
• Falta de proceso
• Falta de propiedad y SLA

Si hay una desconexión, simplemente está practicando la gestión de datos a la antigua usanza. La gestión de datos es el aspecto de mantenimiento rutinario de las operaciones de datos. Lo cual, aunque crucial, no es estratégico. Cuando está en modo mantenimiento, busque la causa de una columna faltante o de un fallo en el pipeline y lo arregla, pero no tiene tiempo para planificar y mejorar.

Su trabajo se convierte en verdaderas “operaciones” cuando transforma los tickets de problemas en correcciones repetibles. Por ejemplo, si encuentra un error de transformación procedente de un socio y le envía un correo electrónico para que lo solucione antes de que llegue a su pipeline. O bien, puede implementar un banner de “alertas” en el panel de control de sus ejecutivos que les indique cuando algo anda mal para que sepan que deben esperar la actualización. Las operaciones de datos, al igual que las operaciones de los desarrolladores, tienen como objetivo poner en marcha sistemas repetibles, comprobables, explicables e intuitivos que, en última instancia, reduzcan el esfuerzo para todos.

Eso es lo que diferencia las operaciones de datos de la gestión de datos. Y entonces la pregunta es: ¿cómo debe estructurarse ese equipo de operaciones de datos?

Así que volvamos a donde empezamos, hablando de cómo los resultados de su sistema reflejan su estructura organizativa. Si su equipo de operaciones de datos es un equipo de "operaciones" solo de nombre y se dedica principalmente al mantenimiento, probablemente recibirá una acumulación interminable de solicitudes pendientes. Rara vez tendrá tiempo de salir a tomar aire para realizar cambios de mantenimiento a largo plazo, como apagar un sistema o ajustar un proceso. Está atrapado en el infierno de respuestas de Jira o ServiceNow.

Si, por otro lado, ha fundado (o relanzado) su equipo de operaciones de datos con principios y estructura sólidas, produces datos que reflejan su estructura interna de alta calidad. Las buenas estructuras del equipo de operaciones de datos producen buenos datos.

Reúna a un ingeniero de datos, un científico de datos y un analista en un grupo o "pod" y pídales que aborden juntos cosas que podrían haber abordado por separado. Invariablemente, estas tres perspectivas conducen a mejores decisiones, menos rodeos y más previsión. Por ejemplo, en lugar de que el científico de datos escriba un notebook que no tiene sentido y se lo pase al ingeniero solo para crear un bucle de ida y vuelta, ellos y el analista pueden hablar sobre lo que necesitan y el ingeniero puede explicar cómo debe hacerse.
Muchos equipos de operaciones de datos ya trabajan de esta manera. "Los equipos deben aspirar a ser 'full-stack', de modo que el talento necesario en ingeniería de datos esté disponible para tener una visión a largo plazo de todo el ciclo de vida de los datos", dicen Krishna Puttaswamy y Suresh Srinivas de Uber. Y en el sitio web de viajes Agoda, el equipo de ingeniería utiliza pods por la misma razón.

Hágalo aunque sea solo una persona. Cada rol es un “sombrero” que alguien debe usar. Para tener un equipo de operaciones de datos que funcione bien, ayuda saber qué sombrero está dónde, y quién es el propietario de los datos para qué. También es necesario reducir el alcance de control de cada individuo a un nivel manejable. Tal vez dibujarlo así le ayude a justificar la contratación.

¿Qué es la gestión del equipo de operaciones de datos? Una capa de coordinación sobre las estructuras de su pod que desempeña el papel de líder de servicio. Gestionan proyectos, entrenan y desbloquean. Idealmente, son las personas más informadas del equipo.

Hemos ideado nuestra propia estructura ideal, en la foto, aunque es un trabajo en progreso. Lo que es importante destacar es que hay una sola persona al frente con una visión de los datos (el vicepresidente). Por debajo de ellos hay varios líderes que guían varias disciplinas de datos hacia esa visión (los directores), y debajo de ellos, equipos interdisciplinarios que garantizan que la organización de datos y las características de datos funcionen juntas. (Gracias a nuestro arquitecto de soluciones de datos, Michael Harper, por estas ideas).

Elegir una métrica North Star ayuda a todos los involucrados a comprender para qué se supone que deben optimizar. Sin un acuerdo así, se generan disputas. Tal vez sus “clientes” de datos internos se quejen de que los datos son lentos. Pero la razón por la que es lento es porque sabe que su deseo tácito es optimizar primero la calidad.

North Starts de DataOps: calidad de los datos, automatización (procesos repetibles) y descentralización de los procesos (también conocida como autosuficiencia del usuario final).

Una vez que tiene una North Star, también puede decidir sobre submétricas o subprincipios que apuntan a esa North Star, que casi siempre es un indicador rezagado.

Organice el equipo para que los diferentes grupos dentro de él interactúen con frecuencia y pidan cosas a otros grupos. Estas interacciones pueden resultar invaluables. "Cuando los científicos e ingenieros de datos aprenden cómo trabajan los demás, estos equipos avanzan más rápido y producen más", afirma Amir Arad, director sénior de ingeniería de Agoda.

Amir dice que uno de los valores ocultos de una pequeña redundancia interfuncional es que la gente hace preguntas que nadie en ese equipo había pensado en hacer.

"La brecha en los conocimientos de ingeniería es realmente interesante. Puede llevarnos a pedirnos que simplifiquemos", dice Amir. "Pueden decir: '¿Pero por qué no podemos hacer eso?' Y a veces, volvemos atrás y nos damos cuenta de que no necesitamos ese código o no necesitamos ese servidor. A veces, los no expertos aportan cosas nuevas a la mesa".

Al igual que en DevOps, los mejores equipos de operaciones de datos son invisibles y trabajan constantemente para volverse redundantes. En lugar de ser el héroe que gusta de acudir al rescate para salvar a todo el mundo, pero que al final hace que el sistema sea frágil, sea el líder servidor. El objetivo es, como lo expresó Lao Tzu, guiar a las personas hacia la solución de un modo que les haga pensar: “Lo hicimos nosotros mismos”.

Trate a su equipo de operaciones de datos como un equipo de producto. Estudie a su cliente. Mantenga un backlog de correcciones. Su objetivo es que la herramienta sea lo suficientemente útil como para utilizar realmente los datos.

No existe "demasiado pronto" para la monitorización y la observabilidad de los datos. La analogía que se utiliza a menudo para justificar el aplazamiento del seguimiento es: “Estamos construyendo el avión mientras está volando”. Piense en esa imagen. ¿No le dice eso todo lo que necesita saber sobre su supervivencia a largo plazo? Una analogía mucho mejor es la simple arquitectura antigua. Cuanto más espere para montar una base, más costosa será su colocación y más problemas creará la falta de una.

Leer: ¿Qué es la observabilidad de los datos?

Las decisiones que tome ahora con su infraestructura de datos tendrán, como dijo el general Maximus, "eco en la eternidad". El truco de crecimiento de hoy es la pesadilla gigantesca de mañana, un caos interno en el sistema que transforma los datos. Necesita obtener el apoyo ejecutivo para tomar decisiones inconvenientes pero correctas, como decirles a todos que deben pausar las solicitudes porque necesita un trimestre para hacer las correcciones.

CASE significa "copiar y robar todo", una forma irónica de decir, no construya todo desde cero. Hoy en día hay muchos microservicios útiles y ofertas de código abierto. Apóyese en los hombros de gigantes y céntrese en crear el 40 % de su pipeline que realmente necesita ser personalizado, y hacerlo bien.

Eche un vistazo a los tickets que tiene en su lista de pendientes. ¿Con qué frecuencia reacciona a los problemas en lugar de anticiparse? ¿Cuántos de los problemas que ha abordado tenían una causa raíz claramente identificable? ¿Cuántos pudo arreglar de forma permanente? Cuanto más se adelanta, más se parece a un verdadero equipo de operaciones de datos. Y, más útil le resultará una herramienta de observabilidad de los datos. La visibilidad total puede ayudarle a pasar del simple mantenimiento a la mejora activa.

Los equipos que mejoran activamente su estructura mejoran activamente sus datos. La armonía interna conduce a la armonía externa, en una conexión que enorgullecería a Melvin Conway.

Más información sobre la plataforma de observabilidad de los datos de IBM Databand y cómo ayuda a detectar antes los incidentes de datos, resolverlos más rápido y ofrecer datos más fiables a la empresa. Si está listo para profundizar, solicite una demostración hoy mismo.