Capítulo 1. El camino hacia los datos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

El mundo anterior a la COVID-19 ya era rápido y estaba muy orientado a los datos, pero el ritmo del cambio se ha acelerado rápidamente. La competencia feroz, la era digital, las expectativas cada vez mayores de los clientes y el creciente escrutinio normativo exigen que las organizaciones se transformen en empresas modernas impulsadas por los datos. Esta transformación dará lugar inevitablemente a que las organizaciones del futuro sean más digitales que las de hoy, y tengan una visión diferente de los datos. Las organizaciones del mañana respirarán datos y adoptarán una filosofía que los sitúe en el centro de su negocio. Gestionarán los datos como un producto, tomarán decisiones estratégicas basadas en el análisis de datos y tendrán una cultura que actúe sobre los datos.

Basarse en los datos no es sólo una palabra de moda.1 Estar basada en datos proporciona a una organización una ventaja competitiva significativa sobre otras organizaciones. Puede ser proactiva y predecir lo que va a ocurrir antes de que ocurra. Utilizando los datos correctamente, las organizaciones pueden reaccionar rápidamente ante los cambios. El uso de datos genera una mayor confianza porque las decisiones se basan en hechos, no en intuiciones. Con los datos, se pueden detectar antes las nuevas tendencias del sector y las oportunidades de negocio. También mejoran la retención y la satisfacción del cliente, porque los datos informan a las organizaciones de lo que piensan los clientes, cómo se comportan y qué quieren. Con los datos, las organizaciones pueden ser más flexibles, ágiles y rentables, porque los datos proporcionan información sobre los resultados medidos, la lealtad de los empleados, las dependencias, las aplicaciones y los procesos. Así pues, el imperativo de que las organizaciones se transformen en empresas impulsadas por los datos está definitivamente ahí.

Antes de adentrarnos en la transformación propiamente dicha, exploraremos los retos actuales que nos obligan a reevaluar cómo deben gestionarse los datos. Estableceremos una definición común de gestión de datos, que abarque todas las disciplinas y actividades relacionadas con la gestión de datos como activo. Después, nos centraremos en varios desarrollos tecnológicos clave y tendencias del sector, y consideraremos su impacto en la gestión de datos. Analizaremos algunas buenas prácticas de la última década en la gestión de datos, y comprenderemos por qué las arquitecturas de la generación anterior son difíciles de ampliar. Por último, consideraremos cómo podría ser una arquitectura de datos de próxima generación, y presentaré una serie de puntos de acción que deberás abordar al desarrollar tu estrategia de datos.

Desarrollos tecnológicos recientes y tendencias del sector

Transformar una organización para que se rija por los datos no es fácil. Es un proceso a largo plazo que requiere paciencia y fortaleza. Con más datos disponibles, las arquitecturas tradicionales ya no pueden ampliarse debido a su tamaño, complejidad, diseños monolíticos y modelos operativos centralistas. Las empresas necesitan una nueva estrategia de datos y una arquitectura basada en la nube. También se necesita un cambio de paradigma y de cultura, porque los modelos operativos centralizados de datos y TI que funcionan hoy en día ya no funcionarán cuando se apliquen modelos federados de propiedad de datos y consumo de autoservicio. Esto requiere que las organizaciones redefinan cómo se alinean las personas, los procesos y la tecnología con los datos.

Los recientes avances tecnológicos y las tendencias del sector nos obligan a reevaluar cómo deben gestionarse los datos. Tenemos que dejar de canalizar todos los datos en un único silo y adoptar un enfoque que permita a los dominios, equipos y usuarios distribuir, consumir y utilizar los datos por sí mismos de forma fácil y segura. Las plataformas, los procesos y los patrones deben simplificar el trabajo a los demás. Necesitamos interfaces sencillas, bien documentadas, rápidas y fáciles de consumir. Necesitamos una arquitectura que funcione a escala.

Aunque hay muchos aspectos positivos en la evolución hacia una organización verdaderamente orientada a los datos, es importante ser consciente de varios avances tecnológicos y tendencias del sector que están influyendo en el panorama de los datos. En este capítulo, hablaré de cada una de ellas y de su influencia en la gestión de datos. En primer lugar, la analítica está fragmentando el panorama de los datos debido a la diversidad de casos de uso. En segundo lugar, las nuevas metodologías de desarrollo de software están dificultando la gestión de los datos. En tercer lugar, la computación en nube y las redes más rápidas están fragmentando los paisajes de datos. Además, hay que tener en cuenta los problemas de privacidad, seguridad y normativa, y el rápido crecimiento de los datos y su consumo intensivo están haciendo que los sistemas operativos se resientan. Por último, la monetización de los datos requiere una arquitectura de ecosistema a ecosistema. El impacto de estas tendencias en la gestión de datos es tremendo, y están obligando a toda la industria a replantearse cómo debe realizarse la gestión de datos en el futuro.

Afortunadamente, en los últimos años han surgido nuevos enfoques para la gestión de datos, incluidas las ideas de malla de datos y tejido de datos:

  • La malla de datos es una nueva y apasionante metodología para gestionar datos a gran escala. El concepto prevé una arquitectura en la que los datos estén muy distribuidos y un futuro en el que la escalabilidad se consiga federando responsabilidades. Hace hincapié en el factor humano y en abordar los retos de la gestión de la creciente complejidad de las arquitecturas de datos.

  • La malla de datos es un enfoque que aborda los retos actuales de la gestión de datos y la escalabilidad, añadiendo inteligencia y simplificando el acceso a los datos mediante el autoservicio. A diferencia de la malla de datos, se centra más en la capa tecnológica. Es una visión arquitectónica que utiliza metadatos unificados con una capa integrada de extremo a extremo (tejido) para acceder, integrar, aprovisionar y utilizar fácilmente los datos.

Estos enfoques emergentes de la gestión de datos son complementarios y a menudo se solapan. A pesar de la creencia popular entre los profesionales de los datos y de lo que dicen los vendedores comerciales, no deben considerarse técnicas rígidas o independientes. De hecho, espero que estos enfoques coexistan y se complementen entre sí y con cualquier inversión existente en almacenes de datos operativos, almacenes de datos y lagos de datos.

En la transición hacia la orientación por los datos, las organizaciones tienen que hacer concesiones para equilibrar los imperativos de centralización y descentralización. Algunas prefieren un alto grado de autonomía para sus equipos empresariales, mientras que otras priorizan la calidad y el control. Algunas organizaciones tienen una estructura relativamente sencilla, mientras que otras son brutalmente grandes y complejas. Crear la estructura de gobierno y la arquitectura de datos perfectas no es fácil, así que, mientras desarrollas tu estrategia, te animo a que veas estos enfoques de la gestión de datos como marcos de referencia. No hay correcto o incorrecto. Con el enfoque de malla de datos, por ejemplo, puede que te gusten algunas de las buenas prácticas y principios, pero no otros; no necesariamente tienes que aplicarlos todos.

En este libro, compartiré mi punto de vista sobre la gestión de datos , basado en observaciones realizadas sobre el terreno al trabajar estrechamente con muchas grandes empresas, y que te ayudará a tomar las decisiones correctas aprendiendo de los demás. Iremos más allá de los conceptos de malla de datos y tejido de datos, porque creo firmemente que una estrategia de datos debe incluir tanto el plano operativo como el analítico, y que el método de descomposición tanto de los dominios de datos como de los productos de datos debe modificarse para adaptarse a la escala de las grandes empresas. Para ayudarte en tu viaje, compartiré mis observaciones sobre las estrategias y arquitecturas que han diseñado distintas empresas, por qué y qué compensaciones han hecho.

