Uma Pequena Provocação aos Arquitetos

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

sergiotaborda wrote:Parece que feri o ego de muita gente afirmando que um arquiteto de verdade tem que ter experiencia passada com o desenvolvimento de sistemas.

O problema não foi dizer em desenvolvimento de sistemas. Você não se referiu a qualquer sistema, mas a sistemas distribuídos. E foi isso que incomodou o pessoal.

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

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

sergiotaborda wrote: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).

Hahaha

Você não havia dito que arquiteto deveria ter desenvolvido sistemas. Isto é óbvio, duvido que alguém aqui discorde.

Você disse que um arquiteto deveria ter desenvolvido ao menos 3 sistemas distribuídos. Isto, como eu já disse, é uma das coisas mais bizarras que eu já li aqui.

JavaBaby Membro desde: 18/09/2004 11:10:06 Mensagens: 90 Offline

sergiotaborda wrote:
algumas referencias - já que vocês são incapazes de procurar no google

Não tenho dúvidas que todos somos capazes de usar o Google. Mas não espere que possamos adivinhar em quais referências você apoia suas teorias.
Acho que a discussão aqui está sendo muito válida, mas por favor, sem levar para o lado pessoal.

Olá

paulofernandesjr wrote:...

sergiotaborda wrote:...última mensagem...

Então... estamos nos entendendo e concordo com os dois.

Quando sai jogando pedras contra os arquitetos de aplicações distribuídas é porque na minha vivẽncia muita gente andou tentando distribuir o que não era para ser assim. E influenciado pelos teóricos da SUN que são useiros e vezeiros na tentativa de criar regulamentos e burocracias desnecessárias.

Já conheci arquitetos/gerenbtes de projeto extremamente criativos que não conheciam quase nada do código a ser usado no projeto Java. Mas com enorme conhecimento do negócio que lhes dava uma visão geral tão boa que a partir de algumas explicações técnicas e um bom backgroung tecnológico, conseguiram perceber as vantagens e desvantagens das alternativas oferecidas.

Mas o normal e desejável é que o arquiteto entenda de design e de código.

[]s
Luca

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

ViniGodoy wrote:

sergiotaborda wrote:Parece que feri o ego de muita gente afirmando que um arquiteto de verdade tem que ter experiencia passada com o desenvolvimento de sistemas.

O problema não foi dizer em desenvolvimento de sistemas. Você não se referiu a qualquer sistema, mas a sistemas distribuídos. E foi isso que incomodou o pessoal.

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

lol... e ninguem disse isso ...

Eu não lembro se o autor disse essa palavra. Mas veja-se o seguinte:

O cara que participou do desenvolvimento de um projeto que não numa posição de decisão pode ser chamado de arquiteto ?
Quantos projetos precisa participar na posição de simples desenvolvedor - sem decidir tecnologias, design, protocolos, etc... - a pessoa precisaria para pode se considerar arquiteto ?
Quantos projetos em que participou das decisões ?
Quantos projetos em que foi responsável pelas decisões ? ( ou seja, em quantos o dele estava na reta)

Ok. Agora escolhido esse numero pense:

Ainda é válido se todos esses projetos foram standalone ? (digamos swing local para tocar mp3 ou embarcado sem comunicação externa) Ou seja, ainda é válido se em nenhum desses projetos ele usou/escolheu um protocolo sequer ?

Pode ser menos se todos os projetos demandaram algum tipo de distribuição (aka :usaram 1 ou mais protocolos) ?

Na minha opinião se o cara não fez sistemas distribuidos ele não se pode considerar arquiteto. E mais, se ele fez mas apenas com uma tecnologia - digamos java - ele não se pode chamar Arquiteto, apenas Arquiteto Java ( o que pela definição de arquiteto não é um arquiteto verdadeiro). Para ser arquiteto é preciso ter conhecimento de várias tecnologias e várias plataformas. Várias >= 2.

O cara usou clipper, delphi, VB5 , VB6 :vc o contraria para arquiteto ?
E se ele desenvolveu um sistema java e um sistema .net ?
...

O ponto é que - independentemente da citação - existe um limite mínimo para que se possa considerar que a pessoa pode ser chamada de arquiteto. A sun fala em 100 horas de projeto ( mais ou menos um mês, mês e meio, na america) , conhecer design patterns (aka ter sido developer ) protocolos (especialmente HTTP) e tecnologias distribuída :EJB , Corba e conceitos como concorrencia e transação que só fazem sentido em aplicações com algum nivel de distribuição.

Acho que a noção que de que a experiência tem que ser em sistemas distribuídos é implícita. Como vc juntaria duas tecnologias em sistemas que não são distribuidos ?

sergiotaborda wrote:

O ponto é que - independentemente da citação - existe um limite mínimo para que se possa considerar que a pessoa pode ser chamada de arquiteto. A sun fala em 100 horas de projeto ( mais ou menos um mês, mês e meio, na america) , conhecer design patterns (aka ter sido developer ) protocolos (especialmente HTTP) e tecnologias distribuída :EJB , Corba e conceitos como concorrencia e transação que só fazem sentido em aplicações com algum nivel de distribuição.

Acho que a noção que de que a experiência tem que ser em sistemas distribuídos é implícita. Como vc juntaria duas tecnologias em sistemas que não são distribuidos ?

é óbvio(ou deveria ser) que quanto mais uma pessoa tenha trabalhado, seja com a mesma tecnologia ou tecnologia diferente, em situações diferentes que ela melhore o seu desempenho em tomar decisões, isso ocorre até com desenvolvedores, quem é que não pegou o seu primeiro código e não disse "Nossa como qu eu fiz isso, tem tanta coisa que poderia ser melhorada" isso é fato, quanto mais se trabalha melhor fica e claro, ler as opniões de outras pessoas ( livros , blogs. etc.. ) aprimoram o conhecimento

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

Kenobi wrote:
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.

Sem dúvida Kenobi. Mas tb há os "Miguétetos" que, iludidos pelos vendedores on não, acreditam que é só definir as ferrramentas e as camadas para depois colocar o pé em cima da mesa e esperar que o projeto aconteça na mão dos desenvolvedores. Essa tb é a realidade na maioria das empresas.

This message was edited 1 time. Last update was at 03/12/2009 13:41:34

andre_salvati wrote:

Kenobi wrote:
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.

Sem dúvida Kenobi. Mas tb há os "Miguétetos" que, iludidos pelos vendedores on não, acreditam que é só definir as ferrramentas e as camadas para depois colocar o pé em cima da mesa e esperar que o projeto aconteça na mão dos desenvolvedores. Essa tb é a realidade na maioria das empresas.

Não há produto que resista a um mau design. Veja o caso dos ESBs, que irei blogar a semana que vem, é visto hoje por muitos como um mal, pois os players venderam de forma errônea, atrelaram SOA à utilização do produto, o que é um absurdo !!

Produtos possuem papel e serventia. A função da equipe de marketing das empresas é maximizar a oferta, tentando abocanhar os mais diferentes pontos a fim de completar uma estrégia de ação comercial, resultando em mais vendas.

O papel do Arquiteto nesse ponto é saber até onde ele pode usar os produtos, se de fato há ROI na utilização dos mesmos. Deveria na minha opinião fazer a orientação sobre a compra ou não e também melhores formas de utilização. Isso vai desde um ApplicationServer a produtos complexos como Engine de Real Time, Grid de Memória, Processador de Eventos, Engine de WorkFlow e por aí vai ...

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

Kenobi wrote:
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..

kenobi acho que o ponto da discussão é justamente esse!
porque toda a equipe de desenvolvedores, ou só quatro caras mais experientes, discutindo a arquitetura não é mais eficiente do que apenas uma pessoa?
já pararam para pensar no efeito positivo que tem fazer com que todo mundo entenda para onde e porque o projeto está indo por tal caminho?
eu acredito que na mão de um ditador o projeto tem muito mais chances de falhar do que numa democracia técnica.
acredito também que o problema é que na faculdade e no dia-a-dia não somos estimulados a convencer as pessoas, aí tem que ser criados esses cargos de ditadura para que as pessoas aceitem nossas idéias boas. quando a gente aprende a discutir e apresentar idéias, cargos como esses não são mais necessários.

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

bobmoe wrote:

Kenobi wrote:
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..

kenobi acho que o ponto da discussão é justamente esse!
porque toda a equipe de desenvolvedores, ou só quatro caras mais experientes, discutindo a arquitetura não é mais eficiente do que apenas uma pessoa?
já pararam para pensar no efeito positivo que tem fazer com que todo mundo entenda para onde e porque o projeto está indo por tal caminho?
eu acredito que na mão de um ditador o projeto tem muito mais chances de falhar do que numa democracia técnica.
acredito também que o problema é que na faculdade e no dia-a-dia não somos estimulados a convencer as pessoas, aí tem que ser criados esses cargos de ditadura para que as pessoas aceitem nossas idéias boas. quando a gente aprende a discutir e apresentar idéias, cargos como esses não são mais necessários.

Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal "Arquiteto", pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.

Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas....mas quantas equipes você encontra dessa maneira ?

Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão ...complicado !!

Fazendo um paralelo com o sistema Taylorista, em muitos cenários ele se aplica, não que seja a melhor prática.

Kenobi wrote:

bobmoe wrote:

Kenobi wrote:
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..

