Construa para hoje. Planeje para amanhã. Planeje para a falha.
Também em 28 idiomas
English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 5 de 7 do capítulo Pensar como um arquiteto de dados, o primeiro capítulo do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Arquitetura é a arte dos trade-offs · Próximo: Conheça suas ferramentas: as nove perguntas
A pergunta que este módulo responde: Como projetar para os requisitos de hoje enquanto se planeja para o crescimento e para a falha?
Um dos erros mais fáceis em arquitetura é projetar apenas para os requisitos que estão à sua frente. Temos um projeto, um backlog e requisitos. Construímos algo que os atende. Funciona, e declaramos vitória. Seis meses depois o negócio muda, ou os dados crescem, ou outra unidade de negócio quer usar aquilo, ou adquirimos uma empresa, ou um novo sistema precisa se integrar, ou algo falha sem que ninguém tenha planejado.
Nada disso deveria surpreender um arquiteto. Não conseguimos prever tudo o que vai acontecer, mas podemos projetar sabendo que algo vai acontecer. É por isso que olho a arquitetura por três lentes:
Construa para hoje. Planeje para amanhã. Planeje para a falha.
Você precisa das três.
Construa para hoje
Seção intitulada “Construa para hoje ”A arquitetura começa com o problema que realmente temos. Parece óbvio, mas arquitetos podem cometer o erro oposto ao pensamento de curto prazo: podemos superarquitetar. E se adquirirmos doze empresas, tivermos um bilhão de clientes, expandirmos para 40 países e cada sistema precisar de integração em tempo real? Talvez. Mas essas são possibilidades reais, ou estamos inventando problemas? Arquitetura não é construir o sistema mais sofisticado que conseguimos imaginar. É construir o apropriado.
Então comece por hoje: o que o negócio precisa, os volumes, usuários e transações reais, com que frequência os dados mudam e quão rápido precisam se mover, quem precisa de acesso, e de onde os dados vêm e para onde vão. E, mais importante: por quê? Essas respostas nos dão algo concreto para projetar.
Procure os requisitos implícitos
Seção intitulada “Procure os requisitos implícitos ”Os requisitos que lhe passam não são necessariamente todos os requisitos que você tem. Quase sempre há requisitos implícitos.
O negócio diz: “Precisamos dos dados de clientes no Salesforce.” Certo. Então alguém precisa ser dono desses dados e decidir quão atualizados eles precisam estar. Precisamos saber o que acontece quando o sistema de origem cai, como vamos perceber quando a sincronização falha, e qual lado vence quando o Salesforce e a origem discordam. Precisamos de um prazo de retenção, de um modelo de acesso, de uma decisão sobre campos sensíveis e de uma forma de corrigir dados ruins.
Nada disso estava na user story. Tudo isso continua sendo arquitetura. Uma grande parte de se tornar arquiteto é aprender a reconhecer as perguntas que ainda não foram feitas.
Conheça seus números
Seção intitulada “Conheça seus números ”Eu pressiono os arquitetos o tempo todo a quantificar. Não me diga que há muitos dados; diga quantos. Dez mil, dez milhões, cem milhões, um bilhão? São arquiteturas muito diferentes. Não me diga que a integração roda com frequência: a cada hora, a cada minuto, mil vezes por segundo? Não me diga que estamos crescendo rápido. Quão rápido?
Quando não tenho um número melhor, minha referência é 30% de crescimento anual. Não é uma previsão; é uma forma de forçar a conversa. Se alguém me diz que temos 10 milhões de registros hoje, não quero que a discussão pare em 10 milhões. A 30% ao ano, estaremos em uns 13 milhões no ano que vem, 17 milhões no seguinte e uns 22 milhões no outro. Agora vamos falar do design. Se o negócio me disser que 30% é ridículo, ótimo: me dê o número real. A questão é tornar o crescimento parte da discussão de arquitetura.
Eu chamo isso de Número de Zeros do Steve (Steve’s Number of Zeros). Um zero a mais pode mudar completamente sua arquitetura. Dez mil, cem mil, um milhão, dez milhões, cem milhões: o recurso não mudou, e o requisito talvez não tenha mudado, mas a arquitetura pode ter mudado.
Lembra dos agendamentos do módulo 1? Vamos colocar os números reais neles. Mais de 1.200 locais, 100 agendamentos por local por dia, seis dias por semana, cerca de 305 dias por ano. São mais de 36 milhões de agendamentos no primeiro ano. Cada visita cria dois registros, então mais de 73 milhões de registros. Agora guarde cinco anos de histórico, crescendo 30% ao ano, e são mais de 650 milhões de registros. Mesmo recurso, mesmo requisito. Uns zeros a mais, e uma arquitetura muito diferente.
Planeje para amanhã
Seção intitulada “Planeje para amanhã ”Depois de entender o hoje, olho para frente: o que provavelmente vai mudar? Volume faz parte disso, mas amanhã não é só mais. Também pode significar diferente: mais produtos, unidades de negócio e países; requisitos de privacidade diferentes; novos canais e integrações; uma fusão ou aquisição; uma nova estratégia de dados mestres ou plataforma de análise; um agente de IA consumindo informações que foram projetadas só para humanos.
É por isso que me importo tanto em saber se a arquitetura consegue crescer por adição em vez de mudanças constantes. Se o negócio adiciona um produto, o modelo comporta? Se outro sistema precisa dos dados, conseguimos expô-los de forma limpa? Se o volume dispara, temos para onde ir? Se a estrutura do negócio muda, vamos ter de desmontar o modelo de dados? Não estamos tentando prever o futuro com perfeição. Estamos tentando não nos encurralar num canto.
Não construa o amanhã hoje
Seção intitulada “Não construa o amanhã hoje ”Há um equilíbrio aqui. Planejar para amanhã não significa construir hoje o sistema de amanhã. Se temos 100 mil registros e talvez tenhamos 100 milhões em cinco anos, isso não significa construir agora a arquitetura para 100 milhões de registros. Ela pode trazer custo e complexidade de que ainda não precisamos.
A pergunta que quero respondida é: a arquitetura de hoje consegue evoluir para a de amanhã? Se podemos começar de forma simples com um caminho claro adiante, isso muitas vezes é melhor do que pagar o custo da complexidade anos antes. O perigo não é começar pequeno. O perigo é começar em algum lugar sem para onde ir.
Planeje para a falha
Seção intitulada “Planeje para a falha ”Agora a parte de que ninguém gosta de falar: as coisas falham. Nunca projetei um sistema em que todo componente ficasse disponível para sempre, toda integração tivesse sucesso, todo usuário inserisse dados perfeitos e todo sistema externo se comportasse exatamente como documentado. Então não projete esse sistema.
Pergunte o que pode falhar, depois pergunte o que acontece quando falhar. Uma integração estoura o tempo limite. Uma API rejeita uma requisição. Uma carga noturna processa 800 mil registros e falha em 200 mil. Um sistema de origem cai. Um usuário insere dados inválidos. Um identificador externo aparece duas vezes. Um sistema anterior muda o formato de um valor sem mudar o nome do campo. Um processo tem sucesso num sistema e falha em outro. Esses não são casos extremos incomuns. É assim que a produção é.
Sucesso parcial ainda é uma falha que você precisa entender
Seção intitulada “Sucesso parcial ainda é uma falha que você precisa entender ”Falhas parciais são especialmente perigosas em arquitetura de dados. Imagine mover um milhão de registros, e o processo informa que concluiu. Ótimo. Mas chegaram um milhão, ou 999.997, e quais três estão faltando? Talvez 200 mil tenham falhado, alguns tenham sido criados em duplicidade, ou tudo chegou e alguns campos falharam na transformação.
“Job concluído” não é a mesma coisa que os dados estão corretos. Um arquiteto de dados pensa em reconciliação: como sabemos o que deveria ter acontecido, o que realmente aconteceu, e a diferença? E o que fazemos a respeito?
Eis o que faço quando os sistemas ficam complexos. Os registros vão de A para B, da esquerda para a direita. Então B devolve algo: uma confirmação para cada registro que recebeu e salvou. Agora A pode comparar o que enviou com o que foi confirmado. Se todo registro tem sua confirmação, a execução teve sucesso. Se faltam confirmações, não teve, diga o que disser o status do job, e sabemos exatamente atrás de quais registros ir: tentar de novo, encaminhar para uma pessoa ou disparar um alerta.
Falhe com elegância
Seção intitulada “Falhe com elegância ”Quando a falha acontece, quero saber o que o sistema faz em seguida: se tenta de novo, automaticamente ou não; o que acontece se a mesma transação for processada duas vezes; para onde vão os registros que falharam, e se os registros bons continuam fluindo depois de um ruim; quem é alertado, com que informação, e como essa pessoa reprocessa a falha; e como um usuário fica sabendo que algo deu errado.
E, mais importante: conseguimos nos recuperar sem piorar o problema? Uma estratégia de nova tentativa que cria dados duplicados não é bem uma estratégia de recuperação. Boa arquitetura assume a falha e nos dá um caminho de volta.
Monitore o que importa
Seção intitulada “Monitore o que importa ”Planejar para a falha sem monitoramento não é planejar de verdade. Se uma integração falha às 2 da manhã e ninguém percebe até um cliente ligar três dias depois, não tínhamos uma arquitetura operacional. Tínhamos esperança.
Decida o que precisa ser observável: o processo rodou, quanto tempo levou, quantos registros foram processados, quantos tiveram sucesso e quantos falharam? Os volumes estão de repente diferentes do normal? O backlog está crescendo, os erros estão aumentando? A arquitetura não termina quando o deploy dá certo. Alguém precisa operar este sistema amanhã, e isso faz parte do design.
Pense nas três direções
Seção intitulada “Pense nas três direções ”Continue aplicando as três lentes no resto deste curso. Quando projetarmos um modelo de dados: ele funciona hoje, consegue crescer amanhã, e o que acontece quando os dados estão errados ou incompletos? Uma integração: ela move os dados de hoje, aguenta o volume e os sistemas de amanhã, e o que acontece quando um dos lados cai? Grandes volumes de dados: o que temos hoje, para onde os números estão indo, e como nos recuperamos quando uma grande operação dá certo só em parte?
A tecnologia muda de capítulo para capítulo. As perguntas não.
A arquitetura existe ao longo do tempo
Seção intitulada “A arquitetura existe ao longo do tempo ”Um desenvolvedor às vezes pode olhar para um requisito e perguntar: “Isso funciona?” O arquiteto precisa perguntar mais: funciona hoje, vai continuar funcionando amanhã, e o que acontece quando não funcionar de jeito nenhum? Essas três perguntas nos levam além da implementação, para a vida do sistema.
Você não vai prever todo requisito futuro nem evitar toda falha. Esse não é o objetivo. O objetivo é construir algo apropriado para o que sabemos hoje, deixar um caminho para amanhã e ter um plano para quando a realidade não colaborar.
Construa para hoje. Planeje para amanhã. Planeje para a falha. Vamos usar essas três lentes de novo e de novo.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Quais são os volumes e o crescimento reais, e quais números mudariam o design.
- Quais requisitos implícitos o negócio ainda não declarou.
- Como o design de hoje pode evoluir para o de amanhã, sem construir hoje o sistema de amanhã.
- O que acontece quando algo falha: recuperação, reconciliação e monitoramento.