Sua empresa não precisa de um time de Arquitetura de Software, e você não precisa ser um Arquiteto de Software

Se você é responsável pela área de tecnologia, você não precisa de um time de arquitetura de software. E e se você é um engenheiro de software, você também não precisa ser um arquiteto de software no futuro.

Calma! Eu sei que se você é o responsável pela area de tecnologia, só quer garantir que as coisa sejam feitas do jeito certo. E se você é um engenheiro, só quer ser um melhor programador. E tudo bem. Porém, um time de arquitetura de software, ou ser um arquiteto de software, não é o caminho ideal. Prometo que até o final do texto você vai saber os motivos e as alternativas. Vamos lá!

Existe um tema bastante polêmico entre as empresas de tecnologia referente ao cargo de arquiteto de software. Ter ou não ter arquitetos de software? Quando ter?

O título de arquiteto de software tem um certo glamour e é muito desejado pelos desenvolvedores. Eu me lembro de quando eu comecei a trabalhar como programador e muitos amigos tinham como ambição ser um arquiteto de software no futuro. O desejo de ser arquiteto de software normalmente significava:

• projetar e construir uma solução de software considerada de qualidade e robusta;
• de qualidade porque seria de fácil extensão e manutenção;
• robusta porque suportaria grande volume de requisições e dados;
• que fosse confiável e segura;
• e que fosse legível e elegante. Quem não gosta de um código bonito?

O senso comum era de que a função principal do arquiteto era garantir uma boa implementação dos requisitos não funcionais, mais conhecidos como: performance, escalabilidade, disponibilidade, segurança, manutenibilidade, gerenciabilidade, confiabilidade e extensibilidade.

Acredito que foi com esse propósito que os times de arquitetura surgiram e se dividiu as responsabilidades dos desenvolvedores, ou engenheiros de software, e os arquitetos de software. Os engenheiros de software ficaram com a responsabilidade de criar as funcionalidades de negócio, ou também como eram conhecidos, requisitos funcionais.

Assim chegamos em algumas organizações que vemos hoje: um time de Engenharia de Software, com engenheiros de software, gerente de engenharia, diretores de engenharia e VP de engenharia. E outro time de Arquitetura de Software com arquitetos de softwares respondendo para um Chief Architecture Officer.

Como funcionam os times de Arquitetura de Software

O fator que vai determinar como os times de engenharia e arquitetura funcionam é a quantidade de engenheiros necessários para entregar os produtos e funcionalidades que o negócio exige.

Normalmente uma empresa pequena, de algumas dezenas de engenheiros, não vai ter um time de arquitetura, porém uma empresa com algumas centenas de engenheiros vai sentir falta de criar padrões para que todos os outros engenheiros possam seguir. Além de criar e manter esses padrões o time de arquitetura também vai garantir que os engenheiros estão seguindo os padrões.

E foi assim que eu tive minha primeira experiência com um time de arquitetos. Depois de alguns anos eu decidi sair de uma empresa com dezenas de desenvolvedores onde nós éramos responsáveis por todo o processo de desenvolvimento de um software, desde a análise até a manutenção em produção e entrega de novas funcionalidades, e entrei em uma empresa com centenas de desenvolvedores, onde minha responsabilidade era primeiro criar um documento de visão com toda especificação do software, casos de usos, modelos de dados e requisitos não funcionais antes de implementar qualquer solução.

Esses documentos eram aprovados pelos times de negócios e arquitetura. Eu tinha uma reunião com o arquiteto de software durante 30 minutos, ele fazia uma leitura dinâmica do documento que eu fiz, esse documento projetava a quantidade de requisições e volume de dados que minha aplicação teria, ele assinava o documento e com a sua assinatura eu estava livre para implementar a minha solução.

Nesse caso a empresa estava passando por uma migração de uma arquitetura distribuída com Java EE e EJB para uma arquitetura SOA. A regra era que tudo novo precisaria ser escrito em SOA, o problema é que faltavam peças escritas em SOA. O arquiteto de software não tinha tempo a perder com esses detalhes, tinha que ser escrito no SOA e pronto. Essa era a nova regra do time de arquitetura.

