Por que uma estratégia de design de dados estruturados é importante: Um Exemplo

Fundo

Em dois artigos anteriores, focamos em considerações sobre design orientado a dados; e especificamente, em como os dados empresariais representam valor empresarial latente. A mensagem principal é que uma arquitetura de dados estruturada é a base técnica que permite extrair esse valor inerente. No entanto, esses artigos se concentraram em introduzir os tópicos relevantes no nível conceitual. Hoje, gostaria de demonstrar os conceitos no contexto de um exemplo mais tangível e compreensível: uma história sobre como alguém pode pensar em arquitetar um aplicativo consistente com uma mentalidade de priorização de dados.

Mas primeiro, por que devo me importar?

Antes de pular direto para a história, vamos recapitular por que os dados são mais importantes hoje do que foram no passado.  Historicamente, muitas empresas realizam a coleta e o armazenamento de dados principalmente para seu próprio bem, por razões de governança, como auditoria e conformidade. Como tal, a coleta e o armazenamento de dados têm sido historicamente vistos como uma espécie de “imposto” sobre as operações comerciais, com pouco valor operacional direto percebido.

O que mudou agora é a compreensão mais completa de que os dados coletados podem ser explorados para otimizar processos de negócios e melhorar a experiência do cliente. Por exemplo, de acordo com um inquérito recente a empresas de retalho digital, estes dois objectivos — actualizar os processos empresariais e a experiência do cliente — foram os principais impulsionadores da transformação digital para 57% de todos os inquiridos. negócios . A observação crítica, a essência de "por que isso importa", é que os fluxos de trabalho baseados em dados impactam os negócios tanto em domínios voltados para o exterior (como a experiência do cliente) quanto em domínios voltados para o interior, para os principais processos de negócios. É por isso que uma estratégia de dados bem pensada e deliberada é fundamental para permitir a qualidade e a relação custo-benefício dos fluxos de trabalho empresariais mais importantes. Além disso, quando os fluxos de trabalho são instrumentados para transmitir seus dados observados para uma infraestrutura de coleta e análise de dados, os próprios fluxos de trabalho podem ser continuamente analisados e aprimorados, resultando em fluxos de trabalho de negócios constantemente adaptáveis e otimizados.

Como nota lateral, a ansiedade mais séria dessas mesmas empresas em relação à transformação digital era garantir a segurança cibernética desses mesmos processos digitais — o que, como se vê, é outra área onde essa mesma abordagem de telemetria e análise de dados tem um papel fundamental a desempenhar — embora eu guarde isso para outro artigo. 

A Aplicação: Pedidos e entregas em restaurantes

Passando para nosso experimento mental, escolhi uma história com a qual muitos de nós provavelmente podemos nos identificar no estilo de vida atual adaptado ao Coronavírus: um aplicativo que fornece um serviço online para pedidos e entregas de comida em restaurantes. As refeições são pedidas on-line em um restaurante especificado pelo cliente, e o usuário pode escolher se o pedido será retirado diretamente pelo cliente ou se o serviço também fará a entrega.

Nesta história, desempenharemos o papel do Proprietário do Aplicativo. Nessa função, precisamos abordar muitas preocupações diferentes, que dividiremos em dois grupos: primeiro, atividades operacionais necessárias e, segundo, preocupações estratégicas voltadas para o futuro.

O primeiro conjunto — atividades operacionais necessárias — inclui preocupações como:

• Encontrar e caracterizar restaurantes, incluindo sua localização e horário de funcionamento
• Coletando dados sobre itens de menu e preços
• Informando restaurantes sobre pedidos
• Processando pagamentos
• Manter dados sobre a disponibilidade de recursos humanos para retirada e entrega de pedidos
• Acompanhamento da prontidão do pedido e status da entrega

O segundo conjunto de preocupações é menos operacional do dia a dia, mas não menos importante. Essas questões — se pensadas antecipadamente — permitirão que o negócio seja ágil, adaptável e melhore continuamente. Exemplos desses tipos de preocupações são:

• Como a demanda pode ser prevista? Isso pode ser simplesmente uma demanda agregada por hora do dia/semana, ou pode ser mais detalhado, como por restaurante.
• Que tipo de ferramentas, processos ou fluxos de trabalho fornecem insights de negócios para meus fornecedores (restaurantes)?
• Como os preços — tanto da comida quanto da entrega — podem ser ajustados dinamicamente?
• Supondo que meu aplicativo esteja hospedado na nuvem pública, como meus custos de infraestrutura operacional podem ser otimizados?

Isto é, naturalmente, um subconjunto de toda a riqueza de preocupações que teríamos, mas mesmo este conjunto menor é suficiente para permitir uma boa discussão que destaca a importância da arquitetura de dados estruturados no suporte de um pipeline de processamento de dados extensível.

Arquitetura de Dados ou Pipeline de Dados/Galinha ou Ovo

