Há 7 anos ouvi pela primeira vez o termo Arquiteto de Software numa feira sobre Java promovida pela Global Code em São Paulo. E surgiu a pergunta ao final de uma das palestras:
Quanto tempo leva para se tornar um arquiteto de software?
Coçando o queixo, o palestrante exitou alguns segundos e então lançou:
Com uns 5 anos e muita dedicação é possível formar um arquiteto.
Desde então, como alguém que respira TI, comecei a perseguir o tão famigerado título.
O que, afinal, seria um arquiteto de software?
Há muitas definições. Algumas você pode encontrar na Wikipédia, na InfoQ, no Blog da GlobalCode, no fórum Javafree.
Não só a definição formal varia, como há muitas visões diferentes sobre a real necessidade deste tipo de profissional.
Não quero repetir aqui o que já existe em dezenas de sites. Então vou resumir em poucas palavras a minha opinião:
Arquiteto de Software é o especialista técnico que enxerga mais longe e mais profundamente, podendo orientar e participar das decisões tecnológicas.
O que não é um arquiteto de software
Existe um estereótipo de arquiteto análogo ao Arquiteto do filme Matrix, isto é, que fica escondido em uma sala tomando todas as decisões importantes e impondo-as aos meros programadores que não podem pensar por si mesmos.
Algumas pessoas podem pensar que é possível atingir um nível tão extraordinário de conhecimento, ou pelo menos de arrogância, de modo que uma pessoa possa tomar todas as decisões acertadas desde o início em um projeto de desenvolvimento de software.
Muitos, contando comigo, acreditam que tal estereótipo é uma aberração e deveria ser banido completamente.
Porque você ainda não é um arquiteto
Este é um tópico retórico. Estou pensando em mim mesmo. Na verdade, estou pensando também em meia dúzia de “arquitetos” que entrevistei por esses dias.
Algo que eu notei em arquitetos de verdade é que eles possuem maturidade profissional e confiança bastante grandes. Isto advém de larga experiência em suas áreas de atuação e conhecimento que vai do quesito técnico mais fundamental até o relacionamento com clientes e fornecedores, claro, dentro de sua competência. Além disso, arquitetos comunicam suas ideias de forma clara e muito convincente.
O que notei em pseudo-arquitetos é quase o oposto. Imaturos, eles se auto denominam arquitetos após poucos projetos e poucos anos de experiência. Falta-lhes humildade. Alguns, como já foi meu caso, acham que são arquitetos simplesmente porque conhecem um pouco mais do que a grande massa de desenvolvedores, portanto acham-se aptos a orientar os outros.
Mas deixe-me informar-lhe: só porque você conhece meio dúzia de frameworks, já trabalhou em uma dúzia de projetos, lê alguns livros em casa, usa um ou dois recursos mais avançados de uma linguagem, isso não o torna apto a guiar estrategicamente as decisões tecnológicas a longo prazo de uma empresa ou produto, principalmente se houver mais do que quatro ou cinco envolvidos. Quem dirá uma multinacional.
A maioria dos pseudo-arquitetos que já conheci ficam fascinados com qualquer novidade tecnológica. Estão sempre usando frameworks da moda, mas nunca consideram o contexto mais amplo de uma organização, que as transformações daquela tecnologia recente irão acarretar em custos e manutenção desnecessários, talvez até em prejuízo, assim como na falta de documentação que irá fazer seus colegas menos técnicos arrancarem os cabelos.
Muita gente se diz Arquiteto Java e não conhece nem as APIs padrão do JavaSE de forma abrangente, não conhece os principais frameworks e suas alternativas, nem sabe responder quais as vantagens de determinadas APIs sobre as outras, exceto talvez casos mais básicos.
Eles não conhecem profundamente padrões arquiteturais reconhecidos e padrões de projetos, assim como seus respectivos impactos positivos e negativos em um projeto, portanto, mesmo que sejam gênios e saibam resolver tudo por conta própria, não sabem comunicar-se devidamente com outros desenvolvedores.
Pior, eles não conseguem avaliar o impacto de suas decisões em médio e longo prazo, o que hoje gera bilhões em prejuízos em manutenção de sistemas que se tornam legados antes mesmo da conclusão do projeto.
Um desenvolvedor sênior não se torna arquiteto automaticamente por conhecer um número de tecnologias ou por tempo de empresa, mas por suas efetivas experiências e conhecimentos acumulados que o tornam um guia confiável para ajudar seus pares a trilhar o caminho das pedras.
Torne-se um arquiteto
O mundo de TI precisa de arquitetos, principalmente de melhores e mais maduros. Poucas pessoas aceitam o desafio. A grande maioria desiste da parte técnica e parte para gerência de projetos ou análise funcional. Outros ficam o resto de suas vidas brincando de serem geeks em pequenos projetos isolados, mas sem assumir responsabilidades ou riscos.
Na GFT, onde trabalhei recentemente, existe uma carreira técnica que culmina em ser um arquiteto de verdade. Um arquiteto sênior exige algo em torno de 15 anos de experiência, se for uma boa experiência, além de vários outros requisitos. A princípio eu não achava razão nesse tipo de limitação, mas hoje percebo que o tempo muda as pessoas, e quando o faz para melhor, elas se tornam melhores profissionais.
Considerações
Se você tem aquela imagem romântica hollywoodiana de um garoto recém-formado que sai da faculdade sabendo mais do que pessoas com décadas de experiência, esqueça isso, por favor. Esta é a mentira de uma geração preguiçosa, que pensa poder suprir deficiências de personalidade e de disciplina com uma pesquisa de cinco minutos no Google e no fim pensa ter obtido sucesso. Isso se dá apenas por plena falta de consciência sobre as próprias limitações.
Tornar-se um arquiteto exigirá, sim, muito tempo de experiência e dedicação, mas certamente isto também trará suas próprias glórias, honras e recompensas.
E aí? Vai encarar ou vai continuar brincando?