Antes de entrar en detalles, tenemos que ponernos de acuerdo sobre qué es la gestión de datos y por qué es importante. A continuación, tenemos que determinar cómo definir los límites y dar forma a nuestro panorama basándonos en diversas compensaciones. Por último, examinaremos cómo pueden diseñarse y organizarse las actuales arquitecturas de datos empresariales para hoy y mañana.

Permíteme poner las cartas sobre la mesa: la descentralización no es un estado deseado, sino el futuro inevitable de los datos. Por eso creo firmemente que la escalabilidad está obligando a la gestión de datos a organizarse de forma más descentralizada. La gestión de datos a escala exige federar responsabilidades clave, establecer normas sólidas y alinear adecuadamente los recursos y actividades centrales y locales. Este cambio afecta a múltiples áreas: personas, procesos y tecnología. Te obliga a descomponer tu arquitectura, dividiendo y agrupando responsabilidades. El cambio de la centralización a la descentralización también contradice las buenas prácticas establecidas en la última década: construir grandes silos de datos en los que todos los datos se recopilan e integran antes de servirlos. Aunque las arquitecturas de almacén y lago de datos son enfoques excelentes para utilizar los datos, estos modelos centralizados no son adecuados para una arquitectura de datos distribuida descentralizada.

Ahora que hemos preparado el escenario, te pido que respires hondo y dejes a un lado tus prejuicios. Puede que muchos de nosotros estemos profundamente comprometidos con las arquitecturas de datos centralizadas; ésta ha sido una buena práctica durante muchos años. Reconozco que la necesidad de armonizar los datos y de llevar grandes cantidades de datos a un contexto concreto sigue existiendo, y que hacerlo aporta valor a las organizaciones, pero algo que debemos tener en cuenta es la escala a la que queremos aplicar esta disciplina. En un ecosistema altamente distribuido, con cientos o incluso miles de aplicaciones, ¿la mejor forma de gestionar los datos es aplicar la centralización en todas las dimensiones? ¿Es mejor integrar y armonizar todos los datos?

Gestión de datos

El término gestión de datos se refiere en al conjunto de procesos y procedimientos utilizados para gestionar datos. El Cuerpo de Conocimientos de Gestión de Datos de la Asociación de Gestión de Datos (DAMA-DMBOK) tiene una explicación más amplia de la gestión de datos, que define como "el desarrollo, ejecución y supervisión de planes, políticas, programas y prácticas que proporcionan, controlan, protegen y mejoran el valor de los datos y los activos de información a lo largo de sus ciclos de vida".2 El DAMA-DMBOK identifica 11 áreas funcionales de la gestión de datos, con la gobernanza de datos en el centro, como se muestra en la Figura 1-1. Es crucial integrar todas ellas profundamente en tu organización. De lo contrario, carecerás de visión y te volverás ineficaz, y tus datos se descontrolarán. Centrarte en los datos -obtener el máximo valor posible de tus datos- se convertirá en un reto. La analítica, por ejemplo, no vale nada si tienes datos de baja calidad.

dms2 0101
Figura 1-1. Las 11 áreas funcionales de la gestión de datos

Las actividades y disciplinas de la gestión de datos son amplias y abarcan múltiples áreas, algunas estrechamente relacionadas con la arquitectura de software .3 En este libro, me centraré en los aspectos de la gestión de datos más relevantes para gestionar una arquitectura de datos moderna a escala. Veamos más detenidamente las 11 áreas identificadas en esta figura y dónde se tratan en el libro:

  • La gobernanza de los datos, que se muestra en en el centro de la Figura 1-1, implica todas las actividades en torno a la aplicación y el cumplimiento de la autoridad y el control sobre la gestión de los datos, incluidos todos los activos correspondientes. Esta área se describe detalladamente en el Capítulo 8.

  • La arquitectura de datos implica la definición de el plan maestro para tus datos, incluyendo los planos,4 arquitecturas de referencia, visión del estado futuro y dependencias. Gestionarlos ayuda a las organizaciones a tomar decisiones. Todo el libro gira en torno a la arquitectura de datos en general, pero la disciplina y sus actividades se tratarán en profundidad en los Capítulos 2 y 3.

  • El modelado y diseño de datos consiste en estructurar y representar los datos dentro de un contexto y unos sistemas concretos. Descubrir, diseñar y analizar los requisitos de los datos forman parte de esta disciplina. Trataremos estos temas en los Capítulos 4, 7 y 11.

  • Elalmacenamiento y las operaciones de datos se refiere a la gestión del diseño de la base de datos, su correcta implementación y el soporte para maximizar el valor de los datos. La gestión de la base de datos también incluye la gestión de las operaciones de la base de datos. Trataremos este tema en el Capítulo 11.

  • La seguridad de los datos incluye todas las disciplinas y actividades de que proporcionan autenticación, autorización y acceso seguros a los datos. Estas actividades incluyen acciones de prevención, auditoría y mitigación de escaladas. Esta área se describe con más detalle en el Capítulo 8.

  • La integración e interoperabilidad de datos incluye todas las disciplinas y actividades relacionadas con el traslado, recopilación, consolidación, combinación y transformación de datos para trasladarlos eficazmente de un contexto a otro. La interoperabilidad de los datos se refiere a la capacidad de comunicar, invocar funciones o transferir datos entre varias aplicaciones de forma que se requiera poco o ningún conocimiento de las características de la aplicación. La integración de datos, por otra parte, consiste en consolidar datos de distintas (múltiples) fuentes en una visión unificada. Este proceso, que considero el más importante, a menudo se apoya en herramientas adicionales, como la replicación y las herramientas ETL (extraer, transformar y cargar). Se describe ampliamente en los capítulos 4, 5 y 6.

  • La gestión de documentos y contenidos es el proceso de gestión de datos almacenados en formatos no estructurados (medios) y de datos. Algunos aspectos de esto se tratarán en los Capítulos 5 y 6.

  • La gestión de datos maestros y de referencia es acerca de la gestión de datos críticos para garantizar que los datos sean accesibles, precisos, seguros, transparentes y fiables. Esta área se describe con más detalle en el Capítulo 10.5

  • El almacenamiento de datos y la gestión de la inteligencia empresarial incluyen todas las actividades que proporcionan información empresarial y apoyan la toma de decisiones. Esta área, incluida la analítica avanzada, se describe con mayor profundidad en el Capítulo 11.

  • La gestión demetadatos implica que gestione todos los datos que los clasifican y describen. Los metadatos pueden utilizarse para que los datos sean comprensibles, estén listos para la integración y sean seguros. También pueden utilizarse para garantizar la calidad de los datos. Esta área se describe con más detalle en el Capítulo 9.

  • Gestión dela calidad de los datos incluye todas las actividades relacionadas con la gestión de la calidad de los datos para garantizar que puedan utilizarse. Algunos aspectos de esta área se describen en los Capítulos 2 y 3.

La parte del DAMA-DMBOK que necesita más trabajo, y que me inspiró a escribir la primera edición de este libro, es la sección sobre integración e interoperabilidad de datos. Creo que a esta sección le falta profundidad: la relación con la integración de aplicaciones y la arquitectura de software no está clara. No habla de arquitecturas descentralizadas, y carece de orientaciones modernas sobre la interoperabilidad de los datos, como las buenas prácticas de observabilidad y la gestión moderna de canalizaciones de datos. Además, el vínculo con la gestión de metadatos es débil. Los metadatos también necesitan integración e interoperabilidad, porque están dispersos por muchas herramientas, aplicaciones, plataformas y entornos de formas y maneras diversas. La interoperabilidad de los metadatos -la capacidad de dos o más sistemas o componentes para intercambiar datos descriptivos sobre los datos- recibe un tratamiento insuficiente: la construcción y gestión de una arquitectura a gran escala tiene mucho que ver con la integración de metadatos. La interoperabilidad y los metadatos tampoco están bien conectados con el área de la arquitectura de datos. Si los metadatos se utilizan de forma correcta, puedes ver qué datos pasan, cómo se pueden integrar, distribuir y asegurar, y cómo se conectan con las aplicaciones, las capacidades empresariales, etc. Hay pocas orientaciones en el DAMA-DMBOK sobre la gestión de tus datos como un todo, utilizando y conectando los metadatos de .

Otra preocupación que tengo es la visión que tienen DAMA y muchas organizaciones sobre la consecución de la coherencia semántica de extremo a extremo de . A día de hoy, se sigue intentando unificar la semántica para proporcionar coherencia en toda la empresa. Es lo que se denomina una versión única de la verdad. Sin embargo, las aplicaciones son siempre únicas, y los datos también. Diseñar aplicaciones implica mucho pensamiento implícito. El contexto (de dominio) del problema empresarial influye en el diseño de la aplicación y se abre camino en los datos. Pasamos por este contexto cuando pasamos del diseño conceptual al diseño lógico de la aplicación y al diseño físico de la aplicación.6 Es esencial entender esto porque enmarca cualquier arquitectura futura. Cuando los datos se mueven entre aplicaciones, siempre es necesario un paso de transformación de datos en . ¡No hay escapatoria a este dilema de la transformación de datos! En los capítulos siguientes, volveré sobre esta idea.

Otro punto de vista que veo en muchas organizaciones es que la gestión de datos debe ser central y debe estar conectada con los objetivos estratégicos de la empresa. Algunas organizaciones siguen creyendo que los costes operativos pueden reducirse centralizando todas las actividades de gestión de datos. También existe la profunda suposición de que una plataforma centralizada puede eliminar el dolor de la integración de datos para sus usuarios y consumidores. Las empresas han invertido mucho en sus plataformas de datos empresariales, que incluyen almacenes de datos, lagos de datos y buses de servicios. Las actividades de gestión de datos maestros están fuertemente conectadas con estas plataformas, porque la consolidación nos permite mejorar simultáneamente la precisión de nuestros datos más críticos.

Una plataforma centralizada -y el modelo centralizado que conlleva- estará sujeta al fracaso porque no podrá seguir el ritmo de los avances y tendencias que sustentan la descentralización, como la analítica, la computación en la nube, las nuevas metodologías de desarrollo de software, la toma de decisiones en tiempo real y la monetización de los datos. Aunque conozcan estas tendencias, muchas empresas no comprenden el impacto que tienen en la gestión de datos. Examinemos las tendencias más importantes y determinemos la magnitud de ese impacto.

La analítica está fragmentando el panorama de los datos

La tendencia más pionera de es la analítica avanzada, que explota los datos para que las empresas sean más receptivas, competitivas e innovadoras. ¿Por qué la analítica avanzada altera el panorama de datos existente? Con más datos disponibles, el número de opciones y oportunidades se dispara. La analítica avanzada consiste en hacer análisis hipotéticos, proyectar tendencias y resultados o acontecimientos futuros, detectar relaciones y comportamientos ocultos y automatizar la toma de decisiones. Debido al valor reconocido y a los beneficios estratégicos de la analítica avanzada, se han desarrollado muchas metodologías, marcos y herramientas para utilizarla de formas divergentes. Sólo hemos arañado la superficie de lo que la inteligencia artificial (IA), el aprendizaje automático (AM) y el procesamiento del lenguaje natural (PLN) serán capaces de hacer en el futuro.

Nota

El nuevo ChatGPT de OpenAI es un ejemplo alucinante de lo que es capaz la IA. Los modelos que hay detrás de OpenAI, que incluyen la serie Generative Pre-trained Transformer (GPT) , pueden trabajar en tareas complejas como analizar problemas matemáticos, escribir fragmentos de código, elaborar ensayos de libros, crear recetas utilizando una lista de ingredientes y mucho más.

Estas tendencias analíticas obligan a distribuir los datos en muchas aplicaciones analíticas, porque cada caso de uso individual requiere datos diferentes. Los problemas empresariales únicos requieren un pensamiento único, datos únicos y una tecnología optimizada para ofrecer la mejor solución. Tomemos, por ejemplo, una unidad de negocio de marketing cuyo objetivo es identificar nuevas oportunidades de venta para clientes mayores y jóvenes. Dirigirse a estos dos públicos requiere características diferentes -propiedades medibles para el análisis- en los conjuntos de datos. Por ejemplo, los clientes potenciales más jóvenes se segmentarán y agruparán de forma diferente a los clientes potenciales de más edad. Pedir al departamento de marketing que utilice un único conjunto de datos para ambos públicos objetivos requiere muchos compromisos, y probablemente acabarás con un almacén de características que no añade ningún valor a cada caso de uso.7 La solución óptima para generar el máximo valor es dar a cada caso de uso su propio conjunto único de características optimizadas para cada algoritmo de aprendizaje. La creciente popularidad de la analítica avanzada y los consiguientes problemas de diversidad de casos de uso conducen a dos problemas: la proliferación de datos y la intensificación de datos.

Con la proliferación de datos de , los datos están distribuidos y dispersos en una miríada de ubicaciones, aplicaciones y bases de datos. Esto se debe a que los dominios consumidores necesitan procesar los datos para encajarlos en sus soluciones únicas. Esta distribución de datos introduce otros problemas. Por un lado, cuando los datos se copian repetidamente y se dispersan por toda la organización, resulta más difícil encontrar su origen y juzgar su calidad. Esto te obliga a desarrollar una única visión lógica de los mismos datos que se gestionan en distintas ubicaciones. Además, una amplia distribución de los datos hace que su control sea mucho más difícil, porque los datos pueden dispersarse aún más en cuanto salen de una aplicación determinada. Esto requiere que desarrolles un marco para reutilizar los datos de forma eficaz, al tiempo que aplicas la gobernanza y cumples las normativas externas.

La proliferación de técnicas analíticas también está acelerando el crecimiento de la intensidad de los datos: la relación lectura-versus-escritura está cambiando significativamente. Los modelos analíticos que se reentrenan constantemente, por ejemplo, leen constantemente grandes volúmenes de datos. Esto afecta a los diseños de aplicaciones y bases de datos, porque tenemos que optimizar la legibilidad de los datos. También podría significar que necesitamos duplicar los datos para aliviar a los sistemas de la presión de servirlos constantemente, o preprocesar los datos debido al gran número de diversas variaciones de casos de uso y sus patrones de lectura asociados. Además, puede que necesitemos proporcionar diferentes representaciones de los mismos datos para muchos consumidores distintos. Facilitar una gran variedad de patrones de lectura al tiempo que se duplican los datos y se mantiene el control no es fácil. En el Capítulo 4 se ofrece una solución para este problema.

La velocidad de entrega del software está cambiando

En el mundo actual, los servicios basados en software son el núcleo de la mayoría de las empresas, lo que significa que las nuevas características y funcionalidades deben entregarse rápidamente. En respuesta a las demandas de mayor agilidad, han surgido nuevas ideologías en empresas como Amazon, Netflix, Meta, Google y Uber. Estas empresas han avanzado en sus prácticas de desarrollo de software basándose en dos creencias.

La primera creencia es que el desarrollo de software (Dev) y las operaciones de tecnología de la información (Ops) deben combinarse para acortar el ciclo de vida del desarrollo de sistemas y proporcionar una entrega continua con una alta calidad de software. Esta metodología, denominada DevOps, requiere una nueva cultura que abarque más autonomía, comunicación abierta, confianza, transparencia y trabajo en equipo interdisciplinar.