Depois de um ano eu troquei de empresa novamente e agora para uma empresa com dezenas de engenheiros e bastante trabalho terceirizado para fábricas de software, com outras dezenas de engenheiros. Essa empresa também tinha um time de arquitetos que decidiu todas as ferramentas que seriam usadas para o desenvolvimento nos primeiros meses da empresa. Os arquitetos decidiram tudo de melhor segundo o que dizia o Gartner.

O time de arquitetura raramente, ou nunca, fazia entregas de funcionalidades e consequentemente não usava os padrões criados para entregar código em produção. Acredito que a maioria deles nem escreviam códigos. Inclusive a proposta de uma das ferramentas era escrever soluções arrastando caixinhas. Quem conheceu o Oracle BPM?

A arquitetura utilizada foi SOA, com Oracle Service Bus, Oracle API Gateway, Oracle BPEL e muitos serviços em Java que se comunicavam através do Service Bus utilizando o protocolo SOAP. O banco de dados também era Oracle. Para o front-end também era utilizado uma ferramenta da Oracle chamada Oracle WebCenter Sites.

O mais interessante das ferramentas era o SVN. Porém, na época o Git já era tão superior que a fábrica de software resolveu usar o Git e automatizar a entrega para o SVN para cumprir a regra do SVN. Acredito que essa regra existia mais pela falta de comunicação do que pela preferência pelo SVN. É uma consequência de trabalhar em silos.

Independente da arquitetura, o resultado foi que o produto não teve aderência e a empresa demitiu grande parte dos funcionários e teve que pivotar o negócio. Nessa mudança o time de arquitetura acabou desaparecendo e as decisões de arquitetura foram absorvidas e executadas por uma equipe de engenheiros que participavam ativamente nas entregas dos produtos. Na prática é difícil afirmar que as decisões foram melhores, porém o time que tomava as decisões era o mesmo time que colhia os resultados, isso foi uma mudança importante. Trabalhei um bom tempo em alguns time de produtos nessa empresa, sem equipes de arquitetura.

Depois de um bom tempo acostumado a não trabalhar com um time de arquitetura de novo, eu fui para uma empresa que também era orientada a produtos e tinha um time de arquitetos. Em uma empresa orientado a projetos, como a que eu tinha que escrever documentos de visão e casos de uso, o papel do arquiteto é só mais uma papel em toda a cadeia burocrática, porém em uma empresa orientada a produto, a equipe de arquitetura se torna o verdadeiro empecilho para entregas de funcionalidades e inovação.

Normalmente um time organizado em volta de produtos é composto por Product Manager, Product Designer e alguns Software Engineers. A ideia é que esse time tenha autonomia para entregar todas as funcionalidades do produto fim a fim. Conhece o conceito de two pizza team?

O Product Manager é basicamente responsável por gerar hipóteses que serão validadas com o mínimo de esforço dos engenheiros. Várias hipóteses serão descartadas e as que sobreviverem a aprovação do cliente serão então evoluídas para serem estendidas, escaladas, rescritas com mais qualidade e etc. Famosas dívidas técnicas.

Nesse tipo de desenvolvimento o time precisa ter completa autonomia para decidir o que construir, quando construir e o mais importante como construir.

Por outro lado o time de arquitetura tem o objetivo de criar padrões e garantir que os times de engenharias sigam estes padrões. O problema é que esses padrões são feitos para garantir que a solução final seja robusta e a maior parte das entregas do time de engenharia não precisará ser robusta e será descartada o mais rápido possível. Na verdade, quanto menos código para testar uma hipótese melhor para o time de engenharia e terrível para o time de arquitetura. Perceberam o dilema?

Baseado nessa experiência eu tenho alguns motivos pelos quais eu acredito que toda empresa orientada a produtos não deveria ter um time de arquitetura.

