What is *97 Things Every Software Architect Should Know* about?

*97 Things Every Software Architect Should Know* is a curated collection of actionable insights from over 40 leading software architects. Focused on non-technical challenges, it covers communication, stakeholder management, complexity reduction, and balancing business needs with technical decisions. Key themes include prioritizing simplicity, quantifying requirements, and fostering collaboration between developers and stakeholders.

Who should read *97 Things Every Software Architect Should Know*?

Aspiring and experienced software architects, senior developers transitioning to architectural roles, and technical leads will benefit most. The book is ideal for professionals seeking practical advice on managing cross-functional teams, aligning technical decisions with business goals, and avoiding common pitfalls in large-scale system design.

Is *97 Things Every Software Architect Should Know* worth reading?

Yes—it distills decades of real-world experience into concise, actionable essays. Unlike technical manuals, it emphasizes soft skills like leadership and communication, making it a unique resource for architects navigating organizational dynamics. Critics praise its focus on practical over theoretical solutions.

What are the key concepts in *97 Things Every Software Architect Should Know*?

- **Essential vs. Accidental Complexity**: Simplify core challenges while minimizing unnecessary technical debt. - **Quantify Requirements**: Replace vague terms like “scalable” with measurable criteria (e.g., “handle 10K users by Q3”). - **Communication as Leadership**: Clear, stakeholder-focused dialogue prevents misalignment. - **Failure Preparedness**: Design systems assuming components will fail.

How does *97 Things Every Software Architect Should Know* address performance optimization?

The book advocates embedding performance considerations early—e.g., defining response-time thresholds (like “≤1500ms under normal load”) during requirements gathering. It stresses iterative testing and aligning metrics with business outcomes rather than technical vanity.

What frameworks does *97 Things Every Software Architect Should Know* recommend?

- **Simplicity Before Generality**: Solve immediate needs before over-engineering for hypothetical futures. - **Interface-Centric Design**: Prioritize user experience, as “the interface *is* the system” for end-users. - **Technical Debt Management**: Regularly refactor to avoid compounding hidden costs.

How does *97 Things Every Software Architect Should Know* compare to *Clean Architecture*?

While *Clean Architecture* focuses on technical patterns, *97 Things* emphasizes human-centric challenges: stakeholder negotiation, team empowerment, and business alignment. Both stress modularity, but *97 Things* offers broader organizational strategies.

What criticism does *97 Things Every Software Architect Should Know* receive?

Some note its fragmented structure due to multiple contributors, which may lack depth on specific topics. However, this format provides diverse perspectives, making it a practical reference over a linear guide.

97 Coisas que Todo Arquiteto de Software Deve Saber book cover

Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Richard Monson-Haefel

3.62(779 Reviews)

Visão geral do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

O guia definitivo do arquiteto - 97 pílulas de sabedoria de lendas da indústria como Neal Ford e Michael Nygard. Enquanto a tecnologia evolui, esses princípios perduram, moldando as práticas de desenvolvimento modernas, do Agile ao Domain-Driven Design. Qual ponto cego arquitetural está custando caro para sua equipe agora?

Escolha como a história é contada

Explore o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber em diferentes estilos de aprendizagem

As mesmas ideias de 97 Coisas que Todo Arquiteto de Software Deve Saber. Escolha a voz, a profundidade e o ritmo ideais para você. Mude quando quiser.

Capítulo 1

O Verdadeiro Mandato do Arquiteto

Mais de dois terços dos projetos de software fracassam totalmente ou chegam à linha de chegada aos trancos e barrancos — atrasados, estourando o orçamento ou odiados pelas próprias pessoas que os encomendaram. Esse número vem de estudos citados por arquitetos que viveram esse caos de perto. E o mais surpreendente é onde a culpa quase nunca cai. Não é no banco de dados. Não é na linguagem de programação. A culpa é das decisões — aquelas tomadas por quem está bem no meio do caminho entre o negócio e o código. Essa pessoa é o arquiteto de software. E o conhecimento reunido nesta coletânea não vem de uma única voz, mas de dezenas delas: Michael Nygard, que escreveu o livro definitivo sobre sistemas em produção depois de ver tudo quanto é tipo de falha; Neal Ford, veterano da ThoughtWorks obcecado pela diferença entre uma dificuldade necessária e uma bagunça autoimposta; Mark Richards, que conta a história de um navio de guerra sueco que afundou por motivos que qualquer arquiteto vai reconhecer na hora; além de uma longa lista de profissionais que contribuíram, cada um, com uma lição valiosa aprendida na prática. Tudo isso foi reunido e editado por Richard Monson-Haefel. À primeira vista, parecem noventa e sete vozes diferentes gritando ao mesmo tempo. Mas, se você escutar com atenção, verá que elas se resumem a quatro grandes papéis que um arquiteto realmente desempenha: entender o que a empresa realmente precisa, dominar a complexidade sem criar mais confusão, liderar pessoas que não respondem diretamente a você e manter tudo funcionando quando o sistema vai para o ar e começa a falhar de jeitos imprevisíveis. Vamos começar exatamente de onde todo projeto começa. Não com um diagrama, mas com uma pergunta que ninguém fez com clareza suficiente.

Capítulo 2

Perguntar "Por Quê" Antes de Perguntar "Como"

