Minha mente sempre foi muito lógica de modo que aprendi programar de forma bem natural. Basic (Argh!), um pouco de assembly pro z80, depois Basic pro CPM, Clipper já no mundo dos pcs, C, Visual Fox Pro, VB, C# .Net. Tornei-me perito em SQL Server 7.0-2008. Conquistei todas as certificações M$ disponíveis na época.
Ao longo da minha carreira como desenvolvedor sênior e dba sql, sempre tive preocupação com padronização, reutilização, clareza de código e performance das aplicações que desenvolvi, dos projetos que participei ou os que liderei. Isso desde que trabalhava com clipper como freelancer.
Pra todo problema eu sempre tinha uma solução, e como estava 'bitolado' ao mundo Microsoft achava que essa era a única e com certeza melhor maneira de fazer as coisas. É claro que a visão radical de muitos do mundo open source contribuiu para eu pensar assim.
Minha visão começou a mudar quando assumi o cargo de arquiteto de sistemas numa multinacional com um parque de aplicativos espalhados por sistemas operacionais heterogêneos, desenvolvidos nas mais diversas tecnologias.
De início minhas soluções quase sempre direcionavam o uso de tecnologia Microsoft, de forma natural. Com o tempo porém ficou claro que um arquiteto de soluções não pode ficar limitado a uma visão míope ou preconceituosa. Ao contrário, é nosso papel ter visão ampla, desapaixonada, para poder decidir pela tecnologia mais apropriada para cada cenário. Não existe fórmula mágica, nem existe padrão universal. Portanto, para ser um bom arquiteto que se preocupa com a corporação para a qual trabalha é essencial deixar a visão de desenvolvedor, que tem preferência por linguagem, banco, etc. É preciso ter perspicácia, ver além do óbvio, é preciso saber quando pesquisar outros meios de fazer a mesma coisa. Saber usar o legado a seu favor e não como um estorvo as iniciativas de melhoria sistêmica. É claro que tudo isso não se aprende do dia pra noite. Por isso não existe um curso para arquiteto de soluções, se existir caia fora, é balela. Arquiteto é experiência, é saber ser humilde pra reconhecer quando você erra e que aquela solução que pensava ser a mais adequada, agora depois que você testou, fuçou, esgotou as possibilidades e viu que não era bem como imaginava, precisa ser revista. Se for teimoso e orgulhoso por medo que outros digam: "mas você recomendou a tecnologia A ou B e agora mudou de opnião?", neste caso irá em frente em detrimento da melhor escolha para a sua organização.
Há uma diferença abismal entre um arquiteto de soluções, que deve ter a visão da organização, conhecer muitas tecnologias diferentes (mas não necessariamente ser especialista em tudo), de um arquiteto de aplicação, que conhece a tecnologia que ele domina e tem visão e expectativas limitadas ao seu escopo.
Nem um dos dois está errado. O problema é quando um quer fazer o papel do outro. Se você se intitula "Arquiteto" pense nessas considerações, reflita sobre como desempenha seu papel e você saberá responder pra si mesmo se você é mesmo um arquiteto ou não.
Abraços e até a próxima,
Paulo Barros
Nenhum comentário:
Postar um comentário