• Um time de arquitetura representa um departamento diferente do time de engenharia. Departamentos diferentes, gestores diferentes e no fim, objetivos diferentes. Essa é causa de constante discussões onde ambos estão certos porém com objetivos que apontam para direções contrarias. É um trabalho em silos.
• Eu costumo dizer que na fabula do porco e a galinha, o engenheiro é o porco e o arquiteto é a galinha. Isso porque todos os padrões gerados pelos arquitetos serão usados diariamente pelos engenheiros sob a supervisão dos arquitetos. Enquanto um decide qual é a arquitetura apropriada e como os sistemas devem se comunicar, o outro é responsável por implementar. O engenheiro vai lidar com os problemas da arquitetura no dia a dia enquanto o arquiteto só vai ver a beleza das caixas e linhas que se conectam no diagrama. O dia que acontecer um problema em produção quem vai resolver? O porco está comprometido e a galinha está apenas envolvida.
• Muitos times de arquitetura fazem programas de intercambio, onde os arquitetos devem ativamente participar de sprints desenvolvendo novas funcionalidades junto com os times de engenharia de produto. Nesse período ele coleta feedbacks da arquitetura e volta para o seu departamento para implementar as melhorias. Isso acontece uma ou duas vezes a cada semestre. Na minha opinião esse tipo de programa só reforça o quanto esses dois times trabalham em silos e pessoalmente eu nunca vi grandes mudanças serem implementadas com esse tipo de feedback.
• O time de arquitetura normalmente tem a palavra final sobre as decisões técnicas e por isso elas são tomadas de maneira unilateral, não considerando as necessidades do negócio ou as necessidades de engenharia. Isso também gera uma sensação de que o engenheiro é um second class citizen ou cidadão de segunda classe. Ele deve receber a aprovação de alguém que não tem os mesmos incentivos que ele: testar o máximo de hipóteses possível com o mínimo de esforço necessário.
• Em algumas empresas a supervisão do time de arquitetura é tão forte que nenhum pull request é integrado ao código principal sem a aprovação de um arquiteto. Nenhum deploy é realizado em staging ou produção sem uma aprovação de um arquiteto. Isso é exterminar com a autonomia de qualquer time.

Acredito que o problema principal pode ser atacado com o alinhamento dos objetivos entre as areas de arquitetura e engenharia. Infelizmente o título de arquiteto de software está tão enraizado nesse modelo de desenvolvimento em silos que apenas removendo esse departamento e título será possível realizar alguma mudança significativa.

Mas sem arquiteto de software como ficam os requisitos não funcionais?

Se você chegou até aqui provavelmente deve estar perguntando: E a solução? Quem vai garantir os padrões de qualidade?

Se o time é pequeno, os próprios engenheiros mais seniores vão decidir a arquitetura. Se o time é maior você vai precisar criar uma guild, comitê, ou o nome que você desejar para o grupo, que vai participar ativamente dessas decisões, porém esse grupo ainda deve trabalhar em um time de produto e ainda têm suas responsabilidades com relação as funcionalidades do produto.

Você pode ter um comitê para cada situação especifica, qualidade de código, pipeline de deliver, linguagens de programação, banco de dados e etc. E o ideal é que qualquer desenvolvedor possa participar desse grupo, pelo menos passivamente, e que as decisões sejam tomadas sempre mediante algum racional.

Idealmente, deve ser definido a estratégia de engenharia que o time de engenharia vai seguir, isso vai criar os princípios que guiará as decisões de tecnologia.

A estratégia do time de engenharia é ter poucas ferramentas para acelerar o desenvolvimento e integrar os serviços de maneira mais fácil? Tudo bem. A estratégia vai ser ter mais liberdade e flexibilidade para utilizar a ferramenta apropriada com o custo de ter um desenvolvimento mais longo em algumas ocasiões? Tudo bem também. Não existe bala de prata.

Esses princípios vão guiar as decisões técnicas que vão ser definidas de maneira colaborativa pelas pessoas que mais vão sofrer o resultado positivo e negativo dessas decisões. O livro Staff Engineering apresenta uma opção para se criar a estratégia de engenharia.

O fato é que alguns engenheiros vão trabalhar na arquitetura enquanto também trabalham no time de engenharia. Eles respondem para o mesmo gestor e têm o mesmo objetivo: testar o máximo de hipóteses possível com o mínimo esforço e depois criar soluções robustas que foram foram já foram validadas.

Esses engenheiros normalmente são conhecidos como staff plus engineers e podem ter títulos como senior software engineer, technical lead, staff engineer, distinguished engineer entre outros. Eles também podem ter outras responsabilidades como ajudar a definir a estratégia de engenharia, ajudar o time de contratação, influenciar outros engenheiros em soluções técnicas e implementações, dar mentoria a outros engenheiros, patrocinar outros engenheiros que querem progredir na carreira e etc. Dessa forma os engenheiros mais juniores também podem vislumbrar um caminho mais claro para crescer em vez de querer apenas ser o arquiteto de software, que normalmente envolveria trocar de departamento.

