Então você quer ser um arquiteto Java?

Durante o atual processo de revisão do livro de Arquitetura e Design de Software, discussões apareceram sobre o termo arquiteto. Antes de definir o que faz um arquiteto, há o termo arquitetura.

Quem é o arquiteto? Aquele que senta sozinho e toma todas as grandes decisões?

O que é a arquitetura de uma aplicação?
Uma pergunta difícil de responder. Entre as definições mais antigas, Roy Fielding possui um bom texto no primeiro capítulo de sua dissertação de doutorado. O Instituto de Engenharia de Software da Universidade de Carnegie Mellon apresenta diferentes definições, algumas clássicas e bastante conhecidas, como “arquitetura é a estrutura do sistema, composta de componentes, as propriedades que são visíveis externamente desses componentes e o relacionamento entre eles“.

Nas palavras de Martin Fowler, “o termo arquitetura envolve a noção dos principais elementos do sistema, as peças que são difíceis de mudar. Uma fundação na qual o resto precisa ser construído“. Fowler reformula sua definição de arquitetura e a define como “as peças que as pessoas acham que é difícil de mudar“. No mesmo artigo Ralph Johnson, do GoF, diz que arquitetura “é o conjunto de decisões de design que gostaríamos de ter feito no começo do projeto” e termina com uma definição mais abrangente: “arquitetura é tudo aquilo que importa“. Com tantas definições, talvez seja mais fácil diferenciarmos design de arquitetura.

Qual é a diferença de design e arquitetura de software?
Aqui também temos uma resposta clássica na literatura: a arquitetura é responsável pelos requisitos não-funcionais, e o design pelos funcionais. Mas parece que essa distinção não é tão clara assim para muitos outros autores.

Neal Ford apresenta uma distinção simples, realçando que o design é feito em cima do que foi decidido pela arquitetura, e por isso o que faz parte da arquitetura é mais difícil de mudar. Devemos minimizar as peças que dificultam mudanças do nosso design, mas é impossível eliminar todas, além de que flexibilidade sempre vem a um custo de complexidade.

É difícil criar um distinção maior entre os dois. No livro Patterns of Enterprise Application Architecture, Fowler diz que “alguns dos padrões nesse livro podem ser chamados arquiteturais, já que representam decisões importantes sobre essas partes; outros são mais sobre design e te ajudam a implementar essa arquitetura. Eu não faço nenhuma tentativa forte de separar esses dois, já que é o que é arquitetural ou não é subjetivo“.

O arquiteto deve saber programar na plataforma em questão?
Sem dúvida. Cada vez mais vemos que o design e a implementação devem ser trabalhados juntos. A imagem de um arquiteto distante sem profundo conhecimento técnico que apenas toma as grandes decisões ficou pra trás: conhecimento técnico e a capacidade de liderança são as características fundamentais.

Mais do que querer ser o poderoso arquiteto que apenas despacha ordens e toma todas as grandes decisões, cada vez mais enxergamos que o caminho é ser o líder que incentiva essa tomada de decisão, além de ser um exímio programador. Parafraseando mais uma vez Martin Fowler, “…o arquiteto deve ser como um guia… que é um experiente e capacitado membro da equipe que ensina aos outros a melhor se virarem, ainda assim ele está sempre lá para as partes mais complicadas“.

Vale lembrar que precisamos de mais de 10 mil horas, ou 10 anos, para dominar uma linguagem.

