En dos artículos anteriores nos hemos centrado en las consideraciones para el diseño basado en datos; y específicamente, en cómo los datos comerciales representan valor comercial latente. El mensaje clave ha sido que una arquitectura de datos estructurada es la base técnica que permite extraer ese valor inherente. Sin embargo, esos artículos se centraron en introducir los temas relevantes a nivel conceptual. Hoy me gustaría demostrar los conceptos en el contexto de un ejemplo más tangible y relacionable: una historia sobre cómo uno podría pensar en diseñar una aplicação consistente con una mentalidad centrada en los datos.
Sin embargo, antes de pasar directamente a la historia, recapitulemos por qué los datos son más importantes hoy que en el pasado. Históricamente, muchas empresas han recopilado y almacenado datos principalmente por su propio bien, por razones de gobernanza, como auditoría y cumplimiento. Como tal, la recopilación y el almacenamiento de datos históricamente se han visto como una especie de “impuesto” a las operaciones comerciales, con poco valor comercial operativo directo percibido.
Lo que ha cambiado ahora es la apreciación más plena de que los datos recopilados pueden utilizarse para optimizar los procesos de negocio y mejorar la experiencia del cliente. Por ejemplo, según una encuesta reciente de empresas minoristas digitales, estos dos objetivos (mejorar los procesos comerciales y la experiencia del cliente) fueron los principales impulsores de la transformación digital para el 57 % de todos los encuestados. negocios . La observación crítica, la esencia de “por qué es importante”, es que los flujos de trabajo basados en datos impactan el negocio tanto en los dominios externos (como la experiencia del cliente) como en los internos, para los procesos centrales del negocio. Por eso, una estrategia de datos reflexiva y deliberada es fundamental para permitir la calidad y la rentabilidad de los flujos de trabajo comerciales más importantes. Además, cuando los flujos de trabajo están instrumentados para transmitir el escape de datos observados a una infraestructura de recopilación y análisis de datos, los flujos de trabajo en sí pueden analizarse y mejorarse continuamente, lo que da como resultado flujos de trabajo comerciales constantemente adaptables y optimizados.
Como nota al margen, la mayor ansiedad de estas mismas empresas en torno a la transformación digital era garantizar la ciberseguridad de estos mismos procesos digitales (lo que, como resulta, es otra área en la que este mismo enfoque de análisis y telemetría de datos tiene un papel clave), aunque lo guardaré para otro artículo.
Pasando a nuestro experimento mental, he elegido una historia con la que muchos de nosotros probablemente podamos identificarnos en el estilo de vida actual adaptado al coronavirus: una aplicação que ofrece un servicio en línea para pedidos y entregas de comida de restaurantes. Las comidas se piden en línea desde un restaurante especificado por el cliente, y el usuario puede elegir que el cliente recoja el pedido directamente o que el servicio realice también la entrega.
En esta historia, jugaremos el papel del propietario de la aplicação . En ese papel, debemos abordar muchas preocupaciones diferentes, que dividiremos en dos grupos: primero, las actividades operativas requeridas y, segundo, las preocupaciones estratégicas prospectivas.
El primer conjunto —actividades operativas requeridas— incluye preocupaciones tales como:
El segundo conjunto de preocupaciones son menos operativas y cotidianas, pero no por ello menos importantes. Si se piensa en estas cuestiones desde el principio, permitirán que la empresa sea ágil, adaptable y mejore continuamente. Ejemplos de este tipo de preocupaciones son:
Este es, por supuesto, un subconjunto de la riqueza total de preocupaciones que tendríamos, pero incluso este conjunto más pequeño es suficiente para permitir una buena discusión que resalte la importancia de la arquitectura de datos estructurados en apoyo de un proceso de procesamiento de datos extensible.
En nuestro rol imaginado de Propietario de la Aplicação , al considerar nuestra estrategia de datos general, podemos comenzar enumerando nuestros flujos de trabajo comerciales, identificando las necesidades de procesamiento de datos de cada uno. Un ejemplo es el flujo de trabajo que ubica restaurantes abiertos cercanos y luego presenta selecciones de menú y precios de artículos para cada uno; necesitaría filtrar restaurantes por ubicación y horario comercial, y luego buscar selecciones de menú para un restaurante específicamente seleccionado, quizás también filtrado por la disponibilidad de conductores de entrega. Y podríamos hacer esto para cada flujo de trabajo: procesamiento de pagos, vinculación de conductores con entregas, etc.
O, con igual razón, podríamos comenzar nuestras consideraciones con los “átomos” de datos básicos: los bloques de datos que se necesitan. Identificaríamos y enumeraríamos los átomos de datos importantes, prestando especial atención a tener una representación uniforme y una semántica consistente de esos átomos de datos junto con cualquier vocabulario de metadatos necesario para respaldar nuestros flujos de trabajo comerciales. Los ejemplos de átomos de datos en nuestra aplicação de muestra incluirían: datos de ubicación de restaurantes, clientes y conductores; alimentos necesarios para menús y facturas; tiempo, utilizado para filtrar y rastrear la calidad de la entrega; e información de pago, asociada con los flujos de trabajo de pago de clientes y conductores.
Cuál de estos dos posibles puntos de partida (el flujo de trabajo de procesamiento de datos o, alternativamente, los “átomos” de datos) utilizar para nuestra estrategia de datos es una cuestión de qué es la gallina y el huevo. Ambas perspectivas son útiles y, lo que es más importante, son interdependientes. No podemos razonar sobre el proceso de procesamiento de datos sin pensar en los átomos de datos subyacentes, ni podemos desarrollar la arquitectura de datos sin considerar las necesidades del proceso de procesamiento. Dicho esto, sin embargo, en general, recomendaría un enfoque en el que uno hace un primer paso a través de los flujos de trabajo para enumerar los átomos de datos, pero luego aborda el diseño estructurado de la arquitectura de datos antes de hacer el diseño detallado de la tubería de datos. Esto se debe a que los flujos de trabajo son más dinámicos; se agregan y modifican a medida que el negocio evoluciona, mientras que los datos subyacentes tienen más historia e inercia y, por lo tanto, la arquitectura de datos se beneficia más de la previsión.
Volviendo a nuestro ejemplo, supongamos que, como propietario de una aplicação , tenemos una visión bastante desarrollada de los flujos de trabajo críticos para el negocio y los átomos de datos que se necesitan para respaldarlos. Anteriormente en esta discusión, habíamos identificado algunos de los elementos de datos fundamentales necesarios para nuestros flujos de trabajo: ubicación, hora, alimentos e información de pago. Y, para recapitular los artículos anteriores, la arquitectura de datos debe permitir tres objetivos clave: uniformidad de sintaxis, consistencia de semántica y un vocabulario de metadatos para razonar sobre los datos y gobernarlos. Ahora podemos aplicar estos principios para analizar las consideraciones de arquitectura de datos para los átomos de datos específicos enumerados en el ejemplo de hoy.
Al ampliar el átomo de datos de ubicación , considere cada uno de los tres objetivos clave de la arquitectura de datos.
Solo hemos hablado de los requisitos de ubicación y ahora podríamos realizar un ejercicio similar para cada uno de los otros campos de datos. Sin embargo, en lugar de enumerar todas las áreas de preocupación para cada uno de los átomos de datos, destacaré algunas observaciones notables:
Si bien este ejemplo apenas roza la superficie, ha resaltado muchas de las preocupaciones asociadas con escenarios del mundo real. En el mundo real, sin embargo, el proceso de pensar en la estrategia de datos no terminaría aquí sino que sería iterativo y continuo. A medida que los elementos de datos se incorporan a los canales de procesamiento de datos que incorporan flujos de trabajo comerciales, se realizarán ajustes y mejoras iterativos a la arquitectura de datos. A medida que se mejoran los flujos de trabajo existentes y se agregan nuevos, descubriríamos requisitos de arquitectura de datos adicionales para los átomos de datos existentes junto con los nuevos átomos de datos.
Si bien este ejemplo se ha simplificado para hacerlo más breve, aún demuestra los principios clave en torno a la correlación de los flujos de trabajo con sus implicaciones en la arquitectura de datos. El proceso siempre comienza considerando las necesidades del negocio: la experiencia del cliente y los procesos de negocio necesarios para satisfacer esas necesidades. Los procesos de negocio, a su vez, definen los elementos de un vocabulario empresarial. En el siguiente nivel de especificidad, los procesos se asignan a una canalización de datos, que aprovecha un vocabulario de datos.
El principio clave es que una arquitectura de datos robusta (que define la sintaxis, la semántica y las anotaciones) construye una base que permite mejorar de manera eficiente el flujo de datos y agregar fácilmente nuevos flujos de trabajo. En la capa de abstracción empresarial, esto significa que los procesos empresariales existentes se pueden modificar fácilmente y que los procesos empresariales nuevos o emergentes se pueden poner en línea rápidamente. Por el contrario, no tomar decisiones bien pensadas en cualquiera de estas áreas (vocabulario de datos, marco de arquitectura de datos o vinculación de estos con las necesidades del negocio) en última instancia conducirá a un sistema frágil y quebradizo, que no será ágil ante los nuevos requisitos del negocio.