Existe uma história da aviação militar que os arquitetos adoram recontar, e por um bom motivo. Harry Hillaker liderou a equipe de projeto do que viria a ser o caça F-16 Falcon. A exigência da Força Aérea era direta: construir um avião que voasse de Mach 2 a 2,5. Essa era uma meta de engenharia brutal. Afinal, a resistência do ar quadruplica quando você dobra a velocidade, e cada quilo a mais na estrutura para aguentar essa velocidade gera mais peso contra você. A equipe de Hillaker poderia ter simplesmente construído o avião mais rápido que a física permitisse e considerado o trabalho feito. Em vez disso, eles perguntaram por quê. Por que Mach 2 a 2,5? E a resposta que receberam não tinha nada a ver com velocidade máxima: era "para conseguir escapar do combate". Essa única frase mudou absolutamente tudo. A equipe não precisava de velocidade pura. Precisava de uma aeronave com uma alta relação empuxo-peso, algo que pudesse acelerar e manobrar rapidamente para sair do perigo. O resultado foi um avião mais leve, mais barato e muito melhor adaptado ao problema real do que a solicitação literal teria produzido. Einar Landre, que conta essa história, extrai daí uma lição que todo arquiteto deveria ter gravada em um lugar visível: os clientes entregam a você o palpite deles para uma solução e chamam isso de requisito. O seu trabalho é encontrar o valor real por trás desse palpite. Pergunte para que serve esse requisito. Não de forma agressiva, mas com curiosidade genuína, em reuniões onde o objetivo é entender o mundo do cliente, e não defender as suas próprias opiniões técnicas. No momento em que você começa a debater a implementação antes de entender a intenção, você já perdeu o fio da meada. Mas isso só funciona se você também desarmar as suas próprias motivações. Nitin Borwankar aponta essa armadilha sem rodeios: muitos arquitetos recomendam tecnologias simplesmente porque querem colocar essa habilidade no currículo, e não porque ela serve ao projeto. É um pecado fácil de cometer sem perceber — aquela vontade de usar o framework novo, o paradigma do momento, a tecnologia que vai garantir uma entrevista de emprego melhor no futuro. O ponto de Borwankar é desconfortavelmente direto: a sua carreira é construída por uma longa esteira de clientes que receberam a solução certa, e não por um portfólio de brinquedos brilhantes que você convenceu os outros a usar. Se um projeto não é empolgante o suficiente para as suas ambições, vá procurar outro — não deforme o projeto que está na sua frente só para inflar o seu currículo. Quando você finalmente descobre o que é necessário, o próximo desafio é provar isso em uma linguagem que o negócio consiga usar, e não com adjetivos que não dizem nada.

Veja cada palavra enquanto a ouve

Acompanhe a leitura sem esforço enquanto cada palavra do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber se destaca em tempo real.

Capítulo 3

Falando uma Linguagem que o Negócio Consiga Entender

Palavras como "rápido", "escalável" ou "flexível". Keith Braithwaite chama essas palavras pelo que elas realmente são: não são requisitos, são apenas desejos fantasiados de requisitos. Ninguém consegue construir um sistema "rápido", porque ninguém consegue saber quando essa meta foi atingida. A disciplina de Braithwaite é brutalmente simples: quantifique tudo. Quantos? Em qual período? Com que frequência? Com que rapidez? Se o negócio diz que o sistema precisa ser escalável, pergunte de onde virão os novos usuários e quando eles vão chegar. Rejeite respostas como "muitos" e "em breve". Um requisito real é assim: "O sistema deve responder em no máximo 1.500 milissegundos. Sob carga normal, o tempo médio de resposta deve ficar entre 750 e 1.250 milissegundos. Abaixo de 500 milissegundos, os usuários não percebem a diferença, então não vamos pagar para chegar até lá." Isso não é burocracia. Isso é a única coisa que vai permitir saber, mais tarde, se você teve sucesso ou não. Eben Hewitt usa uma imagem inesperada para descrever essa mesma disciplina: o consommé. É um caldo clarificado tantas vezes que um chef treinado consegue jogar uma moeda no fundo da tigela e ler a data gravada nela através do líquido. Os requisitos de software, reunidos de clientes e analistas, chegam turvos, cheios de suposições, generalidades e ressalvas. O método de Hewitt é coar esses requisitos como um chef coa um caldo: faça a mesma pergunta de formas diferentes até que as contradições apareçam. Teste cada afirmação adicionando mentalmente a frase "sempre, para sempre e em qualquer circunstância", e observe as pessoas se contorcendo para refinar a ideia. Você só termina quando conseguir ler a data através do que sobrou. E, mesmo depois de saber o que é necessário e conseguir definir isso com precisão, você ainda precisa sobreviver à conversa sobre quem vai pagar a conta. Como lembra Michael Nygard, isso é uma negociação, quer você encare dessa forma ou não. Ele descreve a emboscada clássica: o patrocinador do projeto pergunta "nós realmente precisamos de um segundo servidor?", com aquele tom de pai flagrando o filho gastando a mesada com gibi. O instinto do engenheiro é explicar, apresentar os prós e contras honestamente, cheio de ressalvas, até que o patrocinador deixa de prestar atenção logo após a palavra "bom...". A solução de Nygard é reconhecer que isso não é uma conversa de engenharia, é uma negociação. E a primeira regra de uma negociação é não ceder à demanda inicial. Você responde mostrando o custo real de ficar sem aquilo — por exemplo, que o sistema vai cair bem durante a reunião da diretoria — e depois, de forma deliberada, pede mais do que precisa, deixando margem para negociar até chegar ao que realmente necessita. Parece desconfortavelmente político para quem foi treinado para dizer apenas a verdade técnica sobre latência. Mas é exatamente assim que os orçamentos de infraestrutura sobrevivem ao contato com as pessoas que controlam o dinheiro. Saber o que construir e como defender o projeto não adianta nada se o que você constrói desmorona sob o peso da própria complexidade. E essa é uma disciplina completamente diferente.