La segunda creencia se refiere al tamaño al que deben desarrollarse las aplicaciones. Se espera que la flexibilidad y la velocidad de desarrollo aumenten cuando las aplicaciones se transformen en servicios descompuestos más pequeños. Este enfoque de desarrollo incorpora varias palabras de moda: microservicios, contenedores, Kubernetes, diseño dirigido por dominios, informática sin servidor, etc. No entraré aún en detalles sobre todos estos conceptos, pero es importante reconocer que esta evolución en el desarrollo de software implica una mayor complejidad y una mayor demanda para controlar mejor los datos.

La transformación de aplicaciones monolíticas en aplicaciones distribuidas -por ejemplo, microservicios- crea muchas dificultades para la gestión de datos. Al dividir las aplicaciones en piezas más pequeñas, los datos se reparten entre distintos componentes más pequeños. Los equipos de desarrollo también deben pasar de sus almacenes de datos (únicos), en los que entienden perfectamente el modelo de datos y tienen todos los objetos de datos juntos, a un diseño en el que los objetos de datos están repartidos por todas partes. Esto introduce varios retos, como una mayor comunicación en red, réplicas de lectura de datos que deben sincronizarse, dificultades al combinar muchos conjuntos de datos, problemas de coherencia de los datos, problemas de integridad referencial, etc.

El reciente cambio en las tendencias de desarrollo de software requiere una arquitectura que permita a las aplicaciones más finas distribuir sus datos. También requiere una nueva cultura de DataOps y una filosofía de diseño diferente, con más énfasis en la interoperabilidad de los datos, la captura de eventos inmutables y un acoplamiento reproducible y suelto. Discutiremos esto con más detalle en el Capítulo 2.

El impacto de la nube en la gestión de datoses inconmensurable

Las redes son cada vez más rápidas, y el ancho de banda aumenta año tras año. Los grandes proveedores de la nube han demostrado que es posible mover terabytes de datos en la nube en cuestión de minutos, lo que permite un enfoque interesante: en lugar de llevar la potencia de cálculo a los datos -que ha sido la mejor práctica común debido a las limitaciones de la red-, podemos darle la vuelta y llevar los datos a la potencia de cálculo distribuyéndolos. La red ya no es el cuello de botella, por lo que podemos mover los datos rápidamente entre entornos para permitir que las aplicaciones los consuman y utilicen. Este modelo resulta especialmente interesante a medida que se popularizan los mercados del software como servicio (SaaS) y del aprendizaje automático como servicio (MLaaS). En lugar de hacer todas las cosas complejas internamente, podemos utilizar las redes para proporcionar grandes cantidades de datos a otras partes.

Este patrón de distribución de copiar (duplicar) datos y llevarlos a la potencia de cálculo en una instalación diferente, como un centro de datos en la nube, fragmentará aún más el panorama de los datos, haciendo que una estrategia clara de gestión de datos sea más importante que nunca. Requiere que proporciones directrices, porque la fragmentación de los datos puede afectar negativamente al rendimiento debido al retraso en el acceso a los datos. También requiere que organices y modeles tus datos de forma diferente, porque los proveedores de servicios en la nube diseñaron arquitecturas separadas de computación y almacenamiento para hacerlas escalables de forma independiente.

La privacidad y la seguridad son una prioridad absoluta

Las empresas necesitan para replantearse la seguridad de los datos en respuesta a la proliferación de fuentes de datos y al creciente volumen de los mismos. Es indiscutible que los datos son clave para las organizaciones que buscan optimizar, innovar o diferenciarse, pero también existe un lado más oscuro con trasfondos poco amistosos que incluyen robos de datos, discriminación y perjuicios políticos que socavan los valores democráticos. Veamos algunos ejemplos para hacernos una idea del impacto de una mala privacidad y seguridad de los datos.

UpGuard mantiene una larga lista de las mayores violaciones de datos hasta la fecha, muchas de las cuales han aprovechado los mismos errores. La brecha de Cambridge Analytica y 500 millones de cuentas hackeadas en Marriott son impresionantes ejemplos de sucesos perjudiciales. Los gobiernos se implican cada vez más en la seguridad y la privacidad porque todos los aspectos de nuestra vida personal y profesional están ahora conectados a Internet. La pandemia de COVID-19, que obligó a muchos de nosotros a trabajar y socializar desde casa, aceleró esta tendencia. Las empresas no pueden permitirse ignorar las amenazas de las infracciones de la propiedad intelectual y los escándalos de privacidad de datos.

Las tendencias de datos masivos, análisis avanzados más potentes y distribución más rápida de datos han desencadenado un debate en torno a los peligros de los datos, planteando cuestiones y discusiones éticas. Permíteme compartir un ejemplo de mi propio país. En Holanda, la Administración Tributaria holandesa practicaba actividades ilegales y discriminatorias. Rastreaban a los ciudadanos con doble nacionalidad en sus sistemas y utilizaban clasificaciones raciales y étnicas para entrenar modelos de derecho a prestaciones por cuidado de hijos. El resultado: miles de familias fueron clasificadas erróneamente como delincuentes y se les suspendieron las prestaciones. Se les ordenó devolver lo que ya habían recibido, a veces por transgresiones técnicas como no firmar correctamente un formulario. Algunas personas se vieron obligadas a vender sus casas y posesiones después de que se les negara el acceso a la reestructuración de la deuda.

Éste es sólo un ejemplo de uso inadecuado de los datos. Como las organizaciones inevitablemente cometen errores y cruzan las líneas éticas, espero que los gobiernos agudicen la regulación exigiendo más seguridad, control y conocimiento. Sólo hemos arañado la superficie de los verdaderos problemas éticos y de privacidad de los datos. Las normativas, como las nuevas leyes europeas sobre gobernanza de datos e inteligencia artificial, obligarán a las grandes empresas a ser transparentes sobre qué datos se recopilan y compran, qué datos se combinan, cómo se utilizan los datos en los modelos analíticos y qué datos se distribuyen (venden). Las grandes empresas tienen que empezar a pensar ya, si no lo han hecho ya, en la transparencia y en los enfoques que dan prioridad a la privacidad, así como en la forma de abordar las grandes cuestiones normativas.

La regulación es un tema complejo. Imagina una situación en la que se utilizan varias regiones de nube y diferentes servicios SaaS y los datos están dispersos. Satisfacer normativas como el GDPR, la CCPA, el BCBS 239 y el nuevo Marco Transatlántico de Privacidad de Datos es difícil, porque se exige a las empresas que tengan conocimiento y control de todos los datos personales, independientemente de dónde estén almacenados. La gobernanza de los datos y el tratamiento correcto de los datos personales es una prioridad para muchas grandes empresas de .8

Estos requisitos normativos más estrictos y la preocupación por la ética de los datos darán lugar a más restricciones, procesos adicionales y un mayor control. La información sobre dónde se originaron los datos, cómo se entrenan los modelos y cómo se distribuyen los datos es crucial. Se requiere una gobernanza interna más fuerte, pero esta tendencia de mayor control es contraria a las metodologías de desarrollo rápido de software, que implican menos documentación y menos controles internos. Requiere un punto de vista diferente, más defensivo, sobre cómo se gestionan los datos, con procesos más integrados y mejores herramientas. Varias de estas preocupaciones se tratarán en en el Capítulo 8.

Hay que integrar los sistemas operativos y analíticos

La necesidad de reaccionar más rápidamente a los acontecimientos empresariales introduce nuevos retos. Tradicionalmente, ha existido una gran división entre las aplicaciones transaccionales (operativas) y las aplicaciones analíticas, porque los sistemas transaccionales no suelen bastar para suministrar grandes cantidades de datos ni para enviarlos constantemente. Las buenas prácticas aceptadas han consistido en dividir la estrategia de datos en dos partes: el procesamiento transaccional operativo y el almacenamiento de datos analíticos y el procesamiento de big data.

