Arquitetura é a arte dos trade-offs

🌐 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)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 4 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: O Teste de Reversibilidade · Próximo: Construa para hoje. Planeje para amanhã. Planeje para a falha.

A pergunta que este módulo responde: Quando várias soluções poderiam funcionar, como um arquiteto escolhe, e como explica a escolha?

Se arquitetura fosse simplesmente identificar a resposta correta, seria muito mais fácil. Aprenda a plataforma, aprenda os padrões, aprenda os limites, escolha o certo, pronto.

Não é assim que a arquitetura real funciona. As decisões difíceis geralmente não são entre uma solução obviamente boa e uma obviamente ruim. São entre várias soluções que poderiam funcionar, cada uma com vantagens e desvantagens, cada uma levando a arquitetura numa direção um pouco diferente. É aí que o arquiteto conquista seu lugar à mesa.

Muitas formas de resolver o problema

Já usei uma versão deste exemplo muitas vezes ao ensinar arquitetos.

Pode haver muitas formas de resolver um problema no Salesforce. Às vezes eu dou um número, digamos dez, mas isso é uma analogia, não uma contagem. Muitas das opções têm problemas desde o início: esbarram numa restrição da plataforma, deixam de atender um requisito crítico ou criam um problema de segurança ou de desempenho que não podemos aceitar. Essas podemos descartar rápido. Algumas outras funcionam hoje, mas vão ter problemas quando os dados crescerem. Funcionam tecnicamente, mas não vão aguentar o crescimento que já sabemos que vem por aí.

O que sobra é um pequeno número de opções que conseguem atender às suas necessidades daqui para frente, e agora fica interessante. Cada uma delas pode funcionar, escalar e atender aos requisitos. Então qual é a correta? Talvez todas. O trabalho do arquiteto é entender as diferenças.

Até algo tão simples quanto uma lista de opções funciona hoje e pode ter problemas à medida que os dados crescem. Uma lista de opções é fácil para os usuários. Mas pergunte de onde vêm os valores, e quantos podem existir. Listas de opções funcionam melhor com menos de uns 20 valores. De vez em quando vamos até 50, como os estados dos EUA, e raramente passamos de 100, como os países, e esses ficam difíceis de manejar. Então, para cada lista de opções, conheça o limite superior. E mudar os valores de uma lista de opções é uma mudança de metadados, não de dados.

Use um relacionamento de pesquisa em vez disso, e a interface fica um pouco mais complexa. Mas a lista pode continuar crescendo sem limite superior, e novos valores podem chegar de uma integração. Isso é um trade-off contra a usabilidade. Esse é o equilíbrio.

Click to enlarge

Ideal não quer dizer perfeito

Uso a palavra ideal com cuidado. Uma arquitetura ideal não é aquela em que cada decisão individual é perfeita; essa arquitetura provavelmente não existe. É aquela em que a solução como um todo é equilibrada.

Suponha que a Solução A dê o melhor desempenho, mas seja cara e difícil de manter. A Solução B custa menos e é mais fácil de operar, mas abre mão de algum desempenho. A Solução C é mais flexível para o futuro, mas acrescenta complexidade hoje. Qual é a ideal? Não consigo responder só com esses fatos. Preciso conhecer o negócio, os requisitos e as prioridades, e quais restrições são reais e quais são preferências. Arquitetura depende de contexto. É por isso que o padrão certo para um cliente pode estar completamente errado para o próximo.

E o seu trabalho como arquiteto de dados é equilibrar essas decisões. Você vai tomar dezenas delas sozinho, ou com sua equipe. Saiba quais são, e saiba quando uma decisão tem impacto maior, em custo, prazo ou funcionalidade, e precisa subir para os principais tomadores de decisão.

Uma decisão abaixo do ideal pode fazer parte de uma arquitetura ideal

Esta é uma das ideias mais importantes deste capítulo. Às vezes eu tomo conscientemente uma decisão abaixo do ideal em uma parte da arquitetura porque ela melhora a solução como um todo.

Talvez eu duplique uma pequena quantidade de dados, porque eliminar a duplicação criaria uma complexidade de integração desnecessária. Talvez eu escolha um modelo de dados mais simples, porque o teoricamente mais limpo tornaria os relatórios e o uso diário muito mais difíceis. Talvez eu aceite um pequeno custo de desempenho, porque a alternativa acrescenta infraestrutura que a organização ainda não está pronta para operar.

