Arquitetura é a arte dos trade-offs

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

A pergunta que este módulo responde: Quando várias soluções poderiam funcionar, como é que 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 má. São entre várias soluções que poderiam funcionar, cada uma com vantagens e desvantagens, cada uma a levar a arquitetura numa direção um pouco diferente. É aí que o arquiteto conquista o 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 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, falham um requisito crítico ou criam um problema de segurança ou de desempenho que não podemos aceitar. Essas podemos descartar depressa. 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 aí vem.

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

Até algo tão simples como 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 utilizadores. Mas pergunte de onde vêm os valores, e quantos podem existir. As 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 gerir. Por isso, 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 antes uma relação de pesquisa, e a interface fica um pouco mais complexa. Mas a lista pode continuar a crescer sem limite superior, e podem chegar novos valores 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 é cara e difícil de manter. A Solução B custa menos e é mais fácil de operar, mas abdica 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 estes factos. Preciso de conhecer o negócio, os requisitos e as prioridades, e que restrições são reais e quais são preferências. A arquitetura depende do contexto. É por isso que o padrão certo para um cliente pode estar completamente errado para o seguinte.

E o seu trabalho como arquiteto de dados é equilibrar estas decisões. Vai tomar dezenas delas sozinho, ou com a sua equipa. Saiba quais são, e saiba quando uma decisão tem um impacto maior, em custo, prazo ou funcionalidade, e precisa de subir aos principais decisores.

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

Esta é uma das ideias mais importantes deste capítulo. Às vezes tomo conscientemente uma decisão abaixo do ideal numa 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 destas isoladamente e 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 a fazer. O perigoso é fazer o trade-off sem saber que o está a fazer.

Saiba de que está a abdicar

Sempre que alguém me diz «esta é a melhor solução», a minha pergunta seguinte é «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 competências especializadas? Quase sempre há outra dimensão em que a resposta não é «a melhor». Esse é o trade-off. Quero saber o que estamos a ganhar, e também quero saber de que estamos a abdicar.

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

Nem todos os requisitos são iguais

Os trade-offs também nos obrigam a ver que nem todos os requisitos têm o mesmo peso.

Alguém diz: «Os dados precisam de estar disponíveis instantaneamente.» Certo, o que significa instantaneamente? Um segundo, dez segundos, um minuto? E porquê? Talvez seja deteção de fraude, em que os segundos importam. Talvez alguém simplesmente não goste de esperar pela carga noturna. São requisitos muito diferentes, e o arquiteto continua a perguntar 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 o fizermos? «Rápido» não é um requisito de arquitetura. «95% das atualizações de clientes precisam de 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 equipa de operações que a empresa não tem não é uma boa arquitetura. Uma funcionalidade 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 de entrar em produção dentro de oito semanas.

Nada disto significa abandonar a boa arquitetura por causa de um prazo. Significa entender o que estamos a comprometer, porquê, e que consequências estamos a aceitar, e, de preferência, como vamos passar do compromisso de hoje para a arquitetura de amanhã.

O arquiteto precisa de uma imagem do «ideal»

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

Quando olho para um modelo de dados, quero saber o que construiria se pudesse otimizar para os requisitos sem restrições desnecessárias. Assim, 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 a fazer cedências ao acaso. Sei em que direção me estou a afastar do ideal, e porquê. Essa é a arte da arquitetura, e o instinto exige prática.

Desenhe

Uma das melhores formas de entender um trade-off é desenhá-lo. Os diagramas de arquitetura não são enfeites para uma apresentação; são ferramentas de pensamento. Se estamos a escolher entre duas abordagens, desenhe as duas. Onde vivem os dados, e para onde se movem? Quem é dono deles? Onde ficam as fronteiras, e onde é aplicada a segurança? 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 isto importa num projeto com uma empresa de serviços públicos. Reunião após reunião, dava por mim a explicar os mesmos conceitos outra vez e a trazer a conversa de volta ao design original. Então mudei a forma de conduzir essas reuniões: cada revisão começava com o modelo de dados no ecrã. Não o detalhado, com cada campo. Um modelo resumido: uma conta tem contactos, este registo tem filhos, é aqui que o trabalho fica pendurado. A sala era formada sobretudo por executivos, e levava uns dois minutos.

Como eram as mesmas pessoas reunião após reunião, o diagrama tornou-se a nossa linguagem comum. As pessoas começaram a usar os nomes dele. As perguntas repetidas desapareceram, e as reuniões ficaram muito mais fáceis. Chamo a isto ancorar a reunião: um diagrama simples, mostrado sempre, valeu muito mais do que custou a 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 se torne «eu já fiz isto antes, confie em mim». A experiência importa enormemente; ajuda a reconhecer padrões mais depressa e a ver problemas mais cedo. Mas a sua experiência deve melhorar o seu raciocínio, não substituí-lo. O nosso trabalho não é só entender a arquitetura. É ajudar a organização a entender a decisão, especialmente quando quem tem a última palavra não é arquiteto.

Pense certo. Pense rápido.

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

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

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 inquérito, 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 respondia aos requisitos ainda por vir, não só aos que tínhamos à frente.

Arquitetura é equilíbrio

À medida que nos aprofundamos em arquitetura de dados, vai encontrar escolhas em que resisto a dar-lhe 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.

Isto não é indecisão. Isto é arquitetura.

O que um arquiteto decide aqui

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