Não! Uma solução ou decisão não serve para todos os casos!

Com base nas discussões da semana e muita farpa trocada em grupos de discussão, vejo cada vez mais jovens buscando uma solução única para os problemas de arquitetura e design. Seja ao modelar um domínio, ao desenhar a arquitetura de um projetinho simples, ou mesmo algo complexo como lidar com e-commerces.

A busca por uma arquitetura, um design universal, ou framework definitivo produz ignorância e falta se senso de contexto.

A visão radical que prevê tal solução arquitetural como o Santo Graal em detrimento a tudo que existiu é uma visão míope inclusive sobre como chegamos até aqui.

A ideia de que só o que é novo é bom, produz uma visão óbvia de que o passado é ruim. E não estou falando de saudosismo algum, estou querendo lembrar que é preciso entender o contexto e levar em conta que há formas testadas e comprovadas de resolver problemas conhecidos. Mas como qualquer evolução, as empresas e suas demandas mudaram, mas não todas.

É preciso discernimento para entender quando tirar proveito de uma tecnologia, um framework, uma ideia, um desenho arquitetural ou design.

Esse discernimento exige conhecimento tanto específico quanto abrangente e isso só é possível ser alcançado com esforço de… … … es-tu-dar! Ok que a prática ajuda, mas antes da prática o estudo se faz necessário.

O imediatismo é o vilão

Enquanto milhares de soluções e desenhos estão à nossa volta para nos prover facilitadores e “empoderar” o desenvolvedor, surge uma classe de devs e “arquitetos” que não compreendem o impacto de cada decisão, este esteriótipo que descrevo, se prende a um modelo definitivo, e vende a ideia de que tudo que não se encaixa nessa dobradinha, é ruim, porco, retrógrado e antiquado.

Boa parte dessa concepção minimalista é fruto do imediatismo. Tentativas de resolver questões complexas da forma mais rápida: obviamente evitando ter de conhecer outras abordagens. Sob essa visão basta conhecer XXX e YYY para montar a estratégia de qualquer projeto.

O impacto

Afirmações a respeito do padrão definitivo e da arquitetura definitiva são levianos por definição.

Não é possível definir um padrão ou uma arquitetura sem sequer conhecer o problema. A leviandade reside aí.

O impacto natural pode ser percebido em qualquer grupo de discussão, falácias são contadas e cuidado: Desconstruir essa “pseudo-realidade” tende a deixar muitos frustrados pelo caminho.

Conclusão

Discernimento é a palavra-chave na hora de definir qualquer tecnologia, padrão, estilo, design e arquitetura. É preciso entender o contexto e entregar as melhores soluções para o cenário, levando em conta aspectos técnicos mas principalmente, aspectos não técnicos, como DNA e cultura da empresa. Os aspectos financeiros também devem entrar nessa conta.

Minhas experiências dividindo e compartilhando a tomada de decisão com gestores não técnicos nem sempre foi boa, em geral, por mais que eu compartilhasse de minhas preocupações sequer tinha a atenção de todos os envolvidos por não entenderem do que eu estava falando. Isso melhorou quando comecei a mostrar números e projeções, que em geral eram reflexo das minhas decisões técnicas. Algo como:

Se eu seguir pela linha X:

• Você conseguirá fazer Z com uma equipe de custo Y.
• A curva de aprendizado que era W passa a ser Z
• Em caso de turnover, perdemos mais ou menos em relação a outra opção.
• O custo de infra para atender X é Y, já para atender 2X é 1,5Y

Esmiuçar esses números e dar opções pautadas em números é sempre mais relevante para quem toma decisões estratégicas. Os números não mentem, as pessoas que mentem sobre os números.

No post que coloco aqui abaixo eu detalho melhor como eu tomo minhas decisões na hora de definir uma arquitetura.

Como definir a Arquitetura de um Software