book

Facilitar a arquitetura de software

by Andrew Harmel-Law

April 2025

Intermediate to advanced

512 pages

17h 11m

Portuguese (Portugal, Brazil)

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Quem deve ler este livroPorque escrevi este livroComo navegar neste livroConvenções utilizadas neste livroMaterial suplementarAprendizagem em linha da O'ReillyComo contactar-nosAgradecimentos
Tanto a prática como o resultado final da arquitetura de software são essenciais para o sucessoQuais são as práticas da arquitetura tradicional?Torre de Marfim ArquitectosArquitectos práticosO que há de errado com as duas abordagens tradicionais?Cinco revoluções desbloquearam o poder do softwareOs efeitos das cinco revoluções na prática da arquiteturaA ascensão da descentralizaçãoA queda das práticas de arquitetura centralizadasO que deve proporcionar uma nova prática de arquitetura?Nenhuma abordagem pode proteger-te contra as forças do caosAs arquitecturas devem aceitar a incertezaAs arquitecturas devem permitir a emergênciaConclusão
As decisões são o núcleo da arquitetura de softwareO que é uma decisão de arquitetura?EstruturaCaraterísticas multifuncionaisDependênciasInterfacesTécnicas de construçãoAlguns exemplos de decisões de arquitetura e não arquitetônicasQuem toma estas decisões de arquitetura?Decisões de arquitetura significativaO que torna uma decisão de arquitetura "significativa"?O que não deve ser considerado em relação ao significado arquitetónico?Significado da arquitetura em relação ao software implementadoAlguns exemplos de decisões significativas de arquiteturaConclusão
Processos de decisãoFase 1: Decisão necessáriaFase 2: O ato de decidirFase 3: Decisão implementadaOnde se situa o equilíbrio de poderes nos processos de decisão?As abordagens tradicionais de arquitetura expõem insuficientemente as equipas à fase de tomada de opções do processo de decisãoProcessos de decisão à escalaAbordagens padrão para decisões em escalaProcessos de decisão num mundo revolucionadoConclusão
A necessidade de um processo de decisão mais rápido e descentralizadoO processo de aconselhamento em arquitetura: Uma regra, dois grupos de aconselhamento e um contratoO processo de aconselhamento em arquitetura é rápidoO processo de aconselhamento sobre arquitetura é descentralizadoO processo de aconselhamento em arquitetura dá origem a um contrato socialDois exemplos do processo de aconselhamento sobre arquitetura em açãoHistória 1: Uma equipa de desenvolvimento decide usar alternadores de lançamentoHistória 2: Um arquiteto decide resolver um problema de fluxo de trabalhoA centralidade do aconselhamentoAconselhamento é uma sugestão de direção mais raciocínioAconselhamento dá poder a quem faz opções e a quem toma decisõesDar conselhos não te torna responsável - tomar decisões simA importância das conversasO significado da confiançaConclusão
Primeiros passosSe já tens poder de decisãoSe atualmente não tens poder de decisãoIndependentemente do ponto de partida, começa pequenoSuperar os desafios da fase inicialExplicar o processo de aconselhamento sobre arquitetura a todas as pessoas envolvidasObtém conselhos das pessoas certasPergunta às pessoas certas e descobre "porquê?"Torna explícito quem é responsável por cada decisãoPreocupações de confiança decorrentes do processo de aconselhamento em matéria de arquiteturaFalta de confiança nas tuas capacidades de decisão e nas dos outrosFalta de confiança na procura e oferta de conselhosFalta de confiança em saber tudo o que está a acontecerConclusão
Introdução aos registos de decisões de arquiteturaA estrutura de um ADRTítuloMeta-elementosDecisãoContextoOpçõesConsequênciasAconselha-teElaborar um ADR para apoiar a decisãoPasso 1: Cria o teu ADR vazio e define os seus metadadosPasso 2: Escreve o contextoPasso 3: Faz opções e recolhe as suas consequênciasPasso 4: Propõe uma opção selecionadaUtilizar os ADR para facilitar o processo de aconselhamentoQuando e como procurar aconselhamentoConfigurar a secção de aconselhamentoRecolha de conselhosAtualizar o ADR para refletir os contributos dos outrosTomar a tua decisão e concluir o ADRSeleciona a opção de decisãoEscreve a tua secção de decisão e actualiza o teu títuloAltera o estado do ADR para AceitePartilha a decisãoO ciclo de vida dos ADRStatus das normas: Projeto, Proposta, Aceite e SubstituídaEstatutos ADR não normalizadosGestão de ADRsAspectos fundamentais da gestão de ADRsADRs em Wikis e ficheiros Rich Text no Controlo de FontesADRs em sistemas de registo de trabalhoCuradoria de ADRsConclusão