Capítulo 4

Os Dois Tipos de Complexidade

Neal Ford faz uma distinção que todo arquiteto deveria ter em mente: a complexidade essencial é a dificuldade inerente ao próprio problema; já a complexidade acidental é o que construímos por cima para tentar gerenciar essa dificuldade, e que frequentemente piora as coisas. Coordenar o tráfego aéreo de um país é essencialmente complexo: aviões, altitude, velocidade, clima, tudo mudando em tempo real, sem atalhos. Mas os sistemas reais de controle de tráfego aéreo, construídos há décadas para domar essa complexidade, tornaram-se tão emaranhados que atualizá-los é quase impossível. A solução para a complexidade essencial virou o seu próprio monstro. O aviso de Ford se dirige a qualquer framework ou plataforma de fornecedor que prometa resolver o seu problema: verifique quanto do seu código lida com o problema real do negócio e quanto serve apenas para manter funcionando as costuras criadas pelo próprio framework. Ele nota que desenvolvedores são atraídos pela complexidade como mariposas pela luz, porque resolver quebra-cabeças difíceis é divertido. Mas se divertir não é o trabalho. Kevlin Henney leva esse mesmo instinto um passo adiante com uma regra que parece simples demais para ser útil: simplicidade antes de generalidade, uso antes de reuso. Bibliotecas de componentes e frameworks adoram ser projetados para qualquer caso futuro hipotético, e o resultado é um menu estonteante de opções que ninguém usa de verdade. O conselho de Henney é: quando dois projetos forem igualmente viáveis, escolha o mais simples, baseado em uma necessidade real e conhecida, e não o mais elaborado que promete lidar com cenários que ninguém pediu. Se mais tarde ficar provado que você realmente precisa de mais generalidade, é muito mais fácil expandir um design simples do que desfazer uma estrutura superdimensionada que acabou não sendo genérica do jeito certo. A verdadeira generalidade, segundo ele, vem de compreender profundamente os casos específicos reais, e não de adivinhar abstrações com antecedência. Então, como lidar com os momentos em que você realmente não sabe qual caminho seguir? É aí que entra a próxima disciplina, que começa com a recusa em decidir cedo demais.

Aproveite ainda mais o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Receba insights diários de mais de 100 mil lições
As palavras se destacam em sincronia com o áudio
Sua biblioteca salva em todos os dispositivos

Capítulo 5

A Disciplina de Não Decidir Ainda

Kevlin Henney traz aqui uma segunda visão ainda mais afiada, que inverte a forma como a maioria das pessoas pensa sobre decisões de arquitetura. Quando você fica preso entre duas opções, o instinto é simplesmente escolher uma e seguir em frente. Henney diz que a presença de duas opções viáveis é, na verdade, um sinal — uma prova de que existe uma incerteza sobre a qual vale a pena projetar o sistema ao redor, e não tentar atravessá-la à força. Ele pega emprestada a definição de arquitetura de Grady Booch: todo design de arquitetura é design, mas nem todo design é arquitetura; o que torna uma decisão arquitetônica é o quão caro seria mudá-la mais tarde. O melhor movimento, ao enfrentar uma encruzilhada real, muitas vezes é fazer uma pergunta totalmente diferente: não "opção A ou opção B?", mas "como posso construir isso para que a escolha entre A e B deixe de fazer tanta diferença?" Isso significa encontrar a divisão, a abstração, a fronteira que permite adiar o compromisso real até que você tenha conhecimento concreto em vez de palpites, mas não tão tarde a ponto de a informação chegar quando não houver mais utilidade. Mark Richards ilustra o custo de ignorar essa lição com uma história impressionante do século XVII. A Suécia, em guerra com a Polônia e querendo uma vantagem rápida e decisiva, encomendou um navio de guerra chamado Vasa: mais de duzentos pés de comprimento, sessenta e quatro canhões distribuídos em dois conveses e capacidade para transportar trezentos soldados. O rei queria um navio de combate e um transporte de tropas em um único casco, com um prazo apertado e orçamento curto. O arquiteto naval só tinha experiência com navios menores de convés único, mas extrapolou o que sabia e atendeu a todas as especificações que o rei exigiu. No dia do lançamento, o Vasa navegou orgulhosamente pelo porto, deu a sua salva de tiros e afundou na hora. Tentar satisfazer a todos os requisitos de uma vez produziu um navio estável o suficiente para não agradar a ninguém e seguro o suficiente para afundar no primeiro teste. A lição de Richards se aplica diretamente ao software: buscar alto desempenho, alta disponibilidade, alta segurança e alta abstração ao mesmo tempo produz o equivalente em código a um navio de guerra pesado demais no topo. Em algum momento, algo precisa ceder de forma deliberada e planejada, e não por acidente no dia do lançamento. Peter Gillard-Moss acrescenta o toque final de humildade a tudo isso: não importa o quanto você planeje antes da implementação, o resultado nunca vai ficar igual ao desenho original. A realidade se impõe — premissas erradas, requisitos que mudam, códigos estranhos de outras pessoas —, e aquele design elegante do início acaba cheio de remendos. A resposta dele não é planejar com menos cuidado, mas aceitar que o design é um processo de descoberta contínuo e empírico, e não um plano estático entregue de uma vez para ser defendido para sempre. Todo esse julgamento técnico não vale nada, no entanto, se as pessoas que realmente escrevem o código não confiarem em você. E isso é um problema de liderança, não de engenharia.

Capítulo 6