Olhe para qualquer uma dessas isoladamente e você diria que não é ideal. Correto. Mas arquitetura não é otimizar cada componente sozinho; é otimizar o sistema. Uma decisão localmente abaixo do ideal pode fazer parte de uma arquitetura globalmente ideal, desde que entendamos o trade-off que estamos fazendo. O perigoso é fazer o trade-off sem saber que você o está fazendo.

Saiba do que você está abrindo mão

Sempre que alguém me diz “esta é a melhor solução”, minha próxima pergunta é “melhor em quê?” Mais rápida? Mais barata? Mais simples? Mais escalável, mais segura, mais flexível? Mais fácil de operar, mais rápida de entregar, menos dependente de habilidades especializadas? Quase sempre há outra dimensão em que a resposta não é “a melhor”. Esse é o trade-off. Quero saber o que estamos ganhando, e também quero saber do que estamos abrindo mão.

Pegue duas opções para um grande conjunto de dados corporativos. Uma copia os dados para o Salesforce, o que facilita usar os recursos nativos do Salesforce, mas agora somos responsáveis por movê-los, armazená-los, sincronizá-los, proteger mais uma cópia e lidar com latência. A outra deixa os dados onde estão e os acessa quando necessário. Eliminamos parte da duplicação, mas agora disponibilidade, desempenho de consultas, dependências de rede e as capacidades do sistema remoto importam mais. Nenhuma das descrições nos diz qual escolher. Elas nos dizem que perguntas fazer.

Nem todos os requisitos são iguais

Os trade-offs também nos obrigam a ver que nem todo requisito tem o mesmo peso.

Alguém diz: “Os dados precisam estar disponíveis instantaneamente.” Certo, o que significa instantaneamente? Um segundo, dez segundos, um minuto? E por quê? Talvez seja detecção de fraude, em que segundos importam. Talvez alguém só não goste de esperar a carga noturna. São requisitos muito diferentes, e o arquiteto continua perguntando até sabermos qual temos.

Gosto de requisitos que resistem a perguntas: quanto, quantos, quão rápido, com que frequência, para quem, e o que acontece se não fizermos? “Rápido” não é um requisito de arquitetura. “95% das atualizações de clientes precisam estar disponíveis para o agente de atendimento em até 30 segundos” está muito mais perto de um. Agora podemos avaliar trade-offs.

As restrições mudam a resposta

Às vezes a arquitetura não é restringida pela tecnologia. É restringida por dinheiro, pessoas, tempo, licenciamento ou maturidade organizacional.

Uma arquitetura tecnicamente excelente que exige uma equipe de operações que a empresa não tem não é uma boa arquitetura. Um recurso que resolve o problema com elegância mas exige um licenciamento que o cliente não vai comprar também não é a solução. E a transformação perfeita de três anos não ajuda uma empresa que precisa entrar no ar em oito semanas.

Nada disso significa abandonar a boa arquitetura por causa de um prazo. Significa entender o que estamos comprometendo, por quê, e quais consequências estamos aceitando, e, de preferência, como vamos sair do compromisso de hoje para a arquitetura de amanhã.

O arquiteto precisa de uma imagem do “ideal”

Aqui há uma tensão interessante. Estou dizendo que muitas vezes não existe uma resposta perfeita, e também quero que você carregue na cabeça uma imagem de como é uma solução ideal. Isso não é contraditório. Você precisa de um ponto de referência.

Quando olho para um modelo de dados, quero saber o que eu construiria se pudesse otimizar para os requisitos sem restrições desnecessárias. Então, quando restrições reais nos afastam desse design (achatamos parte do modelo, duplicamos alguns dados, adiamos uma integração, aceitamos um processo manual temporário), não estou fazendo concessões aleatórias. Sei em que direção estou me afastando do ideal, e por quê. Essa é a arte da arquitetura, e o instinto exige prática.

Desenhe

Uma das melhores formas de entender um trade-off é desenhá-lo. Diagramas de arquitetura não são enfeite para uma apresentação; são ferramentas de pensamento. Se estamos escolhendo entre duas abordagens, desenhe as duas. Onde os dados vivem, e para onde se movem? Quem é dono deles? Onde ficam as fronteiras, e onde a segurança é aplicada? O que acontece quando algo falha, e o que muda à medida que o volume cresce?

