Who gets to be a software architect

Bookmark and Share

Dilbert - ArchitectOlá pessoal!

Neste post gostaria de compartilhar um resumo do conteúdo de um podcast que ouvi recentemente, cujo tema principal era justamente o título deste post: “Who gets to be a software architect”. Acredito que o assunto seja bastante relevante, pois tem sido tema de diversas discussões em diversas comunidades, demonstrando que ainda há pouca maturidade e falta de consenso no mercado.

O podcast foi disponibilizado pelo Oracle Technology Network, no canal ArchBeat, que trata de assuntos relacionados à arquitetura. Para quem ainda não conhece, vale a pena conferir. O canal aborda assuntos diversos relacionados à arquitetura, tecnologias e tendências, como SOA, Cloud Computing, Governança, Enterprise Architecture, Business Architecture, etc.

O podcast consistiu em uma panel discussion, composta por quatro participantes de peso, além do Bob Rhubart, host dos podcasts deste canal. São eles:

  • Ron Batra: Oracle ACE Director, Diretor de desenvolvimento de produtos cloud computing na AT&T;
  • Brian Huff: Oracle ACE Director, Chief Software Architect na Bezzotech, Inc.;
  • Randy Stafford: Membro do Oracle’s A-Team – um grupo de arquitetos que trabalham em um grupo de desenvolvimento Oracle Middleware;
  • Eric Stephens: Enterprise Architecture Director, na Oracle;

A seguir consta o link para mais detalhes do podcast, onde também pode ser baixado o áudio: https://blogs.oracle.com/archbeat/entry/show_notes_who_gets_to_be_a_so.

Separei o conteúdo da discussão em alguns temas, que podem ser conferidos a seguir. Procurei manter o conteúdo fiel ao que foi discutido no podcast, sem incluir opiniões pessoais e sem alterar o sentido ou opinião dos participantes.

O que separa o papel de um desenvolvedor do papel de um arquiteto

Arquitetos caminham na direção de uma liderança técnica, enquanto desenvolvedores estão mais focados em tarefas de codificação. Arquitetos produzem especificações técnicas, diagramas arquiteturais, mas não focam em bits e bytes o tempo todo. O arquiteto estrutura o que deve ser construído. Ao mesmo tempo, arquitetos devem saber programar seu design. Os melhores arquitetos iniciaram sua carreira como desenvolvedores e posteriormente assumiram novas responsabilidades gradualmente.

O fato de estar longe da codificação não exime do arquiteto a responsabilidade de se manter atualizado, contribuindo para o desenvolvimento, o que aumenta sua credibilidade perante o time.

Alguns soft skills diferenciam arquitetos de desenvolvedores. Arquitetos devem saber influenciar, devem ter visão, liderança, devem saber trabalhar com times diversos, comunicar decisões arquiteturais / design.

“The developers are the ones who build skyscrapers, while the architect is someone who designs the city, while enterprise architects are the city planners.“

Diferentes papeis dentro do tema “Arquitetura”

Alguns exemplos de diferentes papeis dentro do tema arquitetura foram citados, demonstrando que ao contrário do que comumente é entendido, não existe apenas o papel do Arquiteto de Aplicações / Sistemas:

  • Infrastructure Architects: focam em detalhes de arquitetura de infraestrutura. Cluster, load balancing, firewalls, virtualização, servidores, etc, são temas recorrentes no seu dia-a-dia;
  • Integration Architects: SOA, EAI e padrões relacionados são suas principais preocupações;
  • Enterprise Architects: Conhecem o mapa de projetos / sistemas / frentes de negócios da corporação, estabelecem roadmaps de tecnologia e lidam com aspectos técnicos e também não-técnicos da organização.
  • Application Architect: Trabalham no nível de projetos. Em geral estabelecem e comunicam visões arquiteturais, que compreendem decisões de design de um projeto.

O título de “Arquiteto” deve ser reservado para aqueles que possuem certificações?IASA Carrer Map

Em geral, certificações mais técnicas focam em um produto ou framework especifico. Neste sentido, um profissional certificado será um excelente profissional para implementação de uma solução e-business, ou para identificar um determinado problema em uma base de dados ou aplicação java. Tais habilidades são extremamente valiosas para desenvolvedores / implementadores de solução, que em geral, procuram certificações para se distinguirem ou se destacarem.

Existem também organizações e certificações voltadas para as diversas segmentações dentro de arquitetura (infrastructure, information, business) e também voltadas à arquitetura corporativa (Enterprise Architecture). O IASA – International Association for Software Architects é uma organização que provê um mapa de carreira com cursos voltados para arquitetos e certificações relacionadas – veja imagem ao lado. O SEI – Software Engineering Institute também provê excelentes materiais e cursos relacionados à arquitetura de software. A Oracle também possui uma certificação voltada a Enterprise Architecture, chamada Oracle Enterprise Architecture Designation, além do Open Group, com o TOGAF.

Para arquitetos, além da competência técnica, habilidades de comunicação são cruciais. Normalmente, um arquiteto deverá passar sua visão para CIO, CTO, CEO, fornecedores, desenvolvedores, etc. Neste sentido, uma certificação não garante que o arquiteto seja competente o suficiente para realizar seu trabalho, já que é muito difícil certificar habilidades comunicacionais. Em geral, o que é levado em consideração na contratação de um arquiteto são suas experiências anteriores bem-sucedidas.

“The person (arquiteto) should have the ability to transcend one technology to the concept.”

Excelentes desenvolvedores podem se tornar arquitetos?

Se você é um excelente vendedor, não significa que você se tornará um excelente gerente de vendas. O mesmo vale para desenvolvedores e arquitetos. Algumas pessoas possuem profundos conhecimentos em bancos de dados, conhecem todas os truques para que o banco de dados ou o java faça exatamtente o que querem, e a forma mais rápida para resolver um problema em um sistema existente. Outras pessoas se dão muito bem quando trabalham em cima de requisitos difusos ou não claros.

É uma questão de mudança de ferramentas. Enquanto que para o desenvolvedor a principal ferramenta de comunicação é o teclado, para o arquiteto sua principal ferramenta deve ser o quadro branco e apresentações power point. Alguns desenvolvedores não gostam de se expor e não há nada de errado nisso. O mais importante é estar fazendo aquilo que se sente bem.

A discussão encerrou com o tema “hot-button issues” (más práticas), comummente cometidas por arquitetos.

  • Decisões “make or buy” devem ser bem pensadas. Por vezes, arquitetos ou pessoas com tal responsabilidade (CIO) decidem por manter e investir em uma ferramenta desenvolvida “in-house”, enquanto que comprar um pacote de mercado e investir em sua implantação pode trazer uma melhor relação custo/beneficio a longo prazo.
  • Um arquiteto não deve optar por tecnologias apenas por possuir conhecimento prévio. O benefício maior para a organização deve ser levado em consideração;
  • Um arquiteto nunca deve misturar diversas visões em apenas um diagrama. É comum encontrar componentes de infraestrutura, fluxo de dados, aplicações, regras e camadas de negócios no mesmo diagrama. Diferentes áreas de conhecimento devem ser representadas em diferentes visões / diagramas.
  • Excelentes comunicadores que não sabem desenvolver seu design não necessariamente são bons arquitetos.
  • Utilizar tecnologias apenas porque todos estão usando, ou utilizar tecnologias recém-lançadas, cedendo ao apelo comercial, não necessariamente é a melhor solução. Arquitetos devem saber selecionar as tecnologias mais apropriadas para o problema em questão, e que melhor se adequem ao cenário da organização.

Leave a Reply

  

  

  

Imagem CAPTCHA

*

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>