Fazendo-se Entender

Burk Hufnagel descreve uma reunião que quase todo arquiteto já vivenciou. O pessoal do negócio quer uma mudança "simples". Eles explicam em termos claros: mais fatia de mercado, vendas mais fáceis. O arquiteto e o programador imediatamente começam a murmurar entre si em "símbolos ocultos" e jargões incompreensíveis, vão até a lousa e desenham diagramas que deixam o lado do negócio perplexo e desconfiado — achando que o arquiteto é incompetente ou está enrolando. Ninguém na sala fala a língua do outro, e o resultado é a desconfiança disfarçada de atualização de status. A solução de Hufnagel parece óbvia demais para ser dita: aprenda a falar a língua do negócio com a mesma fluência com que fala a língua do programador, e traduza constantemente nos dois sentidos, até que a concordância substitua a suspeita. Mark Richards enquadra essa mesma habilidade de outra forma: a comunicação é a rainha, e a clareza e a liderança são suas servas. Ele é direto sobre o que destrói projetos de cima para baixo: arquitetos que ditam ordens de suas torres de marfim, entregam documentos de decisão de cem páginas que ninguém lê e depois se perguntam por que os desenvolvedores se revoltam. O remédio dele é quase antitecnológico: use quadros brancos, não documentos do Word. Tire uma foto do quadro antes de sair da sala e compartilhe a imagem, porque nada mata mais o ritmo do que ideias brilhantes presas em uma parede que outra pessoa vai apagar cinco minutos depois para uma reunião diferente. E há um conselho menor e mais curioso de Udi Dahan que é fácil de descartar até você testar: fique de pé. Se você estiver apresentando a sua recomendação para mais de uma pessoa, ficar de pé enquanto todos os outros estão sentados muda a forma como você é ouvido. Traz mais autoridade, mais contato visual, menos interrupções e uma voz que desacelera naturally nos pontos que realmente importam. Parece simples demais para fazer diferença de verdade. Mas o argumento de Dahan é que é exatamente simples assim, e que a maioria dos arquitetos deixa essa vantagem de lado apenas porque se sente desconfortável, e não porque ela não funciona. Assim que as pessoas começarem a ouvir você, a próxima pergunta é o que fazer com essa autoridade. E a resposta honesta é: o mínimo possível.

Veja cada palavra enquanto a ouve

Acompanhe a leitura sem esforço enquanto cada palavra do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber se destaca em tempo real.

Capítulo 7

Desapegando do Controle

Philip Nelson faz um argumento que vai contra todos os instintos que um arquiteto traz da época em que era desenvolvedor: dê autonomia para a sua equipe. A maioria dos arquitetos começou como desenvolvedor, e a tentação de continuar controlando como o código é escrito não desaparece só porque o cargo mudou. O teste de Nelson para saber se você está fazendo o trabalho direito é quase paradoxal: se você estiver fazendo uma boa arquitetura, não deveria ter tempo livre para ficar vigiando o trabalho de ninguém. Você estará ocupado demais observando os pontos de atrito em todo o sistema: as pessoas estão sofrendo para escrever testes? Arrume as interfaces. Elas estão usando de forma errada uma API que você projetou? Torne o design mais óbvio. Você guia pelas bordas, não pelo centro, e cria um ambiente onde as pessoas vêm até você com dúvidas, em vez de um ambiente onde você fica patrulhando em busca de erros. Dave Quick dá nome direto ao inimigo dessa atitude: o ego. Ele confessa ter caído em todas as armadilhas contra as quais alerta: achar que entendia os requisitos melhor do que os próprios clientes, tratar os desenvolvedores como meros executores de suas ideias e ficar na defensiva quando questionado. O seu antídoto é de uma simplicidade quase devocional: os requisitos não mentem, então deixe que eles guiem a arquitetura, e não as suas preferências pessoais; trate a equipe como a sua rede de segurança, e não como seus funcionários; e avalie o seu próprio comportamento diariamente: você deu respeito real às ideias das pessoas hoje ou só esperou que elas parassem de falar? Barry Hawkins chega à mesma conclusão usando termos diferentes: responsabilidade no lugar de exibicionismo. Um arquiteto entra em um projeto carregando um voto de confiança implícito, e a tentação é provar o seu valor deslumbrando a sala com genialidade técnica. O ponto de Hawkins é que o exibicionismo serve apenas ao ego do arquiteto, enquanto a responsabilidade — que é assumir silenciosamente a gestão dos recursos de outra pessoa e gastá-los com sabedoria — serve ao projeto. Ele escreve: "Você está jogando com o dinheiro dos outros." Cada escolha desnecessariamente complexa de framework é um saque de uma conta que não é sua. Timothy High conta uma história que torna concreta essa necessidade de humildade. Um amigo dele que gerenciava a tecnologia de uma startup de internet viu o desempenho do sistema desabar conforme a base de usuários crescia. O chefe perguntou o que poderia ser feito. "Comprar uma máquina maior", foi a resposta. "O que mais podemos fazer?", pressionou o chefe. "Até onde eu sei, só isso." Ele foi demitido na hora. E o veredito de High é que o chefe estava coberto de razão. Se você só consegue pensar em uma única solução para um problema, você não está resolvendo o problema, está apenas chutando. E um arquiteto que nunca comparou alternativas não tem como negociar trocas quando as prioridades do negócio inevitavelmente mudarem. Nada dessa liderança importa, porém, se o sistema que você construiu cair no momento em que receber o tráfego real de produção. É aí que começa o último pilar.

Capítulo 8

Projetando para a Falha que Você Não Pode Evitar

