Introdução
Uma arquitetura de software não deve começar pela escolha de uma linguagem, framework, banco de dados ou serviço de nuvem.
Antes de definir como uma solução será construída, é necessário compreender:
- O que a empresa faz?
- Como ela gera valor?
- Quais processos não podem parar?
- Como a demanda se comporta?
- Quais regulamentações precisam ser atendidas?
- Quanto tempo existe para colocar a solução no mercado?
- Quais riscos são aceitáveis?
- Quais consequências uma falha pode causar?
A tecnologia precisa estar alinhada à estratégia do negócio. Caso contrário, uma solução tecnicamente sofisticada pode se tornar cara, difícil de operar ou inadequada para o problema que deveria resolver.
Objetivos de aprendizagem
- Traduzir processos críticos, restrições e riscos em direcionadores arquiteturais.
- Distinguir requisitos funcionais de atributos de qualidade.
- Registrar decisões considerando negócio, operação, segurança e custo.
Arquitetura como ecossistema
A arquitetura de software pode ser comparada ao planejamento de uma cidade.
Projetar uma cidade não significa apenas desenhar uma quadra ou construir uma casa. É necessário considerar um conjunto de estruturas interdependentes:
- Saneamento
- Energia
- Transporte
- Segurança
- Comunicação
- Abastecimento
- Crescimento populacional
- Manutenção
- Integração entre regiões
Da mesma maneira, uma arquitetura de software não pode analisar somente a aplicação isolada.
Ela precisa considerar:
- Infraestrutura
- Redes
- Bancos de dados
- Segurança
- Monitoramento
- Integrações
- Processos de implantação
- Pessoas
- Governança
- Custos
- Continuidade do negócio
Uma decisão tomada em uma parte do sistema pode produzir efeitos em várias outras.
Por exemplo, adotar uma arquitetura distribuída não afeta apenas a organização do código. Essa decisão também influencia observabilidade, comunicação entre serviços, segurança, custos de infraestrutura, estratégia de testes e capacidade operacional do time.
Uma visão integrada entre áreas
O arquiteto não deve tomar decisões sozinho nem produzir definições desconectadas da realidade do time.
A arquitetura precisa ser construída a partir da colaboração entre:
- Negócio
- Produto
- Desenvolvimento
- Infraestrutura
- Segurança
- Operações
- Finanças
- Compliance
Cada área observa uma dimensão diferente do sistema.
Produto pode priorizar velocidade de entrega. Segurança pode identificar riscos de exposição. Operações pode apontar dificuldades de monitoramento. Finanças pode demonstrar que uma solução tecnicamente viável possui um custo operacional insustentável.
A função da arquitetura é equilibrar essas perspectivas e criar condições para que:
- os desenvolvedores produzam soluções melhores;
- a operação seja sustentável;
- os riscos sejam conhecidos;
- o negócio consiga evoluir.
Arquitetura como alicerce
Um trecho de código mal escrito pode, em muitos casos, ser:
- Refatorado
- Substituído
- Testado
- Reorganizado
- Corrigido gradualmente
Uma decisão arquitetural inadequada pode causar impactos mais amplos e difíceis de reverter.
Decisões estruturais criam restrições que moldam tudo o que será construído posteriormente. Por isso, a arquitetura pode ser comparada ao alicerce de uma construção.
Se o alicerce for inadequado, os problemas aparecerão nas estruturas construídas sobre ele.
Entre as consequências de uma arquitetura frágil estão:
- Dificuldade de crescimento
- Alto custo operacional
- Instabilidade
- Baixa disponibilidade
- Falhas de segurança
- Dependência excessiva de fornecedores
- Lentidão nas entregas
- Dificuldade de manutenção
- Aumento do retrabalho
- Problemas de integração
Isso não significa tentar prever todo o futuro ou criar uma solução excessivamente complexa desde o início.
O objetivo é compreender quais decisões podem gerar restrições duradouras e quais podem ser alteradas posteriormente com menor impacto.
Classificando os processos de negócio
Antes de projetar uma solução, é necessário compreender que tipo de processo será atendido.
Três classificações ajudam a orientar as decisões:
- Processo crítico
- Processo sazonal
- Processo regulado
Um mesmo sistema pode apresentar mais de uma dessas características.
Uma plataforma financeira, por exemplo, pode ser simultaneamente crítica, regulada e sujeita a picos de demanda.
Processo crítico
Um processo crítico é aquele cuja falha pode causar perdas graves ou interromper a operação principal da empresa.
Considere um sistema de pagamentos bancários.
Uma indisponibilidade de poucos minutos pode causar:
- Perdas financeiras
- Transações incompletas
- Insatisfação dos clientes
- Danos à reputação
- Problemas regulatórios
- Paralisação de operações
Nesse contexto, resiliência não é um diferencial opcional. É uma necessidade para a continuidade do negócio.
Decisões arquiteturais possíveis
Um processo crítico pode exigir:
- Alta disponibilidade
- Redundância
- Replicação de dados
- Monitoramento constante
- Recuperação automática
- Plano de contingência
- Estratégias de disaster recovery
- Testes de carga
- Testes de falha
- Observabilidade
A intensidade dessas medidas deve ser proporcional ao impacto da falha.
Nem todo sistema precisa da mesma disponibilidade de uma plataforma bancária. Entretanto, sistemas críticos precisam tratar falhas como eventos esperados e planejar como continuar operando ou se recuperar.
Processo sazonal
Um processo sazonal apresenta variações previsíveis e significativas de demanda.
Um exemplo é uma plataforma de comércio eletrônico durante a Black Friday.
Durante a maior parte do ano, o sistema pode operar com um volume normal de acessos. Em um período específico, porém, a demanda cresce intensamente.
Necessidades arquiteturais
Uma aplicação sazonal pode exigir:
- Elasticidade
- Escalabilidade horizontal
- Balanceamento de carga
- Cache
- Filas
- Auto Scaling
- Testes de desempenho
- Planejamento de capacidade
A nuvem pode oferecer vantagens nesse cenário porque permite aumentar ou reduzir recursos conforme a demanda.
Entretanto, capacidade técnica e sustentabilidade financeira precisam ser avaliadas em conjunto.
Um sistema pode suportar um grande pico de acessos e, ainda assim, gerar uma conta de nuvem incompatível com o retorno financeiro do evento.
Escalar também possui custo
A decisão não deve ser apenas:
Como suportar mais acessos?
Também é necessário perguntar:
Quanto custará suportar esses acessos e qual retorno o negócio espera obter?
Processo regulado
Um processo regulado está sujeito a leis, regulamentações, auditorias ou regras específicas de um setor.
Considere uma aplicação de saúde que manipula informações de pacientes.
Esse sistema pode precisar garantir:
- Privacidade
- Rastreabilidade
- Integridade das informações
- Controle de acesso
- Auditoria
- Consentimento
- Retenção adequada dos dados
- Proteção contra vazamentos
Decisões arquiteturais possíveis
Um processo regulado pode exigir:
- Criptografia
- Registros de auditoria
- Controle de acesso baseado em papéis
- Segregação de dados
- Mascaramento de informações sensíveis
- Políticas de retenção
- Autenticação forte
- Monitoramento de acessos
- Governança de dados
Nesse tipo de sistema, a arquitetura não pode considerar apenas velocidade de entrega.
Também é necessário garantir que a solução preserve direitos, proteja informações e produza evidências de conformidade.
Comparando os três tipos de processo
| Tipo | Característica principal | Exemplo | Prioridades arquiteturais |
|---|---|---|---|
| Crítico | A falha pode interromper a operação ou causar perdas graves | Sistema de pagamentos | Resiliência, disponibilidade, recuperação e observabilidade |
| Sazonal | A demanda apresenta picos previsíveis | E-commerce na Black Friday | Elasticidade, capacidade, desempenho e controle de custos |
| Regulado | A solução precisa atender leis ou regras setoriais | Sistema de saúde | Segurança, auditoria, privacidade e governança |
Essa classificação não cria uma resposta arquitetural automática.
Ela ajuda a identificar quais atributos de qualidade merecem maior atenção.
Três dimensões para orientar decisões
Além da classificação do processo, três dimensões ajudam a orientar a arquitetura:
- Risco
- Comportamento operacional e sazonalidade
- Time to market
Risco
A análise de risco procura compreender o impacto de uma falha.
Algumas perguntas importantes são:
- Quanto a empresa pode perder?
- A falha afeta clientes?
- Existem riscos legais?
- A reputação da empresa pode ser comprometida?
- Quanto tempo o sistema pode permanecer indisponível?
- Existe risco de perda ou exposição de dados?
Quanto maior o risco, maior tende a ser a necessidade de:
- Segurança
- Redundância
- Observabilidade
- Continuidade
- Planos de recuperação
- Controles preventivos
Arquitetura não elimina todos os riscos.
Ela identifica, reduz, transfere ou aceita riscos de maneira consciente.
Comportamento operacional e sazonalidade
Essa dimensão avalia como a demanda se comporta ao longo do tempo.
É necessário compreender:
- Quantidade média de usuários
- Picos de acesso
- Horários de maior utilização
- Eventos comerciais
- Crescimento esperado
- Volume de dados
- Frequência das transações
Uma solução com demanda constante pode exigir uma arquitetura diferente de outra que recebe milhões de acessos em poucos minutos.
A capacidade precisa ser planejada a partir do comportamento real ou esperado da operação, e não apenas de estimativas técnicas isoladas.
Time to market
Time to market representa o tempo necessário para colocar uma solução ou funcionalidade no mercado.
Em alguns contextos, entregar rapidamente pode representar uma vantagem competitiva.
Entretanto, velocidade não significa abandonar:
- Qualidade
- Segurança
- Planejamento
- Manutenibilidade
- Controle de custos
O desafio está em equilibrar:
- Velocidade
- Qualidade
- Segurança
- Custo
- Manutenibilidade
- Risco
Uma arquitetura excessivamente complexa pode atrasar a entrega.
Uma arquitetura simplificada demais pode gerar problemas quando o produto começar a crescer.
Não escolher tecnologias apenas pela popularidade
Uma tecnologia não deve ser escolhida somente porque:
- Está popular
- Aparece em muitas vagas
- É utilizada por uma grande empresa
- Está em destaque nas redes sociais
- Foi apresentada como tendência
- Parece tecnicamente sofisticada
A tecnologia precisa resolver um problema real.
Antes de adotá-la, é importante perguntar:
- Qual problema ela resolve?
- O time possui conhecimento para utilizá-la?
- Existe documentação adequada?
- A comunidade é ativa?
- A tecnologia é madura?
- Qual é o custo de operação?
- Ela aumenta ou reduz a complexidade?
- Existe risco de dependência do fornecedor?
- Há uma alternativa mais simples?
- A escolha ajuda o negócio a atingir seus objetivos?
Uma solução moderna pode ser inadequada para o contexto da empresa.
A melhor tecnologia não é necessariamente a mais recente. É aquela que melhor se encaixa no problema, nas restrições do negócio e na capacidade do time.
O Technology Radar, da Thoughtworks, pode apoiar esse tipo de avaliação ao organizar tecnologias de acordo com seus níveis de maturidade e adoção recomendada.
Zero Trust
Zero Trust parte do princípio de que nenhum usuário, dispositivo, aplicação ou serviço deve ser considerado confiável automaticamente.
Isso não significa desconfiar das pessoas de maneira pessoal.
Significa evitar que a arquitetura dependa de confiança implícita.
Princípios básicos
- Verificar explicitamente cada acesso
- Aplicar o menor privilégio possível
- Limitar permissões
- Autenticar usuários e serviços
- Monitorar comportamentos
- Segmentar redes e sistemas
- Considerar que uma invasão pode acontecer
- Revisar acessos continuamente
Uma aplicação interna não deve ser considerada segura apenas porque está dentro da rede corporativa.
Da mesma forma, um serviço autenticado não deve receber acesso irrestrito a todos os recursos.
Segurança como parte da arquitetura
Profissionais de segurança, compliance e auditoria não estão apenas adicionando etapas ao trabalho do time.
Essas áreas ajudam a identificar riscos que podem causar:
- Vazamento de dados
- Multas
- Fraudes
- Interrupções
- Danos financeiros
- Danos à reputação
Segurança precisa ser tratada como requisito arquitetural, e não como uma etapa adicionada ao final do desenvolvimento.
Como justificar decisões para a liderança
Lideranças de negócio geralmente não são convencidas apenas por argumentos técnicos.
Dizer que uma tecnologia é mais moderna ou que uma arquitetura é mais sofisticada pode não ser suficiente.
A decisão precisa ser traduzida em consequências concretas.
Argumentos relevantes
- Redução de riscos
- Aumento da segurança
- Redução de custos
- Ganho de produtividade
- Maior disponibilidade
- Menor tempo de entrega
- Redução de incidentes
- Melhoria da experiência do cliente
- Aumento de receita
- Facilidade de expansão
- Atendimento às regulamentações
Argumento exclusivamente técnico
Precisamos implantar redundância entre zonas de disponibilidade.
Argumento orientado ao negócio
Com a redundância, reduzimos o risco de o serviço ficar indisponível caso um data center apresente falha. Isso protege as vendas, reduz perdas financeiras e melhora a continuidade da operação.
O segundo argumento conecta a decisão arquitetural aos resultados esperados pela organização.
Arquitetura é estratégia
Arquitetura de software não é apenas produção de código.
O arquiteto pode escrever código, criar provas de conceito e apoiar implementações. Entretanto, sua principal responsabilidade está nas decisões estruturais.
Entre suas atividades estão:
- Compreender o negócio
- Identificar riscos
- Avaliar restrições
- Definir princípios
- Criar diretrizes técnicas
- Escolher padrões
- Registrar decisões
- Apoiar os times
- Avaliar custos
- Planejar a evolução do sistema
- Comunicar consequências
- Garantir alinhamento estratégico
O código é uma das materializações da arquitetura, mas não representa a arquitetura inteira.
Relação com o AWS Well-Architected Framework
Os conceitos apresentados se relacionam ao AWS Well-Architected Framework, que orienta a avaliação de arquiteturas em nuvem.
Seus pilares ajudam a observar diferentes dimensões de uma solução:
- Excelência operacional
- Segurança
- Confiabilidade
- Eficiência de desempenho
- Otimização de custos
- Sustentabilidade
Esses pilares reforçam que uma arquitetura não deve ser avaliada apenas pelo funcionamento do código.
Também é necessário observar como ela:
- Opera
- Responde a falhas
- Protege dados
- Utiliza recursos
- Controla custos
- Evolui ao longo do tempo
Um roteiro para compreender o negócio
Antes de propor uma arquitetura, é possível organizar a análise em cinco etapas.
1. Entender o valor gerado
- Qual problema o produto resolve?
- Quem utiliza a solução?
- Como ela gera receita ou reduz custos?
- Quais jornadas são essenciais?
2. Classificar os processos
- O processo é crítico?
- É sazonal?
- É regulado?
- Pode combinar essas características?
3. Identificar riscos e restrições
- Quanto tempo de indisponibilidade é aceitável?
- Quais dados precisam ser protegidos?
- Existem restrições legais?
- Qual é o orçamento?
- Qual é a capacidade técnica do time?
4. Compreender a operação
- Qual é o volume médio?
- Existem picos?
- Como o sistema será monitorado?
- Quem responderá a incidentes?
- Como será realizada a recuperação?
5. Traduzir decisões em resultados
- Qual risco será reduzido?
- Qual custo será criado ou evitado?
- Como a decisão afeta o prazo?
- Qual benefício será percebido pelo cliente?
- Como a solução poderá evoluir?
Conclusão
A arquitetura de software deve ser construída a partir do contexto do negócio.
Antes de escolher tecnologias, é necessário identificar se o processo é:
- Crítico
- Sazonal
- Regulado
Também é necessário avaliar:
- Riscos
- Comportamento da demanda
- Time to market
- Segurança
- Custos
- Capacidade do time
- Estratégia de crescimento
Decisões arquiteturais criam restrições de longo prazo. Por isso, precisam ser justificadas por benefícios concretos e alinhadas aos objetivos da organização.
Arquitetar não significa selecionar a solução tecnicamente mais sofisticada.
Significa criar uma base segura, sustentável e coerente para que o negócio consiga operar e evoluir.
Desafio de decisão
Qual é o primeiro passo coerente antes de escolher a arquitetura?
O produto ainda possui requisitos instáveis, equipe pequena e processos críticos pouco mapeados.
A recomendação considera apenas este contexto; mudanças nas restrições podem mudar a decisão.
Revisão do artigo
Pontos principais
- — Processos, riscos e restrições orientam decisões técnicas.
- — Atributos de qualidade precisam de prioridade e medida.
- — Decisões arquiteturais devem registrar contexto e consequências.
Referências
- AMAZON WEB SERVICES. AWS Well-Architected Framework. Acesso em: 3 jul. 2026.
- BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 4. ed. Boston: Addison-Wesley Professional, 2021.
- FOWLER, Martin. Patterns of Enterprise Application Architecture. Boston: Addison-Wesley Professional, 2002.
- JOURNAL OF INFORMATION AND DATA MANAGEMENT. JIDM. Acesso em: 3 jul. 2026.
- THOUGHTWORKS. Technology Radar. Acesso em: 3 jul. 2026.