Durante alguns anos eu sempre tive o desejo de ser uma liderança técnica de referência dentro das empresas que trabalhei. Meu intuito com isso era ajudar as pessoas a tomar as melhores decisões, e o papel de Arquiteto de Software me parecia um objetivo que dava “match” com esse desejo.

Quando fui descobrindo o que essas pessoas faziam e como era a relação do papel com outros dentro de uma organização, começaram a surgir dúvidas sobre a vantagem real de haver essa concentração de responsabilidades. Me parecia uma centralização desnecessária, burocrática e que diminuía o uso da criatividade dos times. E parece que eu estava certo.

Hoje, eu não acredito que deveria existir alguém como “Arquiteta de Software” nas organizações. E quero discorrer um pouco do porquê deixei de acreditar nesse papel e na necessidade dele existir.

*apenas um aviso rápido: minha crítica é sobre o papel, e não sobre as pessoas.

Torre de Mármore (Ivory Tower)

Esse conceito de Torre de Mármore se refere a um lugar inacessível, distante dos humanos “normais”, onde só habitam seres que não vivem mais a realidade dos meros mortais.

Infelizmente, quando vejo esse papel sendo discutido nas empresas, vejo que quem exerce acaba tendo um pouco dessa crise existencial entre não querer ser alguém que toma decisões autocráticas versus ouvir opinião de todo mundo.

Geralmente, o caminho tomado é de decisões autocráticas.

Vem junto também a sensação de que essas pessoas sempre estão pensando um passo além das outras (meras pessoas desenvolvedoras) e que elas detém exclusividade no conhecimento e na vanguarda da tecnologia.

Todas essas percepções — e em alguns casos realidade — são causadas por conta das responsabilidades que elas tem, além da expectativa que a alta liderança das empresas deposita em papéis como esse. Em alguns casos, nem as pessoas Arquitetas de Software querem ter esse monopólio da decisão, mas elas são avaliadas em como elas assumem essas responsabilidades, portanto cria-se um ciclo vicioso difícil de sair.

Tomada de decisão centralizada

Quando vejo a descrição desse papel, normalmente responsabilidades vem como algo nessa linha:

Toma decisões sobre uso de uma abordagem de arquitetura de software X ou Y;
Estuda e traz inovações para a área de tecnologia;
Propõe, quando necessário, o uso de novas tecnologias que façam sentido para o negócio;

Todas esses pontos me parecem listar coisas de alguém que normalmente está distante da realidade. Será mesmo que alguém que não está no dia-a-dia dos times consegue decidir sobre o uso ou não de uma abordagem de arquitetura? Só a pessoa Arquiteta de Software deveria ser responsável por estudar e trazer inovações para a área? Propor novas tecnologias deveria ser responsabilidade de um único papel ou um “time de arquitetura”?

Talvez você possa imaginar que sim, poderia fazer essas 3 coisas. Mas meu ponto é que essas decisões, estudos e propostas não deveriam emergir de forma centralizada. Isso deveria ser cultural e descentralizado.

Na minha visão, qualquer pessoa poderia discutir o uso de uma nova abordagem, desde que consiga trazer argumentos suficientes para o uso dela. Qualquer pessoa deveria poder estudar e trazer inovações para a área. Me parece tirar o poder criativo e remover o poder de emergir ideias.

Eu acredito numa tomada de decisão compartilhada e descentralizada, onde quem propõe ideias não necessariamente precisa ter um papel de arquiteta ou arquiteto, mas que consiga listar os porquês de uma tecnologia, uma nova stack, ou alguma mudança precisa ser levada adiante — e ser aberta para um número considerável de pessoas comentarem, trazerem pontos de vista diferentes.

Você pode até argumentar que uma pessoa Arquiteta de Software poderia tomar decisões sem passar por essa fase de coleta de percepções, mas eu tendo sempre a imaginar que essas pessoas geralmente sempre pendem a tomar decisões enviesadas — muitas vezes por gostos pessoais e sem o devido contexto local.

“Mas vai ser um caos, qualquer pessoa vai poder mudar coisas”

O grande medo das pessoas que defendem a manutenção do papel de Arquiteto de Software é que a “governança” sobre decisões de arquitetura vai acabar, e todo mundo vai querer usar um monte de stack de linguagem ou abordagens diferentes — o caos vai reinar.

