Inspirado por mais um post no GUJ, resolvi escrever um pouco meus pensamentos sobre esta tão comentada e tão pouco definida função. Quem é o arquiteto de software? O que ele faz?
Vamos olhar o que é Arquitetura de Software segundo o livro Pattern-Oriented Software Architecture, Volume 1: A System of Patterns (Hardcover) (tradução livre minha):
A arquitetura de um software é a descrição dos subsistemas e componentes e suas relações. Subsistemas e componentes são tipicamente especificados em diferentes pontos de vista para mostrar suas propriedades funcionais e não funcionas que sejam relevantes. A arquitetura é um artefato. É resultado de uma tarefa de design de software.
Nos baseando por este conceito, podemos dizer que o arquiteto é quem especifica os subsistemas e componentes de um software e como estes se relacionam.
Olhando por esta ótica, não parece que o arquiteto deva saber sequer programar. A certificação de Arquiteto Java da Sun, por exemplo, não exige esta habilidade. A prova exige conhecimentos de UML, Design Patterns clássicos e JEE, sobre a arqutietura de aplicações distribuídas e as APIs Java EE.
Ainda que acredite que a ementa da Sun seja parte integrante da formação de um bom arquiteto, algum tempo atrás em uma entrevista para o JavaPosse com Burr Sutter, líder do Chapter de Atlanta da IASA , um conceito que acredito que seja o mais importante: Um Arquiteto deveria ser capaz de fazer o sistema todo sozinho.
Não é preciso ser um super-homem para isso, na verdade basta apenas experiência. É claro que podemos ter um arquiteto que nunca participou de projetos como júnior (um em um outro cargo que não costume tomar muitas decisões sobre design de alto nível) ou pleno (ou outro cargo onde você toma muitas decisões o tempo todo mas não tem a palavra final), mas exceto em raros casos de pessoas geniais este “arquiteto nato” não vai conseguir produzir nada muito bom por nunca ter atuado na linha de frente.
Acho que quando a emrpesa possui uma equipe pequena, o arquiteto surge como o gerente da área ou como um líder escolhido por meritocracia. O papel de líder de desenvolvimento separado do de arquiteto é algo preocupante já que as atividades são muito ligadas. O arquiteto deve ser líder e mentor da equipe (não necessariamente gerente), este é seu papel fundamental.
Para resumir esta conversa vou tentar descrever o perfil de um arquiteto que eu contrataria para minha empresa hoje:
Uma pessoa experiente em projetos de diversos tamanhos, preferencialmente em mais de um tipo de negócio e com diversas tecnologias. Programa fluentemente na linguagem a qual o sistema vai ser produzido e em algumas outras, mesmo concorrentes.
Sua mesa ou bookmarks estão cheios de repositórios e catálogos, ele sempre procura referência bibliográfica sobre o que está sendo feito, mesmo que signifique ler um paper de 1975 sobre computadores com bytes de 9 bits. Está sempre sabendo das novidades na sua área de atuação, mesmo que ele nunca tenha nem entrado do site daquela tecnologia nova, ele já ouviu falar e está disposto a ouvir se alguém quiser falar mais sobre ela.
O design que ele produz é simples e extensível ao extremo. Serve como linha-base para o programador mas não sufoca o instinto criativo. Este é criado após mesas redondas com os programadores e demais interessados onde cada idéia é debatida.
Ele sabe que o design mais importante é feito diariamente, então está sempre acompanhando o repositório de código. Uma de suas primeiras atitudes foi convencer a gerência da necessidade de um build contínuo com relatório de métricas de qualidade no código. Também evangeliza ferramentas como PMD e FindBugs e exige que código tenha testes unitários. A qualidade da equipe é fundamental então ele insiste com as pessoas responsáveis que rodas de leitura, workshops e treinamentos sejam realizados.
Para vender todos os seus projetos à gerência, ele aprendeu a falar a linguagem dos gerentes. Um dos papéis mais importantes do seu trabalho é transformar métricas em algo que o seu chefe consiga entender, algo que msotre o real benefício do foco na qualidade do sistema. Mesmo sendo um excelente técnico, ele tem que desenvolver habilidades de comunicação com quem manda na empresa.
Cara, perfeito. Acho que esta figura de arquiteto de software eh a ideal para qualquer empresa. O problema eh que nem sempre as empresas contam com este tipo de profissional…
Sabe a diferença entre um arquiteto e Deus? É que Deus não pensa que é um Arquiteto !
[...] Ainda naquele papo de arquitetura, Grady Booch escreve em seu blog suas definições pessoais de design: As a noun, design is the named (although sometimes unnamable) structure or behavior of an system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions). [...]
legal
Gostei hein P.C.
Esse arquiteto que você contraria é o que está preocupado não em vender e ver a cor do $$, mas sim em fazer alguma coisa decente. E o mais importante de tudo: sempre se atualizando e com muita humildade.
[...] adianta dizer que, em desenvolvimento de software, um bom programador pode não ser um bom projetista e ao contrário do que alguns pensam, projetistas (ou arquitetos) são as pessoas que devem fazer [...]
[...] Falando ainda de arquiteto de software, tem um outro post bem legal: http://philcalcado.com/2006/02/19/o-que-e-um-arquiteto/ [...]