A responsabilidade e a obrigação de prestar contas mudaramAs práticas de governação mais tradicionais tornam-se obsoletasO processo de aconselhamento é compatível com as estruturas de arquitetura empresarial existentesA responsabilidade explícita dos ADR é um controlo para os imprudentesAs equipas não são obrigadas a decidirO espaço da prática de arquitetura abre-seManter o espaço para uma cultura de aprendizagem e confiançaDois exemplos de confiança (ou falta dela) em açãoNão podes partir do princípio de que vai surgir uma cultura de confiança e de aprendizagemUma cultura de confiança e aprendizagem deve ser cuidadosamente cultivadaCompreende a dinâmica de mudança em diferentes tamanhos de organizaçãoAdotar elementos de apoio para proteger o espaço de confiançaProteger o espaço da prática da arquiteturaNão existe uma receita padrão para os elementos de apoioTorna qualquer elemento de suporte teuVerifica a tua motivação antes de acrescentares algoNetflix: Um exemplo da mentalidade de encontrar o fluxoCuidado com os cantos de sereia da certeza e da previsibilidadeExperimenta para encontrar o fluxo da tua organizaçãoConclusão
Apresentamos o Fórum de Aconselhamento sobre ArquiteturaUma agenda simples e permanenteComo é que um Fórum de Aconselhamento difere das reuniões de arquitetura tradicionaisGerir um fórum de aconselhamento sobre arquiteturaAntes de um Fórum de Aconselhamento sobre ArquiteturaPartilhar a agendaAbertura de uma sessão do Fórum de Aconselhamento sobre ArquiteturaIntroduzir um ADROferecer e receber conselhosRegistar os conselhosDinâmicas sociais no Fórum de AconselhamentoAs interações arquitectónicas são adversárias e hierárquicas por defeitoArgumentação coalescente: Uma Alternativa à Argumentação AdversarialO processo de aconselhamento sobre arquitetura e os ADR como abordagem coalescente para a tomada de decisõesOs fóruns de aconselhamento catalisam dinâmicas de grupo poderosasA experiência para quem oferece aconselhamentoA experiência para quem procura aconselhamentoA experiência dos observadores de aprendizagemParticipação partilhada na criatividade concretaOs fóruns de aconselhamento sobre arquitetura promovem a integridade concetual e a coesão socialDescentralizar a execução e centralizar a coordenaçãoConhecimento profundo do domínio: Quando a centralização funciona melhorTransparência para a coesão social e a confiançaO Ritual de Fortalecimento da CadênciaIniciar o processo de aconselhamento com um fórum de aconselhamentoTermos de referênciaSe estás a utilizar o Fórum de Aconselhamento para dar início ao processo de aconselhamentoQuem convoca o Primeiro Fórum de Aconselhamento?Como é que o primeiro Fórum de Aconselhamento será diferente dos seguintesConclusão
A importância do alinhamento organizacionalO alinhamento não garante a eficáciaDetetar um alinhamento organizacional insuficienteQuatro meios de alinhamentoEstás alinhado quando não te surpreendesAcordo mínimo viávelRequisitos multifuncionaisEstratégia tecnológicaTrabalhar para o acordo mínimo viável da tua organizaçãoConclusão
Princípios arquitectónicos de origem de todos os envolvidosExemplos de princípios arquitectónicosCaraterísticas dos bons princípios arquitectónicosCaraterísticas dos maus princípios arquitectónicosOs princípios podem ser requisitos multifuncionais disfarçadosOs princípios arquitectónicos complementam um processo de aconselhamento e os ADRCapturar os teus princípios arquitectónicos com um workshop de princípiosPreparar os inputs para o teu Workshop de PrincípiosWorkshop sobre a definição dos teus princípiosWorkshop "Gerir os teus princípiosApresentar os teus princípios prontos a serem utilizadosManter os princípios úteisO feedback das decisões de arquitetura deve afetar os princípios de arquiteturaAtualização e atualização de princípiosO feedback das decisões pode afetar a estratégia técnicaConclusão
Tendências tecnológicas do Sense e diretrizes de captaçãoOs radares tecnológicos recolhem e partilham continuamente orientaçõesComo funciona o Radar Tecnológico da ThoughtworksO teu radar tecnológico interno será estruturado de forma diferenteO lugar do teu radar num processo de aconselhamentoCriar o teu radar tecnológicoRecolha de BlipsOrdenação e validação de blipsFocalização de BlipPosicionamento do BlipDocumentação BlipRadar PublishingAtualizar os teus BlipsRevisões periódicasActualizações ad hoc baseadas na experiência partilhadaCapturar Blips anteriores e o seu históricoConclusão
A importância do lado mais suaveEnquadrar o contextoA exclusão é tão importante como a inclusãoPerguntas para melhorar o teu julgamento sobre o enquadramentoEnvolve as partes interessadas certasDiscernir as opções e as suas consequênciasNão deixes que a moldura limite a tua criatividadeProcura inspiraçãoAperfeiçoa o contexto e as opções com conselhosDesenvolve a tua metacogniçãoExercício 1: Partilha as tuas razõesExercício 2: Estás a reagir ou a responder?Exercício 3: Procura intencionalmente conselhos que te desafiemLidar com pessoas que não cooperamSeleção de uma opção de decisãoSuperar o medoUltrapassar preconceitosTomar a decisãoQuando estás a tomar a decisãoQuando outros estão a tomar a decisãoConclusão
O efeito da variabilidade na prática da arquiteturaA variabilidade torna difícil o desenvolvimento de sistemasA variabilidade é a força vital do desenvolvimento de softwareTrabalhar eficazmente com a variabilidade arquitetónicaLuta contra a variabilidade tomando e testando decisões rapidamenteTesta profundamente as decisões utilizando o seu contexto funcionalUsa esqueletos ambulantes para testar as tuas decisões mais antigas no seu contexto funcionalLuta contra a variabilidade com decisões mais pequenasO impacto das decisões de arquitetura no fluxo futuroUma boa infraestrutura técnica permite pequenas decisõesUma boa infraestrutura sociotécnica permite também pequenas decisõesUtiliza o processo de aconselhamento para separar as decisões do fluxoUtilizar a variabilidade para combater o risco e descobrir valorRápido e errado é melhor do que lento e corretoObserva os anómalosSequencia as decisões mais valiosas primeiroConclusão
Encontrar um caminho através da variabilidadeApresentando os SpikesOs spikes podem resolver a variabilidade arquitetónica de forma mais económicaOnde se situam os picos num processo de decisão?Aumento das ADRsOs ADRs em alta ainda seguem o processo de aconselhamentoExamina a interconexão das decisõesAs decisões são uma sérieAs decisões são uma hierarquia invertidaAs decisões são atómicasAs decisões são conversas de dois sentidosAs decisões inter-relacionadas são socialmente complicadasConclusão
As transições de poder nunca são simplesA transição para aqueles que ganham o poderSerá que todos acreditam que têm o poder de decidir?Todos compreendem as suas responsabilidades?Porque é que as pessoas não estão a usar o poder que têm à sua disposição?A importância da segurançaA transição para aqueles que têm de partilhar o seu poderO medo dos que deram o poderO comportamento daqueles que não gostam do facto de o poder ter sido partilhadoAs transições são incómodasConclusão
Conceitos errados sobre liderançaEquívoco 1: A liderança é inataEquívoco 2: A liderança está ligada à hierarquiaIdeia errada 3: A liderança é unidirecionalEquívoco 4: Liderança é gestãoO que é a liderança14 pontos de DemingLiderança ServidoraLiderança adaptativaLiderança Líder-LíderDesafios da transição para a liderança líder-líderA necessidade de uma liderança moral permanenteResponder aos desafios moraisSê sensível a todas as tuas culturas actuais, mas não as ignoresNão existem "líderes permanentes"Conclusão
A subcultura da engenharia de softwareRazão 1: O desenvolvimento de software não segue os modelos mentais padrão para a criaçãoRazão 2: As taxas de mudança nos departamentos de TI são muito maiores do que em qualquer outro lugarRazão 3: Os pontos de contacto entre a Engenharia de Software e o resto da organização são poucos e distintosRazão 4: A divisão cultural entre a engenharia de software e o resto da organização já foi aceiteConselhos Processo BolhasAs bolhas só são evidentes para quem as procuraAs bolhas auto-organizam-seAs bolhas são permeáveisExpectativas externas sobre os que estão dentro da bolhaExpectativas evidentesExpectativas menos evidentesAs bolhas apresentam uma interface independente da implementaçãoO contrato de interface da bolhaTorna explícito o valioso trabalho de traduçãoBolhas em crescimentoCrescimento incremental, equipa por equipaAssegura-te de que proteges os principais objetivos da tua prática de arquiteturaDividir as bolhas quando se tornam demasiado grandesNada pode crescer para sempreDividir uma bolha quando os objectivos centrais da tua prática de arquitetura são ameaçadosComo dividir a tua bolhaMantendo-se alinhado entre as bolhasProtege e incentiva as diferenças entre as bolhasConclusão