Eu já ouvi que se não tiver, qualquer pessoa pode decidir usar uma nova linguagem e aí vai ser impossível de dar manutenção em um monte de projeto com stack diferente. E sim, eu até entendo esse medo.

A pergunta que faço é se realmente essa autocracia é o melhor caminho pra se resolver isso.

O melhor seria definir pilares de cultura onde essas stacks precisem ser avaliadas, estudadas, pra só depois serem adotadas. Infelizmente parece um caminho mais fácil centralizar essa responsabilidade de aprovar e propor novas ideias do que realmente mudar a cultura de desenvolvimento de software.

Se um time entende que, pra resolver um determinado problema, usar uma tecnologia X pode ser o melhor caminho, comprovando com estudos e fazendo provas de conceito, analisando outros itens como viabilidade a longo termo, adoção e manutenção pelas comunidades, estabilidade, capilaridade, conhecimento do time com a tecnologia, entre outros, não deveríamos impor limites de quem toma uma decisão, ou de ser exclusiva de um papel. Tendo os critérios levantados, discutidos, e as objeções sendo levadas em conta, não faz sentido ainda passar pela aprovação de um papel exclusivo pra esse tipo de tomada de decisão.

Precisamos empoderar a tomada de decisão aos times, criando ferramentas pra que essas decisões sejam menos arriscadas, mais elaboradas do que só desejos pessoais ou o hype. É um caminho mais difícil, mas me parece potencializar a criatividade e a eficácia da organização.

“Os times não têm tempo pra pensar na arquitetura do futuro”

Esse é o outro ponto que sempre surge pra justificar a manutenção de uma “equipe de arquitetura”. Se os times não tem espaço de tempo suficiente pra discutir o futuro do ecossistema em que trabalham e evoluem todo o santo dia, parece que temos um problema maior.

Essa filosofia de “deixar o time focado” no agora me parece incentivar que as pessoas apenas executem as “tarefas do board”. E pessoas que apenas executam, não tem tempo pra pensar no porquê do que está sendo feito, e do racional das decisões técnicas que foram ou estão sendo tomadas.

Além de tudo isso, me parece um desperdício enorme não contar com a opinião ou visão de quem está com a mão na massa diariamente. São essas pessoas que sabem as dores, os gargalos, as nuances dos ambientes que trabalham, e consequentemente da arquitetura construída pra suportar os produtos que desenvolvem.

Um “time de arquitetura”, ou uma pessoa Arquiteta de Software que não faz parte dos times, nunca vai ter esse tipo de profundiade que pessoas desenvolvedoras tem.

Sou Arquiteta de Software, e agora?

Se você exerce esse papel na sua empresa, eu gostaria de propor um exercício de reflexão sobre as responsabilidades que são esperadas de você. Isso é claro, se você tiver espaço pra rediscutir essas responsabilidades.

Talvez seja uma hora boa de remover toda e qualquer atividade que faça com que se centralize todas as decisões organizacionais técnicas. Talvez algumas propostas possam sim ser feitas por você, mas você não deveria ser o/a aprovador/a oficial de propostas, ou ser a única que cria as mesmas. Em alguns casos, ter o “voto de minerva” pode ser uma solução, mas tirar de você esse modo autocrático de decisões é um bom começo.

Outra dica que eu dou: tente criar uma cultura onde as ideias e propostas possam surgir de qualquer papel na empresa. Crie artefatos, como RFCs (request for comments) ou documentos de propostas, que sigam um padrão que facilite a vinda dessas ideias de forma organizada e com clareza dos porquês delas estarem sendo apresentadas (com argumentos, critérios de avaliação robustos).

A última dica que dou é tentar se aproximar de um time e não ficar isolada numa “área de arquitetura”. Ficar distante só cria mais ainda o afastamento da realidade e de como os times trabalham, quais problemas eles realmente tem.

Se sua empresa tem esse “time de arquitetura”, tente propor uma abordagem onde esses papéis estejam distribuídos em times, pra que sintam como o software é desenvolvido, como os serviços se comunicam, enfim, como a arquitetura de software é de fato construída no dia-a-dia.

Concluindo

Precisamos derrubar essas torres de marfim das empresas e dentro da disciplina de tecnologia também. Um passo importante pra mim é remover esse papel e tornar as decisões mais distribuídas, porém com argumentos sólidos e bem embasados.

*O conteúdo deste artigo é de responsabilidade do(a) autor(a) e não reflete necessariamente a opinião do iMasters.

Eduardo Matos