Michael Nygard começa com uma afirmação que parece derrotista até você entender onde ela vai dar: tudo vai falhar eventualmente. O hardware falha, então adicionamos redundância, o que aumenta a chance de haver pelo menos uma falha em qualquer momento dado. O software monitora falhas, mas o sistema de monitoramento também é um software e, portanto, também pode falhar. A automação elimina o erro humano, mas introduz o risco de uma máquina não responder a algo que só um ser humano perceberia. Cada mecanismo de segurança que você adiciona cria uma nova forma de falha. Nygard recorre a um fato histórico marcante para provar o ponto: o acidente nuclear de Three Mile Island foi provocado em grande parte por uma válvula de alívio de pressão — justamente um mecanismo de segurança projetado para evitar o tipo de falha que acabou causando. A resposta dele não é a paralisia, é a aceitação. Quando você para de fingir que a falha pode ser evitada, você ganha o poder de projetar onde ela vai acontecer. Engenheiros automotivos projetam zonas de deformação, partes feitas para amassarem primeiro, absorvendo o impacto para proteger os passageiros. Os arquitetos podem fazer o mesmo: projetar modos de falha deliberados que limitem o estrago, em vez de deixar tudo ao acaso. Nygard alerta: se você negar a inevitabilidade da falha, perderá todo o controle sobre como ela vai chegar. Em seguida, ele faz um alerta sobre os espaços em branco entre as caixas no seu diagrama de arquitetura — aquelas conexões ligadas por uma setinha de aparência inofensiva com o rótulo "XML sobre HTTP" ou "Processamento de pedidos". Em um caso real que ele descreve, essa simples setinha na verdade se desdobrava em mais de vinte etapas: gerenciadores de mensagens salvando em arquivos, tarefas periódicas de FTP coletando esses dados e servidores encadeados em duas empresas diferentes. O espaço em branco entre os programas está cheio de placas de rede, firewalls, filas de mensagens e até — em seu comentário irônico — barcos de pesca cortando cabos no fundo do oceano. Projetar o espaço em branco significa fazer as perguntas sem glamour que ninguém coloca no diagrama: o que acontece se o chamador fizer requisições demais? O que acontece se a resposta demorar muito — tenta de novo, espera ou assume que falhou e segue em frente? Se você pular essas perguntas, você não construiu uma interface: construiu uma ratoeira e ficou torcendo para ela não armar. Manter um sistema vivo diante desse tipo de incerteza exige mais do que um bom projeto de falhas: exige disciplina nos hábitos diários sem glamour de construção.

Aproveite ainda mais o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Receba insights diários de mais de 100 mil lições
As palavras se destacam em sincronia com o áudio
Sua biblioteca salva em todos os dispositivos

Capítulo 9

Os Hábitos Sem Glamour que Mantêm os Sistemas Vivos

Niclas Nilsson conta uma pequena história que ilustra um grande modo de falha. É fim de tarde, a equipe está em um ótimo ritmo e o João, atrasado para um encontro, termina o código, compila, envia para o repositório e vai embora sem rodar os testes. Minutos depois, a compilação quebra. Todos os outros que atualizam a sua cópia local agora herdam o código quebrado, exatamente no momento em que a equipe precisava integrar tudo para uma demonstração. Nilsson chama o ato de enviar o código e fugir de um crime, porque economiza alguns minutos de uma pessoa ao custo da tarde de todo o resto da equipe. A solução não é um e-mail de bronca, é tornar o comportamento correto o caminho mais fácil: testes rápidos rodando localmente sem acessar um banco de dados real, um servidor de integração contínua que pega o que passou batido e uma arquitetura que torna indolor testar antes de enviar. Dave Bartlett descreve a integração contínua como a morte da antiga compilação no estilo "Big Bang": compilações e testes frequentes e automatizados que encontram problemas de integração em horas, em vez de semanas. Dan Chak faz o mesmo argumento para uma camada totalmente diferente: o banco de dados. A cultura ágil fez ficar de moda projetar à medida que se avança, lançando cedo e iterando. Mas Chak insiste que o seu modelo de dados é o único lugar onde essa filosofia não funciona. Erros na aplicação são temporários e corrigíveis; dados corrompidos frequentemente são permanentes. Ele chama o banco de dados de uma fortaleza: ele deve rejeitar dados inadequados e impor relacionamentos lógicos, codificados em chaves e restrições que permanecem firmes não importa o quanto a camada de aplicação acima oscile. E Burk Hufnagel volta para falar de dinheiro em vez de linguagem, oferecendo a melhor metáfora para os atalhos que toda equipe acaba pegando sob a pressão dos prazos: o débito técnico. Entregue a solução rápida agora e você estará pegando emprestado contra o futuro. Os juros virão em forma de instabilidade e custos crescentes de manutenção, até que alguém volte lá e faça o trabalho direito. A sua disciplina é quase como usar um cartão de crédito com responsabilidade: pegue o atalho quando o negócio realmente precisar de velocidade, mas quite o saldo antes que os juros acumulem, agendando a correção real para a versão seguinte, e não para um "um dia a gente faz". Todos esses quatro pilares — a justificativa de negócio, a complexidade domada, a equipe capacitada e o sistema construído para sobreviver às próprias falhas — apontam para uma última e mais silenciosa verdade sobre o que é esse trabalho.

Capítulo 10

O Arquiteto Humilde

