Uma Pequena Provocação aos Arquitetos

sergiotaborda wrote: ......

Fontes por favor????

GUJ Master Membro desde: 04/06/2007 17:47:24 Mensagens: 1030 Offline

Sérgio, cada discussão que vejo sua não compreendo que papel ou estrutura de estudos teve para chegar a tais pensamentos. Cada vez mais acho que possui menos experiência e vivência no que escreve.
Como o Rodrigo já pediu, referencias ajuda a dar um pontapé de onde está tirando suas ideias. Se são da sua cabeça, seria bom elaborar uma boa teoria e levar em consideração sua experiência e citar as diversas situações que levaram você a concluir algo.

Arquiteto, assim como DBA, é um cargo que vai se extinguir...

Bons arquitetos fazem a arquitetura sumir.

sergiotaborda wrote:
Existe uma máxima - de que não lembro o autor- que um arquiteto só pode ser considerado arquiteto se desenvolveu mais de 3 sistemas distribuídos. Isto deixa claro que o arquiteto é alguem com experiência e que sabe programar e desenvolver. Mas se o cara desenvolveu 3 sistema distribuido com Delphi de pouca valia vai servir para desenvolver JEE. Ok, alguns conceitos são os mesmos , mas a tecnologia não é, e avaliar a tecnologia é uma das principais funções do arquiteto.
Tem feito 3 ou mais sistemas tb não significa que o cara está junto da equipa e desenvolvedor e partilhando dos problemas.
Em agil isso é é fato, mas no comum , o arquiteto é visto como um chefe tecnico (não um lider, um chefe) que manda na equipe. E isso é que é ruim.

"um arquiteto só pode ser considerado arquiteto se desenvolveu mais de 3 sistemas distribuídos"???? Só se for um Sun J2EE Certified EJB Master! Arquiteto tem que ser um cara com um conhecimento mais geral, é bom conhecer "sistemas distribuidos", mas existem muitas outras coisas que o cara precisa saber...

Olá

Rubem Azenha wrote:Só se for um Sun J2EE Certified EJB2 Master!

Concordo. E provavelmente formado e bolovado pelo infame livro Core J2EE Patterns 1a edição. É como twitei hoje de forma obviamente radicalizada pela necessidade de impacto dos 140 chars: Arquiteto que desenvolveu de mais de 3 sistemas distribuídos quase certamente é um imbecil EJBtizado. (*)

De todos os sistemas distribuídos que já ouvi falar, a maioria não precisava ser distribuído e na prática também não podiam ser considerados realmente distribuídos porque muitas vezes o banco de dados era um gargalo na tal "distribuição". Esta é a herança maldita dos EJBs <= 2.x. Não canso de repetir que os EJBs foram a maior tolice que já vi em todos os meus mais de 40 anos de informática. Reparem que os teóricos da SUN capricham nas bobagens porque JSF (+facesxpto) também é dose para elefante.

Fico aqui imaginando o que diria para um arquiteto que pretendesse emprego em uma empresa que eu estivesse coordenando o processo de seleção e ele incluisse no currículo sistemas arquitetados com EJBs <= 2.x.

(*) Escrevi quase porque há exceções: há alguns raros sistemas que realmente precisam ser distribuídos. E destes raros casos, algumas vezes acontece deles serem projetados de forma que realmente funcionem distribuído sem gargalos ou único ponto de falha.

[]s
Luca

This message was edited 1 time. Last update was at 03/12/2009 08:30:50

Luca wrote:Olá

Rubem Azenha wrote:Só se for um Sun J2EE Certified EJB2 Master!

Concordo. E provavelmente formado e bolovado pelo infame livro Core J2EE Patterns 1a edição. É como twitei hoje de forma obviamente radicalizada pela necessidade de impacto dos 140 chars: Arquiteto que desenvolveu de mais de 3 sistemas distribuídos quase certamente é um imbecil EJBtizado. (*)

