La estructura organizativa ideal de DataOps

Las comunicaciones externas de una organización tienden a reflejar sus comunicaciones 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 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, lanzar un equipo bajo este nombre para gestionar esos pipelines puede aportar un elemento de organización y control que de otro modo faltaría.

DataOps tampoco es solo para empresas que venden sus datos. La historia reciente ha demostrado que necesita un equipo de operaciones de datos sin importar la procedencia o el uso de esos datos. Cliente interno o cliente externo, da lo mismo. Necesita un equipo para construir (o seamos realistas, heredar y luego reconstruir) los pipelines. Deberían ser las mismas personas (o, en el caso de muchas organizaciones, una 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 construyeron el pipeline deberían ser las mismas personas que reciben la temida alerta PagerDuty cuando un panel está inactivo, no porque sea punitivo, sino porque es educativo. Cuando se juegan el pellejo, 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 de "Operaciones" de su título es tan importante.

Las operaciones de datos están construyendo procesos resilientes  para mover 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 pronósticos y ganen más dinero, hasta sus actividades de gestión de pipelines, tiene un problema.

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

• Duplicación de datos
• Colaboración problemática
• Esperando datos
• Curitas que dejarán cicatriz
• Problemas de descubrimiento
• Herramientas desconectadas
• Inconsistencias en el registro
• Falta de proceso
• Falta de propiedad y SLA

Si hay una desconexión, simplemente está practicando la gestión de datos antigua. 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ás en modo de mantenimiento, te dedicas a buscar la razón por la que falta una columna o falla un proceso y a arreglarla, pero no tienes tiempo para planificar y mejorar.

Su trabajo se convierte en verdaderas “operaciones” cuando transforma los tickets de problemas en arreglos 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 arregle antes de que llegue a su pipeline. O implementa un banner de “alertas” en el panel de control de sus ejecutivos que les indica cuándo algo anda mal para que sepan que deben esperar la actualización. Las operaciones de datos, al igual que las operaciones de desarrollo, tienen como objetivo implementar sistemas repetibles, comprobables, explicables e intuitivos que, en última instancia, reduzcan el esfuerzo de todos.

Esto es operaciones de datos versus gestión de datos. Entonces, la pregunta es: ¿cómo se debe estructurar ese equipo de operaciones de datos?

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

Si, por otro lado, fundó (o relanzó) su equipo de operaciones de datos con principios y estructura sólidos, producirá datos que reflejen su estructura interna de alta calidad. Las buenas estructuras de 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 cuaderno que no tiene sentido y se lo pase al ingeniero solo para crear un ciclo de ida y vuelta, ellos y el analista pueden hablar sobre lo que necesitan y el ingeniero puede explicar cómo hacerlo. debe hacerse.
Muchos equipos de operaciones de datos ya trabajan de esta manera. "Los equipos deben aspirar a contar con personal de 'pila completa', de modo que el talento de ingeniería de datos necesario 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 de viajes Agoda, el equipo de ingeniería utiliza pods por la misma razón.

Haz esto incluso si eres solo una persona. Cada rol es un “sombrero” que alguien debe llevar. Para tener un equipo de operaciones de datos de alto funcionamiento, es útil 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. Se encargan de la gestión de proyectos, la orientación y la resolución de bloqueos. Idealmente, son las personas más informadas del equipo.

Hemos creado nuestra propia estructura ideal, en la foto, aunque es un trabajo en progreso. Lo que es importante tener en cuenta es que hay una sola persona que lidera con una visión de los datos (el vicepresidente). 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. (Crédito a nuestro arquitecto de soluciones de datos, Michael Harper, por estas ideas).

Elegir una métrica de 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" internos de datos se quejen de que los datos son lentos. Pero la razón por la que es lento es porque sabes que su deseo tácito es optimizar primero la calidad.

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

Una vez que tengas una estrella polar, también puedes decidir sobre submétricas o subprincipios que apunten a esa estrella polar, 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 de datos y los ingenieros aprenden cómo trabajan unos a otros, estos equipos se mueven más rápido y producen más", dice Amir Arad, gerente sénior de ingeniería de Agoda.

Amir dice que encuentra uno de los valores ocultos de un poco de redundancia multifuncional es que las personas hacen preguntas que nadie en ese equipo había pensado hacer.

“La brecha de conocimiento de ingeniería es realmente genial. Puede llevar a que nos pidan que simplifiquemos”, dice Amir. “Podrían 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 con DevOps, los mejores equipos de operaciones de datos son invisibles y trabajan constantemente para hacerse redundantes. En lugar de interpretar al héroe al que le gusta entrar para salvar a todos, pero que en última instancia hace que el sistema sea frágil, juega al líder sirviente. Apunta, como dijo Lao Tzu, a llevar a las personas a la solución de una manera que les haga pensar: “Lo hicimos nosotros mismos”.

Trata a tu equipo de operaciones de datos como un equipo de producto. Estudie a su cliente. Mantenga un registro de arreglos. Trate de hacer que la herramienta sea lo suficientemente útil como para que los datos se utilicen realmente.

No existe tal cosa como “demasiado pronto” para el monitoreo y la observabilidad de los datos. La analogía que a menudo se usa para excusar el aalogamiento del monitoreo es: “Estamos construyendo el avión mientras estamos en vuelo”. Piense en esa imagen. ¿Eso no le dice 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 ensamblar unos cimientos, más costoso será construirlos y más problemas creará la falta de unos.

Lea: ¿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 growth hack de hoy es la gigantesca pesadilla del caos del sistema interno que transformará los datos del mañana. Necesita asegurar el apoyo ejecutivo para tomar decisiones inconvenientes pero correctas, como decirles a todos que deben pausar las solicitudes porque necesita un trimestre para arreglar las cosas.

CASE significa "copiar y robar todo", una forma irónica de decir, no construyas 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 concéntrese en construir el 40 % de su pipeline que realmente necesita ser personalizado, y hacerlo bien.

Echa un vistazo a los tickets pendientes. ¿Con qué frecuencia reaccionas a los problemas en lugar de anticiparte? ¿Cuántos de los problemas que abordaste tenían una causa principal claramente identificable? ¿Cuántos pudo arreglar de forma permanente? Cuanto más te adelantas, más te pareces a un verdadero equipo de operaciones de datos. Y, más útil le resultará una herramienta de observabilidad de los datos. La visibilidad completa puede ayudarlo a realizar la transición 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.

Aprenda más sobre la plataforma de observabilidad continua de datos de IBM Databand y cómo ayuda a detectar incidentes de datos antes, resolverlos más rápido y entregar datos más confiables a la empresa. Si está listo para profundizar, reserve una demostración hoy.