Modelo de Madurez para Data Driven

API Economy

Modelo de Madurez para Data Driven
25/03/2022

¿Cómo pasan las empresas de los modelos tradicionales a convertirse en empresas basadas en datos? Qubole ha creado un modelo de madurez de cinco pasos que describe las fases por las que suele pasar una empresa cuando se encuentra por primera vez con big data. La Figura 2-6 muestra este modelo, seguido de una descripción de cada paso.

Etapa 1: Aspiración

En esta etapa, una empresa suele utilizar un almacén de datos tradicional con informes de producción y análisis ad hoc.

Las señales de que usted esta en una empresa de Etapa 1 incluyen: tener una gran cantidad de aplicaciones que recopilan volúmenes crecientes de datos; investigar grandes datos, pero no invertir en ellos todavía; contratar ingenieros de big data; contratar activamente con aplicaciones de software como servicio (SaaS) y productos de comercialización; y recopilar requisitos presupuestarios para iniciativas de big data.

También enfrenta ciertos desafíos si está en la Etapa 1. No sabe lo que no sabe. Suele tener miedo a lo desconocido. Está legítimamente preocupado por el panorama competitivo. Además de eso, no está seguro de cuál será el costo total de propiedad (TCO) de una iniciativa de big data. Sabe que necesita idear un plan para obtener un retorno de la inversión (ROI) positivo. Y es posible que en este momento también estés sufriendo conflictos organizacionales o culturales internos.

El signo clásico de una empresa de Etapa 1 es que el equipo de datos actúa como un conducto para los datos, y todos los empleados deben pasar por ese equipo para acceder a los datos.

La clave para pasar de la Etapa 1 a la Etapa 2 es no pensar demasiado. En lugar de preocuparse por cómo cambiar a una cultura de DataOps, comience centrándose en un problema que pueda resolver con una iniciativa de big data.

Etapa 2: Experimento

En esta etapa, implementa su primera iniciativa de big data. Esto suele ser pequeño y está dirigido a un problema específico que espera resolver.

Sabrá que se encuentra en la Etapa 2 si ha identificado con éxito una iniciativa de big data. El proyecto debe tener un nombre, un objetivo comercial y un patrocinador ejecutivo. Probablemente aún no se haya decidido por una plataforma y no tenga una estrategia clara para seguir adelante. Eso viene en la Etapa 3. Todavía se deben sortear numerosos desafíos en esta etapa.

Estas son algunas de las características típicas de las empresas de la Etapa 2:

  • No conocen las posibles trampas que se avecinan. Por eso, están confundidos acerca de cómo proceder.
  • Carecen de los recursos y las habilidades para administrar el proyecto de big data. Esto es extremadamente común en un mercado laboral en el que las personas con habilidades de big data son contratadas a precios exorbitantes.
  • No pueden expandirse más allá del éxito inicial. Esto generalmente se debe a que el proyecto inicial no fue diseñado a escala y expandirlo resulta demasiado complejo.
  • No tienen un plan de apoyo claramente definido.
  • Carecen de colaboración entre grupos.
  • No han definido el presupuesto.
  • No tienen claros los requisitos de seguridad.

Etapa 3: Expansión

En esta etapa, varios proyectos utilizan big data, por lo que tiene la base para una infraestructura de big data. Ha creado una hoja de ruta para crear equipos que respalden el medio ambiente.

También te enfrentas a una plétora de posibles proyectos. Por lo general, estos son proyectos “de arriba hacia abajo”, es decir, provienen de lo alto de la organización, de ejecutivos o directores. Está enfocado en la escalabilidad y la automatización, pero aún no está evaluando nuevas tecnologías para ver si pueden ayudarlo. Sin embargo, tiene la capacidad y los recursos para satisfacer las necesidades futuras y ha ganado la aceptación de la gerencia para el proyecto en su infraestructura existente.

En cuanto a los desafíos, esto es lo que las empresas de la Etapa 3 encuentran a menudo:

  • Una brecha de habilidades: necesidad de acceso a talento más especializado
  • Dificultad para priorizar posibles proyectos
  • Sin presupuesto ni hoja de ruta para mantener el TCO dentro de límites razonables
  • Dificultad para mantenerse al día con la velocidad de la innovación.

Pasar de la Etapa 3 a la Etapa 4 es la transición más difícil de hacer. En la Etapa 3, las personas de toda la organización claman por los datos, y se da cuenta de que tener un equipo centralizado como conducto para los datos y la infraestructura ejerce una enorme presión sobre ese equipo al convertirlo en un cuello de botella para las iniciativas de big data de la empresa. Debe encontrar una manera de invertir su modelo actual y abrir los recursos de infraestructura para todos. El concepto de DataOps  de repente es muy relevante y comienza a hablar sobre la posibilidad de implementar un lago de datos.

Todo el dolor involucrado en la Etapa 3 lo empuja a invertir en nuevas tecnologías y a cambiar su mentalidad y cultura corporativa. Absolutamente comienza a pensar en la infraestructura de autoservicio en este momento y ve al equipo de datos como un equipo de plataforma de datos. Está listo para pasar a la Etapa 4.

Etapa 4: Inversión

Es en esta etapa que logra una transformación empresarial y comienza a ver casos de uso “de abajo hacia arriba”, lo que significa que los empleados identifican proyectos para big data por sí mismos en lugar de depender de los ejecutivos para encargarlos. Todo esto es bueno. Pero todavía hay dolor.

Usted sabe que está en la Etapa 4 si ha pasado muchos meses construyendo un clúster y ha invertido una cantidad considerable de dinero, pero ya no siente que tiene el control. Sus usuarios solían estar contentos con la gran infraestructura de datos, pero ahora se quejan. Al mismo tiempo, también ve un alto crecimiento en su negocio, lo que significa más clientes y más datos, y le resulta difícil, si no imposible, escalar rápidamente. Esto da como resultado colas masivas para los datos. No puede atender a sus “clientes”: los empleados y las líneas de negocio no obtienen la información que necesitan para tomar decisiones.

Las empresas de la Etapa 4 se preocupan por lo siguiente:

  • No cumplir con los acuerdos de nivel de servicio (SLA)
  • No poder hacer crecer la base de datos.
  • No poder controlar el aumento de los costos

Etapa 5: Nirvana

Si has llegado a esta etapa, estás a la par con los Facebook y Google del mundo. Usted es una empresa verdaderamente basada en datos con conocimientos ubicuos. Su negocio se ha transformado con éxito.

Cómo se movió Facebook a través de las etapas de madurez de los datos

El equipo de datos evolucionó de un equipo de servicio a un equipo de plataforma, construyendo herramientas de autoservicio en el proceso.

En 2011, Facebook tenía almacenados decenas de petabytes (PB). Para la época, eso era mucho. Pero compare eso con 2015, cuando se ingieren 600 TB todos los días, se procesan 10 PB todos los días y se almacenan 300 PB en total. Durante los seis años de 2011 a 2017, Facebook experimentó un gran crecimiento en la escala de datos, la cantidad de usuarios y las ambiciones de lo que quiere hacer con su plataforma de datos.

El viaje comienza en agosto de 2007. La empresa aún se encontraba en la Etapa 1, el estado “aspiracional” de su viaje de autoservicio. El equipo de datos era una organización de servicios que ejecutaba casos de uso para cualquier persona de la empresa que necesitara respuestas de los datos. La mayoría de los casos de uso giraron en torno a Extraer, Transformar y Cargar (ETL). Los equipos de productos y negocios vendrían al equipo de datos centralizados, y los miembros del equipo de datos descubrirían cómo llevar los datos al equipo que los solicitó. Al mismo tiempo, el equipo de datos necesitaría comprender qué tipo de infraestructura y soporte de procesamiento necesita para obtener esos datos.

En efecto, el equipo de datos era un conducto, o puerta de entrada, a los datos que necesitaban los equipos de productos y negocios. La arquitectura técnica era un almacén de datos en el que se vertían los resultados, en su mayoría resúmenes. Los datos se recopilaron de los servicios web que ejecutan la aplicación de Facebook y los registros de la aplicación recopilados se volcaron en el almacenamiento de archivos para su posterior procesamiento. Facebook estaba usando una infraestructura local para procesar esos datos y luego resumirlos en conjuntos de datos más pequeños que luego se cargaron en el almacén de datos.

