Então você quer ser um arquiteto Java?
Postado em 21. jul, 2010 por Paulo Silveira em Arquitetura, 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.
Paulo Silveira (Google+)
Mais sobre o autor
37 Respostas para “Então você quer ser um arquiteto Java?”
Trackbacks/Pingbacks
-
-
fevereiro 9, 2011
[...] É importante analisar todos esses pontos antes de tomar a decisão se o controle de espaço de aplicação por cliente será feito no nosso código, na camada web, no banco ou em algum outro ponto. Como discutimos bastante no curso de arquitetura, toda e qualquer decisão implica em um tradeoff: o importante é saber o que está sendo trocado e qual é o impacto disso. Tweet [...]
ASSINE NOSSO RSS
Lennon Manchester
21. jul, 2010
Muito legal, me trouxe boas lembranças das aulas de Arquitetura e Design de Projetos Java ministradas pelo Sérgio Lopes.
abs
Lennon
Paulo Silveira
21. jul, 2010
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.
André Faria Gomes
21. jul, 2010
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.
Rodrigo Ramalho
21. jul, 2010
Muito bom, já tinha visto você palestrando sobre isto no caelumday e hoje pude relembrar algumas coisas e buscar mais nas referências.
valeu
Washington Botelho
21. jul, 2010
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?
Jefferson B.
21. jul, 2010
Falou muito e não disse nada.
Paulo Silveira
21. jul, 2010
@ 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“.
Elton Vianna
21. jul, 2010
Paulo, primeiramente meus sinceros parabéns pela abordagem e pela assertividade, o post esta 10!
Sergio kubota
21. jul, 2010
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.
Fábio
21. jul, 2010
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.”
Daniel Destro
22. jul, 2010
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.
Rodrigo Monteiro
22. jul, 2010
Show de bola esse artigo!! Parabéns!!
o paragrafo final então..sem comentários!! hehe
Ronualdo
22. jul, 2010
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.
valfrido
22. jul, 2010
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….
Alexandre Gazola
22. jul, 2010
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
Paulo Silveira
22. jul, 2010
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.
Wagner
23. jul, 2010
Muito bom. Bastante esclarecedor.
Parabens Paulo.
Rafael Duque Estrada
23. jul, 2010
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
thiago
24. jul, 2010
Excelente post!
quando sai o livro???
Paulo Silveira
24. jul, 2010
@valfrido @thiago o livro sai finalmente em outubro! deu um trabalhão mas conseguimos.
Alexandre
29. jul, 2010
Um arquiteto com tantas qualificações não acaba sendo um Engenheiro de Software?
Paulo Silveira
30. jul, 2010
@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”.
Paulo Silveira
31. jul, 2010
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
Vinícius Oliveira
06. ago, 2010
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+.
Claudio Cardozo
06. ago, 2010
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.
Carlos Shumam
07. ago, 2010
“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.
Paulo Silveira
07. ago, 2010
@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).
bruno taboada
01. set, 2010
Olá Pessoal, ótimo post.
Nossa que amplitude!
http://en.wikipedia.org/wiki/Enterprise_architecture
Vamos abrir o leque!
Alexandre Garcia
13. set, 2010
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.
Edu
14. set, 2010
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.
Paulo Silveira
14. set, 2010
@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
Edu
15. set, 2010
@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.
Suelen GC
22. set, 2011
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!
Priscila
24. jan, 2012
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…
Alex Arruda Câmara Campos
16. mar, 2012
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.
Rodrigo Chafik Choueiri
19. set, 2012
Gostei demais desse artigo. Parabéns Paulão.