Os benefícios de uma arquitetura de dados bem construída vão além do processo operacional. Os benefícios se estendem a eficiências operacionais estratégicas, insights de negócios mais profundos e a capacidade de alcançar oportunidades de negócios adjacentes, tudo executado de maneira mais ágil.
Em um artigo anterior, apresentamos um serviço hipotético de pedidos e entregas de comida e apresentamos vários fluxos de trabalho operacionais diários importantes: o processo de pedidos do cliente, o fluxo de trabalho de retirada e entrega de comida e o processamento de pagamentos. Exploramos como uma estratégia de dados intencional em torno das principais entradas de dados para os fluxos de trabalho resulta em processos de negócios mais robustos e ágeis e escaláveis.
Neste artigo, gostaria de ir além da eficiência operacional do dia a dia e demonstrar os benefícios mais estratégicos e de longo prazo do design de arquitetura de dados pensado com antecedência. Avançando nosso cenário inicial em 6 meses, supondo que nossa aplicação tenha sido bem-sucedida, os líderes empresariais agora identificaram algumas oportunidades novas e emergentes. Eles agora estão perguntando aos tecnólogos com que rapidez e facilidade os sistemas subjacentes podem se ajustar e se adaptar a algumas oportunidades específicas e desafios relacionados:
Os quatro exemplos de desafios listados podem ser decompostos em duas grandes categorias:
Primeiro, ajustar e melhorar a eficiência dos principais processos comerciais diários ("táticos").
Dois, criar novos insights que gerem valor de longo prazo ("estratégico") para a empresa, direta ou indiretamente, por meio dos clientes da empresa.
Os dois primeiros novos desafios — expansão de território e requisitos de conformidade associados — envolvem processos comerciais táticos e, portanto, são de natureza mais operacional. Os dois últimos desafios são de natureza mais estratégica.
Vamos primeiro analisar as preocupações táticas e operacionais.
Com a expansão geográfica para cidades adicionais, podemos encontrar alguns problemas diferentes. Um problema potencial para o fluxo de trabalho de entrega é que pode haver um problema de desambiguação com endereços de rua — o mesmo endereço (por exemplo, “100 Main St.”) pode existir em várias cidades. Outro possível problema é que cidades diferentes podem ter fusos horários diferentes; se isso não for considerado, a retirada às 18h00 será possível. O MDT pode atrasar uma hora na entrega para uma cidade vizinha ao PDT (às 18h30). PDT). A arquitetura de dados descrita em nosso artigo anterior incorporou a ideia de uma representação "normalizada" — globalmente única — para elementos de dados, abordando ambos os problemas potenciais e permitindo assim que o aplicativo acomodasse implicitamente esses requisitos adicionais.
A segunda preocupação tática é a conformidade com os requisitos adicionais de governança de dados para o estado da Califórnia. O conjunto completo de preocupações em torno da Lei de Privacidade do Consumidor da Califórnia (CCPA) é um conjunto inteiro de artigos por si só, mas um aspecto é sobre a capacidade de coletar todos os dados de um cliente, anotados com quando foram coletados, juntamente com a fonte dos dados. Conforme discutido anteriormente, a construção de uma estrutura de arquitetura de dados que permita que o pipeline de ingestão de dados primário adicione anotações de metadados, como registros de data e hora, permite que requisitos adicionais de governança de dados sejam atendidos de forma simples e com esforço incremental mínimo.
Além do valor comercial gerado por melhorias nos fluxos de trabalho e processos táticos diários da empresa, outro benefício — sem dúvida mais importante — é o valor estratégico de poder inclinar o campo de jogo existente e também abrir novos campos de jogo nos quais participar.
Uma classe de benefício estratégico é a capacidade de "inclinar o campo" alterando o projeto dos principais fluxos de trabalho operacionais. Isso vai além de simplesmente otimizá-los, mas sim reinventá-los. Uma arquitetura de dados robusta e voltada para o futuro permite a exploração ágil e eficiente dos principais recursos — agregação e análise de dados — necessários para abordar o desafio mencionado anteriormente de degradação do tempo de entrega causada pela variabilidade da demanda, usando preços dinâmicos.
Mais especificamente, devido à premeditação dada à arquitetura de dados, ela:
Como resultado, os dados de dois fluxos de trabalho diferentes — pedidos e entrega — podem ser correlacionados, categorizados e agregados. Além disso, a arquitetura flexível de metadados pode ser aproveitada para anotar os dados coletados com informações contextuais enriquecidas para análise. Considere a latência geral de entrega: o tempo entre o recebimento do pedido e a entrega da comida. A latência pode ser calculada correlacionando os fluxos de trabalho de pedidos e entregas. Além disso, como a representação de dados de geolocalização nos dois fluxos de trabalho também usa sintaxe e semântica consistentes, os cálculos e correlações de latência de entrega podem ser segregados por localização, como por código postal. Assim, em virtude da premeditação na estratégia de dados, podemos criar mais facilmente um conjunto de dados da latência geral de entrega, com granularidade por hora e por código postal. Por fim, aproveitando nossa abordagem flexível de metadados, as estatísticas horárias podem ser anotadas com informações contextuais adicionais, como condições de tráfego e totais de precipitação.
Neste ponto, temos informações valiosas para alimentar um pipeline de análise, que pode então usar métodos de IA preditiva para reconhecer padrões correlacionados com o aumento do tempo geral de entrega e até mesmo antecipar tais condições no futuro.
Como etapa final desta história, podemos imaginar a empresa agora reinventando o fluxo de trabalho de entrega como um problema de oferta e demanda, usando preços para adequar a oferta à demanda. Um exemplo específico é permitir que a remuneração do motorista de entrega seja ajustada por tempo e local, seja por meio de um cronograma fixo ou dinamicamente, com base em condições em tempo real. Isso "fecha o ciclo" no ciclo de dados, aproveitando os dados para tomar medidas práticas (ajustes de preço) para abordar uma preocupação comercial (gerenciando a latência geral de entrega) e usando feedback de ciclo fechado (ajustes dinâmicos de preço, dependendo da latência observada) para tornar o fluxo de trabalho "adaptável".
Um tipo diferente de valor dos dados é usá-los para "abrir novos campos de atuação", criando valor comercial que pode ser monetizado por meio de um benefício direto aos clientes. Um exemplo é mencionado em nosso cenário de 6 meses: fornecer valor aos nossos parceiros fornecedores, os restaurantes. Uma solução para a necessidade comercial de fornecer insights para os clientes do nosso aplicativo é, mais uma vez, aproveitar os dados coletados pelos fluxos de trabalho operacionais do nosso aplicativo — desta vez como matéria-prima para extrair insights comerciais para nossos clientes e parceiros. Esses insights de negócios podem assumir várias formas; alguns exemplos são:
A descoberta desses insights de negócios é possibilitada não apenas pela presença de um grande armazenamento de dados, mas pela estratégia de dados que anota os dados coletados de forma estruturada, usando um vocabulário de metadados consistente.
Analisando uma história específica de insight empresarial, considere como os insights sobre preços de menu podem ser determinados. Começando com as matérias-primas — os dados coletados operacionalmente do fluxo de trabalho de pedidos — o valor da estratégia de dados anotados por metadados se torna prontamente aparente. Especificamente, não apenas o preço de um item em um restaurante específico é registrado, mas os metadados relacionados também são mantidos. Considere os atributos descritivos adicionais de um item alimentar, como o tamanho da porção, o "tipo" de alimento (por exemplo, "refrigerante" ou "hambúrguer") e "aprimoramentos" especiais (por exemplo, "inclui acompanhamento" ou "picante"). Se a arquitetura de dados decorar os dados dos itens alimentares com metadados para esses atributos, usando um vocabulário de tags de metadados consistente (por exemplo, "porção em onças", "classe alimentar", "melhorias") e um conjunto normalizado de valores de metadados, as informações dos itens alimentares poderão ser comparadas entre restaurantes. Por exemplo, se tudo o que se sabe do banco de dados de código é que o "Burger Basement" tem um Man Cave Burger e o "Heart Attack Grill" tem o Double Bypass Burger , não há base para uma comparação significativa. No entanto, se adicionarmos um vocabulário de anotação de metadados, podemos realizar comparações e análises — o sistema entenderia que os dois itens são comparáveis porque ambos são da "classe alimentar" "hambúrguer". Além disso, a análise também pode usar outros campos de metadados para normalizar o tamanho da porção (por exemplo, a "Caverna do Homem" pode ter 8 onças e o "Double Bypass" pode ter 12 onças). Por fim, o uso de um espaço padrão de valores de "aprimoramento", como "inclui queijo", também pode ser usado para fazer ajustes adicionais com base em semelhanças e/ou diferenças secundárias. Mais uma vez, a reflexão sobre a arquitetura de dados — dessa vez, a estratégia de metadados — permitiu que a empresa entregasse rapidamente novas oportunidades de negócios, simplesmente aproveitando a exaustão de dados dos fluxos de trabalho existentes.
A maioria dos líderes empresariais está ciente de que seu sucesso depende do planejamento de seus fluxos de trabalho operacionais críticos, juntamente com a visibilidade da execução desses fluxos de trabalho. Bons líderes empresariais também entendem que a capacidade de gerar esses insights de forma rápida e eficiente e, então, tomar ações — tanto internas quanto externas — com base nesses insights é fundamental para seu sucesso contínuo.
Como tecnólogos, somos solicitados a criar soluções que permitam atingir objetivos comerciais de melhoria contínua da eficiência operacional e agilidade empresarial. Infelizmente, os engenheiros muitas vezes se concentram nos elementos de software de processamento de dados da solução, e não o suficiente na arquitetura de dados em si. Isso geralmente resulta em esforço significativo e atrasos no tempo de implantação na melhoria dos fluxos de trabalho internos e na implementação de novas ofertas derivadas para clientes. Como este artigo demonstra, a atenção inicial dada à arquitetura de dados — o vocabulário de dados, representações e estratégia de metadados — é a base tecnológica para um negócio ágil e robusto baseado em dados.