De todos os sistemas distribuídos que já ouvi falar, a maioria não precisava ser distribuído e na prática também não podiam ser considerados realmente distribuídos porque muitas vezes o banco de dados era um gargalo na tal "distribuição". Esta é a herança maldita dos EJBs <= 2.x. Não canso de repetir que os EJBs foram a maior tolice que já vi em todos os meus mais de 40 anos de informática. Reparem que os teóricos da SUN capricham nas bobagens porque JSF (+facesxpto) também é dose para elefante.

Fico aqui imaginando o que diria para um arquiteto que pretendesse emprego em uma empresa que eu estivesse coordenando o processo de seleção e ele incluisse no currículo sistemas arquitetados com EJBs <= 2.x.

(*) Escrevi quase porque há exceções: há alguns raros sistemas que realmente precisam ser distribuídos. E destes raros casos, algumas vezes acontece deles serem projetados de forma que realmente funcionem distribuído sem gargalos ou único ponto de falha.

[]s

Luca

Não queria que isso virasse um flame novamente, já discuti inúmeras vezes essa questão sobre EJB até mesmo com o Luca, então vou tentar ser breve.

1- Primeiro há um contexto histórico e quais opções tínhamos em mãos naquela época ? Corba ? Vai desenvolver qualquer treco com Corba aí vc vai amar EJBs, pode acreditar.

2- Muitos massacram o ejb anterio à versão 3 e concordo que é uma especificação densa com algumas coisas ruins como Entity Beans. Lembro que muitos sistemas que precisavam ser distribuídos usavam a fórmula Session + DAO só pra evitá-los. Entretanto, SessionBeans estavam lá, MDB estava lá também e sinceramente acho que foi uma das melhores coisas do mundo EE.

3- Por fim, qualquer análise fora de contexto se torna burra e estúpida. Usar EJB por usar é burro assim como criticar a tecnologia sem conhecer as problemáticas envolvidas também.

Hoje realmente essas tecnologias não fazem sentido, temos uma série de formas de resolver os mesmos problemas, desde Grids de memória ( Hadoop, Coherance, Gigaspaces...), cluster de VMS (TerraCota) e por aí vai , por isso gosto sempre de lembrar o contexto, levando em consideração material de apoio como livros, publicações e época.

Com relação ao tópico, o Rodrigo colocou muito bem. Particularmente não acredito num arquiteto que não sente junto com a equipe para analisar os problemas, implementação até para fazer uma análise coesa sobre a situação geral do(s) projeto(s).

Agora sentar no dia-a-dia para programar com a equipe, acaba realmente se tornando inviável, principalmente quando vc é o único da insituição com vários projetos rolando e diferentes equipes. Se você sentar pra resolver junto, acabou seu papel, pois não terá tempo de responder aos questionamentos e nem analisar a coisa toda de fora..

garcia-jj wrote:Vini, não entendi mutio bem seu ponto de vista. Você acha que o arquiteto tem que programar também ou você acha que um bom arquiteto é aquele que já foi programador no passado?

Eu acredito que o arquiteto tenha que saber programar, mas não que ele deva ser um dos programadores da equipe, necessariamente. Um arquiteto que não sabe escrever uma linha de código, na minha opinião, vai ser severas dificuldades em entender o impacto que a tecnologia causa sobre a equipe.

Por isso, acho que um arquiteto com experiência, não precisará mais programar com frequência. No máximo, fazer ele alguns testes, avaliar coisas novas, e entender artigos técnicos.

rodrigoy wrote:Arquiteto, assim como DBA, é um cargo que vai se extinguir...

Bons arquitetos fazem a arquitetura sumir.

Eu realmente não acho que é um cargo que vai sumir, pois há inúmeras técnicas diferentes e todo dia vemos coisas novas. Há também a questão da melhor abstração de negócio, como você pontuou e muitos programadores infelizmente não conseguem enxergar o negócio, mapear o processo do cliente.

Queria fazer uma meção ao último post do Akita e nas empresas cuja a tecnologia não é o Core é muito comum encontrar profissionais que estão ali somente para fazer a atividade mecânica, sair às 18h e nunca pega um livro pra dar uma lida. Essa é a realidade da maiora das companhias e talvez o arquiteto tenha mais um papel, evangelizar, ensinar tecnologias direcionando aquele time de desenvolvedores para algo mais próximo do ideal.

