Por qué es importante una estrategia de diseño de datos estructurados: Un ejemplo

Antecedentes

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.

Pero primero, ¿por qué debería importarme?

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. 

La aplicação: Pedidos y entregas en restaurantes

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:

• Encontrar y caracterizar restaurantes, incluyendo su ubicación y horario de funcionamiento.
• Recopilación de datos sobre los artículos del menú y sus precios
• Informar a los restaurantes de los pedidos
• Procesamiento de pagos
• Mantener datos sobre la disponibilidad de recursos humanos para recoger y entregar pedidos
• Seguimiento del estado de preparación del pedido y entrega

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:

• ¿Cómo se puede predecir la demanda? Esto podría ser simplemente una demanda agregada por hora del día/semana, o podría ser más detallado, como por restaurante.
• ¿Qué tipo de herramientas, procesos o flujos de trabajo proporcionan información empresarial a mis proveedores (restaurantes)?
• ¿Cómo se pueden ajustar dinámicamente los precios, ya sea de la comida o de la entrega?
• Suponiendo que mi aplicação está alojada en la nube pública, ¿cómo se pueden optimizar los costos de mi infraestructura operativa?

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.

Arquitectura de datos o canalización de datos/el huevo o la gallina

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.

Aplicación de una arquitectura de datos holística y un enfoque de canalización a ejemplos concretos

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.

• En primer lugar, ¿cuál es la sintaxis de representación uniforme de datos ?
  Una idea inicial puede ser representar la ubicación mediante la dirección de la calle, ya que así es como los restaurantes y los clientes suelen representar su ubicación. Sin embargo, tenga en cuenta las necesidades de ubicación para rastrear a los conductores que realizan entregas: a menudo están en movimiento, tal vez en una carretera principal o en una ubicación que no está bien descrita por una dirección postal. En cambio, una especificación de latitud y longitud puede ser una mejor manera de representar la ubicación para ese flujo de trabajo, y este formato aún funcionaría para ubicaciones de restaurantes y clientes. Pero debido a que los conductores normalmente deben navegar hasta un restaurante o la ubicación de un cliente, aún debe haber una forma de relacionar la ubicación de un conductor (latitud/longitud) con la ubicación de un cliente (dirección de calle). Por lo tanto, una opción más considerada puede ser la de normalizar todos los datos de ubicación en latitud y longitud (la representación “canónica” requerida), pero con la capacidad de convertir direcciones de calles a latitud/longitud cuando se proporciona la dirección de calle por primera vez (un flujo de trabajo de “ingestión”).
• La segunda consideración es la de la semántica consistente . 
  Suponiendo que la ubicación está normalizada como latitud y longitud, esto es relativamente sencillo, porque se trata de un estándar bien establecido con una interpretación inequívoca. Sin embargo, otro aspecto de la semántica consistente tiene que ver con la precisión: la exactitud implícita de los datos. Dado que los datos de GPS y mapeo tendrán una precisión implícitamente limitada, podemos elegir especificar la ubicación con una precisión constante (por ejemplo, al segundo de arco más cercano, aproximadamente 100 pies) o con precisión variable, dependiendo de la calidad de la fuente de datos. Si elegimos esto último por flexibilidad, debemos anotar (utilizando metadatos, que se describen a continuación) la precisión de cada instancia de datos de ubicación.
• El tercer objetivo de la arquitectura de datos es tener la capacidad de anotar y enriquecer los elementos de datos recopilados.
  En el caso de la ubicación, esto puede incluir la precisión de los datos, como se mencionó anteriormente. Además, también podemos querer anotar la ubicación con una dirección de calle para mayor facilidad de uso y, especialmente, para que se puedan conservar los datos de dirección ingresados. Esto es especialmente importante en los casos en los que varias direcciones de calles pueden corresponder a la misma latitud y longitud, como en el caso de un complejo de apartamentos. Otro enriquecimiento puede ser una marca de tiempo que indique cuándo se recopiló el campo de datos de ubicación, lo que puede ser relevante para un conductor en movimiento donde los datos de ubicación se vuelven obsoletos rápidamente.

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:

• Respecto al átomo de datos del Tiempo : La representación de un valor de tiempo es notoriamente complicada. Puede variar, tanto sintácticamente (por ejemplo, formato de 24 horas frente a formato de 24 horas). 12 horas más AM/PM) y semánticamente (por ejemplo, el concepto de zonas horarias y variación a lo largo de la observación del horario de verano). Por lo tanto, será necesario probablemente canonizar la representación del tiempo (por ejemplo, normalizándola a GMT o a segundos “desde la época” para usuarios de Unix/Linux).
• Las instancias de datos de artículos de alimentos pueden ser bastante variadas y tener necesidades únicas. Debido a que los átomos de datos suelen tener formato libre, un vocabulario de metadatos canónico es más útil que intentar una sintaxis uniforme. Algunos campos de metadatos serían para propiedades estáticas por artículo, como “debe permanecer frío” o “contiene nueces”, pero otros campos de metadatos serían necesarios para información del artículo alimenticio por instancia (por pedido), como “nivel de picante” o “condimentos preferidos”. En cualquier caso, el objetivo del diseño requiere una sintaxis uniforme y una semántica consistente para los campos de metadatos, de modo que puedan compartirse en todo el inventario de elementos del menú.
• Otras consideraciones clave son el cumplimiento y la gobernanza de los datos. Un aspecto es la política de retención de datos, donde algunos campos (como la dirección IP de un cliente o el historial de ubicación de un conductor) pueden conservarse solo por un corto período de tiempo. Otra consideración común es que algunos campos pueden tener restricciones de seguridad o privacidad; un ejemplo es la información de pago . La ampliación de metadatos es una solución para ambos casos. Se deben utilizar metadatos para anotar una dirección IP o un valor de ubicación con un tiempo de expiración de datos para la retención de datos. En el caso de la información de pago, los metadatos se pueden utilizar para transmitir requisitos de seguridad, como la necesidad de cifrar datos en reposo o para especificar restricciones de geolocalización del almacén de datos persistentes.

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.

Reflexiones finales

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.