Sin embargo, esta división está sujeta a la interrupción de . Se espera que la analítica operativa, que se centra en predecir y mejorar los procesos operativos existentes, colabore estrechamente tanto con los sistemas transaccionales como con los analíticos. Los resultados analíticos deben volver a integrarse en el núcleo del sistema operativo para que los conocimientos sean relevantes en el contexto operativo. Podría hacer el mismo argumento para los eventos en tiempo real: cuando los eventos llevan estado, los mismos eventos pueden utilizarse para la toma de decisiones operativas y la distribución de datos.

Esta tendencia requiere una arquitectura de integración diferente, que gestione mejor los sistemas operativos y analíticos al mismo tiempo. También requiere que la integración de datos funcione a distintas velocidades, ya que éstas suelen ser diferentes para los sistemas operativos y los analíticos. En este libro, exploraremos las opciones para conservar los datos históricos en el contexto operativo original y, al mismo tiempo, ponerlos a disposición de los sistemas operativos y analíticos.

Las organizaciones funcionan en ecosistemas colaborativos

Mucha gente piensa que todas las actividades empresariales tienen lugar dentro del único límite lógico en el que opera la empresa. La realidad es distinta, porque muchas organizaciones colaboran estrechamente con otras. Las empresas integran cada vez más sus capacidades empresariales básicas con servicios de terceros. Este aspecto de colaboración influye en el diseño de tu arquitectura, porque necesitas poder distribuir datos rápidamente, incorporar datos abiertos ,9 hacer públicas las API,etc.

Estos cambios significan que los datos se distribuyen más a menudo entre entornos y, por tanto, están más descentralizados . Cuando los datos se comparten con otras empresas, o se utilizan soluciones en la nube o SaaS, acaban en lugares diferentes, lo que dificulta la integración y la gestión de los datos. Además, los problemas de ancho de banda, conectividad y latencia de la red surgen inevitablemente al mover datos entre plataformas o entornos. Perseguir una única nube pública o una única estrategia de plataforma no resolverá estos retos, porque la descentralización es el futuro. Esto significa que si quieres que las API y los sistemas SaaS funcionen bien y utilicen las capacidades de la nube pública, debes ser hábil en la integración de datos , algo que este libro te enseñará a hacer.

Las tendencias que aquí se discuten son importantes y afectarán a la forma en que las personas utilizan los datos y a la forma en que las empresas deben organizar sus arquitecturas. El crecimiento de los datos se acelera, la potencia de cálculo aumenta y las técnicas analíticas avanzan. El consumo de datos también está aumentando, lo que implica que los datos deben distribuirse rápidamente. Se requiere una gobernanza de datos más sólida. La gestión de datos también debe descentralizarse debido a tendencias como los servicios en la nube, SaaS y los microservicios. Todos estos factores deben equilibrarse con un corto plazo de comercialización, gracias a la fuerte competencia. Esta arriesgada combinación nos desafía a gestionar los datos de una forma completamente diferente.

Las Empresas Están Cargadas de Arquitecturas de Datos Anticuadas

Uno de los mayores problemas a los que se enfrentan muchas empresas es obtener valor de sus actuales arquitecturas de datos .10 La mayoría de las arquitecturas de datos existentes utilizan un diseño monolítico, ya sea un almacén de datos empresarial (EDW) o un lago de datos, y gestionan y distribuyen los datos de forma centralizada.11 o un lago de datos- y gestionan y distribuyen los datos de forma centralizada. En un entorno altamente distribuido y orientado al consumidor, estas arquitecturas no satisfarán las necesidades futuras. Veamos algunas de las características de cada una.

El almacén de datos de la empresa: Una única fuente de verdad

La mayoría de las arquitecturas de datos de primera generación de las empresas se basan en el almacenamiento de datos y la inteligencia empresarial. La filosofía es que la centralización es la bala de plata para resolver el problema de la gestión de datos. Con este enfoque hay un repositorio central de datos integrado, que contiene años de datos detallados y estables, para toda la organización. Pero cuando se trata de distribuir datos a gran escala, un diseño tan monolítico tiene varios inconvenientes.

La unificación de los datos empresariales es una empresa increíblemente compleja y se tarda muchos años en llevarla a cabo. Las probabilidades de que el significado de los datos difiera en los distintos dominios de son relativamente altas,12 departamentos y sistemas, aunque los atributos de los datos tengan nombres similares. Así que acabamos creando muchas variaciones o simplemente aceptando las diferencias e incoherencias. Cuantos más datos añadamos, y más conflictos e incoherencias surjan, más difícil será armonizar los datos. Es probable que acabemos con un contexto unificado que carezca de sentido para los usuarios finales. Además, para la analítica avanzada, como el aprendizaje automático, dejar fuera el contexto puede ser un problema importante, porque es imposible predecir correctamente el futuro si los datos carecen de sentido o son irreconocibles.

Los almacenes de datos empresariales se comportan como bases de datos de integración, como se ilustra en en la Figura 1-2. Actúan como almacenes de datos para múltiples aplicaciones consumidoras de datos. Esto significa que son un punto de acoplamiento entre todas las aplicaciones que quieren acceder a los datos. A menudo se asume que la centralización es la solución a la gestión de datos, lo que incluye centralizar todas las actividades de datos y gestión mediante un equipo central, construir una plataforma de datos, utilizar un marco ETL y un modelo canónico, etc. Sin embargo, con una arquitectura centralizada, los cambios deben realizarsecon cuidado debido a las numerosas dependencias cruzadas entre las distintas aplicaciones. Algunos cambios también pueden desencadenar un efecto dominó de otros cambios. Cuando has creado un diseño tan altamente acoplado y difícil de cambiar, has creado lo que algunos ingenieros llaman una "gran bola de barro".

dms2 0102
Figura 1-2. Las arquitecturas centralizadas son un cuello de botella para muchas organizaciones: un equipo debe esperar a que otro termine su trabajo

Debido al alto grado de complejidad del almacén de datos y al hecho de que hay un equipo central que lo gestiona, la falta de agilidad se convierte a menudo en una preocupación. El aumento del tiempo de espera despierta la creatividad de tomar atajos. Los ingenieros, por ejemplo, pueden saltarse la capa de integración y asignar directamente los datos de la capa de preparación a sus marts de datos, mientras que otros desarrolladores crean soluciones provisionales utilizando vistas que combinan rápidamente datos de distintas capas. La deuda técnica (futura reelaboración de ) que se acumula como resultado causará problemas más adelante. La arquitectura se volverá más compleja, y la gente perderá la perspectiva de las soluciones creativas elaboradas para garantizar la entrega a tiempo.

Además, los almacenes de datos están estrechamente acoplados a la solución o tecnología subyacente elegida, lo que significa que los consumidores que requieren patrones de lectura diferentes deben exportar los datos a otros entornos. A medida que cambia el panorama de proveedores y surgen nuevos tipos de bases de datos, los almacenes se ven cada vez más obligados a distribuir los datos fuera del lugar donde se gestionan. Esta tendencia socava la gran visión de utilizar eficazmente un único repositorio central y utilizar el hardware subyacente (caro).

Gestión del ciclo de vida de los datos históricos también suele ser un problema. Los almacenes de datos se consideran archivos de la verdad, que permiten a los sistemas operativos limpiar los datos irrelevantes, sabiendo que los datos se conservarán en el almacén. Para la analítica operativa avanzada -que surgió después de la aparición de los almacenes de datos- puede ser un problema. Si los datos han sido transformados por un equipo central que gestiona todos los datos de la organización, puede que ya no sean reconocibles para el equipo que los entregó (o utilizables para el caso de uso operativo previsto). Además, hacer que los datos estén disponibles rápidamente puede ser difícil, dado que muchos almacenes suelen procesar los datos durante muchas horas antes de almacenarlos. Esto es necesario porque, antes de ser almacenados, los datos deben ser transformados, combinados e integrados con otros datos.

