Sincronização entre sistemas: que idade o dado pode ter?
A frequência certa de sincronização entre dois sistemas é a que cabe na decisão que o dado alimenta, não a mais rápida que a tecnologia permite. Cada informação envelhece num ritmo próprio. A pergunta de arquitetura é qual idade ela pode ter quando alguém age sobre ela.
Por que "tempo real" não é a resposta padrão?
Porque o ritmo certo depende da decisão, não da ferramenta. Richard Wang e Diane Strong perguntaram a consumidores de dados o que qualidade significa para eles. A pesquisa partiu de 179 atributos levantados com 25 consumidores de dados de empresas e 112 alunos de MBA com experiência profissional, passou por uma pesquisa com 355 respostas válidas, chegou a 20 dimensões e terminou com 15, agrupadas em quatro categorias.
A pontualidade ficou na categoria contextual, a que só se avalia diante da tarefa em mãos. O artigo, publicado no Journal of Management Information Systems, a define como a medida em que a idade do dado é apropriada para a tarefa, e adota a visão de que dado de qualidade é o que serve a quem o usa.
Isso desmonta a regra única. O problema não é de tecnologia de sincronização, é de arquitetura: decidir a idade de cada dado. Um saldo de estoque consultado na hora de prometer prazo a um cliente e um custo médio lido no fechamento do mês não têm a mesma exigência. Sincronizar os dois a cada minuto dá trabalho de construção e de monitoramento, e só um deles tira proveito. Essa parte é leitura nossa, não do estudo.
Em que velocidade cada dado envelhece?
Em velocidades diferentes, e dá para estimar isso por atributo. Heinrich, Kaiser e Klier propuseram, na conferência ICIS de 2007, uma métrica em que a pontualidade de um valor é a probabilidade de ele ainda ser válido. Essa probabilidade cai de forma exponencial com a idade, a uma taxa própria de cada atributo. No caso que os autores analisaram, o primeiro nome de um cliente tem taxa zero e a tarifa contratada tem 0,4 por ano. Com a mesma idade, os dois têm validade muito diferente.
O caso é uma campanha de uma operadora de telefonia móvel alemã, com números anonimizados. Numa campanha anterior, para 82.000 clientes, a taxa média de sucesso foi de cerca de 8,5%. Entre os clientes com pontualidade estimada de 0,2 a 0,3, ficou em 4,4%. Entre os de 0,9 a 1, em 12,6%. Pela estimativa dos autores, mirar só nos clientes acima de 0,4 elevaria a rentabilidade da campanha seguinte em 30 pontos percentuais. A explicação é simples: quem tem endereço desatualizado nem chega a poder aceitar a oferta.
O limite é este: o estudo trata de uma campanha de marketing na Alemanha, e a pontualidade ali é uma probabilidade estimada, não uma idade medida em horas. Ele mostra que a idade do dado tem efeito mensurável no resultado e que a taxa de envelhecimento varia por atributo. Não serve de referência para o seu processo.
Que idade o dado tem quando a carga roda de tempos em tempos?
Entre zero e o intervalo da carga, e em média no máximo metade dele. Cho e Garcia-Molina, de Stanford, definem a idade de um item copiado como zero quando a cópia está atualizada e, caso contrário, o tempo desde que o original mudou. Aplicando isso a uma sincronização em intervalo fixo T, uma mudança feita logo depois de uma carga só chega na seguinte. A mudança mais antiga que ainda falta na cópia tem entre 0 e T de idade, e a média fica em no máximo T/2 se as consultas se distribuem ao longo do intervalo. Essa aritmética é nossa, não do artigo.
O efeito soma quando os sistemas se encadeiam. Se o sistema A alimenta o B de hora em hora e o B alimenta o painel uma vez por noite, a defasagem possível chega a 25 horas, mais o tempo que cada carga leva para rodar. Quem lê o painel pouco antes da carga seguinte vê um retrato que pode ter mais de um dia, sem que a tela diga isso.
Dois painéis também divergem por definição, tema de Dashboard gerencial: por que os números não batem. Aqui a divergência é de tempo: as duas fontes são lidas em idades diferentes, e ninguém marcou a idade de cada uma.
Todo dado precisa seguir a mesma cadência?
Não, e a ideia de sincronizar mais vezes o dado que muda mais nem sempre se sustenta. O artigo de Cho e Garcia-Molina, de 1999 e apresentado no SIGMOD 2000, trata de um problema parente: com um orçamento limitado de atualizações, quantas dedicar a cada item de uma cópia. O contexto dos autores é o de cópias de páginas da web, então a lição vale como princípio, não como receita.
O resultado mais contraintuitivo é que atualizar cada item em proporção a quanto ele muda foi pior do que atualizar todos no mesmo ritmo. Num exemplo deles, um item que muda nove vezes por dia rende pouco a cada atualização, porque fica velho logo depois, e um que muda uma vez por dia rende mais. Numa estimativa com dados reais da web, que os próprios autores chamam de grosseira, a política proporcional deixaria em média 12% dos itens atualizados, contra 57% da uniforme.
A leitura que fazemos para uma operação é outra camada: o ritmo não deve vir só de quanto o dado muda, e sim do que a decisão perde quando ele está velho. Um dado que muda toda hora e sobre o qual ninguém decide em minutos pode esperar. Um dado que muda pouco, mas trava um pedido quando está errado, merece atenção especial.
Um exemplo prático: o saldo de estoque que o CRM não vê
O cenário a seguir é hipotético. Os números são premissas ilustrativas, não medição. Uma distribuidora com 60 pessoas usa um ERP para estoque e custo, um CRM para propostas e uma planilha de logística. Uma integração noturna copia dados do ERP para o CRM às duas da manhã.
Às duas da tarde, um vendedor promete 40 unidades a um cliente com base no saldo das duas da manhã. Ao meio-dia, outro pedido já tinha consumido 30. O problema não está na integração, que roda como foi desenhada. Está em tratar três dados diferentes com a mesma idade.
O saldo de estoque alimenta uma promessa feita na hora, e a idade aceitável é de minutos, ou uma consulta direta ao ERP no momento de prometer. A situação de crédito do cliente muda poucas vezes por mês, mas bloqueia pedido quando muda, então a carga diária serve, desde que um bloqueio dispare atualização imediata. O custo médio por produto é lido no fechamento, e a carga ao fim do ciclo basta. Três dados, três idades máximas. A integração noturna única atende bem o custo, atende o crédito só com um gatilho a mais e falha no que mais pesa na hora da venda.
Como definir a idade máxima de cada dado?
Comece por um inventário curto: os dados que passam de um sistema a outro e alimentam decisão, entre cinco e dez para começar. Para cada um, escreva quem decide com ele, em que momento e o que acontece se estiver velho. Dessa resposta sai a idade máxima aceitável, anotada ao lado do dado, em minutos ou horas. Só depois se escolhe o mecanismo de sincronização.
Em seguida, faça a tela dizer a idade. Um campo com a hora da última carga dá ao usuário a informação que Wang e Strong colocam no centro da qualidade: a idade do dado diante da tarefa. Por fim, monitore o atraso real contra o máximo combinado. Uma sincronização que parou sem aviso é a falha tratada em Sua automação parou. Quando você vai descobrir?.
No case da Reatop, coletores de resíduos hospitalares trabalham em áreas sem sinal estável, e o aplicativo registra as pesagens offline e sincroniza os dados automaticamente quando detecta conexão. A cadência ali veio do contexto de uso: o dado nasce onde não há rede e chega quando há.
Perguntas frequentes
A implementação vai exigir tempo demais do time?
O inventário de cinco a dez dados cabe em uma ou duas conversas curtas com quem decide com eles. Esse recorte é recomendação nossa de desenho, não número de pesquisa. O trabalho de construção, se houver, fica restrito aos dados em que a idade pesa, o que evita reescrever integrações que já servem.
Não vejo como mensurar o resultado. O que medir?
Meça a idade do dado no momento da decisão e quantas decisões foram refeitas por dado velho, como o pedido prometido e não atendido. Registre os dois números antes de mudar qualquer coisa. O estudo de Heinrich e colegas mostra que a taxa de sucesso variou com a pontualidade estimada, mas não é referência para o seu processo, então a sua linha de base importa mais.
Receio que a integração não elimine os gargalos de verdade. Tempo real resolveria?
Nem sempre. Se a espera está numa aprovação ou numa fila de conferência humana, sincronizar mais depressa não mexe nela. Antes de mudar a cadência, confirme que o atraso está no dado e não na decisão. Quando está no dado, a idade máxima por informação diz onde vale investir.
O próximo passo
Se o seu painel e o seu ERP mostram números de idades diferentes sem avisar, o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, é um convite para mapear quais dados cruzam os seus sistemas e que idade cada um pode ter: fale com a Yowpi.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico