Primeiramente, eu sei que o título do artigo que fiz recentemente teve um tom muito apocalíptico. Antes de me aprofundar nos argumentos, queria só retratar duas coisas que deixei passar batido:

1- Eu ainda acredito que o papel de arquiteto de software não deva existir, mas não que as pessoas devam deixar a organização. Isso é longe do que quis passar no texto, e no fim dele eu fiz questão de colocar uma sessão descrevendo o que eu pensava de futuro pra quem está nesse papel hoje (veja “Sou Arquiteta de Software, e agora?”).

2- Dizer adeus a um papel, principalmente em empresas que não é só um papel e sim um cargo, foi muito insensível da minha parte. Logo eu que critiquei bastante o movimento de “agilista não faz mais sentido”… E mais, principalmente agora, em tempos de demissões em massa. Eu deveria ter optado por escrever “a evolução do papel de arquiteto de software” ou “alternativas à existência de um papel de arquiteto de software”. Peço perdão às pessoas que se sentiram mal ou até mesmo de alguma forma ameaçada por um conteúdo assim. Não é dessa forma que quero compartilhar meus pensamentos ou ideias!

Dadas essas considerações, queria me aprofundar agora em mais argumentos sobre o quanto esse papel pode ser problemático nas organizações, descrevendo os cenários que já vivenciei e também propor mais alternativas para evitarmos a criação desse papel nas organizações. Bora lá? Senta que o texto vai ser longo 🙂

Cenário Time de Arquitetura 1 — O departamento que aprova arquitetura

O time tem um problema pra resolver. Uma das pessoas desenvolvedoras do time, a mais sênior, tem uma ideia de como poder resolver. Essa pessoa puxa uma discussão com o time, debate ideias e aí chegam numa conclusão. Mas falta uma coisa: a aprovação do time de arquitetura.

O time, mesmo com todo o contexto do negócio, com senioridade necessária pra tomar decisão desse tipo, ainda precisa validar “com a arquitetura”. Já vi isso ser coluna de board de time, porque em alguns casos, o card ficava impedido com a arquitetura, e não segue sem antes a aprovação desse time

Em algumas empresas, isso até pode ser rápido, mas não é realidade no geral. Adicionalmente, essas aprovações geralmente são mais focadas em padrões ou guidelines do que de fato alguma opinião sobre o problema em si a ser resolvido. É como se fosse uma revisão de pull request feita por pessoas, em tese, mais especializadas.

Muita gente pode argumentar que esse time acaba sendo o responsável por guardar os padrões e evitar que as coisas saiam do controle, em termos de qualidade. Além disso, normalmente esses time são formados pelas pessoas mais sêniors da companhia, então a crença de que elas poderão validar e manter a sanidade dos padrões é maior ainda.

Cenário Time de Arquitetura 2 — O time que inova

Com a premissa de que os times não podem sair criando novas stacks, adotando novas tecnologias e linguagens, o time de arquitetura começa a centralizar o protagonismo da inovação da empresa.

Além dessa premissa de possível caos, nessa empresa esse time de arquitetura era considerado como um laboratório de ideias, onde essas pessoas poderiam ter tempo suficiente pra inovarem, ao contrário dos times, que precisavam focar nos objetivos do trimestre.

Na prática, mesmo que haja o argumento de que não é papel desse time protanizar a inovação, esse acordo tácito acaba vigorando quando novas ideias são “reprovadas” pelo time de arquitetura, com o pretexto de que está saindo das stacks que podem ser usadas. Ao mesmo tempo, esse time de arquitetura se permite testar essas novas tecnologias sem culpa.

Esse tipo de cultura mina todas as possíveis contribuições inteligentes e criativas que podem surgir dos times ou emergirem de pessoas de todos os níveis de competência. Essa é uma das coisas que mais me incomoda nessa abordagem de um time apartado tomando esse tipo de decisão, mas vou comentar logo abaixo, nas alternativas, o que vi e vejo funcionando melhor.

Cenário Time de Arquitetura 3 — Abrindo caminhos e aumentando importância de tech

“Um time de arquitetura tem mais poder de influência para priorizar melhorias técnicas ou mudanças mais profundas na arquitetura”. Essa é outra história que ouvi de uma pessoa próxima que convive com essa estrutura dentro da sua empresa.

Esse tipo de argumento me parece vir de uma necessidade de não deixar os outros times pararem, analisarem e sugerirem mudanças arquiteturais, pois eles estão muito ocupados em entregar as histórias priorizadas.

Nessa mesma empresa, esse time era conhecido por desbravar assuntos novos, ou seja, qualquer tipo de novidade tecnológica, passava por eles antes de qualquer time testar ou experimentar. Como tinham “banda” de atuação mais larga que outros times, tinham tempo suficiente pra poder avaliar essas novas tecnologias e dar seus pareceres a respeito delas. Esses pareceres ficavam armazenados num repositório de documentos, então qualquer pessoa que quisesse sugerir o uso de qualquer tecnologia era impedida de seguir, caso esse time já tivesse experimentado e avaliado como algo que não fazia sentido usar.

Ao invés de “abrir caminhos”, o time de arquitetura fechava.

Cenário Time de Arquitetura 4 — padrões pra inglês ver

Mesmo sendo o time guardião dos padrões e guidelines de arquitetura, alguma decisão sempre “escapa”. Isso começa a acontecer justamente quando esses padrões começam a ficar distantes da realidade e atrapalham o time.

Por exemplo, eu já vi numa empresa o padrão de sempre criar uma migration pra rodar mudanças de campos de uma tabela. Quem aprovava a mudança era o time de arquitetura, que validava se a mudança ía afetar outros serviços. Isso já tinha sido feito pela pessoa que subiu a mudança no database schema, até validando com donos dos serviços que poderiam ser impactados. Mas o time de arquitetura reprovou o pull request alegando que aquilo estava quebrando outros serviços — mesmo a pessoa já tendo feito essa checagem com times impactados.

Sim, em algumas empresas, o time de arquitetura assume essa responsabilidade de aprovação para alguns tipos de mudanças de código. E o pretexto é sempre o mesmo: guardar as boas práticas e manter os padrões de qualidade.

Nessa mesma empresa, as pessoas começaram a burlar esse tipo de aprovação, adotando banco de dados no-schema, pra poder controlar os campos num estilo JSON-like e poder ter autonomia de muda-los sem precisar passar por essa etapa. No fim, esses times adotaram um novo tipo de banco de dados apenas pra evitar essa burocracia de processo, que poderia ser um padrão verificado pelas pessoas ou até validado por uma ferramenta de pull request ou CI.

Cenário Time de Arquitetura 5 — Monolitos, aqui não

Sim, essa história é a que mais me demonstra o quanto esse tipo de cultura de aprovação por um time de arquitetura não faz mais sentido em tempos de desenvolvimento de software moderno.

O time X queria construir um produto, que tinha suas camadas e contextos bem divididos, mas que na visão das pessoas seniors do time, não faria sentido construir vários serviços pra sustentar essa arquitetura.

Apesar de desenharem uma solução desacoplada, o time de arquitetura bateu na tecla de que na empresa, não iriam ser mais construídos monolitos, então eles precisavam dividir aquela aplicação em microserviços.

Veja que, mesmo que nesse caso o desenho da aplicação tenha sido pensado de forma modular, facilmente “desacoplável”, o padrão imposto pelo time parecia mais importante do que a razoabilidade de criar uma aplicação mais simples de se manter, e que não exigia essa complexidade toda.

Alternativas

Eu sei que esses cenários podem ter aparecido pra você em diversas oportunidades durante sua jornada como pessoa desenvolvedora. Algumas empresas encaram esses times como essenciais pra se manter alguma “civilidade” na arquitetura e nos ecosssistemas que lidam, então isso ainda é comum em diversos lugares.

Talvez você não tenha poder ou influência suficiente pra mudar totalmente essa cultura, mas eu queria, com base na minha experiência em empresas de médio (30 a 100 pessoas engenheiras) e grande porte (600), sugerir algumas práticas e definições culturais que podem te ajudar a romper com essa lógica de um time apartado, tomando decisões técnicas importantes sem se aproximar de quem coloca a mão na massa no dia-a-dia.

Alternativa 1 — De Arquiteta de Software à Liderança Técnica

Hoje, as organizações estão mais conscientes de que é necessário ter uma trilha de carreira técnica e outra de gestão de pessoas. Antigamente, não existia esse espaço, e duas coisas podiam acontecer: 1) migrar pra carreira de liderança; 2) virar uma pessoa especialista — uma arquiteta de software.

Essas pessoas geralmente eram, ou são, MUITO experientes, com muita vivência em desenvolvimento de software de larga escala. Então, uma das alternativas que eu vejo fazer sentido é equipará-las aos papéis de liderança técnica, como staff engineers, principal engineers, entre outros.

Mas qual seria a diferença? Em primeiro lugar, há um benefício em remover esse título, pois ele acaba confundido tanto as pessoas que exercem o papel quanto as outras que interagem com ele (ex: são as únicas pessoas que podem discutir arquitetura de software?). Dessa forma, passasse a considerar arquitetura como um pilar de competência necessário para as pessoas desenvolvedoras, inclusive as lideranças técnicas (conto mais disso no fim do post).

Alternativa 2 — Ser parte das estruturas

Uma outra forma de pensarmos nesse papel é fazer parte dos times e estruturas atuais. “Espalhar” essa disciplina através de uma pessoa arquiteta de software nesses times pode ser uma boa estratégia pra desfazer a cultura de centralização em um time apenas.

A outra vantagem que vejo dessa abordagem é que, com essas pessoas mais experientes dentro das estruturas, podemos evoluir outras, passando essa experiência toda. Assim, a gente adiciona mais uma competência necessária pra esse papel, de mentoria para pessoas desenvolvedoras.

Mas claro, pra isso acontecer, a responsabilidade de tomar decisões finais sobre arquitetura precisa sofrer mudanças, e vou comentar na próxima sessão o que já vi funcionando.

Alternativa 3 — Cultura de colaboração e decisões por propostas

Pra que essa mudança de paradigma aconteça, movendo as pessoas de um time de arquitetura para os times, é preciso cuidar do formato em que as decisões passam a serem feitas.

Uma forma disso acontecer é o modelo de RFCs (request for comments) — que é um documento onde as pessoas podem fazer propostas e abrir para comentários (ainda vou escrever um post somente sobre isso logo mais). Esse tipo de documento pode ser usado inclusive para essas decisões de arquitetura mais cross-company.

Num time de mais de 600 pessoas engenheiras, documentos como esse circulavam e elas podiam comentar com pontos de atenção, objeções ou contribuições novas. Qualquer pessoa poderia sugerir mudanças, uso de novas tecnologias, ou de abordagens.

Você pode perguntar se isso era eficiente, se não haviam muitos comentários ou vai-e-vem de decisões. Alguns acordos existiam pra manter a sanidade dessas propostas, além do volume delas e dos possíveis comentários. Por exemplo, todas as RFCs eram “catalogadas” num único lugar (repositório, board), evitando que novas propostas surgissem abordando o mesmo assunto e registrando as que tinham sido discutidas. Outro acordo era de colocar data final para as discussões, com no mínimo 1 semana e máximo de 1 mês de documento aberto para comentários. Um último acordo era sobre bom senso: só comente se tiver alguma posição embasada não em opiniões, mas em fatos e argumentos mais sólidos — ou se tivesse uma objeção muito forte, que pudesse colocar em risco a segurança, confiabilidade ou até a estabilidade do ecossistema da empresa.

Em alguns casos, existiam documentos que geravam muitas discussões, então eram criados grupos de trabalhos sobre o assunto. Um bem famoso foi relacionado a mudança de stack mobile para Flutter — que vocês já devem ter ouvido falar por aí. Esses grupos eram formados por pessoas interessadas no assunto e que possuíam experiência o suficiente pra contribuir. O resultado desses grupos eram compartilhados em reuniões de engenharia semanais. Fluía bem, envolvia as pessoas e gerava visibilidade do que estava sendo feito. Simples, porém efetivo.

Alternativa 4 — Atuar em task-forces cross-company

Outra alternativa para o futuro dessas pessoas que são arquitetas de software, é atuar em task-forces que são cross-company. Em alguns momentos, é necessário tocar um projeto que é transversal aos times, ou seja, que impacta diversos deles nos domínios de software de cada um. Nesse caso, uma task-force com pessoas mais especializadas ou mais experientes pode composta por arquitetas de software.

Veja que essa solução pode ser temporária, mas normalmente esses projetos mais complexos acabam levando um tempo considerável. E a participação de gente com vivência em problemas complexos é bem necessária.

Um exemplo disso que já vi acontecer é na remodelagem da definição do que é um usuário, em sua definição de estrutura, onde os dados únicos ficariam e na sua criação. Praticamente todos os sistemas da empresa consumiam dados de um usuário, então a sensibilidade e importância dessa alteração era grande. Envolver as pessoas mais experientes era quase que uma necessidade pra que pudesse acontecer.

Alternativa 5— De Time de Arquitetura à Guilda de Arquitetura (ou Comunidade Prática)

Uma guilda, é um conjunto de pessoas interessadas num determinado assunto — estou aqui usando o termo que o Spotify cunhou no tão famoso modelo (que não era modelo) que eles usaram durante um determinado tempo. Esse modelo de guilda é interessante para discussões que são em comum, e para arquitetura de software, por exemplo, é um ótimo caso de uso.

Numa das empresas que trabalhei, essas guildas eram responsáveis por discutir novidades sobre arquitetura, mas não só isso: problemas reais dos sistemas e da arquitetura dos serviços eram comentadas e trazidas para a mesa. Depois de algumas discussões, a guilda servia como espaço para trazer propostas, discutir ideias e sair com projetos priorizados — tudo isso alinhando com as pessoas responsáveis pelas priorizações dos times (ex: product managers, lideranças de negócio, etc.).

Outro exemplo são as Comunidades Práticas que tem quase o mesmo princípio de uma guilda. A diferença é que esse espaço é para compartilhar ideias, trazer reflexões e discutir assuntos relacionados ao trabalho das pessoas no dia-a-dia, pegando feedback ou trazendo abordagens diferentes do assunto da comunidade. Esse é outro formato que vi funcionar muito bem, e que pode ser uma alternativa para pessoas que eram arquitetas de software puxarem discussões e continuarem influenciando na arquitetura da empresa.

Alternativa 6— Arquitetura como pilar de avaliação de software engineers

Ao invés de manter a competência de arquitetura de software concentrada em apenas um papel, porque não considerar como uma disciplina? Essa é uma competência que acho extremamente necessária pra qualquer pessoas desenvolvedora.

No dia-a-dia quem desenvolve software lida com arquitetura de software constantemente, e dizer que um papel deveria concentrar esse conhecimento, ou se especializar nisso, é brigar contra a realidade. Desde as pessoas mais juniors até principal engineers, arquitetura precisa ser discutida, modelada e evoluída.

Um exemplo de uma trilha de carreira que possui Arquitetura como pilar:

Alternativa 7 — Papel temporário e rotativo de liderança técnica

Não são todas as empresas que tem a possibilidade de ter uma pessoa Lead Engineer por time. Nesses casos, pra que o questionamento sobre o protagonismo do assunto de arquitetura acabar diminuindo não apareça como um problema, eu sugiro também a criação de um papel temporário e rotativo dentro dos times, com as responsabilidades de:

1. Facilitar conversas sobre arquitetura de software dos domínios que o time trabalha;
2. Organizar as propostas que surgirem sobre evoluções de arquitetura;
3. Representar o time nas guildas, comunidades práticas ou fóruns que for discutido o tópico de arquitetura;
4. Representar o time nas conversas de discovery de produto, dando uma perspectiva de viabilidade e propondo discussões com o time sobre mudanças ou implementações novas;
5. Facilitar sessões de modelagem colaborativa de arquitetura, através de artefatos como Sessões de Whiteboard, EventStorming, etc.;

Esse papel pode ser rotacionado de tempos em tempos dentro do time, para permitir que mais pessoas consigam exercer essas responsabilidades e evoluir as competências necessárias no assunto.

Pode ser temporário, pois essas responsabilidades geralmente pertencem a um papel de Lead Engineer ou Staff Engineer, dependendo de como as empresas tratam os níveis de carreira de liderança técnica.

Conclusão

Você percebeu que muitas das coisas que trouxe de cenários e alternativas são aspectos culturais de uma área de engenharia? Essas coisas fazem parte do que chamamos de cultura, e é preciso que as lideranças, tanto de pessoas como técnicas, nutram e permitam que aconteçam nas estruturas da organização. Não é um trabalho fácil e não há receita pronta. O que citei aqui como ideia pode não funcionar na sua empresa, mas experimentar, avaliar e evoluir coisas é algo que precisa ser feito.

Novamente, peço que você, que é arquiteta de software hoje, faça uma reflexão de como tem sido sua atuação, de como as pessoas desenvolvedoras tem visto seu papel nas discussões e decisões que você é responsável. E de repente, usar uma dessas alternativas que sugeri pode ser um bom caminho de mudança e evolução do seu papel para algo mais colaborativo.

Ufa, foi um texto longo! Obrigado por ler até aqui! Não deixa de me seguir aqui e nas outras redes (insta, linkedin, youtube).

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