O que é a arquitetura? Eu defino como estratégias, táticas e elementos que definem um software.

E quando jogo uma definição tão abrangente assim estou dizendo que:
A escolha do banco de dados, é arquitetura.
A escolha da forma como seu código acessa esse banco de dados, é arquitetura.
A forma como você evita que esse banco seja consumido desnecessariamente, usando cache, é arquitetura.
Se a aplicação é Web, Desktop, um serviço agendado, ou um embarcada em um vestível como um relógio, isso é arquitetura.

Os componentes que compõem essa aplicação, são definidos pela arquitetura.
A arquitetura é tudo, que não a construção em si. É como você define cada singelo elemento daquele software. E vai além.

Como você vai estruturar os repositórios de código?
Vai precisar de um Nuget privado?
Um container Registry Privado?
Vai implantar com Containers? Com Kubernetes? Com ou sem Service Mesh? Qual ingress controller?
Qual proxy reverso?
Monolito ou Microsserviço? Faz sentido esse questionamento? E serverless?
Com TDD ou sem TDD?
Com DDD ou sem DDD?
Mensageria e assincronismo ou sincronismo não resiliente?
Qual a volumetria?
Qual o perfil de consumo dessa aplicação?
Quais patterns estão em jogo? E quais patterns serão endereçadas a quais problemas?

É como uma rede social com consumo 24/7 ou é como um backend de uma loja física que fica aberta somente em horário comercial?
O ciclo evolutivo deve ser rápido ou é para ser mais lento?
De como gerenciaremos versões do nosso software até como implementaremos segurança.

Todas essas decisões são decisões arquiteturais.

Ao mesmo passo qual o tamanho do time, em quantas squads esse time será dividido? Qual o skill desse time?
Quanto de recurso financeiro esse projeto está disposto a gastar com infraestrutura?
Qual a projeção de utilização dessa aplicação em caso de sucesso?
Quais e quantos recursos já existem?
Quais integrações com os sistemas que já existem precisam ser feitas?

Tudo isso impacta a arquitetura.

O papel do arquiteto, em qualquer nível, é servir.
O que muda é a audiência que ele serve.
O que muda são os interesses que ele representa.

Aliás, note que eu não falei de Docker, de Kubernetes, de Istio, de NGINX, de .NET, de ELK Stack, de RabbitMQ, de Redis, Keycloak.

Não abordei diretamente nenhuma tecnologia específica.

Embora a arquitetura enderece esses assuntos, seja como arquitetura de software, estando mais próximo do código servindo aos desenvolvedores, quanto arquitetura de solução mais perto do negócio, servindo aos arquitetos de software, as tecnologias são apenas meios, mecanismos.

Uma tecnologia é como tijolo e o cimento na construção de um edifício.

Sem o amparo da engenharia civil, com apenas com tijolo e cimento, não somos capazes de construir um prédio. Embora os prédios sejam feitos disso.

Ao tentarmos realizar esse feito, na maioria esmagadora das vezes criaremos construções que desmoronarão.
Porque são frágeis.

Com software não é diferente. Não bastam exchanges e filas para você ter resiliência infinita. É preciso entender como costurar publishers e consumers de forma a que eles não dependam da disponibilidade um do outro. E se por algum motivo você precisa fazer um deploy enquanto esses 2 esperam mensagens um do outro, que isso não gere impacto. Ou para tornar mais simples, é preciso que a relação seja 100% assíncrona.

E quando não puder ser assíncrono?

Tudo bem, você só não terá a tal resiliência de 100%.

Entender esses simples detalhes muda a forma como você projeta, muda a forma como você ajuda seu time.
Muda a forma como você facilmente identifica incompatibilidade entre um discurso e o resultado prático daquele discurso.

Ou seja, se alguém fala de resiliência e RPC, mesmo que seja com filas, você facilmente percebe que tem algo errado nessa história.

E você consegue argumentar a respeito.

Quando pensamos em ferramentas melhores, estamos pensando em tijolos melhores para cada tipo de construção, para cada pedaço da construção.

Mas se na construção é a engenharia que viabiliza construirmos arranha-céus, e prédios incríveis, aqui é a arquitetura, e o entendimento de estratégias somado ao conhecimento de boas táticas que torna tudo possível.

Esses elementos são necessários e conectam tudo ao ponto de desenharmos projetos que de fato entregam o que foi combinado.

Eu chamo esse profissional, que está atento e consciente dos impactos de cada uma das restrições e decisões, que sabe tomar boas decisões e reconhece seus impactos e a compatibilidade dessas decisões no contexto do seu projeto, eu chamo de Estrategista Técnico.

O estrategista técnico é um tomador de decisão que olha para um projeto, uma equipe, um setor, uma empresa e enxerga como um jogo de estratégia:

Onde seu papel é dominar os problemas, e resolvê-los. De forma estratégica, com boas táticas para cada micro-problema.

Ele pode ser apenas um desenvolvedor, não há nada de errado. Conheço estrategistas técnicos que não estão em cargos de arquitetura.

E nessas empresas sequer existe essa posição.

Quanto menor a empresa mais fácil de você ter de assumir as responsabilidades sobre as decisões técnicas.
E se você toma decisões, essas decisões podem ser estratégicas e sua implementação pode seguir táticas que conduzirão ao sucesso.

É nisso que acredito.

Nessa quinta-feira 12/MAIO, às 21h eu vou abrir as inscrições para uma nova turma do Cloud Native .NET, que é minha formação dedicada a formar esses estrategistas técnicos.

Essa formação é composta por 2 alicerces fundamentais:

• Conteúdo de qualidade, com profundidade e abrangência,
• e acompanhamento, realizado em grupo privado e também em lives 2 vezes ao mês.

Se você quer saber mais sobre a proposta, clique no link ( cloudnative.net.br/next ) e inscreva-se com seu melhor email.

Te vejo na quinta-feira em uma live onde abordarei com detalhes nossa jornada.