O trabalho de arquitetura de software continua sendo executado porém com outras prioridades. Vou apresentar uma lista resumida da diferença desse modelo para o modelo tradicional de arquitetura de software:

• Existe apenas um objetivo e os requisitos não funcionais são tratados como parte do produto. Afinal de contas, ter uma funcionalidade robusta também deve ser uma prioridade para o time produto.
• Menos decisões unilaterais e top-down. O staff+ engineer é responsável por entender o problema que o time quer resolver e influenciar na solução junto com outros engenheiros.
• Autonomia para o time de produtos decidir o que, quando e como implementar uma solução e arcar com as consequências dessa solução.
• Menos controle sobre as pessoas e mais qualidade de código. Eu acredito que uma arquitetura incremental e evolutiva, evitando otimização precoce do código tem um resultado final com mais qualidade.
• Consequentemente mais inovação, mais erros e aprendizados e mais engenheiros de software motivados a fazer um bom trabalho.

Mas nada é tão simples como parece

Outro problema comum é definir quem serão os engenheiros que vão focar no desenvolvimento de novas bibliotecas, do pipeline de integração e deliver, de serviços que serão utilizados por toda empresa, por exemplo, uma API de disparo de e-mails, ou até de decidir entre construir um software novo ou comprar um software pronto.

Uma das maiores dificuldades em tecnologia é conciliar o desenvolvimento de coisas que não vão trazer valor diretamente para o negócio mas que vão acelerar o desenvolvimento de novas funcionalidades. Isso é um constante cabo de guerra.

Eu acredito que isso possa evoluir naturalmente. Primeiro os times de produto podem assumir essas responsabilidades já pensando que outros times poderão usar a ferramenta no futuro. Os novos times que usarão essa ferramenta podem participar de forma colaborativa com melhorias e correções.

Conforme o time for crescendo, uma alternativa é criar times de produto que sejam responsáveis pelo desenvolvimento dessas ferramentas internas para os desenvolvedores. Existem vários nomes para esses times: Developer Experience, Times de Produtos Interno ou Times de Plataforma. Dependendo da quantidade de desenvolvedores será necessário um ou mais times de plataformas.

Por exemplo, pode existir um time de Developer Experience que vai criar soluções para um novo desenvolvedor fazer o setup do ambiente, aprender as tecnologias e começar a ser produtivo o mais rápido possível. E o time de plataformas pode criar ferramentas para facilitar todo o processo de integração e entrega de código em produção.

Não importa muito como você vai chamar esse time, o mais importante é garantir que a responsabilidade seja bem definida e que isso não tire a autonomia dos times de engenharia. Alguns pontos importantes.

• O time de engenharia não deve ser obrigado a utilizar as ferramentas desenvolvidas pelo time de plataforma. As ferramentas devem ser tão boas que o time de engenharia prefira utilizar elas porque serão mais produtivos.
• O time de plataforma precisa entender as necessidades do time de engenharia e da estratégia da empresa. Os engenheiros são os clientes principais do time de plataforma.
• O time de produtos precisa poder participar ativamente das decisões e das coisas que estão sendo construídas pelos times de plataforma. As prioridades devem ser de acordo com as dores da empresa e dos engenheiros. E por fim os próprios engenheiros podem entregar códigos para serviços comuns e bibliotecas comuns.

Acredito que mais detalhes pode ser encontrado nesses artigo sobre times de plataforma.

Se você chegou até aqui deve ter percebido que eu não tenho nada contra o trabalho de arquitetura de software, na verdade acredito que ele seja muito importante, principalmente quando alinhado com os objetivos de negócio e produto.

O verdadeiro problema não está no título arquiteto de software, e sim no modelo de trabalho que foi construindo nas empresas. Apesar de eu pessoalmente não gostar do título arquiteto de software, se pra você esse título não representa o modelo que eu descrevi, acredito que não exista grandes problemas.

E espero que com minha opinião você possa buscar empresas que valorizam o trabalho colaborativo em vez do modelo de arquitetura de software em silos.