Michael Nygard encerra a sua contribuição com uma declaração fácil de passar despercebida em um livro cheio de conselhos técnicos: a arquitetura de software tem consequências éticas. Cada campo obrigatório, cada fluxo de trabalho mandatório é você impondo a sua vontade sobre estranhos, com menos flexibilidade do que a maioria das leis permite — não existe tribunal de recurso para um formulário que recusa envio sem um número de telefone que ninguém quer fornecer. Ele compara isso a pendurar uma placa a seis pés de altura na entrada de uma loja: é conveniente para você, mas custa a cada pedestre dois segundos desviando dela. Multiplique isso por todas as pessoas que algum dia usarem o que você construiu, e a conta dessa "pequena inconveniência" deixa de ser pequena. Bill de hÓra oferece a imagem de encerramento para toda essa disciplina: um ótimo software não é construído, ele é cultivado. Pegamos emprestada a palavra "arquiteto" de uma profissão obcecada por plantas e estruturas acabadas, mas o software que sobrevive é aquele que começou pequeno, rodando de ponta a ponta desde a primeira versão, e foi se adaptando conforme a equipe aprendia quais eram os requisitos reais. Ele destaca que o maior indicador isolado de falha é o tamanho — a tentação de projetar todo o grande sistema antecipadamente, em vez de criar a menor versão possível que consiga funcionar e deixá-la conquistar seu espaço até a visão final. E Barry Hawkins deixa mais um recado que vale a pena guardar: o título de arquiteto se escreve com a minúsculo. A arquitetura de software é jovem, ainda inventando seus próprios padrões e descobrindo o que ela realmente é. Isso não é motivo para menos rigor, é motivo para mais humildade. Os arquitetos que vale a pena ouvir nestas páginas não são aqueles que encontraram o framework perfeito ou o processo inquebrável. São aqueles que continuaram perguntando "por quê", mantiveram o design tão simples quanto o problema permitia, preservaram a confiança da equipe em vez do próprio conforto e projetaram para a falha que sabiam que viria, em vez de fingir que ela não aconteceria. Esse é o verdadeiro mandato: não se trata apenas de código, mas de julgamento, exercido vez após vez, em salas cheias de pessoas que estão confiando em você para fazer a coisa certa.

★★★★★

Você chegou ao fim do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

“Já se passaram 23 dias e usei o app todos os dias. Ele agora faz parte da minha rotina.”

jayallen

Temas principais do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

accidental complexity
technical leadership
stakeholder communication
architectural trade-offs
human-centric design

Melhores citações do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Simplicity before generality is a virtue.
The real foundation for success or failure is people.
When someone seems to be 'not doing it right,' it's conversation.
Accept that failures will happen and design your system's reaction.
Our duty as architects is to solve essential complexity.

Personagens do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Richard Monson-HaefelAuthor and compiler of the architectural wisdom

Sobre o Autor

Richard Monson-Haefel, autor de 97 Things Every Software Architect Should Know, é um renomado arquiteto de software e uma autoridade em best-sellers sobre desenvolvimento Java empresarial. Com mais de 26 anos de experiência, ele moldou padrões da indústria como cofundador do Apache Geronimo e OpenEJB, e atuou em grupos de especialistas do Java Community Process (JCP).

Seu livro destila insights práticos para arquitetos de software, refletindo sua profunda expertise em Java EE, JMS e web services — temas centrais em seus cinco títulos técnicos, incluindo Enterprise JavaBeans e Java Message Service (O’Reilly).

Ex-analista sênior do Burton Group (agora Gartner), Monson-Haefel combina experiência prática de desenvolvimento com análise estratégica. Ele é autor de cursos aclamados na Pluralsight sobre Jakarta EE e React Native, obtendo uma avaliação média de 4,4/5 de milhares de alunos.

Seu trabalho é recomendado por instituições como Apache e Oracle, e seus frameworks sustentam sistemas empresariais globalmente. 97 Things Every Software Architect Should Know tornou-se um recurso seminal, endossado por seus conselhos acionáveis e traduzido para vários idiomas.

A abordagem concisa e baseada em princípios do livro reflete a reputação de Monson-Haefel em transformar conceitos complexos em ferramentas acessíveis para desenvolvedores.

Baixar resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Obtenha o resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber como PDF ou EPUB gratuito. Imprima ou leia offline a qualquer momento.

Usuários também gostaram

97 things every software architect should know

Richard Monson-Haefel

Capa do livro Essential Skills That Make or Break Software Engineers

The 5 Most Important Software Engineering Skills - HackerRank Blog

6 sources

Essential Skills That Make or Break Software Engineers

Capa do livro O Programador Pragmático: Lições de Maestria

Becoming a Pragmatic Programmer: 101 Quick Key Takeaways from "The Pragmatic Programmer" 20th Anniversary Edition
| MikeTsamis.com

The Pragmatic Programmer - Book Summary - TheScrumMaster.co.uk

O Programador Pragmático - Resumo do Livro - TheScrumMaster.co.uk

5 conclusões essenciais de “The Pragmatic Programmer”

4 sources

O Programador Pragmático: Lições de Maestria

Capa do livro Software Architecture Demystified

A Philosophy of Software Design, 2nd Edition

12 sources

Software Architecture Demystified

Capa do livro The Architecture of High-Impact Communication

It's the Way You Say It: Becoming Articulate, Well-Spoken, and Clear | Pegasus Books

8 sources

The Architecture of High-Impact Communication

Software Architecture in Practice

Len Bass

Capa do livro Master Communication as a Developer

6 sources

Master Communication as a Developer

6 sources

Master Communication as a Developer

Perguntas frequentes sobre o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Descubra mais

PLANO DE APRENDIZADO

Architecting for Scale: The Interview Playbook

