Esse post foi originalmente publicado em 2019-01-29. Atualmente, trabalho como especialista de engenharia numa fintech. Não tenho o chapéu de arquitetura, mas ainda exerço a disciplina.

Eu já escrevi e reescrevi esse texto umas três vezes. O título era algo como “O que é Arquitetura, Afinal?” — bem original, não? Minha ideia inicial era definir Arquitetura de Software, Soluções e Corporativa (existe uma multitude de materiais sobre isso). Mas existe tanta intersecção dentro dessas disciplinas, tantas definições subjetivas, tantas interpretações diferentes que acabei desistindo. Vou fazer jus ao título atual e escrever o que eu faço como um arquiteto de soluções.

Escrevo Código

Tem épocas que escrevo bastante código para fazer provas de conceito ou para criar uma espécie de estrutura inicial para os desenvolvedores — como um boilerplate ou stub. Por exemplo, em algumas empresas que trabalhei, o RabbitMQ foi adotado como middleware de mensageria e muitos desenvolvedores não sabiam usá-lo. Com isso, acabava gerando exemplos sobre como abrir conexões, usar canais, o que é thread-safe, o que não é, como os objetos devem ser descartados, como lidar com as falhas, etc. Acaba sendo uma espécie de mentoria técnica. Algumas vezes acabava fazendo isso em uma linguagem pouco conhecida para mim, mas como geralmente o princípio é o mesmo para todas, conseguia fazer sem grandes dificuldades.

Minhas linguagens “principais” são C# e Python, mas já fiz coisas em PHP, ASP, VB, Java, Scala e Node profissionalmente. Sempre digo que a linguagem de programação é um fator secundário para um arquiteto que trabalha em um nível mais alto de abstração.

Em alguns casos, durante reuniões com o time de desenvolvimento, a aplicação de um padrão de projeto (design pattern) fica muito evidente e acontece de alguns desenvolvedores não conhecê-lo. Como sou uma pessoa que funciona melhor na base de exemplos práticos, nesses casos, eu também mergulho no código para apoiar na passagem da ideia daquele padrão de projeto.

Eu conheci arquitetos de soluções mais distantes do código; não se importavam muito em programar. Como eu realmente gosto de programar, sempre que tenho uma oportunidade, tenho um prazer enorme em fazê-lo.

De vez em quando e quando são pequenas, escrevo aplicações completas. Por exemplo, onde trabalho atualmente, começamos a adotar o uso de inteligência artificial e visão computacional. Como o time de desenvolvedores é enxuto, porque quase todo desenvolvimento é feito por empresas terceiras e que não têm experiência nesses assuntos, acabei escrevendo uma aplicação que verifica se um documento específico foi assinado manualmente através de visão computacional.

Me Comunico com Públicos Distintos

Todo mundo já deve ter ouvido falar que uma habilidade necessária para um arquiteto é se comunicar bem. Muitas vezes, quando defino uma solução, tenho que ser capaz de defendê-la e comunicá-la tanto para gerentes de áreas de negócio, quanto para um time técnico que será responsável por implementá-la.

Se um arquiteto não tiver uma boa comunicação e não souber se expressar de maneira clara para diferentes públicos, esse profissional enfrentará muitas dificuldades. Um desenvolvedor também precisa se comunicar, mas não é comum ter que defender uma ideia técnica para um time não técnico — isso já não acontece com um arquiteto.

O formato da minha comunicação variou bastante de empresa para empresa e de times para times. Faço slides para times não técnicos, diagramas de componentes e sequência para times técnicos, algumas documentações de APIs e às vezes — mais raramente ultimamente — documentações de requisitos. Trabalhei em uma empresa em que o time de arquitetura mantia um “Caderno de Arquitetura”, que era uma espécie de wikipedia interna com todos os desenhos, requisitos, premissas, volumetrias e expectativas das soluções que desenhávamos. Cada arquiteto era responsável por criar e atualizar as páginas dos projetos que arquitetava. É uma ideia bacana.

Faço Gestão e Acompanhamento de Projetos