La calidad de los datos también suele ser un problema. ¿A quién pertenecen los datos de un almacén de datos? ¿Quién es responsable si los sistemas fuente entregan datos corruptos? Lo que veo a menudo en las organizaciones es que un equipo central de ingenieros se ocupa de los problemas de calidad de los datos causados por otros equipos. En un caso, los ingenieros arreglaron los datos de la capa de preparación para que se cargaran correctamente en el almacén de datos. Estas correcciones se convirtieron en permanentes, y con el tiempo hubo que aplicar cientos de scripts adicionales antes de que pudiera iniciarse el procesamiento de los datos. Estas secuencias de comandos no forman parte de procesos ETL fiables y no permiten rastrear la propiedad y el linaje de los datos.

También pueden surgir problemas normativos . Los almacenes a menudo carecen de información sobre el consumo ad hoc y la distribución posterior, especialmente cuando los datos se transportan fuera de los límites en los que se gestionan. Con las nuevas normativas, la propiedad de los datos y el conocimiento de su consumo y distribución son importantes, porque tienes que poder explicar qué datos personales ha consumido quién y con qué fin.

Dada la cantidad total de datos de un almacén de datos típico, los años que costó desarrollarlo, los conocimientos que tiene la gente y el uso empresarial intensivo, una migración de sustitución sería una actividad arriesgada y que llevaría mucho tiempo. Por eso, muchas empresas siguen utilizando esta arquitectura y alimentan sus informes empresariales, cuadros de mando de 13 y aplicaciones ávidas de datos desde un almacén de datos, a pesar de los elevados costes de mantenimiento y la falta de flexibilidad.

El Lago de Datos: Un repositorio centralizado dedatos estructuradosy no estructurados

A medida que aumentaban los volúmenes de datos de y la necesidad de información más rápida, los ingenieros empezaron a trabajar en otros conceptos. Los lagos de datos surgieron como alternativa para acceder a volúmenes de datos brutos y más grandes.14 Proporcionar los datos tal cual, sin tener que estructurarlos primero, permite a cualquier consumidor decidir cómo utilizarlos y cómo transformarlos e integrarlos.

Los lagos de datos, al igual que los almacenes de datos, son depósitos de datos centralizados (monolíticos), pero se diferencian de los almacenes en que almacenan los datos antes de que hayan sido transformados, limpiados y estructurados. Por tanto, los esquemas suelen determinarse al leer los datos. Esto difiere de los almacenes de datos, que utilizan una estructura predefinida y fija. Los lagos de datos también proporcionan una mayor variedad al admitir múltiples formatos de datos: estructurados, semiestructurados y no estructurados.

Muchas implementaciones de lagos de datos recogen datos puros, sin modificar y sin procesar de los sistemas fuente originales. El volcado de estructuras de aplicación en bruto -copias exactas- es rápido y permite a los analistas y científicos de datos un acceso rápido. Sin embargo, la complejidad de los datos brutos radica en que los casos de uso siempre requieren una reelaboración de los datos. Hay que solucionar los problemas de calidad de los datos, realizar transformaciones y enriquecerlos con otros datos para contextualizarlos. Esto introduce mucho trabajo repetitivo y es una de las razones por las que los lagos de datos suelen combinarse con almacenes de datos. Los almacenes de datos, en esta combinación, actúan como depósitos de alta calidad de datos depurados y armonizados, mientras que los lagos de datos actúan como entornos analíticos (ad hoc), conteniendo una gran variedad de datos en bruto para facilitar el análisis.

Diseñar lagos de datos, al igual que almacenes de datos, es todo un reto. Empresas como Gartner, VentureBeat AI y Deloitte observan elevadas tasas de fracaso en los proyectos de big data, a menudo superiores al 60% en .15 Las implantaciones de lagos de datos suelen fracasar, en parte, por su inmensa complejidad, difícil mantenimiento y dependencias compartidas:

  • Los datos que las aplicaciones introducen en un lago de datos suelen ser brutos y probablemente una representación compleja de cómo las aplicaciones individuales organizan internamente sus datos. Cuando sigues este enfoque, tu lago de datos se convierte rápidamente en una colección que incluye decenas de miles de tablas, estructuras de datos incomprensibles y valores técnicos que sólo entienden las propias aplicaciones. Además, existe un estrecho acoplamiento con las aplicaciones proveedoras, ya que la estructura heredada es una copia idéntica. Cuando los consumidores utilizan estos datos directamente, existe un riesgo real de que los conductos de datos se rompan cuando las aplicaciones proveedoras cambien sus estructuras de datos.

  • Los modelos analíticos de los lagos de datos suelen entrenarse con datos brutos y armonizados. No es impensable que tanto los ingenieros de datos como los científicos de datos sean técnicamente fontaneros de datos, creando datos y operando estos conductos y modelos de datos a mano o en sus proyectos de ciencia de datos. Por tanto, los lagos de datos conllevan riesgos (operativos) sustanciales.

  • Los lagos de datos suelen ser una única plataforma compartida por muchos casos de uso diferentes. Debido a su estrecho acoplamiento, problemas de compatibilidad, bibliotecas compartidas y configuraciones, estas plataformas son difíciles de mantener.

Estas son sólo algunas de las razones por las que la tasa de fracaso de los proyectos de big data es tan alta. Otras razones son la resistencia de la dirección, la política interna, la falta de experiencia y los problemas de seguridad y gobernanza .

El dolor de la centralización

Los almacenes de datos empresariales o los lagos de datos centrales de pueden ampliarse utilizando técnicas como el ELT basado en metadatos, la virtualización de datos, los servicios en la nube, el procesamiento distribuido, la ingestión en tiempo real, el aprendizaje automático para enriquecimientos, etc. Pero hay un problema mucho mayor: el pensamiento centralizado que subyace a estas arquitecturas. Esto incluye la gestión centralizada, la propiedad centralizada de los datos, los recursos agrupados centralmente y los modelos de datos centrales que dictan que todo el mundo debe utilizar los mismos términos y definiciones. Una consecuencia de esta centralización es que apartar a los profesionales de los datos de los ámbitos empresariales limita la creatividad y las ideas empresariales. Los equipos se ven obligados a una comunicación cruzada constante y a gestionar las entradas, porque están a distancia. Es el modelo operativo central el que constituye el cuello de botella: el equipo central no puede atender todas las preguntas y solicitudes con la suficiente rapidez. Es por una buena razón quelas organizaciones están adoptando metodologías descentralizadas como la malla de datos y abogando por el diseño basado en dominios. Un modelo federado con equipos de dominio puede ser una superpotencia: fomenta la independencia y la responsabilidad; permite escalar porque los equipos autónomos gobiernan, comparten y consumen datos en paralelo; y fomenta mejoras en la calidad, la colaboración y la productividad.

Sin embargo, la descentralización tiene una salvedad. La federación de responsabilidades siempre empieza con la centralización, que implica a nivel empresarial definir normas, establecer límites y proporcionar experiencia y escalabilidad. Sin una autoridad central, la descentralización de responsabilidades se convierte en un gran problema. He observado situaciones en las que los equipos empezaron a definir sus propias normas tecnológicas, de interoperabilidad y de metadatos; en las que los departamentos impusieron un control total sobre sus propios datos, de modo que no podían combinarse con datos de otros equipos; y en las que los equipos aplicaron sus propias normas de modelado de datos, normas de datos de referencia, niveles de granularidad, etc., lo que hizo imposible combinar o integrar datos entre dominios. En resumen: la escalabilidad mediante la descentralización no está exenta de riesgos, y la mejor forma de mitigarlos es mediante la alineación central de la organización, la gobernanza, la tecnología y la arquitectura. Por tanto, lo que necesitas es una estrategia de datos: un plan que (re)defina la cultura, la organización y las personas, la arquitectura, la gobernanza y los procesos, y las normas necesarias para convertirte en una organización basada en datos .

