Arquitetura I
Arquitetura de software é a base de toda solução de software criada para apoiar o negócio. Assim, todo software desenvolvido possui uma arquitetura, boa ou ruim, a depender o ponto de vista.
Equilibrar custo e risco de evolução e manutenção são essenciais para garantir a longevidade do software.
Arquitetura de Software: custo, risco e o jeito certo de mudar
Um dos papeis da arquitetura de software é reduzir o custo futuro. Uma boa arquitetura torna o sistema mais barato e menos arriscado de mudar, já que mudar é inevitável: requisitos mudam, prioridades mudam, tecnologias mudam. Se mudar é caro e arriscado, o negócio sofre. Se mudar é barato e seguro, o negócio ganha velocidade.
Outro aspecto quando falamos de arquitetura é a dívida técnica. Muitas vezes pensamos em “código feio” ou “atalhos mal feitos”. Mas na prática, a dívida técnica é mais que isso. Podemos conceituar como o sacrifício em deixar fazer do jeito certo para entregar em menos tempo. Todavia, isso inevitavelmente cobra seu preço.
Arquitetura não é o Monte Sinai
A tomada de decisão em arquitetura é simples na forma, mas complexa no impacto. Arquitetura de software não é uma “tábua dos mandamentos” descendo do alto da montanha: “está aqui a arquitetura, pronto, use!”.
Não funciona assim.
Arquitetura é design de componentes, responsabilidades e relacionamentos. Ela é viva, evolutiva, resultado de decisões tomadas ao longo do tempo. Para documentar essas decisões, uma ferramenta extremamente útil ó o ADR (Architectural Decision Record).
Um ADR é um documento que registra a decisão arquitetural, o contexto da decisão e as razões por trás dela. É uma documentação simples, mas poderosa, que permite entender não só o que foi decidido, mas o porquê. Um exemplo real pode ser visto aqui
O que a arquitetura precisa garantir
Uma arquitetura não pode ser apenas “preferência de estilo” ou moda do momento. Sem alguns pontos claros, ela não se sustenta. Uma arquitetura precisa:
- Atender aos objetivos de negócio;
- Respeitar restrições (de orçamento, tempo, tecnologia, equipe);
- Entregar atributos de qualidade (performance, segurança, escalabilidade etc.);
- Tornar o sistema mais barato e menos arriscado de evoluir.
Grande parte do que foge disso são detalhes e muitas vezes complexidades desnecessárias, que se transformam em custo e risco direto.
Vendendo ideias para a liderança
Em certos momentos, arquitetos precisam convencer a liderança. Entretanto, falar o “tecniquês”, como sobre “DDD” ou “CQRS”, nem sempre convence CFO, CEO ou diretor de negócio.
Normalmente, o que convence é falar na linguagem deles: custo e risco.
Para isso, uma técnica útil que pode ser utilizada é o framework OSIR, cunhada pelo ElemarJr.
OSIR significa:
- Outcome: qual o benefício para o negócio? Qual dor estou aliviando? (ex.: reduzir custo de manutenção, diminuir risco de indisponibilidade).
- Situação: qual é o cenário atual?
- Implicação: se nada mudar, o que pode acontecer?
- Recomendação: proposta de solução.
Não é sobre tecnologia pela tecnologia. É sobre como a tecnologia apoia e suporta o negócio.
Entendendo os domínios
Outra peça-chave da arquitetura é entender os domínios.
Podemos dividir os domínios em:
- Core: onde a empresa realmente ganha o jogo (ex.: para uma fintech, os algoritmos de risco de crédito).
- Apoio: ajuda a empresa a operar bem o core (ex.: ferramentas internas de atendimento).
- Genérico (suporte): precisa existir, mas não gera diferenciação (ex.: folha de pagamento).
Colocar energia demais em algo que não é core pode ser um desperdício. Saber onde investir esforço arquitetural faz toda a diferença.
Conclusão
Arquitetura de software não é sobre escolher o framework da moda. É sobre equilibrar passado, presente e futuro.
Excesso de passado gera depressão; excesso de futuro, ansiedade. O que precisamos é tomar decisões conscientes, documentar, e construir sistemas que tornem o dia a dia mais barato e menos arriscado.
No fim, a boa arquitetura é invisível: ela não aparece, mas está lá, sustentando cada mudança com segurança, minimizando custo e risco.