Em alguns projetos, principalmente aqueles feitos em parceria com fornecedores externos, é comum eu fazer a gestão. Alguns precisam de uma gestão mais formal com cronogramas, relatórios de status, reuniões periódicas; outros precisam apenas de um acompanhamento mais informal. Algumas vezes, participo de negociações de preços para aquisição de um serviço ou produto. Então, quando te disserem que arquitetos precisam ter noções de gestão de projetos, acredite.

Estudo e Faço Muitas Pesquisas

Bom, se eu não estudar e não pesquisar as últimas tendências, conceitos, paradigmas, entre outros, eu simplesmente estou fora do jogo. Provavelmente conseguiria trabalhar em empresas desatualizadas tecnologicamente, mas não quero isso.

As coisas vão melhorando naturalmente e se eu não acompanhar para ser capaz de tomar decisões informadas sobre um novo serviço, componente, etc., para beneficiar a empresa para qual trabalho, passo a não ser mais interessante. A gente sabe que no final do dia, o que importa para uma empresa — uma instituição que tem o lucro como objetivo — é o dinheiro. E um arquiteto que é capaz de escolher as tecnologias mais eficientes e de menor custo, vai maximizar o lucro para essa empresa. A conta é bem simples.

Eu gosto de estudar, então essa parte não é tão difícil para mim. É claro que existem períodos que estudo menos e logo vejo que o trem passa rápido. O lado bom de estudar bastante é que você aprende a aprender mais eficiente e rapidamente — cria uma espécie de framework para estudar.

Aprendo Lições Importantes

Acho que essa é uma das partes mais legais e valiosas da vida, não só do lado profissional — aprender lições importantes.

Quando um arquiteto desenha uma solução, o contexto importa. Arquitetura é lidar com restrições. Claro que hoje sou um arquiteto melhor do que no passado, e um dos atributos mais importantes que aprendi é que quase tudo que a gente faz (em qualquer contexto) é para outras pessoas. De pessoas para pessoas.

Hoje, quando desenho algo, o peso que as pessoas têm é muito maior do que no passado. São pessoas que vão implementar minhas soluções. São pessoas que vão monitorar essas implementações. Geralmente, são pessoas que vão usar os sistemas resultantes das minhas soluções. Gosto de pensar na experiência e impressão das pessoas que se relacionam pela primeira vez com a arquitetura que desenhei. Essa experiência pode ser a de um desenvolvedor que acabou de entrar no time e vai precisar entender a arquitetura para poder trabalhar. Pode ser a do time que vai monitorar as aplicações que funcionam dentro dela. Essa experiência também pode ser a de ver o desenho dela em um power point para apresentar para pessoas.

Ainda no âmbito das pessoas, algumas decisões arquiteturais (ou quaisquer outras, na verdade), mexem com emoções e sentimentos de outras pessoas. Algumas pessoas podem ter apego sentimental a um componente que pretendo substituir, por exemplo. Muitas vezes preciso levar isso em consideração. Talvez o famoso triângulo de ferro qualidade/tempo/dinheiro possa ser expandido em alguma nova dimensão para incluir as questões humanas que podem impactar em qualidade/tempo/dinheiro. Lembre-se, de pessoas para pessoas.

Outra lição importante que aprendi na vida e que se aplica na disciplina de arquitetura é que errar é importante e te faz crescer. Uma boa pergunta para uma entrevista poderia ser sobre os erros do entrevistado. Tem uma máxima que diz que só erra quem faz. Eu considero um ótimo indício de autoconfiança e até caráter nas pessoas que assumem os erros e falam confortavelmente sobre eles.

Quando estava na 5º ou 6º série, um professor de português disse num tom de poucos amigos que não elogiava ninguém. Disse que elogios não ajudavam ninguém. Filtrando o episódio e colocando no contexto dos erros, a gente consegue dizer que talvez aprende mais errando do que acertando. Os erros doem, nos fazem nos sentir humildes, e isso é bom.

Não quero me gabar, mas já errei bastante :)

O que é Arquitetura, Afinal?

Bom, para mim é também tudo isso que escrevi e um monte de outras coisas — práticas e subjetivas.

Se você é desses, se conecte comigo por aqui ou por outra rede social. Mantenho contas praticamente read-only no Twitter, Facebook e Instagram, e contas normais no LinkedIn e aqui :) Tenho uma conta no Github que uso muito pouco. Todas elas são fáceis de achar se procurar por Zanfranceschi.