JavaChild Membro desde: 14/07/2006 18:09:33 Mensagens: 104 Offline

sergiotaborda wrote:

ViniGodoy wrote:

leosouzabh wrote:não concordo com você Felagund, as vezes um arquiteto realmente bom e experiente não precisar codificar para saber o problema.
O cara tem que ser vivido o suficiente para entender problemas sem ter que debulhar códigos e códigos.
Mesmo porque entender o todo de um sistema de menor porte é ate possível, mais pensando em sistemas legados, e de grande porte acho que fica um pouco inviavél de ter esse conhecimento.

Só acho que ele não vai obter essa experiência que você falou, sem antes ter debulhado linhas e linhas de código. Mas até concordo que alguém que já tenha anos de programação no passado, possa exercer a profissão no futuro programando pouco, e mantendo-se atualizado sobre tecnologias em blogs e fóruns.

Existe uma máxima - de que não lembro o autor- que um arquiteto só pode ser considerado arquiteto se desenvolveu mais de 3 sistemas distribuídos. Isto deixa claro que o arquiteto é alguem com experiência e que sabe programar e desenvolver. Mas se o cara desenvolveu 3 sistema distribuido com Delphi de pouca valia vai servir para desenvolver JEE. Ok, alguns conceitos são os mesmos , mas a tecnologia não é, e avaliar a tecnologia é uma das principais funções do arquiteto.

Nossa, essa foi uma das coisas mais bizarras que eu já li por aqui.

Olá

Kenobi wrote:...contexto histórico ...

Sim, na época os buzzwords daninhos eram DCOM, RPC, CORBA/ORBs. Mas isto não justifica alguém da SUN imaginar que todas as aplicações enterprise precisassem destas coisas.

A minha grande crítica aos EJBs antigos é justamente pelo fato deles tratarem todos os problemas como distribuídos que é como os EJBs foram concebidos. Depois foram modificados para usar uma interface local mas o ranço e o mau hábito já estavam arraigados.

O arquiteto EJBtizado que estigmatizei é aquele antigo que caiu no conto da SUN e baseou todos seus projetos em EJBs quando muitas vezes bastava usar JDBC. E conheci muita gente boa que se EJBtizou. A grande desculpa era a de que no dia que o sistema precisasse ser distribuído já estaria tudo pronto. Só que isto é uma grande falácia porque para um sistema ser distribuído muitas outras coisas precisam ser consideradas. São estes os projetos que duvido que algum arquiteto se orgulhe. Hoje viraram herança maldita e alguns até pouco tempo ainda exigiam servidores obsoletos.

Só para dar um exemplo de mau uso de EJBs vou citar o caso ocorrido em uma empresa que trabalhei onde substituiram um servidor feito em C que atendia com facilidade mais de 180 TPS por outro feito usando EJBs que depois de muitas horas e muito trabalho, não conseguia responder 30 TPS. Foi mais um daqueles famosos casos de escolha de tecnologia porque o "arquiteto" queria aprender. O motivo alegado para a substituição foi a de que a equipe era de Java e que os programadores C já tinham assumido outras funções de chefia e gerência (isto era verdade mas teria sido melhor contratar outros).

E para completar digo que para um sistema ser distribuído, não é obrigatório que seja complexo. Além de algumas coisas que citou, lembro que um CRUDzinho feito usando o CouchDB pode facilmente funcionar distribuído.

PS: arquiteto que usa EJB 3 não tem nada a ver com o tal EJBtizado que citei. Para mim são coisas tão diferentes que deveriam ter outro nome.

[]s
Luca

Luca wrote: A grande desculpa era a de que no dia que o sistema precisasse ser distribuído já estaria tudo pronto. Só que isto é uma grande falácia porque para um sistema ser distribuído muitas outras coisas precisam ser consideradas. São estes os projetos que duvido que algum arquiteto se orgulhe. Hoje viraram herança maldita e alguns até pouco tempo ainda exigiam servidores obsoletos.

Mas em Java há grandes falácias: se mudar a view, se mudar o Application Server, blá blá blá...
Nunca trabalhei numa mudança dessa...

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

rodrigoy wrote:

mochuara wrote:
Ter uma arquitetira executavel não faz sentido pra mim. Eu concordo com o Sergio, ninguém descobre uma arquitetura a ser utilizada no decorrer do projeto (pelo menos não deveria). Na verdade o termo arquitetura de caixinha se refere a utilizar a mesma arquitetura em todos os projetos, como se ela fosse algo executavel.

Em 2007 escreví um artigo com o Scott Ambler e o Jon Kern entitulado "O papel do Arquiteto". Segue o link com uma prévia:

http://blog.aspercom.com.br/2007/09/20/opapeldoarquiteto/

Quando escrevemos esse artigo chegamos a conclusão de 3 coisas muito óbvias. Um arquiteto:

1. Tem experiência variada
2. Elege uma arquitetura baseada nos requisitos (requisitos dirigem a arquitetura e não o contrário)
3. Deve ser embasado nos negócios da empresa (conhecimento do negócio forma um bom arquiteto)

Detalhe: TODOS os autores sérios defendem que uma arquitetura é executável. O que você quer dizer com uma arquitetura que não executa? Aliás, para que ela serve?

Acho que o problema é com o termo "executavel". Se esta querendo dizer que ela deve ser viável de ser implementada dado os recursos disponíveis me parece outro ponto óbvio. Mas dizer que arquitetura é executável no sentido de passível de ser replicada/repetitível como propões ferramentas CASE esse é uma visão longe de ser realidade.

This message was edited 1 time. Last update was at 03/12/2009 10:21:21

felipeguerra wrote:Mas em Java há grandes falácias: se mudar a view, se mudar o Application Server, blá blá blá...
Nunca trabalhei numa mudança dessa...

Mudar a view, até que sim. Não a view toda, mas prover views alternativas para certos dados, isso até é relativamente comum.

Agora, mudar application server, mudar o banco de dados (ou ainda, pior que isso, o mecanismo de persistência), ainda estou para ver também.
Fico me questionando até que ponto vale a pena aumentar o custo e a complexidade de todo projeto, para se prevenir contra mudanças que raramente acontecem.

Minha observações

Li muita coisa aqui, muita besteira e muita coisa que concordo.

Atualmente curso Pós Graduação em Engenharia de Software e lá tive a matéria Arquitetura de Software, e com isso consigo formar uma opinião sobre o que de fato é arquitetura.

NÃO EXISTE DEFINIÇÃO SOBRE O QUE É ARQUITETURA DE SOFTWARE, mas as definições no geral enfatizam que a arquitetura é a descrição do sistema e a soma de pequenas partes dele, e como essas partes se relacionam e cooperam entre si para executar o trabalho do sistema. [Bachmann, Felix; Bass, Len; Carriere, Jeromy; Clements, Paul; Garlan, David; Ivers, James; Nord, Robert; Little, Reed; Software Architecture Documentation in Practice: Documenting Architectural Layers, 2000 SPECIAL REPORT CMU/SEI-2000-SR-004 ]

Acredito difícil existir um arquiteto que nunca programou nada.
Acredito ainda que em sistemas críticos o papel de arquiteto de software assim como o de DBA seja muito importante.
Em empresas que o core não é TI acredito que seja mais importante, pois uma consultoria pode fazer um software, mas nem sempre entendem exatamente como o software deve ser portar, nessa hora que o arquiteto tem seu papel bem claro.

A tecnologia é importante, mas como o sistema deve ser portar é mais ainda.