Um diagrama força a ambiguidade a aparecer, e dá a todos a mesma imagem para apontar.

Aprendi o quanto isso importa num projeto com uma empresa de serviços públicos. Reunião após reunião, eu me pegava explicando os mesmos conceitos de novo e trazendo a conversa de volta para o design original. Então mudei a forma de conduzir essas reuniões: toda revisão começava com o modelo de dados na tela. Não o detalhado, com cada campo. Um modelo resumido: uma conta tem contatos, este registro tem filhos, é aqui que o trabalho fica pendurado. A sala era formada principalmente por executivos, e levava uns dois minutos.

Como eram as mesmas pessoas reunião após reunião, o diagrama virou nossa linguagem comum. As pessoas começaram a usar os nomes dele. As perguntas repetidas sumiram, e as reuniões ficaram muito mais fáceis. Eu chamo isso de ancorar a reunião: um diagrama simples, mostrado toda vez, valeu muito mais do que custou para fazer.

O objetivo não é perfeição artística. Às vezes é um diagrama detalhado para engenheiros, às vezes cinco caixas e seis setas para um executivo. O objetivo é clareza.

Explique o trade-off

Um bom arquiteto expõe em ordem: estas são as opções que consideramos, isto é o que cada uma nos dá, isto é o que cada uma nos custa, esta é a opção que recomendo, e este é o porquê.

Repare que a recomendação vem depois dos trade-offs. Não quero que a arquitetura vire “eu já fiz isso antes, confie em mim”. A experiência importa enormemente; ela ajuda você a reconhecer padrões mais rápido e ver problemas mais cedo. Mas sua experiência deve melhorar seu raciocínio, não substituí-lo. Nosso trabalho não é só entender a arquitetura. É ajudar a organização a entender a decisão, especialmente quando quem dá a palavra final não é arquiteto.

Pense certo. Pense rápido.

Nem sempre você terá três semanas para analisar cada opção. Às vezes terá três minutos. Um requisito muda numa reunião, alguém cita uma restrição que você não conhecia, ou um executivo pergunta: “E se precisarmos disso na Europa ano que vem?”

Uso a frase Think Correct. Think Fast. (Pense certo. Pense rápido.) A velocidade não vem de pular o pensamento. Vem de ter pensado o suficiente antes de o momento chegar: você aprendeu os padrões, conhece a plataforma, já viu falhas, sabe que perguntas fazer e quais decisões são difíceis de reverter. É por isso que trabalhamos com cenários ao longo deste curso. Quanto mais decisões você analisa, mais rápido reconhece o formato da próxima.

Tive um cliente que precisava de preenchimento de formulários. Mas havia muitos formulários, e as perguntas podiam mudar com o tempo. Reconheci rapidamente a necessidade de um modelo de dados de pesquisa, um padrão ao qual voltaremos mais adiante no curso. Como reconheci o padrão e a solução, consegui trazer um modelo de dados mais completo, que atendia aos requisitos ainda por vir, não só aos que estavam à nossa frente.

Arquitetura é equilíbrio

À medida que nos aprofundamos em arquitetura de dados, você vai encontrar escolhas em que resisto a lhe dar uma regra simples. Normalizar ou achatar? Copiar os dados ou federá-los? Síncrono ou assíncrono? Objeto padrão ou personalizado? Arquivar ou manter online?

Existem princípios, padrões e limites, e às vezes respostas claramente erradas. Mas muitas vezes o trabalho do arquiteto é encontrar o equilíbrio certo para este sistema, este negócio e este momento.

Saiba como é o ideal. Entenda as restrições. Identifique as opções viáveis. Torne os trade-offs visíveis. Depois, tome a decisão.

Isso não é indecisão. Isso é arquitetura.

O que um arquiteto decide aqui

• Quais opções são viáveis, e quais estão erradas agora ou vão azedar em um ano.
• O que cada opção viável ganha e perde, medido contra requisitos que resistem a perguntas.
• Quais restrições são reais e quais são apenas preferências.
• Qual opção recomendar, depois de expor os trade-offs, e como explicá-la.