Definir una estrategia de datos

Ahora que entiendes la importancia de los datos, las tendencias recientes y los retos que conllevan la centralización y la descentralización, ¿cómo podría ser un camino estratégico hacia una transformación de datos exitosa? Para responder a esta pregunta, hay que realizar un ejercicio de estrategia, teniendo en cuenta los modelos de negocio de la empresa y el papel de los datos en ellos. Los estrategas y arquitectos deben considerar si se justifican cambios en los modelos empresariales existentes, y si se dan las condiciones adecuadas para, por ejemplo, aplicar la federación.

Es conveniente empezar por analizar la organización y las condiciones en las que opera la empresa. A partir de ahí, debe desarrollarse una visión de la empresa que conecte los bloques de construcción de la empresa con las aplicaciones y las fuentes de datos, los procesos, las personas y otras soluciones tecnológicas que se utilizan para realizar la estrategia. Esta vista permite visualizar la arquitectura (de datos) que permitirá alcanzar los objetivos estratégicos de la empresa. En el próximo capítulo volveré a referirme a todos estos aspectos, pero antes veamos los pasos para definir una estrategia de datos.

Desarrollar una estrategia puede ser difícil. A menudo implica una predicción del valor empresarial que puede crearse o de lo que puede ser cierto en el futuro. Requiere conectar ambiciones de alto nivel con recursos, procesos y capacidades de apoyo. Si aún no tienes una estrategia de datos o no estás seguro de tus ambiciones, considera los siguientes puntos de acción:

  • En primer lugar, céntrate en los objetivos y la estrategia de tu empresa. No te enganches al bombo de los últimos cambios tecnológicos.

  • Adopta la visión de la empresa y adáptala a la forma en que los datos la impulsarán. Determina cómo los datos pueden desempeñar un mejor papel en la resolución de los problemas de tu empresa. Intenta cuantificar el impacto empresarial. A continuación, define cómo será tu estrategia empresarial principal en los próximos tres años y después.

  • Determina el equilibrio correcto entre "defensivo" y "ofensivo". ¿Es el control total una prioridad absoluta? ¿O quieres tener flexibilidad para la innovación disruptiva? ¿Cómo afecta la regulación a tu estrategia? Estas consideraciones influirán en tu diseño inicial y en el ritmo de federación de ciertas responsabilidades.

  • Establece hitos claros y medibles. Crea un plan para determinar cuándo tu estrategia de datos tiene éxito y aporta valor. Define métricas e indicadores clave de rendimiento (KPI) para medir los resultados.

  • Crea un plan de comunicación para asegurarte de que tu estrategia se entiende y se comunica en toda la organización.

  • Determina tu primera área de interés. Puede ser la investigación y el desarrollo, el cumplimiento de la normativa, la reducción de costes, el aumento de los ingresos o cualquier otra cosa.

  • Identifica las barreras dentro de tu organización que podrían impedir un resultado satisfactorio, y busca formas de sortearlas.

  • Replantea tu estrategia de talento y determina si tu organización está preparada para aprovechar plenamente los datos. Si no es así, crea un plan (cultural) de transición y contratación para alinear tus departamentos empresariales haciéndoles responsables de la gestión y el uso de los datos en general.

  • Define cómo serán tus capacidades de TI de la próxima generación. ¿Es la TI del futuro responsable de toda la ejecución? ¿O actúa la TI del futuro como centro de excelencia para proporcionar liderazgo, buenas prácticas, formación, investigación y apoyo?

  • Define cómo es una cultura basada en datos. Por ejemplo, identifica qué habilidades y formación se necesitan. ¿Planeas permitir el uso de datos en régimen de autoservicio completo por parte de los usuarios empresariales? ¿Hay voluntad de compartir datos con otros?

  • Reúne datos sobre tus entornos existentes. Por ejemplo, ¿participa cada unidad empresarial de la organización dentro de los mismos límites del ecosistema? ¿O ves que se aplican normas diferentes en los distintos entornos? Empieza por crear una visión general de alto nivel de tu panorama de datos, analizando los distintos entornos y fuentes de datos. Estudia dónde se crean los datos y cómo se distribuyen y utilizan.

  • Determina si tendrás que transformar tu metodología de desarrollo de software. En caso afirmativo, determina cómo podría afectar esto a tu modelo de entrega para construir tu arquitectura de nueva generación.

  • Establece cómo será la transición hacia el futuro. ¿Tu transición es una remodelación radical o una evolución orgánica?

  • Define algunas primeras opciones tecnológicas de alto nivel. Por ejemplo, ¿planeas aprovechar la computación en nube escalable para procesar datos? ¿Prefieres flexibilidad y adaptabilidad, por lo que desarrollarás tus capacidades informáticas para que sean independientes del proveedor? ¿O prefieres consumir servicios nativos, con el riesgo de dependencia del proveedor?

  • Crea una presentación ejecutiva con los elementos más importantes, todos de alto nivel con secciones: por qué, qué, carencias, hojas de ruta y casos de inversión.

  • Crea una estrategia de gestión de costes alineando tu presupuesto con los objetivos y casos de uso. Determina un plan de revisión y la voluntad de invertir en la gestión de datos. Además, alinea los presupuestos con tu proceso de gestión del ciclo de vida de las TI, que implica planificación, subcontratación, adquisición, implementación y posible desmantelamiento.16

Abordar estos puntos de acción debería dejar claras tus ambiciones y estrategia de alto nivel. Es importante hacer esto primero, porque la dirección estratégica proporcionará información para las decisiones sobre arquitectura, procesos, formas de trabajar, hojas de ruta de transición, gobernanza, etc.

Ten en cuenta que una estrategia basada en datos será diferente para cada organización, dependiendo de sus ambiciones, el tamaño y el tipo de empresa, la financiación y las inversiones previstas, la cultura y el nivel de madurez existentes, y los objetivos empresariales subyacentes. Por ejemplo, en mi anterior puesto en ABN AMRO, queríamos que los clientes tuvieran una experiencia a medida, fluida y unificada a lo largo de su viaje digital cuando interactuaran con nuestro banco basado en datos. Por tanto, decidimos alinear e integrar firmemente todas las unidades de negocio minoristas, corporativas e internacionales. Esto significaba que todas las unidades de negocio tenían que trabajar dentro del mismo ecosistema centrado en los datos, seguir el mismo programa de alfabetización de datos y adherirse a los mismos principios arquitectónicos. Para facilitarlo, también tuvimos que integrar las distintas funciones de arquitectura empresarial para diseñar, orientar y controlar la empresa en su conjunto.

En otra organización, la estrategia de datos podría ser completamente distinta. Por ejemplo, si los objetivos empresariales están menos alineados en toda la organización, puede haber menos necesidades de normalización e integración. Si has experimentado recientemente el traumático suceso de una fuga de datos, probablemente estarás muy centrado en la defensa de los datos. Si tu objetivo principal es monetizar los datos y crear asociaciones, te centrarás en ofrecer interoperabilidad para obtener valor económico y datos que sean valiosos en el sentido de que merezca la pena consumirlos para la parte compradora. Lo más importante es alinear tu estrategia de datos con tus necesidades empresariales actuales y futuras.