37 Comentários

  1. Lennon Manchester 21/07/2010 at 17:57 #

    Muito legal, me trouxe boas lembranças das aulas de Arquitetura e Design de Projetos Java ministradas pelo Sérgio Lopes.

    abs
    Lennon

  2. Paulo Silveira 21/07/2010 at 18:06 #

    Valeu Lenon. O Rafael Ferreira me mandou uma outra observação boa: assim como o termo “arquiteto” é bastante questionável, o termo “arquiteto Java” é mais questionável ainda. Creio que o resumo da ópera é ter de dominar bem uma plataforma para poder tomar decisões grandes nela, independente da tecnologia.

    Vale outra citação, dessa vez ao Spoelsky: “pessoas de todo o mundo estão
    constantemente criando aplicações web usando .NET, usando Java e usando PHP.
    Nenhuma delas está falhando por causa da escolha da tecnologia
    .

  3. André Faria Gomes 21/07/2010 at 19:24 #

    Parabéns Paulo.

    Muito Legal. Realmente há muita confusão nesses conceitos que parecem significar tantas coisas diferentes para diferentes pessoas. Bacana o artigo. Ótimas referências.

    Abraço.

  4. Rodrigo Ramalho 21/07/2010 at 20:03 #

    Muito bom, já tinha visto você palestrando sobre isto no caelumday e hoje pude relembrar algumas coisas e buscar mais nas referências.
    valeu :)

  5. Washington Botelho 21/07/2010 at 21:32 #

    O arquiteto toma as decisões importantes e deve conhecer a fundo a linguagem escolhida. Ok!

    Então o Consultor é um arquiteto? Seria sinônimos ou ainda sim tem diferenças?

  6. Jefferson B. 21/07/2010 at 21:50 #

    Falou muito e não disse nada.

  7. Paulo Silveira 21/07/2010 at 21:55 #

    @ Rodrigo @Andre obrigaod!

    @Washigton Na minha opinião, um consultor pode tomar decisões arquiteturais, e o papel do líder técnico da equipe deve ser incentivar e capacitar os consultores/desenvolvedores/programadores da equipe a tomarem também essas decisões.

    @Jefferson essa era a intenção: deixar cada um tirar suas conclusões, baseado nas referências que passei. De qualquer maneira, acho que o último parágrafo fala pouco e diz tudo: “…o arquiteto deve ser como um guia… que é um experiente e capacitado membro da equipe que ensina aos outros a melhor se virarem, ainda assim ele está sempre lá para as partes mais complicadas“.

  8. Elton Vianna 21/07/2010 at 22:13 #

    Paulo, primeiramente meus sinceros parabéns pela abordagem e pela assertividade, o post esta 10!

  9. Sergio kubota 21/07/2010 at 22:44 #

    Gostei do tema desse post! Conforme fui prestando consultoria encontrei o termo arquiteto de solução focado em interações e desenho de soluções de software, arquiteto de aplicação mas baixo nível como codificação, aplicação de patterns, escolha de frameworks, arquiteto organizacional mais focado no ROI da empresa, aplicando ITIL, criando contrato e modelos de desenvolvimento… E ai vai…. =-D … No fundo somos todos programersss =-D uhh Uhh.

  10. Fábio 21/07/2010 at 23:52 #

    Acho que o esse post foi derivado de uma sugestão minha no GUJ kkkkk Mas se não for tudo bem.
    Estou com um conceito novo agora. Se me perguntarem qual a diferença entre projeto e arquitetura, eu direi “Não se importe com isso. O limiar é subjetivo.”

  11. Daniel Destro 22/07/2010 at 08:56 #

    Paulo, como sempre dando aula sobre TI e de uma forma muito ponderada, sem impor opiniões, mas sim dividindo o conhecimento. Parabéns!

    Estou há 11 anos trabalhando com TI (10 de Java) e cada vez mais entendo que o conhecimento para um “arquiteto” é o mais abrangente possível.

    Cada um entende o termo arquiteto como vê e conhece o mundo por ai. Quando se está inserido apenas no mundo Java, onde Apache, Tomcat e BD são seu mundo, dominar isso significa ser arquiteto. Quando extrapolamos os limites de nosso meio começamos a ver que há um mundo bem maior por ai.

    Aplicações distribuídas, redes, clusters, nuvem, grids, alta disponibilidade, segurança, mainframe, SOA etc. Um infinito de requisitos que ampliam as funções e conhecimentos de um arquiteto.

    Cabe aí ao profissional a humildade de entender que o mundo é bem maior e desconhecido do que pensamos.

  12. Rodrigo Monteiro 22/07/2010 at 09:31 #

    Show de bola esse artigo!! Parabéns!!

    o paragrafo final então..sem comentários!! hehe

  13. Ronualdo 22/07/2010 at 14:49 #

    Muito bom o Post.

    Gostei particularmente do último paragrafo, sempre achei muito estranha a idéia de um arquiteto que não fosse um ótimo programador.

  14. valfrido 22/07/2010 at 15:35 #

    Gostaria de saber q dia msm vai ser lançado este livro de arquitetura e design, desde o ano passado falam q ele vai ser lançado….
    estou ansioso por este livro….

  15. Alexandre Gazola 22/07/2010 at 19:55 #

    Muito bom, Paulo!

    No livro “The mythical man-month”, o Fred Brooks fala muito que a arquitetura idealmente deveria ser realizada por uma pessoa (ou poucas pessoas) para preservar a “integridade conceitual” do produto. Neste caso, ele parece usar o termo ‘arquitetura’ para se referir ao produto em si, o que é visível para o usuário. Seria pensar na arquitetura num nível mais alto.

    abraços

  16. Paulo Silveira 22/07/2010 at 19:58 #

    agradeço os comentários! realmente é uma condensação de pensamentos sem expressar minha opinião, mas estou de acordo com o último paragrafo do Fowler também.

    @Alexandre: bem lembrado do Brooks. mais ainda, no novo livro dele (e na palestra que ele deu em São Paulo) ele falou muito de que essa visão geral deve ser feita por uma ou duas pessoas. Ele foi mais além e disse que o melhor seria se fossem duas pessoas e deu zilhares de exemplos.

  17. Wagner 23/07/2010 at 12:26 #

    Muito bom. Bastante esclarecedor.

    Parabens Paulo.

  18. Rafael Duque Estrada 23/07/2010 at 12:29 #

    Bom post, tema sempre abordado em discussões técnicas.
    Embora eu não concorde com esse cargo, como muitos autores que citou.
    O que vejo no mercado são 3 tipos de arquitetos:
    1- Arquiteto de Soluções Teórico;
    Esse é o profissional que trabalhou como desenvolvedor em alguns projetos porém evoluiu acha que evoluiu mais rápido e começou a estudar N metodologias, patterns, linguagens, sem ter aplicado na prática a maioria delas e é o senhor da verdade. É o cara que fica atrás da mesa ditando o que se deve fazer porém quando coloca um código na sua frente para ele resolver, sempre arruma uma desculpa (até chega a suar frio) e a banana acaba ficando na mão do desenvolvedor.
    2- Arquiteto Desenvolvedor Senior;
    Esse é o profissional que trabalhou como desenvolvedor em vários projetos, e chegou em um nivel de senioridade legal e decidiu se intitular como arquiteto, procurando oportunidades de arquiteto no mercado, pois existe aos montes para esse tipo de profissional, pois empresas não querem pagar pelos verdadeiros especialistas.
    3- Arquiteto de Soluções Técnico;
    Esse é o profissional que trabalhou a vida inteira desenvolvendo, em vários linguagens, aplicando patterns diversos, tecnologias, etc. Devido a sua experiência e vivência ele é realmente um especialista em tecnologia.

    Não acho certo intitularem arquitetos, mas em funções como:

    1- Professor Didático;
    2- Desenvolvedor Senior;
    3- Especialista em Soluções.

    =P

  19. thiago 24/07/2010 at 11:49 #

    Excelente post!
    quando sai o livro???

  20. Paulo Silveira 24/07/2010 at 11:58 #

    @valfrido @thiago o livro sai finalmente em outubro! deu um trabalhão mas conseguimos.

  21. Alexandre 29/07/2010 at 18:15 #

    Um arquiteto com tantas qualificações não acaba sendo um Engenheiro de Software?

  22. Paulo Silveira 30/07/2010 at 16:10 #

    @Alexandre… é esse tipo de duvida de nomenclatura que o Fowler nao quer entrar muito na discussão, por ser dificil dar nomes aos bois, e talvez não valer muito a pena. Acho que essa pessoa, com todas essas qualidades, é alguém que possamos chamar de “desenvolvedor experiente”.

  23. Paulo Silveira 31/07/2010 at 17:49 #

    Aqui tem um outro artigo do Joel que se posiciona bastante em relação a “arquitetos que não programam” que ele chama de “arquitetos astronauta”:
    http://www.joelonsoftware.com/articles/fog0000000018.html

  24. Vinícius Oliveira 06/08/2010 at 11:10 #

    Muito bom este artigo, pois foi bem superficial e deixou com que as pessoas refletissem sobre o assunto.

    Porém achei bem legal a pergunta do @Washigton e a resposta do @Paulo Silveira, pois o que mais vejo por ai, são arquitetos com perfil de desenvolvedor/consultor e consultores com papéis de arquitetos/gerente de projetos, e por ai vai….

    A troca de papéis na empresas/consultorias são muito constantes e nem sempre isso deixa o pessoal satisfeito, lógico que guardadas as devidas proporções.

    Infelizmente existem pessoas subutilizadas em seus projetos e as vezes a própria pessoa não tem ciência da sua capacidade. Muito problemático isso!!!

    Mas ai já entramos em outro ponto que é o da auto análise e gestão das próprias metas/objetivos das pessoais.

    Bom é isso ai pessoal, estou feliz com meu cargo hoje e escrevi isto só porque vejo essas trapalhadas por ai e o tema é bem amplo. OK?

    Abss e T+.

  25. Claudio Cardozo 06/08/2010 at 11:36 #

    Após 24 anos em TI, e mais de 30 mil horas de “voo”, sempre me pergunto se sou de fato um arquiteto. Os outros acham que sou, pelo que fiz, faço e farei. Arquiteto ou arquitetura, é uma essência conceitual, voltado para suportar construções e modelos; ela é algo pensada e modelada, para não ter retorno, raramente se altera esse conceito, sob pena de desmoronamento da engenharia.

  26. Carlos Shumam 07/08/2010 at 08:27 #

    “Martin Fowler, ‘…o arquiteto deve ser como um guia… que é um experiente e capacitado membro da equipe que ensina aos outros a melhor se virarem, ainda assim ele está sempre lá para as partes mais complicadas’. ”

    Sinceramente sou fã de Fowler, e o considero um otimo profissional e educador (quando leio seus livros), mas como auto intitulá-se, é as vezes um falastrão!

    Devemos aprender a diferenciar conceitos de “filosofias” ou mesmo “poesias” nas frases de determinados autores, que foi o caso do Fowler agora. Outro exemplo: a definição que o Silveira destacou sobre arquitetura, principalmente: “arquitetura é tudo aquilo que importa“ é muito poético, lindo para profissionais desta área, mas de nenhuma maneira conceitua realmente. Não é realmente uma definição! Aliás, esta é uma definição? Isto é soa tão poético, quanto afirmar ao Programador que este é o profissional mais importante do mundo atualmente, que o Médico é um deus de carne e osso, que o Padeiro é o profissional que produz nosso pão de cada dia e sem ele não haveria um bom dia.

    Conceitos envolvem imparcialidades e definem características de algo ou “alguém”, que ao serem citados levá-nos logo a pensar neste algo ou “alguém”.

    Pelos capitulos demos o livro parace ser muito bom, mas definições deste tipo não podem ser passadas adiante, ou então, não sabem o que é um “Arquiteto de uma aplicação” ainda e não podem lançar este livro até descobrir! (Desculpe-me Silveira se parecer grosseiro, mas como uma pessoa que atualmente é muito considerada na comunidade, este tipo de comentário não é mais aceito. Isto fica para o ínicio da carreira onde falamos qualquer coisa e fica por isto mesmo, pois pouca gente nos conhece. O que não é o seu caso.)

    Tenha certeza de que você não conceituou “arquitetura de uma aplicação” neste post!
    Se considera este conceito realmente importante corrijá-o, defina-o corretamente sem poesias, pois podem servir de base para estudantes e pesquisadores.

  27. Paulo Silveira 07/08/2010 at 09:14 #

    @Carlos, agradeço o comentário. É um comentário forte mas de maneira alguma grosseiro.

    Creio que o objetivo do post é que não ficou claro: incitar cada desenvolvedor para que perceba o quão íntima é a relação de arquitetura, design e código, e de que todos estão muito ligados. Por isso o post começa discutindo arquitetura e passa para arquitetura X design, até chegar em código.

    O livro é mais técnico, não entra em questões conceituais. No livro mostramos trade offs de uma técnica com outra, de um framework com outro, etc.

    Sobre não ter conceituado arquitetura, você tem razão, não ficou expressa minha opinião (você não foi o único a criticar isso, recebi diversos emails também). Acho curioso que gerou tanta polêmica sem eu dar minha opinião pessoal… creio que se tivesse dado seria mais barulhento. Na sua frase “não sabem o que é um Arquiteto de uma aplicação”, infere-se de que há uma e única definição. Eu não concordo, e acho “arquiteto de aplicação” um termo vago para ser usado dessa forma, um buzzword, que cada um acaba puxando para a situação da sua empresa e da sua aplicação. Na minha opinião, dar uma única definição a “arquiteto de aplicação” vai apenas criar uma outra figura de linguagem, no mesmo sentido que você utilizou o termo “poético” (e concordo com você aqui).

  28. bruno taboada 01/09/2010 at 16:49 #

    Olá Pessoal, ótimo post.

    Nossa que amplitude!
    http://en.wikipedia.org/wiki/Enterprise_architecture

    Vamos abrir o leque! :)

  29. Alexandre Garcia 13/09/2010 at 14:25 #

    Este tema ficou ainda mais claro depois de sua paletra no
    QCON 2010.
    Ao meu ver você foi muito feliz e mostrou com muita clareza e propriedade,
    através de exemplos simples, os principais conceitos envolvidos.
    Uma aula bastante objetiva.
    Sugiro disponibilizar o vídeo com sua apresentação no QCON
    tão logo seja possível.

    abs,
    Garcia.

  30. Edu 14/09/2010 at 11:05 #

    Eu já sou meio radical. Acho que o kra pra ser considerado Arquiteto Java tem que ter a certificação Java EE 5 Enterprise Architect da Oracle/Sun.

  31. Paulo Silveira 14/09/2010 at 13:50 #

    @Alexandre Obrigado! Vou fazer um novo post sobre o assunto para deixar mais clara minha própria opinião.

    @Edu essa é realmente uma opinião que ninguém da Caelum compartilha. A certificação não tem como provar algo assim

  32. Edu 15/09/2010 at 11:35 #

    @Paulo, eu sei que é apenas um título, mas o mundo é feito de títulos não? para a pessoa ser advogado tem que ter o título da OAB, para ser médico tem que ter o diploma de medicina, PhD, Doutorado etc. O que acontece é que na área de TI as coisas não seguem um padrão.
    Eu sei que tem muitos kras bons sem certificacação nenhuma, mas temos que valorizar quem estudou e se esforçou para ter uma certificação dessas. Existem alguns contratos públicos que só são feitos se tiver pelo menos um profissional certificado Java EE 5 Enterprise Architect no projeto.
    Realmente eu fui muito radical, mas o kra para ser considerado arquiteto teria que ter uns 8 anos com Java e um diploma universitário, no mínimo. Agora o kra ser um moleque de 18a,19a, não ter diploma universitário e se considerar arquiteto é uma grande piada.

  33. Suelen GC 22/09/2011 at 20:29 #

    Muito bom o texto, curto e direto… concordo em gênero e grau quando diz que “A imagem de um arquiteto distante sem profundo conhecimento técnico que apenas toma as grandes decisões ficou pra trás…” e com todo o restante. Parabéns!

  34. Priscila 24/01/2012 at 16:46 #

    Concordo plenamente. E considero que infelizmente o mercado está cheio de profissionais assim, que enchem linguiça junto aos seus líderes mas na hora de tirar dúvidas técnicas e dar aquele suporte aos desenvolvedores, deixam a desejar. Ainda existe sim aquele pensamento de que o arquiteto não deve de preocupar com a programação. Acho isso um lixo de pensamento! Depois que vira arquiteto a pessoa simplesmente aborta o aprofundamente em apis e etc na tecnologia… Tive poucos arquitetos com quem pude trabalhar, mas garanto que 1 deles, pra mim foi excepcional. O cara era fera! Garanto que cansa aquele diz -diz que não diz nada destes profissionais incompletos…

  35. Alex Arruda Câmara Campos 16/03/2012 at 15:41 #

    Interessante mostra várias definições para um assunto tão singular que é a Arquitetura, porem gostei da subjetividade de “arquitetura é tudo aquilo que importa“.

    Obrigado pelo artigo.

  36. Rodrigo Chafik Choueiri 19/09/2012 at 15:56 #

    Gostei demais desse artigo. Parabéns Paulão.

Deixe uma resposta