This playbook is essential for software engineers aiming for senior or staff-level roles at top-tier tech companies. It provides a structured methodology to tackle the high-pressure system design interview by focusing on data scalability and the art of the trade-off.

1 h 30 m•3 Seções

PLANO DE APRENDIZADO

The Architecture of Inner Strength

In an era of burnout and cynicism, professional success requires more than technical skills; it demands a resilient internal architecture. This plan is designed for leaders and professionals feeling stuck, helping them transform psychological friction into a disciplined foundation for growth.

1 h 30 m•3 Seções

PLANO DE APRENDIZADO

The Architect's Guide to Wisdom

This plan is designed for leaders and thinkers who need to maintain clarity and ethical integrity in high-pressure environments. By merging ancient philosophy with modern social analysis, it provides a comprehensive toolkit for anyone seeking to master their internal state and external influence.

2 h•4 Seções

PLANO DE APRENDIZADO

The Chief Architect’s Mission Playbook

This playbook is essential for senior technical leaders transitioning into strategic executive roles within the federal sector. It provides the framework needed to align complex architecture with CISA’s mission-critical cybersecurity priorities.

1 h 30 m•3 Seções

PLANO DE APRENDIZADO

Architecting Features for Scale

This plan is essential for developers moving beyond basic coding into high-level system design. It bridges the gap between feature ideation and scalable execution, making it ideal for engineers preparing for senior roles or high-traffic environments.

2 h•4 Seções

PLANO DE APRENDIZADO

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 Seções

PLANO DE APRENDIZADO

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 Seções

PLANO DE APRENDIZADO

How to build habits.

In an era of constant distraction, mastering behavior architecture is the ultimate competitive advantage. This plan is designed for professionals and individuals seeking to replace friction with flow by leveraging neuroscience and systematic design.

4 h 57 m•4 Seções

Criado por ex-alunos da Universidade de Columbia | em San Francisco

BeFreed Reúne Uma Comunidade Global De Mentes Curiosas

4.7

avaliação média

Mais de 7,84 mil avaliações do app

Comunidade BeFreed

Sério, eu ainda nem explorei o app por completo, mas só de usar nos últimos dias já fiquei impressionada… O BeFreed está em outro nível comparado a qualquer outro app de aprendizado que já usei. Ele prende demais a atenção e realmente melhora a concentração — ótimo para quem não larga o scroll!

@ladyInfinity

Comprei o BeFreed há exatamente 23 dias e uso todos os dias desde então. Ele se encaixou por completo na minha rotina de trabalho e nos meus hábitos de estudo.

@jayallen

A verdade é que o app superou todas as minhas expectativas. Posso pedir para gerar áudio sobre qualquer tema, seja qual for, e o resultado é impressionante. Minha área profissional é uma especialização em psicoterapia, bem multidisciplinar; mesmo assim, as respostas são muito precisas.

@Raguipa

O que eu mais valorizo é o quanto ele reduziu meu tempo de scroll: passo menos tempo procurando e mais tempo absorvendo informação. A combinação de audiolivros completos, podcasts e os planos de aprendizado é brilhante.

@colonyofcreatorsNGO

Sou instrutor de aprendizado acelerado PhotoReading há 24 anos… livros, leitura e aprendizado são a minha praia, e o BeFreed fez um ótimo trabalho ao trazer uma abordagem inovadora para entregar informação de um jeito fácil de consumir.

@BeFreed user

Não é só um app de resumo de livros: usei a opção de leitura divertida e é um resumo muito melhor, um jeito mais fácil de captar as ideias do que o tradicional. Só isso já vale o investimento.

@austinakon

Amo este app. Usei por vários dias e não consigo parar de ouvir. Um jeito ótimo de começar.

@jcrules328

Gosto muito do programa; já estou testando há cerca de um mês e sinto que é uma verdadeira joia. Funciona muito bem porque posso usar o BeFreed para criar meus próprios temas, e a voz é ótima, com opções ilimitadas de narração.

@DanielCZ

Sério, eu ainda nem explorei o app por completo, mas só de usar nos últimos dias já fiquei impressionada… O BeFreed está em outro nível comparado a qualquer outro app de aprendizado que já usei. Ele prende demais a atenção e realmente melhora a concentração — ótimo para quem não larga o scroll!

@ladyInfinity

Comprei o BeFreed há exatamente 23 dias e uso todos os dias desde então. Ele se encaixou por completo na minha rotina de trabalho e nos meus hábitos de estudo.

@jayallen

A verdade é que o app superou todas as minhas expectativas. Posso pedir para gerar áudio sobre qualquer tema, seja qual for, e o resultado é impressionante. Minha área profissional é uma especialização em psicoterapia, bem multidisciplinar; mesmo assim, as respostas são muito precisas.

@Raguipa

O que eu mais valorizo é o quanto ele reduziu meu tempo de scroll: passo menos tempo procurando e mais tempo absorvendo informação. A combinação de audiolivros completos, podcasts e os planos de aprendizado é brilhante.

@colonyofcreatorsNGO

Sou instrutor de aprendizado acelerado PhotoReading há 24 anos… livros, leitura e aprendizado são a minha praia, e o BeFreed fez um ótimo trabalho ao trazer uma abordagem inovadora para entregar informação de um jeito fácil de consumir.

@BeFreed user

Não é só um app de resumo de livros: usei a opção de leitura divertida e é um resumo muito melhor, um jeito mais fácil de captar as ideias do que o tradicional. Só isso já vale o investimento.

@austinakon

Amo este app. Usei por vários dias e não consigo parar de ouvir. Um jeito ótimo de começar.

@jcrules328