Em nossa função imaginada de Proprietário de Aplicativo, ao considerarmos nossa estratégia geral de dados, podemos começar enumerando nossos fluxos de trabalho de negócios, identificando as necessidades de processamento de dados de cada um. Um exemplo é o fluxo de trabalho que localiza restaurantes abertos próximos e, em seguida, apresenta seleções de menu e preços de itens para cada um deles. Ele precisaria filtrar restaurantes por localização e horário comercial e, em seguida, procurar seleções de menu para um restaurante selecionado especificamente, talvez também filtrado pela disponibilidade de entregadores. E poderíamos fazer isso para cada fluxo de trabalho: processamento de pagamentos, correspondência de motoristas com entregas e assim por diante.

Ou, igualmente razoável, poderíamos começar nossas considerações com os “átomos” básicos de dados — os blocos de construção de dados que são necessários. Identificaríamos e enumeraríamos os átomos de dados importantes, prestando atenção especial à representação uniforme e à semântica consistente desses átomos de dados, juntamente com qualquer vocabulário de metadados necessário para dar suporte aos nossos fluxos de trabalho comerciais. Exemplos de átomos de dados em nosso aplicativo de exemplo incluem: dados de localização de restaurantes, clientes e motoristas; itens alimentares necessários para menus e faturas; tempo, usado para filtrar e rastrear a qualidade da entrega; e informações de pagamento, associadas aos fluxos de trabalho de pagamentos de clientes e motoristas.

Qual desses dois potenciais pontos de partida — o pipeline de processamento de dados dos fluxos de trabalho ou, alternativamente, os "átomos" de dados — usar para nossa estratégia de dados é uma questão do ovo ou da galinha. Ambas as perspectivas são úteis e, mais importante, são interdependentes. Não podemos raciocinar sobre o pipeline de processamento de dados sem pensar nos átomos de dados subjacentes, nem podemos desenvolver a arquitetura de dados sem considerar as necessidades do pipeline de processamento. Dito isso, no entanto, em geral, eu recomendaria uma abordagem em que se faz uma primeira passagem pelos fluxos de trabalho para enumerar os átomos de dados, mas depois se aborda o design estruturado da arquitetura de dados antes de fazer o design detalhado do pipeline de dados. Isso ocorre porque os fluxos de trabalho são mais dinâmicos; os fluxos de trabalho são adicionados e modificados conforme o negócio evolui, enquanto os dados subjacentes têm mais histórico e inércia — e, portanto, a arquitetura de dados se beneficia mais da previsão.

Aplicando uma Arquitetura de Dados Holística e Abordagem de Pipeline a Exemplos Concretos

Voltando ao nosso exemplo, vamos supor que, como Proprietário do Aplicativo, temos uma visão bastante desenvolvida dos principais fluxos de trabalho críticos para os negócios e dos átomos de dados necessários para suportá-los. Anteriormente nesta discussão, identificamos alguns dos elementos de dados fundamentais necessários para nossos fluxos de trabalho: localização, hora, itens alimentares e informações de pagamento. E, para recapitular artigos anteriores, a arquitetura de dados deve permitir três objetivos principais: uniformidade de sintaxe, consistência de semântica e um vocabulário de metadados para raciocinar e governar os dados. Agora, podemos aplicar esses princípios para discutir considerações de arquitetura de dados para os átomos de dados específicos enumerados no exemplo de hoje.

Dando uma olhada mais de perto no átomo de dados de localização , considere cada um dos três principais objetivos da arquitetura de dados.

• Primeiro, qual é a sintaxe de representação uniforme de dados ?
  Uma ideia inicial pode ser representar a localização pelo endereço da rua, já que é assim que restaurantes e clientes normalmente representam sua localização. No entanto, considere as necessidades de localização para rastrear motoristas que fazem entregas: eles geralmente estão em movimento, talvez em uma rodovia principal ou em um local que não é bem descrito por um endereço. Em vez disso, uma especificação de latitude e longitude pode ser uma maneira melhor de representar a localização desse fluxo de trabalho, e esse formato ainda funcionaria para restaurantes e localizações de clientes. Mas como os motoristas normalmente precisam ir até um restaurante ou a localização de um cliente, ainda deve haver uma maneira de relacionar a localização do motorista (lat/lon) à localização do cliente (endereço). Portanto, uma escolha mais ponderada pode ser normalizar todos os dados de localização em latitude e longitude (a representação “canônica” necessária), mas com a capacidade de converter endereços de rua para lat/lon quando o endereço de rua for fornecido pela primeira vez (um fluxo de trabalho de “ingestão”).
• A segunda consideração é a da semântica consistente . 
  Supondo que a localização seja normalizada como lat/lon, isso é relativamente simples, porque esse é um padrão bem estabelecido com interpretação inequívoca. Entretanto, outro aspecto da semântica consistente diz respeito à precisão: a exatidão implícita dos dados. Considerando que os dados de GPS e mapeamento terão uma precisão implicitamente limitada, podemos escolher especificar a localização com uma precisão constante (por exemplo, até o segundo de arco mais próximo, aproximadamente 100 pés) ou com precisão variável, dependendo da qualidade da fonte de dados. Se escolhermos a última opção por flexibilidade, devemos anotar — usando metadados, descritos a seguir — a precisão de cada instância de dados de localização.