Content preview from Facilitar a arquitetura de software

Capítulo 9. CFRs testáveis e estratégia tecnológica

Este trabalho foi traduzido com recurso a IA. Agradecemos o teu feedback e comentários: translation-feedback@oreilly.com

Este capítulo começará por ponderar a importância do alinhamento com a visão e os objetivos da tua organização. Considera como isso pode ser alcançado num mundo descentralizado, revolucionado e centrado no feedback, com restrições mínimas no espaço de decisão - restrições que precisam de ser compreendidas e acordadas por todos. Para atingir este objetivo geral de alinhamento, precisas de um nível mínimo viável de acordo, abrangendo tanto o que precisas como a forma como pretendes que os teus sistemas trabalhem em conjunto de forma eficaz.

Com isso definido, vais aprender sobre um elemento de suporte em duas partes. A primeira parte é muito específica (mas não muito diretiva) sobre o "quê" na forma de requisitos multifuncionais testáveis (CFRs). Na verdade, como esta não é a primeira vez que os CFRs aparecem neste livro, vou passar um bom tempo falando sobre eles.

A segunda parte complementa isto, sendo diretiva (mas não muito específica) sobre o "como" sob a forma de estratégia tecnológica. Ao contrário dos CFRs, não vou entrar em pormenores sobre como criar uma estratégia, uma vez que isso está fora do âmbito deste livro. No entanto, dar-te-ei os meios para garantir que qualquer estratégia que tenhas é adequada e suficiente.