Gosto muito do programa; já estou testando há cerca de um mês e sinto que é uma verdadeira joia. Funciona muito bem porque posso usar o BeFreed para criar meus próprios temas, e a voz é ótima, com opções ilimitadas de narração.

@DanielCZ

Adoro poder receber informações e ideias úteis e condensadas em um áudio estilo podcast de 8 a 15 minutos. Não sou muito fã de podcasts por causa da enrolação, mas aqui vai direto ao ponto.

@BeFreed user

Estou terminando meu doutorado e preciso ler muito material desconhecido… Com o BeFreed, você só digita um prompt e o app encontra as fontes e gera um podcast em áudio. Acho o processo do BeFreed mais fluido que o do NotebookLM.

@Brad

Costumo procurar no YouTube algo para ouvir enquanto preparo o café da manhã, caminho ou me desloco, e o BeFreed oferece uma abordagem ainda mais certeira, sem anúncios e sem enrolação!

@BeFreed user

A melhor coisa desta plataforma é a versatilidade. Literalmente nenhum assunto fica de fora. Ela dá conta de tudo o que você mandar… É raro encontrar uma ferramenta de aprendizado sem limitações que realmente cumpre o que promete.

@jayallen

O BeFreed é fantástico. O design intuitivo faz com que eu passe menos tempo navegando e mais tempo aprendendo. A mistura de audiolivros, podcasts e planos de aprendizado é uma combinação genial que mudou completamente a minha rotina.

@BeFreed user

No começo, levei um tempo para entender como criar podcasts em italiano e… boom! É incrível! Posso pedir para explicar qualquer assunto e ele explica super bem, com muita inteligência!

@matteo77

O BeFreed virou meu app diário de audiolivros… O que eu mais gosto é que você coloca o seu texto e recebe um áudio para ouvir em qualquer lugar.

@kotanzu1

Adoro poder receber informações e ideias úteis e condensadas em um áudio estilo podcast de 8 a 15 minutos. Não sou muito fã de podcasts por causa da enrolação, mas aqui vai direto ao ponto.

@BeFreed user

Estou terminando meu doutorado e preciso ler muito material desconhecido… Com o BeFreed, você só digita um prompt e o app encontra as fontes e gera um podcast em áudio. Acho o processo do BeFreed mais fluido que o do NotebookLM.

@Brad

Costumo procurar no YouTube algo para ouvir enquanto preparo o café da manhã, caminho ou me desloco, e o BeFreed oferece uma abordagem ainda mais certeira, sem anúncios e sem enrolação!

@BeFreed user

A melhor coisa desta plataforma é a versatilidade. Literalmente nenhum assunto fica de fora. Ela dá conta de tudo o que você mandar… É raro encontrar uma ferramenta de aprendizado sem limitações que realmente cumpre o que promete.

@jayallen

O BeFreed é fantástico. O design intuitivo faz com que eu passe menos tempo navegando e mais tempo aprendendo. A mistura de audiolivros, podcasts e planos de aprendizado é uma combinação genial que mudou completamente a minha rotina.

@BeFreed user

No começo, levei um tempo para entender como criar podcasts em italiano e… boom! É incrível! Posso pedir para explicar qualquer assunto e ele explica super bem, com muita inteligência!

@matteo77

O BeFreed virou meu app diário de audiolivros… O que eu mais gosto é que você coloca o seu texto e recebe um áudio para ouvir em qualquer lugar.

@kotanzu1

Veja mais sobre como o BeFreed é discutido na web

Comece sua jornada de aprendizado, agora

Capítulo 3

Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Visão geral do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Explore o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber em diferentes estilos de aprendizagem

O Verdadeiro Mandato do Arquiteto

Perguntar "Por Quê" Antes de Perguntar "Como"

Veja cada palavra enquanto a ouve

Falando uma Linguagem que o Negócio Consiga Entender

Os Dois Tipos de Complexidade

Aproveite ainda mais o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

A Disciplina de Não Decidir Ainda

Fazendo-se Entender

Veja cada palavra enquanto a ouve

Desapegando do Controle

Projetando para a Falha que Você Não Pode Evitar

Aproveite ainda mais o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Os Hábitos Sem Glamour que Mantêm os Sistemas Vivos

O Arquiteto Humilde

Você chegou ao fim do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Temas principais do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Melhores citações do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Personagens do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Sobre o Autor

Baixar resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Usuários também gostaram

Perguntas frequentes sobre o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

What is 97 Things Every Software Architect Should Know about?

Who should read 97 Things Every Software Architect Should Know?

Is 97 Things Every Software Architect Should Know worth reading?

What are the key concepts in 97 Things Every Software Architect Should Know?

Descubra mais

BeFreed Reúne Uma Comunidade Global De Mentes Curiosas

Explore o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber em diferentes estilos de aprendizagem

O Verdadeiro Mandato do Arquiteto

Perguntar "Por Quê" Antes de Perguntar "Como"

Veja cada palavra enquanto a ouve

Falando uma Linguagem que o Negócio Consiga Entender

Os Dois Tipos de Complexidade

Aproveite ainda mais o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

A Disciplina de Não Decidir Ainda

Fazendo-se Entender

Veja cada palavra enquanto a ouve

Desapegando do Controle

Projetando para a Falha que Você Não Pode Evitar

Aproveite ainda mais o Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Os Hábitos Sem Glamour que Mantêm os Sistemas Vivos

O Arquiteto Humilde

Você chegou ao fim do Resumo de 97 Coisas que Todo Arquiteto de Software Deve Saber

Usuários também gostaram

Descubra mais