Construa para hoje. Planeie para amanhã. Planeie para a falha.

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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)

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

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 sustenta-se sozinho. Anterior: Arquitetura é a arte dos trade-offs · Próximo: Conheça as suas ferramentas: as nove perguntas

A pergunta que este módulo responde: Como projetar para os requisitos de hoje enquanto se planeia para o crescimento e para a falha?

Um dos erros mais fáceis em arquitetura é projetar apenas para os requisitos que temos à frente. Temos um projeto, um backlog e requisitos. Construímos algo que os cumpre. 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 de se integrar, ou algo falha sem que ninguém o tenha planeado.

Nada disto 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 para a arquitetura através de três lentes:

Construa para hoje. Planeie para amanhã. Planeie para a falha.

Precisa das três.

Click to enlarge

Construa para hoje

A arquitetura começa com o problema que realmente temos. Parece óbvio, mas os arquitetos podem cometer o erro oposto ao pensamento de curto prazo: podemos sobrearquitetar. E se adquirirmos doze empresas, tivermos mil milhões de clientes, expandirmos para 40 países e cada sistema precisar de integração em tempo real? Talvez. Mas são possibilidades reais, ou estamos a inventar problemas? Arquitetura não é construir o sistema mais sofisticado que conseguimos imaginar. É construir o apropriado.

Por isso, comece por hoje: o que o negócio precisa, os volumes, utilizadores e transações reais, com que frequência os dados mudam e quão depressa precisam de se mover, quem precisa de acesso, e de onde vêm os dados e para onde vão. E, mais importante: porquê? Essas respostas dão-nos algo concreto para projetar.

Procure os requisitos implícitos

Os requisitos que lhe passam não são necessariamente todos os requisitos que tem. Quase sempre há requisitos implícitos.

O negócio diz: «Precisamos dos dados de clientes no Salesforce.» Certo. Então alguém precisa de ser dono desses dados e de decidir quão atualizados têm de estar. Precisamos de saber o que acontece quando o sistema de origem vai abaixo, como vamos perceber quando a sincronização falha, e que lado ganha 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 maus.

Nada disto estava na user story. Tudo isto continua a ser arquitetura. Uma grande parte de se tornar arquiteto é aprender a reconhecer as perguntas que ainda não foram feitas.

Conheça os seus números

Estou sempre a pressionar os arquitetos para quantificarem. Não me diga que há muitos dados; diga quantos. Dez mil, dez milhões, cem milhões, mil milhões? São arquiteturas muito diferentes. Não me diga que a integração corre com frequência: de hora a hora, de minuto a minuto, mil vezes por segundo? Não me diga que estamos a crescer depressa. Quão depressa?

Quando não tenho um número melhor, a 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 registos hoje, não quero que a discussão pare nos 10 milhões. A 30% ao ano, estaremos em uns 13 milhões no próximo ano, 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: dê-me o número real. A questão é tornar o crescimento parte da discussão de arquitetura.

Chamo a isto o Número de Zeros do Steve (Steve’s Number of Zeros). Um zero a mais pode mudar completamente a sua arquitetura. Dez mil, cem mil, um milhão, dez milhões, cem milhões: a funcionalidade não mudou, e o requisito talvez não tenha mudado, mas a arquitetura pode ter mudado.

Lembra-se das marcações do módulo 1? Vamos pôr-lhes os números reais. Mais de 1.200 locais, 100 marcações por local por dia, seis dias por semana, cerca de 305 dias por ano. São mais de 36 milhões de marcações no primeiro ano. Cada visita cria dois registos, portanto mais de 73 milhões de registos. Agora guarde cinco anos de histórico, a crescer 30% ao ano, e são mais de 650 milhões de registos. A mesma funcionalidade, o mesmo requisito. Uns zeros a mais, e uma arquitetura muito diferente.

Planeie para amanhã

Depois de entender o hoje, olho para a frente: o que é provável que mude? O 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 a consumir informação que foi projetada só para humanos.

É por isso que me importa tanto saber se a arquitetura consegue crescer por adição em vez de mudanças constantes. Se o negócio acrescenta um produto, o modelo comporta-o? 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 a tentar prever o futuro com perfeição. Estamos a tentar não ficar encurralados.

Não construa o amanhã hoje

Há um equilíbrio aqui. Planear para amanhã não significa construir hoje o sistema de amanhã. Se temos 100 mil registos e talvez tenhamos 100 milhões dentro de cinco anos, isso não significa construir já a arquitetura para 100 milhões de registos. Ela pode trazer custo e complexidade de que ainda não precisamos.