Antes de terminar, quiero reconocer que algunas personas defienden que no es necesaria una estrategia global. Para ellos, es demasiado trabajo previo. En lugar de desarrollar un plan, creen que deberías simplemente ponerte en marcha y ver qué ocurre por el camino mientras implementas casos de uso. Este enfoque aportará absolutamente un valor inmediato. Sin embargo, a largo plazo tendrá consecuencias desastrosas para tu arquitectura, porque no habrá compromiso con la coherencia y la normalización. Sin un mapa guía, la transición podría ser una larga marcha en la dirección equivocada, que requerirá frecuentes reinicios y ejercicios de marcha atrás.

Conclusión

Una estrategia es el punto de partida de toda transformación digital. Sin duda, los datos son un ingrediente fundamental. Pero, ¿cómo te aseguras de que los datos contribuyen realmente a tus objetivos y ambiciones a largo plazo? ¿Y cómo facilitas el cambio organizativo necesario para utilizar los datos en general? Aquí es donde se requiere una visión de helicóptero, que permita una comprensión real del negocio de extremo a extremo. La planificación para el éxito requiere que primero obtengas una imagen completa. Necesitas alejarte y obtener una visión abstracta de tu negocio, antes de acercarte a espacios problemáticos concretos. Después, tienes que definir una arquitectura y una estructura organizativa que respalden tu transición y se alineen con tu planificación general, tu forma de trabajar y tu modelo de gobierno. A medida que avancemos en el libro, aprenderás más sobre estos conceptos.

Diseñar una arquitectura que se ajuste a todos los requisitos y ambiciones de tu estrategia de datos es la parte más difícil de la transición. En primer lugar, debes crear una imagen holística de tu estructura organizativa, aplicaciones, procesos y panorama de datos. A continuación, puedes elaborar distintos escenarios potenciales equilibrando dimensiones como la flexibilidad, la apertura, el control, el tiempo, el coste de realización, los riesgos, etc. Cada escenario potencial puede incluir hojas de ruta, arquitecturas de transición y diferentes estados futuros. Este proceso es un ejercicio dinámico y colaborativo y va mucho más allá de la creación de simples visualizaciones. Una nota importante al respecto: establecer la dirección estratégica y futura empieza de arriba abajo, desde la empresa. No debe proceder sólo del departamento de TI.

Un aspecto importante de tu estrategia de datos es equilibrar los imperativos de centralización y descentralización. Por ejemplo, ¿federalizas la gobernanza y las actividades, o la arquitectura y la infraestructura, o ambas? Hay mucha confusión sobre este tema, ya que a menudo vemos extremos. Por ejemplo, la malla de datos, como reacción a las organizaciones de datos, arquitecturas y modelos de gobierno centralizados, promueve un cambio de dirección de 180 grados. Adopta la descentralización en todos los aspectos, defendiendo que todos los datos deben ser propiedad descentralizada de dominios que utilicen infraestructuras gestionadas descentralizadamente. Sobre el papel, la descentralización resuena bien entre los líderes empresariales y los responsables de TI , pero en la práctica, las cosas no son tan fáciles.

La descentralización conlleva riesgos, porque cuanto más se dispersan las actividades por toda la organización, más difícil resulta armonizar la estrategia y alinear y orquestar la planificación, por no hablar de fomentar la cultura y contratar el talento necesarios para gestionar adecuadamente tus datos. La fragmentación resultante también plantea nuevas preguntas, como "¿Cuántos modelos de negocio o dominios tengo?" y "¿Cuántas plataformas de datos necesito?". Lo que he observado en la práctica es que muchos arquitectos y profesionales de datos consideran que la descomposición de dominios y el establecimiento de límites es la parte más difícil de la descentralización. A menudo, hay una falta fundamental de comprensión de la arquitectura empresarial y del diseño orientado al dominio. A muchos profesionales de datos les resulta demasiado difícil comprender las nociones conceptuales del diseño basado en dominios. Otros intentan proyectar ejemplos de programación demasiado simplificados u orientados a objetos en su paisaje de datos.

Los principios que sustentan la descentralización también son objeto de debate en lo que respecta a cómo deben gestionarse los datos y las plataformas. Entre los ingenieros de datos, hay escepticismo porque aún no existen normas abiertas de interoperabilidad para los productos de datos. Además, preocupa la utilidad de los datos cuando los equipos individuales operan en burbujas.

Estas observaciones son una buena transición a los capítulos siguientes. En el próximo capítulo, volaremos nuestro helicóptero un nivel más abajo, acercándote lo suficiente como para identificar tu arquitectura, dominios de datos y zonas de aterrizaje. Te ayudaré con esto simplificando el vocabulario de los dominios y proporcionándote orientación pragmática y observaciones desde el terreno. Después, volaremos al lado del sistema fuente de nuestro paisaje y nos quedaremos allí unos cuantos capítulos antes de que nuestro viaje continúe. ¡Buen viaje!

1 El mercado de la analítica de datos está en auge. Alcanzará más de 200.000 millones de dólares de gasto anual en 2022, según IDC.

2 El Cuerpo de Conocimientos es desarrollado por la comunidad DAMA. Su ciclo de actualización es lento: la primera versión fue en 2008, la segunda en 2017.

3 La arquitectura del software se refiere al diseño y la estructura de alto nivel del software necesarios para desarrollar un sistema que cumpla los requisitos empresariales e incluya características como flexibilidad, escalabilidad, viabilidad, reutilización y seguridad. Si quieres saber más, lee Fundamentos de la arquitectura del software, de Mark Richards y Neal Ford (O'Reilly).

4 Un anteproyecto también se conoce como implementación de referencia. Consiste en las definiciones de la Infraestructura como Código (IaC) para crear con éxito un conjunto de servicios para un caso de uso concreto.

5 En este libro utilizamos el término "gestión de datos maestros" (MDM) porque ha sido ampliamente adoptado y no tiene una alternativa en toda la industria en el momento de escribir este libro, pero aceptamos alternativas más inclusivas a la terminología "maestro/esclavo".

6 Si quieres saber más sobre las distintas fases del modelado de datos, consulta la entrada de mi blog "La integración de datos y el modelado de datos desmitificados". El modelo conceptual también se denomina a veces modelo de negocio, modelo de dominio, modelo de objetos de dominio o modelo de objetos de análisis.

7 Un almacén de rasgos es una herramienta para almacenar rasgos de uso común (propiedades o características individuales mensurables de un fenómeno).

8 Los datos personales son cualquier información relacionada con una persona física identificada o identificable.

9 Los datos abiertos son aquellos que se pueden utilizar libremente y se ponen a disposición del público.

10 La arquitectura de datos de una empresa comprende la infraestructura, los datos y los esquemas, integraciones, transformaciones, almacenamiento y flujos de trabajo necesarios para permitir los requisitos analíticos de la arquitectura de la información.

11 Para más información sobre los almacenes de datos (empresariales) y por qué no se amplían, consulta mi entrada del blog "La extinción de los almacenes de datos empresariales".

12 Un dominio es un campo de estudio que define un conjunto de requisitos, terminología y funcionalidad comunes para cualquier programa informático construido para resolver un problema en el ámbito de la programación informática.

13 Los informes suelen ser principalmente tabulares, pero pueden contener gráficos adicionales o componentes de gráficos. Los cuadros de mando son más visuales y utilizan diversos tipos de gráficos.

14 James Dixon, entonces director tecnológico de Pentaho, acuñó el término lago de datos.

15 Brian T. O'Neill mantiene una lista de referencias sobre las tasas de fracaso.

16 Las tecnologías son volátiles, por lo que en algún momento tendrás que sustituirlas o actualizarlas.

Get Gestión de datos a escala, 2ª edición now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial