Uma Pequena Provocação aos Arquitetos

Programação Arquitetura
#21

[quote=andre_salvati][quote=sergiotaborda]
Tecnicamente arquitetura de um sistema não se programa, se escolhe.
[/quote]

Quem escolhe ou é o Miguéteto ou é o vendedorzinho de ferramentas Java EE (normalmente com o pomposo nome de Solutions Architect).

Arquiteto de verdade é Programador Jedy, e põe a mão na massa, e desenvolve, e testa e valida a Arquitetura de acordo com requisitos fornecidos pelo cliente. E ainda define padrões e práticas e orienta e garante que o time esteja desenvolvendo de acordo com esses padrões. Por isso ele deve trabalhar lada a lado com desenvolvedores e não em uma torre de marfim onde só seres semelhantes a ele podem se elevar.

Ahhh, e não existe Arquiteturinha receita-de-bolo como muitos acreditam. :wink:
[/quote]

Olhando assim tua frase me parece que o arquiteto é programador senior, o que não é verdade. Muita gente pensa assim, mas não é. Um arquiteto não deve de forma alguma fazer um caso de uso e afins. Nem perto disso.

Outro dia um amigo que está trabalhando em um projeto de NFE me disse: fui contratado como junio, mas estou programando que nem arquiteto. Então eu tive de corrigir: não, você está programando que nem um PROGRAMADOR senior.

Como eu disse acima, não vejo problemas em um arquiteto codificar componentes que envolvem a arquitetura, mas no máximo isso. Se envolver com funcionalidades, escrever tela de login e afins é coisa de programador.

#22

[quote=garcia-jj]
Como eu disse acima, não vejo problemas em um arquiteto codificar componentes que envolvem a arquitetura, mas no máximo isso. Se envolver com funcionalidades, escrever tela de login e afins é coisa de programador.[/quote]

Já vi telas de login derrubarem JVMs de tanta coisa que o código fazia quando o usuário logava. E aí? Culpa do arquiteto ou do programador?

Aliás, existem empresas que onde o login envolve vários tipos de autenticação, em várias bases de dados e com Single Sigle-on. Problema de arquiteto ou de desenvolvedor? :wink:

#23

[quote=garcia-jj][quote=andre_salvati][quote=sergiotaborda]
Tecnicamente arquitetura de um sistema não se programa, se escolhe.
[/quote]

Quem escolhe ou é o Miguéteto ou é o vendedorzinho de ferramentas Java EE (normalmente com o pomposo nome de Solutions Architect).

Arquiteto de verdade é Programador Jedy, e põe a mão na massa, e desenvolve, e testa e valida a Arquitetura de acordo com requisitos fornecidos pelo cliente. E ainda define padrões e práticas e orienta e garante que o time esteja desenvolvendo de acordo com esses padrões. Por isso ele deve trabalhar lada a lado com desenvolvedores e não em uma torre de marfim onde só seres semelhantes a ele podem se elevar.

Ahhh, e não existe Arquiteturinha receita-de-bolo como muitos acreditam. :wink:
[/quote]

Olhando assim tua frase me parece que o arquiteto é programador senior, o que não é verdade. Muita gente pensa assim, mas não é. Um arquiteto não deve de forma alguma fazer um caso de uso e afins. Nem perto disso.

Outro dia um amigo que está trabalhando em um projeto de NFE me disse: fui contratado como junio, mas estou programando que nem arquiteto. Então eu tive de corrigir: não, você está programando que nem um PROGRAMADOR senior.

Como eu disse acima, não vejo problemas em um arquiteto codificar componentes que envolvem a arquitetura, mas no máximo isso. Se envolver com funcionalidades, escrever tela de login e afins é coisa de programador.[/quote]

Se souber de alguma empresa que paga arquiteto pra ficar coçando me avisa.

#24

[quote=leosouzabh]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.[/quote]

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.

#25

Você realmente sabe ler? Em momento algum eu falei isso. Há um erro achar que realmente o arquiteto vai programar como desenvolvedor. O Sérgio mesmo já havia ilustrado sobre isso. Releia com atenção antes de fazer comentários sem fundamento.

[quote=andre_salvati]Já vi telas de login derrubarem JVMs de tanta coisa que o código fazia quando o usuário logava. E aí? Culpa do arquiteto ou do programador?

Aliás, existem empresas que onde o login envolve vários tipos de autenticação, em várias bases de dados e com Single Sigle-on. Problema de arquiteto ou de desenvolvedor? ;)[/quote]

Criar uma tela de login é papel do programador, arquiteto não faz isso. Da forma que você falou é muito vago, porém se for um erro de arquitetura é culpa do arquiteto sim, mas se for um maldito loop infinito que o programador fez, que culpa tem o arquiteto?

Muitas empresas contratam arquiteto para codificar, achando que o arquiteto é um programador senior, o que nem sempre é verdade. Há uma mistura de papéis aí.

#26

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?

Abraços

#27

Não. O que vc diz é uma grande besteira porque o arquiteto tem que ser um desenvolvedor. Se ele vai programar mais ou menos do que outro que é desenvolver full-time não é relevante para a discussão como vc quer fazer parecer.

#28

[quote=ViniGodoy][quote=leosouzabh]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.[/quote]

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.[/quote]

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.

#29

Você realmente sabe ler? Em momento algum eu falei isso. Há um erro achar que realmente o arquiteto vai programar como desenvolvedor. O Sérgio mesmo já havia ilustrado sobre isso. Releia com atenção antes de fazer comentários sem fundamento.

[/quote]

Em lado nenhum eu falei que o arquiteto programava mais ou menos que o desenvolvedor. Eles programam quanto for necessário quando for necessário. Como falei, arquiteto é um role. Designer é outro, tester, etc… todos programam. dizer que um programa mais que outro não faz sentido.

Ora aqui é que está. as pessoas têm que entender que a culpa é quem tomou a decisão errada. É por isso que em agil a decisão é tomada em grupo e a responsabilidade é tomada em grupo. Porque errar é menos pior que deixar errar ou não solucionar.

[quote]
Muitas empresas contratam arquiteto para codificar, achando que o arquiteto é um programador senior, o que nem sempre é verdade. Há uma mistura de papéis aí.[/quote]

Isso é verdade. Senioridade não faz um arquiteto (nem sequer faz um programador, quanto mais).

#30

[quote=mochuara]
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.[/quote]

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:

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?

#31

Fontes por favor???

#32

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.

#33

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

Bons arquitetos fazem a arquitetura sumir.

#34

[quote=sergiotaborda]
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.[/quote]

“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…

#35

Olá

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

#36

[quote=Luca]Olá

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[/quote]

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…

#37

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.

#38

[quote=rodrigoy]Arquiteto, assim como DBA, é um cargo que vai se extinguir…

Bons arquitetos fazem a arquitetura sumir.[/quote]

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.

#39

[quote=sergiotaborda][quote=ViniGodoy][quote=leosouzabh]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.[/quote]

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.[/quote]

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.[/quote]
Nossa, essa foi uma das coisas mais bizarras que eu já li por aqui.

#40

Olá

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