kenobi acho que o ponto da discussão é justamente esse!
porque toda a equipe de desenvolvedores, ou só quatro caras mais experientes, discutindo a arquitetura não é mais eficiente do que apenas uma pessoa?
já pararam para pensar no efeito positivo que tem fazer com que todo mundo entenda para onde e porque o projeto está indo por tal caminho?
eu acredito que na mão de um ditador o projeto tem muito mais chances de falhar do que numa democracia técnica.
acredito também que o problema é que na faculdade e no dia-a-dia não somos estimulados a convencer as pessoas, aí tem que ser criados esses cargos de ditadura para que as pessoas aceitem nossas idéias boas. quando a gente aprende a discutir e apresentar idéias, cargos como esses não são mais necessários.

Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal "Arquiteto", pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.

Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas....mas quantas equipes você encontra dessa maneira ?

Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão ...complicado !!

realmente é complicado montar uma equipe, porém um grupo técnicamente bom poderia resolver em pouco tempo uma arquitetura ruim, mas uma boa arquitetura não é a prova de uma equipe ruim.

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

bobmoe wrote:

Kenobi wrote:
Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal "Arquiteto", pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.

Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas....mas quantas equipes você encontra dessa maneira ?

Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão ...complicado !!

realmente é complicado montar uma equipe, porém um grupo técnicamente bom poderia resolver em pouco tempo uma arquitetura ruim, mas uma boa arquitetura não é a prova de uma equipe ruim.

Eu acho o mesmo que o Kenobi. Mais pessoas não significa melhores decisões. E sim, o papel do arquiteto, do verdadeiro, daquele que recebe cachê por ter esse titulo, é decidir as sais justas. Nâo apenas decidir, mas arcar com as consequencias. todas elas.

Pensar que mais pessoas tomam melhores decisões é o que os gerentes de meia-boca que contratam 4 juniors e esperam um sistema bem feito. Qualidade não se compra, se tem.

O Livro de Mythical Man-Month fala do que chama "uma equipe cirurgica" no sentido que ha um cirurgião que opera e um conjunto de auxiliares. Este conceito é perene ainda hoje pq as pessoas querem que alguem - que não elas- seja responsável. embora todos os auxiliares terem formação superior e serem especialistas no seu campo é uma pessoa que os faz trabalhar juntos. Este conceito do "lider moral" da equipe é muito comum,mas ninguem sabe a quem atribui-lo. alguns o atribuiem ao arquiteto outros ao gerente ,etc... mas não podemos conjundir essas posições com essa do "lider moral" da equipa. O ponto é que ninguem consegue ser "lider moral" sem saber muito sobre o seu trabalho e o dos outros.

This message was edited 1 time. Last update was at 03/12/2009 15:56:32

sergiotaborda wrote:

bobmoe wrote:

Kenobi wrote:
Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal "Arquiteto", pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.

Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas....mas quantas equipes você encontra dessa maneira ?

Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão ...complicado !!

realmente é complicado montar uma equipe, porém um grupo técnicamente bom poderia resolver em pouco tempo uma arquitetura ruim, mas uma boa arquitetura não é a prova de uma equipe ruim.

Eu acho o mesmo que o Kenobi. Mais pessoas não significa melhores decisões. E sim, o papel do arquiteto, do verdadeiro, daquele que recebe cachê por ter esse titulo, é decidir as sais justas. Nâo apenas decidir, mas arcar com as consequencias. todas elas.

Pensar que mais pessoas tomam melhores decisões é o que os gerentes de meia-boca que contratam 4 juniors e esperam um sistema bem feito. Qualidade não se compra, se tem.

O Livro de Mythical Man-Month fala do que chama "uma equipe cirurgica" no sentido que ha um cirurgião que opera e um conjunto de auxiliares. Este conceito é perene ainda hoje pq as pessoas querem que alguem - que não elas- seja responsável. embora todos os auxiliares terem formação superior e serem especialistas no seu campo é uma pessoa que os faz trabalhar juntos. Este conceito do "lider moral" da equipe é muito comum,mas ninguem sabe a quem atribui-lo. alguns o atribuiem ao arquiteto outros ao gerente ,etc... mas não podemos conjundir essas posições com essa do "lider moral" da equipa. O ponto é que ninguem consegue ser "lider moral" sem saber muito sobre o seu trabalho e o dos outros.

mas a qualidade do arquiteto vai seguir o nível da empresa, é por isso que ter mais cabeças pensantes sempre vai ser melhor.
o problema desse lider moral que vc citou é a centralização do conhecimento em uma pessoa. saias justas não podem existir, tudo deve estar disseminado entre a equipe, ou pelo menos para uma parte mais capacitada do grupo (que seja mais de uma pessoa).

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

Arquiteto que não programa ta fazendo o que? brincando de ser empresário?

mochuara wrote:Arquiteto que não programa ta fazendo o que? brincando de ser empresário?

bixo, pior q ta chegando nesse ponto, existe gente por aí até achando que arquiteto é um cargo administrativo

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