Não podemos confundir a arquitetura do software com o design. A arquitetura se preocupa com a seleção de elementos arquiteturais, suas iterações e restrições, já o design são as atividades que se preocupam com a modularização e detalhamento de interfaces, algoritmos, procedimentos e tipos de dados que darão suporte satisfatório a arquitetura. [ Eden H., Amnon; Kazman, Rick; Architecture, Design, Implementation
http://www.eden-study.org/articles/2003/icse03.pdf ]

Já foi falado, mas só para citar, todos questionam o EJB anterior a versão 3, concordo que muitos utilizaram de forma errada no passado, mas o que existia naquela época???
Hoje existe um grande questionamento o JSF [ http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ ] , alguns questionam outros não, mas tudo depende do que a aplicação precisa fazer.

Voltando a arquitetura, cada caso é um caso que deve ser analisado separadamente, NÃO podemos criar uma arquitetura padrão e seguir em todos os sistemas, um sistema para a BOVESPA não pode ser desenvolvido como um intranet, o foco é outro, outro próposito, tudo é diferente.

Creio que com isto tenha deixado uma contribuição para quem ler futuramente.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Parece que feri o ego de muita gente afirmando que um arquiteto de verdade tem que ter experiencia passada com o desenvolvimento de sistemas (sistemas, plural).

Isso é muito curioso. Existem na várias referencias a como um arquiteto tem que ter essa experiencia porque só assim ele pode ter noção comparativa de tecnologias e fazer bons trade-off. Assim como existem várias definições do que deveria ser um arquiteto.

A noção de o arquiteto deveria ser quase um PM é aburda embora eu concorde que um arquiteto tem que conhecer de gerencia e estimativas - mas para auxiliar o PM, não para ser o PM. Ter lido Software Estimation: Demystifying the Black Art é fundamental.

Não é credivel que uma pessoa sem experiencia de campo possa decidir por uma arquitetura.
Eu já tive que trabalhar em sistemas sem arquiteto , ou seja, sem alguem que visse "the big picture" e definissem estratégias.
isso resulta sempre em sistemas porcaria. Sistemas JSP puro (como no asp 3 , sem classes , sem servlets , sem mvc de nenhuma especie). Sistemas com necessidade pesada de comunicação usando protoclos criados ad doc em xml transferidos com sockets (não http) em vez de jms ou - menor dos pecados -webservices. Sistemas com excesso de uso de api de terceiros, simplesmente enche o sistema com todas as api conhecidas à humanidade e não faz nada na mão. Pior que isso :distribui a aplicação em 10 jars diferentes e usa o maven para os compor. Uso de EJB em aplicações apenas locais sem distribuição (no remote ejb) ou transação distribuida (jdbc +jms por exemplo). Uso de MDB em vez de frameworks de batch. Uso de Spring sem usar injeção (apenas define os objetos e depois usa um ServiceLocator para os recuperar do contexto como se fosse um map.
Exemplos de juniors desenvolendo "arquiteturas" não me faltam.

algumas referencias - já que vocês são incapazes de procurar no google - sobre o que é arquitetura de sistemas , os vários tipos de arquiteto, as várias definições do que é um arquiteto - e ha muitas - e os principais problemas e más práticas dos arquitetos : por exemplo : não conhecerem as tecnologias, não conhecerem o nivel tecnico das equipes , não saberem estimar.

http://www.bredemeyer.com/Architect/RoleOfTheArchitect.htm Refiro este url não pelo conteudo em si mas pelas referencias que tem. Elas devem ser lidas.
http://stal.blogspot.com/2006/03/software-architects-role.html
http://jrothman.com/blog/mpd/2006/04/architects-must-write-code.html
http://www.designpatternsfor.net/default.aspx?pid=5
http://www.designpatternsfor.net/default.aspx?pid=19
http://www.designpatternsfor.net/default.aspx?pid=53
http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCast-Becoming-an-Architect/ <- pelos comentários
http://www.delphi.co.za/PermaLink,guid,2261ac8e-0ae3-452b-b638-acc8b01f63c4.aspx

A referencia aos três projetos para ser arquiteto assisti num video então está mais dificil de achar (sobretudo pq não lembro o autor). quando achar eu coloco aqui. Mesmo ignorando isso, as referencias acima deixam claro que experiencia é necessária para ser arquiteto. Embora existam pessoas como o Martin Fowler que acham que não precisamos deles. (procurem que acham o pdf dele).

Notícias, artigos e o maior fórum brasileiro sobre Java