El problema era que el equipo de datos se había convertido en un cuello de botella. Cada vez que los solicitantes de la organización necesitaban un nuevo conjunto de datos, tenían que volver al equipo de datos y describir lo que necesitaban. El equipo de datos escribiría más código utilizando sus herramientas propias, procesaría los registros, crearía los datos y los devolvería a los solicitantes.

Otro problema fue que los datos detallados se ignoraron y se desecharon. El equipo de datos resumió los datos en un nivel muy bajo de granularidad, muy limitado a ETL y casos de uso. Los ejecutivos querían que la toma de decisiones se basara en datos, pero dado este estado de cosas, era muy difícil incorporar datos en el proceso de toma de decisiones. Facebook sabía que necesitaba cambiar esto y armar una infraestructura que escalaría con la empresa.

Facebook alcanzó la Etapa 2 en el momento en que estaba lanzando su plataforma de anuncios. Esto no fue una coincidencia. Con la red publicitaria, Facebook tenía una necesidad urgente de recopilar datos de flujo de clics y usarlos para comprender qué anuncios deberían mostrarse, en qué momento y a qué personas. Facebook sabía que tenía que pensar un poco diferente, por lo que comenzó a experimentar con Hadoop.

Esto fue entre agosto de 2007 y enero de 2008, y lo que hizo Facebook en ese momento tuvo profundas implicaciones. El lago de datos de Hadoop hizo posible retener datos sin procesar y ponerlos en línea. Hive se desarrolló en ese momento para hacer que ese lago de datos fuera ampliamente accesible. En efecto, el equipo de datos evolucionó durante esta etapa de un equipo de servicio a un equipo de plataforma, construyendo herramientas de autoservicio en el proceso. Facebook se dio cuenta de que ahora podía abrir esta arquitectura al equipo de ingeniería y hacer que los datos fueran accesibles, obviando la necesidad del equipo de datos de ser un conducto para estos datos.

Pasar a esta etapa fue un éxito en dos niveles. En primer lugar, la productividad de los desarrolladores se disparó y las barreras para que las personas recopilaran los niveles correctos de datos y realizaran análisis se redujeron drásticamente. En el lado de los datos, significó que se volvió extremadamente fácil usar API para registrar datos sin muchas aprobaciones y procesos internos.

Para Facebook, fue interesante ver cómo algunas decisiones aparentemente simples tenían un efecto magnificador. El autoservicio resultó ser algo que pagó a la organización con creces. Pero ahora tenía que preocuparse por implementar controles y salvaguardas que recompensaran a los buenos usuarios y capacitaran a los malos sobre cómo usar el sistema correctamente.

En este punto, Facebook pasó a la Etapa 3. Usando los servicios de metadatos junto con Hive, los usuarios podían ver tanto los datos como los metadatos. Esto sucedió a fines de 2008 y realmente abrió el poder de los grandes datos a muchos más casos de uso dentro de Facebook. Ahora los analistas podían realizar análisis ad hoc, algo que antes no podían hacer, pero debido a que las herramientas aún eran muy técnicas, los gerentes de productos y otros usuarios comerciales que estaban interesados ​​en los datos todavía tenían algunos problemas para acceder a ellos. En la Etapa 3, Facebook comenzó a pensar mucho sobre cómo construir una verdadera plataforma de autoservicio para todos en la empresa.

Facebook alcanzó la Etapa 4 en 2009. Desarrolló interfaces de usuario que eran lo suficientemente amigables e intuitivas para que las dominaran los usuarios sin conocimientos técnicos. A medida que aumentó el uso, también lo hicieron los desafíos que conlleva el autoservicio: la demanda de un procesamiento más rápido, la demanda de tiempos de respuesta de carga más rápidos y otras demandas de los usuarios. También hubo una proliferación de datos y, a medida que más empleados usaban la infraestructura, se volvió muy importante decidir cómo compartir la infraestructura de manera equitativa y evitar que los usuarios ejecutaran consultas incorrectas.

Aunque se podría argumentar que “Nirvana” (Etapa 5) siempre está fuera de alcance, se podría argumentar que Facebook hoy está cerca. Ha abordado muchos de los desafíos que surgieron en etapas anteriores y continúa ampliando los límites de lo que es posible con big data.