• O terceiro objetivo da arquitetura de dados é ter a capacidade de anotar e enriquecer os elementos de dados coletados.
  No caso da localização, isso pode incluir a precisão dos dados, conforme mencionado anteriormente. Além disso, também podemos querer anotar o local com um endereço de rua para facilitar o acesso humano e, principalmente, para que os dados de endereço ingeridos possam ser preservados. Isso é especialmente importante para casos em que vários endereços de rua podem ser mapeados para a mesma lat/lon, como um complexo de apartamentos. Outro enriquecimento pode ser um registro de data e hora de quando o campo de dados de localização foi coletado, o que pode ser relevante para um motorista em movimento, onde os dados de localização ficam obsoletos rapidamente.

Falamos apenas sobre os requisitos de localização e agora podemos fazer um exercício semelhante para cada um dos outros campos de dados. No entanto, em vez de enumerar todas as áreas de preocupação para cada um dos átomos de dados, destacarei algumas observações notáveis:

• Em relação ao átomo de dados de tempo : A representação de um valor de tempo é notoriamente complicada. Pode variar, tanto sintaticamente (por exemplo, formato de 24 horas vs. 12 horas mais AM/PM) e semanticamente (por exemplo, o conceito de fusos horários e variação na observação do horário de verão). Portanto, a representação do tempo provavelmente precisará ser canonizada (por exemplo, normalizando para GMT ou segundos “desde a época” para usuários de Unix/Linux).
• As instâncias de dados de itens alimentares podem ser bastante variadas, com necessidades únicas. Como os átomos de dados geralmente são livres, um vocabulário de metadados canônico é mais útil do que tentar uma sintaxe uniforme. Alguns campos de metadados seriam para propriedades estáticas por item, como "precisa permanecer frio" ou "contém nozes", mas outros campos de metadados seriam necessários para informações de itens alimentares por instância (por pedido), como "nível de picante" ou "condimentos preferidos". Em ambos os casos, o objetivo do design requer sintaxe uniforme e semântica consistente para os campos de metadados, para que eles possam ser compartilhados em todo o inventário de itens de menu.
• Outras considerações importantes são a conformidade e a governança de dados. Um aspecto é a política de retenção de dados, em que alguns campos — como o endereço IP de um cliente ou o histórico de localização de um motorista — podem ser mantidos apenas por um curto período de tempo. Outra consideração comum é que alguns campos podem ter restrições de segurança ou privacidade; um exemplo são as informações de pagamento . O aumento de metadados é uma solução para ambos os casos. Os metadados devem ser usados para anotar um endereço IP ou valor de localização com um tempo de expiração de dados para retenção de dados. No caso de informações de pagamento, os metadados podem ser usados para transmitir requisitos de segurança, como a necessidade de criptografia de dados em repouso ou para especificar restrições de geolocalização do armazenamento de dados persistentes.

Embora esse exemplo seja apenas superficial, ele destacou muitas das preocupações associadas a cenários do mundo real. No mundo real, no entanto, o processo de reflexão sobre a estratégia de dados não terminaria aqui, mas seria iterativo e contínuo. À medida que os elementos de dados são inseridos nos pipelines de processamento de dados que incorporam fluxos de trabalho de negócios, ajustes e melhorias iterativas seriam feitos na arquitetura de dados. À medida que os fluxos de trabalho existentes são aprimorados e novos fluxos de trabalho são adicionados, descobriremos requisitos adicionais de arquitetura de dados para átomos de dados existentes, juntamente com novos átomos de dados.

Considerações Finais

Embora este exemplo tenha sido simplificado para ser mais breve, ele ainda demonstra os princípios-chave em torno do mapeamento de fluxos de trabalho para suas implicações na arquitetura de dados. O processo sempre começa considerando as necessidades do negócio — a experiência do cliente e os processos de negócios necessários para atender a essas necessidades. Os processos de negócios, por sua vez, definem os elementos de um vocabulário empresarial. No próximo nível de especificidade, os processos são mapeados para um pipeline de dados, que aproveita um vocabulário de dados. 

O princípio fundamental é que a arquitetura de dados robusta — que define sintaxe, semântica e anotações — cria uma base que permite que o pipeline de dados seja aprimorado com eficiência e que novos fluxos de trabalho sejam facilmente adicionados. Na abstração da camada de negócios, isso significa que os processos de negócios existentes podem ser facilmente modificados, e processos de negócios novos ou emergentes podem ser rapidamente colocados online. Por outro lado, deixar de tomar decisões ponderadas em qualquer uma dessas áreas — vocabulário de dados, estrutura de arquitetura de dados ou vinculação destes às necessidades do negócio — acabará levando a um sistema frágil e quebradiço, que não será ágil para novos requisitos de negócios.