A pergunta a que quero resposta é: a arquitetura de hoje consegue evoluir para a de amanhã? Se podemos começar de forma simples com um caminho claro pela frente, isso muitas vezes é melhor do que pagar o custo da complexidade anos antes. O perigo não é começar pequeno. O perigo é começar num sítio sem ter para onde ir.

Planeie para a falha

Agora a parte de que ninguém gosta de falar: as coisas falham. Nunca projetei um sistema em que todos os componentes ficassem disponíveis para sempre, todas as integrações tivessem sucesso, todos os utilizadores introduzissem dados perfeitos e todos os sistemas externos se comportassem exatamente como documentado. Por isso, não projete esse sistema.

Pergunte o que pode falhar, depois pergunte o que acontece quando falhar. Uma integração esgota o tempo limite. Uma API rejeita um pedido. Uma carga noturna processa 800 mil registos e falha em 200 mil. Um sistema de origem vai abaixo. Um utilizador introduz dados inválidos. Um identificador externo aparece duas vezes. Um sistema a montante muda o formato de um valor sem mudar o nome do campo. Um processo tem sucesso num sistema e falha noutro. Estes não são casos extremos invulgares. É assim que a produção é.

Um sucesso parcial continua a ser uma falha que precisa de entender

As falhas parciais são especialmente perigosas em arquitetura de dados. Imagine mover um milhão de registos, e o processo informa que terminou. Ótimo. Mas chegaram um milhão, ou 999.997, e quais são os três que faltam? Talvez 200 mil tenham falhado, alguns tenham sido criados em duplicado, ou tudo chegou e alguns campos falharam na transformação.

«Job concluído» não é o mesmo 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 quanto a isso?

Eis o que faço quando os sistemas ficam complexos. Os registos vão de A para B, da esquerda para a direita. Depois B devolve algo: uma confirmação para cada registo que recebeu e guardou. Agora A pode comparar o que enviou com o que foi confirmado. Se cada registo tem a sua confirmação, a execução teve sucesso. Se faltam confirmações, não teve, diga o que disser o estado do job, e sabemos exatamente que registos ir buscar: tentar de novo, encaminhar para uma pessoa ou disparar um alerta.

Click to enlarge

Falhe com elegância

Quando a falha acontece, quero saber o que o sistema faz a seguir: 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 registos que falharam, e se os registos bons continuam a fluir depois de um mau; quem é alertado, com que informação, e como essa pessoa volta a processar a falha; e como um utilizador fica a saber que algo correu mal.

E, mais importante: conseguimos recuperar sem piorar o problema? Uma estratégia de nova tentativa que cria dados duplicados não é bem uma estratégia de recuperação. Uma boa arquitetura assume a falha e dá-nos um caminho de volta.

Monitore o que importa

Planear para a falha sem monitorização não é planear a sério. Se uma integração falha às 2 da manhã e ninguém dá por isso até um cliente telefonar três dias depois, não tínhamos uma arquitetura operacional. Tínhamos esperança.

Decida o que precisa de ser observável: o processo correu, quanto tempo levou, quantos registos foram processados, quantos tiveram sucesso e quantos falharam? Os volumes estão de repente diferentes do normal? O backlog está a crescer, os erros estão a aumentar? A arquitetura não termina quando o deploy corre bem. Alguém precisa de operar este sistema amanhã, e isso faz parte do design.

Pense nas três direções

Continue a aplicar as três lentes no resto deste curso. Quando projetarmos um modelo de dados: funciona hoje, consegue crescer amanhã, e o que acontece quando os dados estão errados ou incompletos? Uma integração: move os dados de hoje, aguenta o volume e os sistemas de amanhã, e o que acontece quando um dos lados vai abaixo? Grandes volumes de dados: o que temos hoje, para onde vão os números, e como recuperamos quando uma grande operação só corre bem em parte?

A tecnologia muda de capítulo para capítulo. As perguntas não.

A arquitetura existe ao longo do tempo

Um programador às vezes pode olhar para um requisito e perguntar: «Isto funciona?» O arquiteto precisa de perguntar mais: funciona hoje, vai continuar a funcionar amanhã, e o que acontece quando não funcionar de todo? Estas três perguntas levam-nos para além da implementação, para a vida do sistema.

Não vai prever todos os requisitos futuros nem evitar todas as falhas. 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. Planeie para amanhã. Planeie para a falha. Vamos usar estas três lentes uma e outra vez.

O que um arquiteto decide aqui

• Quais são os volumes e o crescimento reais, e que números mudariam o design.
• Que 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 monitorização.