Uma Pequena Provocação aos Arquitetos

Polemico este assunto.

Me faz lembrar um tema do mundo administração relacionado ao tipo de lider:

Tem aquele que nunca participou dos processos da empresa (traduzindo: meteu a mão na massa no amago da coisa) porem está na posição de liderança se valendo dos conceitos teóricos adquiridos nos livros e com os professores da universidade. Por outro lado existe outro tipo de lider que nasce dentro da organização passando pela maioria dos processos deixando seu suor em boa parte da empresa e que agora chegou na posição de lider.

Um ignora questões relacionadas a pratica em função da teoria; isto é bom? Acredito que nem sempre.

O outro ignora questões relaconadas a teoria em função da pratica; isto é bom? Acredito que nem sempre também.

Na minha opinião, para todos em tudo o que vale é o bom senso; saber desempenhar bem o papel no momento devido, não esquecendo que as coisas raramente estão totalmente desconectadas principalmente no tocante a sistemas (sistemas não é coisa só da computação).

Hoje penso que a arquitetura parte como sugestão de um profissional que chamam de arquiteto e como tal precisa ser avaliada pela equipe antes de ser instaurada. E que nada impede do “arquiteto” participar como desenvolvedor.

flws

Eu não consigo respeitar um arquiteto que não esteja engajado com o projeto.
Claro, existem níveis e níveis de arquitetura. Em mega-projetos, talvez a equipe arquitetural responsável não sente do teu lado e te ajude com um problema do framework, mas para todos os outros tipos de projetos, eu desprezo totalmente arquitetos-de-prateleira, que só sabem ficar falando asneiras, e dando pitaco no trabalho dos outros, sem se envolver e participar ativamente do desenvolvimento do projeto.

O fato de você ser um arquiteto não significa que você é programador; mas isso também não significa que você não pode programar.

@fantomas É verdade cara. Acho que o melhor é quanto se tem um equilíbrio entre a teoria e prática.

Exato. E não siginifica que você fica fazendo diagraminhas. Arquitetos são, na grande maioria das vezes, para tomada de decisões em relação a um sistema existente ou em fase de construção, considerando os “ilitys” que ele aprendeu nos anos de experência que tem.

Na maioria das vezes vejo o papel do arquiteto em decisões importantes mesmo, pq dificilmente trabalho com projetos novos. (So barco afundando rs). As vezes a necessidade de integrar alguns sistemas, ou a detecção de problemas futuros na arquitetura de sistemas legados.
Essas coisas. nesse caso as vezes o legal é ter um programador bom para visualizar a ideia do arquiteto com facilidade, liderar tecnicamente a equipe e meter a mão na massa.

Mas não quer dizer que o fato de tomar decisão seja apenas fazer docs e diagramas, as vezes e na maioria delas uma boa prova de conceito é uma forma de decisão

Esse bom é aquela mesma história de analista so faz diagrama.

Todo o profissional deve entender o todo, não somente a sua parte. Apartir do momento que um analista não codifica, ou um arquiteto, ele não conheçe o problema, nem sabe quais decisões tomar corretamente, ele toma baseado no achismo, no que ele acredita certo.

Pra mim quem não suja as mãos não mereçe meu reconhecimento.

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.

Complementando meu comentário, quando digo que o arquiteto pode sim programar não falo de codificar regras de negócio, mas sim algum componente que faça parte da arquitetura do projeto.

É a velha história do DEPENDE.
Cada caso é um caso e acho que a maioria aqui pode dar exemplos e contra-exemplos.

andrefariagomes:

Retirado do artigo Software Craftsmanship com Uncle Bob Martin
http://andrefaria.com/2009/11/30/software-craftsmanship-com-uncle-bob-martin/

Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no ?mundo que constroem para os outros?, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ?não tem que dormir na cama que faz?.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experiências o que o time está fazendo para saber o que ele realmente precisa.

E aí galera, vocês concordam com isso?
Os que são arquitetos, põe realmente a mão na massa ou passam o dia fazendo diagramas?

Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz “architecture” ou “design”.
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.

Um exemplo interessante que conta como ponto positivo aos arquitetos “que ficam dando pitaco no código dos outros”, é quando você possui uma equipe muito grande (não quero dizer que isso seja uma coisa boa), e precisa manter certa “homogenidade” na base de código.

Minha visão é que o arquiteto de software deve prover ferramentas pra facilitar a vida dos desenvolvedores, e matar 3 aliens e um predador por semana :mrgreen:

Fantástico - queria que todos gerentes de projetos da face da terra (que aplicam waterfall) percebessem isso - nossa vida seria muito mais fácil

sergiotaborda:

Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz “architecture” ou “design”.
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.

Sérgio, como assim? O que é arquitetura para você? Escolher o que? Liguagens? Frameworks? Se você acha que o Robert Martin não sabe do que fala seria legal vc escrever um artigo, citando fontes e provando isso…

A todos…Desde o método Objectory, pré RUP, nosso amigo Jacobson já falava que arquitetura é EXECUTÁVEL (e isso nos anos 70 e 80). Nenhum autor, diz que arquitetura são diagramas. O RUP que geralmente é o culpado pelas aberrações do mercado desde sempre disse que o fruto da elaboração é uma arquitetura provada com software funcionando (geralmente implementando alguns cenários complexos dos casos de uso mais importantes). E acredite, há projetos que você PRECISA provar a arquitetura antes de começar a entregar kilos de funcionalidades. Foco em arquitetura: uma das bases do RUP, resolva a arquitetura primeiro e você não terá problemas no futuro. Isso é válido para sistemas mais complexos, se você só usa arquitetura Toddinho (de caixinha), você nunca fez um software com riscos arquiteturais significativos…

Se um arquiteto não sabe codar ele não serve para nada. #ivory_tower…

rodrigoy:

sergiotaborda:

Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz “architecture” ou “design”.
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.

Sérgio, como assim? O que é arquitetura para você? Escolher o que? Liguagens? Frameworks? Se você acha que o Robert Martin não sabe do que fala seria legal vc escrever um artigo, citando fontes e provando isso…

A todos…Desde o método Objectory, pré RUP, nosso amigo Jacobson já falava que arquitetura é EXECUTÁVEL (e isso nos anos 70 e 80). Nenhum autor, diz que arquitetura são diagramas. O RUP que geralmente é o culpado pelas aberrações do mercado desde sempre disse que o fruto da elaboração é uma arquitetura provada com software funcionando (geralmente implementando alguns cenários complexos dos casos de uso mais importantes). E acredite, há projetos que você PRECISA provar a arquitetura antes de começar a entregar kilos de funcionalidades. Foco em arquitetura: uma das bases do RUP, resolva a arquitetura primeiro e você não terá problemas no futuro. Isso é válido para sistemas mais complexos, se você só usa arquitetura Toddinho (de caixinha), você nunca fez um software com riscos arquiteturais significativos…

Se um arquiteto não sabe codar ele não serve para nada. #ivory_tower…

O que o Robert Martin fala na referencia citada é que um arquiteto deve ser uma pessoa que também codifica. a palavra chave aqui é “também”. Em nenhum ponto ele fala que arquitetura é codificada. O que ele diz é que o arquiteto deve pertencer À equipa, codificar com ela, e estar a par dos problemas.

Nos EUA o arquiteto é uma especie de lider. Lider Tecnico e Arquiteto são sinonimos. Eu não acho que isso tenha que ser assim. Eu acho que arquiteto é um role, não uma pessoa.
Numa equipe multifuncional alguem tem que fazer o papel do arquiteto. Isso não significa que ele não faça outros papeis, inclusive o de lider e o de programador.

Arquitetura , por definição, é diferente de design. A arquitetura atente a requisitos não funcionais de comunicação e deploy das aplicações que formam o sistema. O papel de um arquiteto é saber conjugar aplicações, não fazer aplicações. Escolher protocolos , escolher plataformas. No cubo arquitetural ele é responsável pela escolha das plataformas que sustentarão a aplicação e de manter algumas qualidades do sistema como a disponibilidade. O papel do arquiteto não é escrever codigo, ele pode escrever , mas não é a sua principal preocupação. A sua principal preocupação é entender as tecnologias, e como elas atuam para um determinado fim. Por exemplo, escolher entre EJB e ESB , entre Java o .NET etc… pode chegar no nivel de escolher a linguagem conforme a equipe (java ou ruby ) e por isso ele pode se confundir com o lider tecnico. O arquiteto escolhe quantos e quais os componentes da aplicação. De quantos e quais jars a aplicação será formada e dependencias de outas bibliotecas.
Em resumo, o arquiteto cuida de todo o ambiente externo ao codigo mas que o influencia ou é influenciado por ele.

O designer cuida dos andares ( camadas) ele cuida de como montar cada componente da arquitetura baseado nas tecnologias, plataformas e protocolos escolhidos pelo arquiteto. Ele escolhe entre frameworks que fazem o mesmo na arquitetura, por exemplo, o arquiteto define o uso de java e um servlet container. o designer escolhe entre o tomcat e o jetty (ou outros). Ele escolhe e aplica padrões de design , ele define práticas de programação, ele define estilo de programação ( checkstyle) . Em resumo, ele cuida do codigo que constroi cada componente da arquitetura.

A arquitetura é executável ? sim. Podemos fazer provas de conceito de arquitetura? sim. Mas isso não significa que o arquiteto escreve codigo ou que a arquitetura é algo codificável.
A decisão de um designer é facilmente refactorada a de um arquiteto não. Mudar de webservice para JMS representa mudar o como o sistema se comporta no ambiente, e suas dependências com esse ambiente e o como as outras aplicações enxergam esse sistema, ou seja, é mudar superficie de contato do sistema. Isso torna-o em outro sistema, mesmo que ele faça o mesmo.

Em nenhum momento o Robert fala que arquitetura é programável ou codificável. Ou que teria que ser. Ele fala que: arquitetura é sobre tomar decisões e que o arquiteto deve pertencer à equipa e que ele deve codificar a aplicação como qq outro membro da equipa. Tudo isto é verdade. E em nenhum momento ele afirma que arquitetura é algo que se codifica.

Como nota devo acrescentar que o que se fazia ou se achava ou não nos anos 70 e 80 não é relevante. Muitas das assunções feitas nesse tempo se mostram completamente irreais agora e o proprio Robert cita as ferramentas CASE como um exemplo de algo que não deu certo.

Eu tb sou defensor de uma aproximação arquitetura primeiro e já vi muitos sistemas falharem por terem uma arquitetura mais desenvolvida e desorganizada. Nem sei o que seria uma arquitetura de caixinha. You are overreacting.

Resumindo o assunto, depois que ouvi o que o Robert tinha a dizer eu achei extremamente válido e aprendi o nome de algo que já conhecia da prática,mas não conhecia o nome, nem sabia que era algo “institucionalizado” : software craftmanship. Acho que isto sim é a mensagem mais importante do dialogo e que tanto agilistas como tradicionalistas deveriam entender. A parte sobre robotizar o desenvolvimento teve um saida inteligente - dizendo que os IDE e as ferramentas são esses robots - mas quando apertado pelo entrevistador ele voltou um pouco atrás na ideia de um modelo executável que ele tinha começado por ser contra (CASE, MDA). Não acho que o dialogo se resume a uma provocação aos arquitetos mas sim um apelo a todos os desenvolvedores sérios a acordarem para a qualidade e orgulho na qualidade do software que produzem.

Felagund:

Esse bom é aquela mesma história de analista so faz diagrama.

Todo o profissional deve entender o todo, não somente a sua parte. Apartir do momento que um analista não codifica, ou um arquiteto, ele não conheçe o problema, nem sabe quais decisões tomar corretamente, ele toma baseado no achismo, no que ele acredita certo.

Pra mim quem não suja as mãos não mereçe meu reconhecimento.

eu concordo… para mim um arquiteto deve conhecer muito da tecnologia, ja inclusive ter mechido com ela (por que certas coisas, certos conhecimentos só vem com a prática) e conhecer da regra de negocio também, apesar de considerar que o conhecimento da regra de negócio é um pouco menos importante que da tecnologia e da forma utilizada para transformar essa regra de negócio em software, isso qu o arquiteto deve ser mais voltado.

opinião.

concordo em genero, numero e grau!!!

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.

rodrigoy:

sergiotaborda:

Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz “architecture” ou “design”.
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.

Sérgio, como assim? O que é arquitetura para você? Escolher o que? Liguagens? Frameworks? Se você acha que o Robert Martin não sabe do que fala seria legal vc escrever um artigo, citando fontes e provando isso…

A todos…Desde o método Objectory, pré RUP, nosso amigo Jacobson já falava que arquitetura é EXECUTÁVEL (e isso nos anos 70 e 80). Nenhum autor, diz que arquitetura são diagramas. O RUP que geralmente é o culpado pelas aberrações do mercado desde sempre disse que o fruto da elaboração é uma arquitetura provada com software funcionando (geralmente implementando alguns cenários complexos dos casos de uso mais importantes). E acredite, há projetos que você PRECISA provar a arquitetura antes de começar a entregar kilos de funcionalidades. Foco em arquitetura: uma das bases do RUP, resolva a arquitetura primeiro e você não terá problemas no futuro. Isso é válido para sistemas mais complexos, se você só usa arquitetura Toddinho (de caixinha), você nunca fez um software com riscos arquiteturais significativos…

Se um arquiteto não sabe codar ele não serve para nada. #ivory_tower…

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.

andre_salvati:

sergiotaborda:

Tecnicamente arquitetura de um sistema não se programa, se escolhe.

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.

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.

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.

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?

garcia-jj:

andre_salvati:

sergiotaborda:

Tecnicamente arquitetura de um sistema não se programa, se escolhe.

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.

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.

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

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.

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.

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.

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? ;)

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í.

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

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.

ViniGodoy:

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.

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.
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.

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.

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.

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í.

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

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.

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?

Fontes por favor???

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:

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á

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

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

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…

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:

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.

sergiotaborda:

ViniGodoy:

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.

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.

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

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…

rodrigoy:

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.

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?

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.

felipeguerra:

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.

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).

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:

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).

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.

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á

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

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.

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 ?

é ó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

Kenobi:

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.

andre_salvati:

Kenobi:

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 …

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.

bobmoe:

Kenobi:

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:

bobmoe:

Kenobi:

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.

bobmoe:

Kenobi:

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.

sergiotaborda:

bobmoe:

Kenobi:

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).

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

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

Ninguém tá falando que o arquiteto não tem skill de programação e muitas vezes programa em diversas linguagens como Haskell, Erlang,Scala, Ruby, escreve DSL conhece produtos e por aí vai …Mas porém, contudo, todavia se o mesmo ficar no ambiente de trabalho sentado sobre o código de uma aplicação específica, ele acaba perdendo o sentido de coaching por exemplo sobre a equipe. Perde a visão externa da aplicação, não consegue dar vazão aos diversos projetos da empresa.

Acredito que o bom arquiteto precisa sim saber programar, fazer pesquisas, conhecer produtos e afins e se ficar somente programando, ele vira apenas mais um programador e não terá tempo de tomar decisões, conversas com fornecedores, fazer reuniões com clientes internos e externos e por aí vai … Esse é o ponto.

bobmoe:

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).

Bob, o problema são os “enterpresys” como diz o Akita. Você no papel de arquiteto estará sempre um passo à frente pois estuda, se dedica, tem conhecimento teórico e muitas vezes prático também, enquanto o seu colega sai às 18h e vai pro futebol e não tem a mínima idéia de quem seja por exemplo Eric Evans.

Cara já entrevistei muito “especialista SOA” que não sabia quem era Thomas Erl imagine se ouviu falar do Ian Robson, Jim Webber e por aí vai … Complicado !!

Por tanto, em muitos cenários - “enterprisys”, prefiro o Taylorismo.

Espero ter entendido errado, logo, sem querer ofender, mas esta coisa de exigir que um técnico saiba nomes de autores de livros e etc acho um pouco demais. É bonito, demonstra certo respeito e muitas vezes deixa o caboclo bem posicionado.

Mas…todos que conheci, sem exceção nenhuma, que ficava se gabando que leram tais e tais livros, ficavam citando nomes, passagens (como na biblia) e frases de efeito eram muuuuuito ruins tecnicamente; tremendos caras de pau. Costumavamos chama-los de vendedores, reis do xaveco. Enganavam o “gerente” tosco sem noção e conseguiam as vagas, infelizmente testes ajudam nesta hora.

Quando começavam a trabalhar era aquela coisa…não saia nada.

Portanto, quando encontro com alguem que começa a bancar o poeta ou professor de historia (estes sim sabem de nomes) perto de mim já vou logo desconfiando.

Na minha opinião tem que ser objetivo…vamos falar de problemas, soluções, novidades, formas criativas de construir software, trabalho em equipe, solução de conflitos e por ai vai.

Os nomes ajudam bastante na hora de comprar os livros na livraria - muitas vezes o vendedor pergunta pelo nome.

flws

Exactamente.
Acho que o problema é que o pessoal vive num misto de academismo/reverencialismo que é dificil de quebrar quando a pessoa não tem realmente conhecimento real. E além disso é sempre mais facil de fulano X disse porque :

1. argumento de autoridade , se x disse e x é autoridade => deve ser verdade
2. se der merda a culpa é do x.

Kenobi:

bobmoe:

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).

Bob, o problema são os “enterpresys” como diz o Akita. Você no papel de arquiteto estará sempre um passo à frente pois estuda, se dedica, tem conhecimento teórico e muitas vezes prático também, enquanto o seu colega sai às 18h e vai pro futebol e não tem a mínima idéia de quem seja por exemplo Eric Evans.

Cara já entrevistei muito “especialista SOA” que não sabia quem era Thomas Erl imagine se ouviu falar do Ian Robson, Jim Webber e por aí vai … Complicado !!

Por tanto, em muitos cenários - “enterprisys”, prefiro o Taylorismo.

Só reforçando, vale a pena ler o artigo do Fowler: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Eu gosto da citação “A importância de um arquiteto é inversamente proporcional ao número de decisões que ele precisa tomar.”

abracos

Sinceramente, pra mim é impossível o cara ter uma boa base sem conhecimento literário. Não tem como você ser bom, principalmente em Design de software sem estudar à fundo o assunto.

Se você nunca leu por exemplo um livro do Eric Evans - Domain Driven Design, ou não fez um curso referente ao tema, como sabe que está no caminho certo da modelagem ? Se nunca estudou engenharia de software, nunca leu um pattern, que é uma solução catalogada para aquele problema específico, como vai saber se seu design não vai incorrer nos problemas que muitos já passaram ?

Pra mim ir na raça, fazendo sem base alguma pode resultar em muita coisa ruim. Há também os que citam sem nunca terem lido e aí que está talvez sua má impressão ou pior, leu e não entendeu nada.

Mas se já é difícil fazer algo bom estudando muito, imaginem o cara que nunca pega um livro pra estudar…

Só pra fechar o assunto eu tenho a experiência inversa, inclusive muitos processos seletivos mais modernos pedem pra você citar seus 3 últimos livros lidos - TW, Globo.com (entre outras empresas). As pessoas mais antenadas, possuiam mais domínio do assunto.

Particularmente minha última contratação enquanto Gerente da equipe, era uma pessoa que conheci aqui no GUJ, que possui bastante experiência literária apesar da pouca idade e vi a diferença de destaque no dia-a-dia junto à equipe - Rubem Azenha.

PS: Sabe nome dos autores não é imprescindível, normalmente você o faz de forma incosnciente, pois se gosta da leitura acessa blog, artigos entre outros.

Bob, existe um conceito no Aikidô de Sempai-Kohai, onde o faixa preta(Sempai) é responsável pelo faixa branca (Kohai) e ajuda o mesmo no seu caminho à evolução.

Ninguém vai a um campeonato com faixas brancas, daí a importância de um processo seletivo criterioso. Você vai com um Shihan (Arquiteto) e vários Yodans, Sandans e no máximo alguns Shodans (faixa-preta 1 grau). Se você tiver no seu DOJO mais de um Shihan, sorte sua, ou alunos Yodan-Sandan, legal você pode compartilhar 90% da formação dos alunos. Aquele pedacinho que falta, onde o Shiran possui maior experiência ele contribui e auxlia no processo.

Se você não pode cuidar do processo de contratação, precisa cuidar da formação da sua equipe, tentar fazê-los passar de faixa, forçando os Katas, aprendizado.

Em muitas empresas, por questões de custo, optam em contratar profissionais intermediários (Faixa Azul - Aikidô) e o Shihan precisa forçar os conceitos, ensinar as melhores práticas e vai do discípulo querer evoluir, senão estaciona mesmo na faixa por anos.

Faixa branca é estagiário, não deve ter responsabilidade sobre decisões e nem sobre o andamento do projeto como um todo, está ali para aprender, fazer suas 6h de estágio, 4h em épocas de prova, conforme a lei e prestar o exame de faixa a final do mesmo :-).

kenobi:

Sinceramente, pra mim é impossível o cara ter uma boa base sem conhecimento literário. Não tem como você ser bom, principalmente em Design de software sem estudar à fundo o assunto.

Se você nunca leu por exemplo um livro do Eric Evans - Domain Driven Design, ou não fez um curso referente ao tema, como sabe que está no caminho certo da modelagem ? Se nunca estudou engenharia de software, nunca leu um pattern, que é uma solução catalogada para aquele problema específico, como vai saber se seu design não vai incorrer nos problemas que muitos já passaram ?

Pra mim ir na raça, fazendo sem base alguma pode resultar em muita coisa ruim. Há também os que citam sem nunca terem lido e aí que está talvez sua má impressão ou pior, leu e não entendeu nada.

Mas se já é difícil fazer algo bom estudando muito, imaginem o cara que nunca pega um livro pra estudar…

Só pra fechar o assunto eu tenho a experiência inversa, inclusive muitos processos seletivos mais modernos pedem pra você citar seus 3 últimos livros lidos - TW, Globo.com (entre outras empresas). As pessoas mais antenadas, possuiam mais domínio do assunto.

Particularmente minha última contratação enquanto Gerente da equipe, era uma pessoa que conheci aqui no GUJ, que possui bastante experiência literária apesar da pouca idade e vi a diferença de destaque no dia-a-dia junto à equipe - Rubem Azenha.

PS: Sabe nome dos autores não é imprescindível, normalmente você o faz de forma incosnciente, pois se gosta da leitura acessa blog, artigos entre outros.

De acordo…

A questão é a seguinte, eu quiz dizer que: não é porque o individuo leu o livro do Eric Evans, Martin Fowler e etc… ele será um entendido em determinada tecnologia ou será um bom arquiteto. Irá indicar, na minha opinião, apenas que a pessoa se interessa pelo assunto. Alem disso, não basta ler TEM QUE ENTENDER. Ou seja, leu 3 livros, mas aí vem as perguntas: Será que entendeu? Será que não formou pre-conceitos? Será que trocou o paradigma ou apenas adaptou? Aqui no GUJ percebo várias destas situações.

As vezes é melhor trabalhar com alguem que não conhece a tecnologia mas que tem todos os subsidios (principalmente a humildade) para aprender do que trabalhar com alguem que ACHA que sabe, pensa que porque leu o livro do Martin Fowler está salvo.

É claro que lêr é importante. Ler (e entender) livros na nossa àrea é algo que talvez não deveria ser nem questionado. Eu nunca ouvi dizer que perguntou se o carro viria com as rodas na hora da compra. Mais uma vez, eu entendo seu ponto de vista, quando participo de entrevistas procuro perceber se o candidato faz leituras, só não pergunto diretamento, porque estou em busca de conteúdo. Uma situação acaba levando a outra.

Se o arquiteto conhece bem DDD, interessa que livro ele leu? Aliás, o candidato acaba comentando mesmo sem querer.

Este teste dos 3 (é um número mágico?) livros me parece interessante, mas pelo que entendi funciona da seguinte maneira: se a pessoa leu um livro Eric Evans, um do Martin Fowler e outro do Ken Schwaber ele seria considerado profissional “antenado”. Mas uma coisa me chamaria a atenção sobre o candidato: o individuo não leu nada sobre trabalho em grupo, como funciona as relações interpessoais, produtividade etc…, ou seja, posso assumir também que o cara é um porre para trabalhar em equipe; talvez não saiba ouvir e nem se expressar com objetividade e clareza.

A idéia não é dizer que vc está certo ou errado…só não concordo totalmente com a idéia no momento.

E mais ainda, alertar que o mundo da tecnologia é maior do que a maioria pensa.

O mercado indica que o mais difícil não é encontrar alguem que conheça a tecnologia; o difícil é encontrar alguem que saiba se comportar, ser produtivo em grupo sem falar da questão de ser confiável no sentido de assumir justos compromissos.

flws

No Encontro Ágil 2009, Jutta Eckstein (http://www.jeckstein.com) disse que era importante ter em equipes uma pessoa que seja responsável pela visão de negócio e uma pessoa responsável pela visão técnica, claro que essa visão deve ser transmitida e compartilhada por toda a equipe, mas esses seriam, segundo ela, respectivamente, o papel (!= cargo), do product owner e do arquiteto.

Essa é outra definição interessante:

The architect is responsible for defining and maintaining the structure of the solution, and ensuring that it will meet the requirements. An agile architect must also help the team to work together in an agile fashion, to jointly own the solution, and to interface well with other parts of the organisation.

Fonte: http://www.agilearchitect.org/agile/role.htm

Eu creio que a necessidade, desde papel em uma equipe, assim como o papel de scrum master, por exemplo, está diretamente relacionado com a maturidade da equipe e das necessidades do projeto. Não acho que exista uma regra absoluta que seja aplicada a qualquer tipo de projeto ou equipe, entretanto, investigar o real valor deste papel em uma equipe é muito válido e pode ser tentado, desde que isso possa de alguma forma realmente agregar valor ao resultado final.

Outra referência interessante: http://martinfowler.com/articles/designDead.html#id73363

In software, the term architect means many things. (In software any term means many things.) In general, however it conveys a certain gravitas, as in “I’m not just a mere programmer - I’m an architect”. This may translate into “I’m an architect now - I’m too important to do any programming”. The question then becomes one of whether separating yourself from the mundane programming effort is something you should do when you want to exercise technical leadership.

Creio que Martin Fowler na frase acima realmente apresentou o real motivo de arquitetos estarem tão na moda. (e olha que este texto é de 2000).

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

Estamos falando da mesma coisa, mas em palavras diferentes. Talvez eu não esteja sabendo me explicar.

Olá

Parabéns pelo que escreveu.

Apesar de geralmente não ler com atenção mensagens anônimas, isto é, de quem não se identifica, li a sua e gostei muito.

Ler também é uma questão de gosto e de hábito. Leio desde criança e acho que minha geração lia mais do que as atuais. Alguém que diz que lê impressiona mas é como você escreveu. Há gente que aprende e gente que dá uma lidinha rápida. Posso falar por mim. Tenho um monte de livros. A maioria dei uma lidinha rápida ou li com atenção só uma parte do livro.

fantomas:

alertar que o mundo da tecnologia é maior do que a maioria pensa.

O mercado indica que o mais difícil não é encontrar alguem que conheça a tecnologia; o difícil é encontrar alguem que saiba se comportar, ser produtivo em grupo sem falar da questão de ser confiável no sentido de assumir justos compromissos…

Aqui então você matou a pau. Não basta saber. Tem que ser produtivo e construir um bom ambiente.

[]s
Luca

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a “arquitetura da aplicação” (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a “arquitetura da aplicação” (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

Uma equipe de 6 profissionais, concordo com você. Agora quando passa dos 40, se o cara ficar programando não faz coaching por exemplo e no mercado, o valor hora de um arquiteto é maior, logo seria um disperdício de dinheiro se ele ficasse programando igual a um programador Sr. e realmente ele terá inúmeras atribuições, pode acreditar.

PS: Dá um pulo em empresas de grande porte como Claro ou Bovespa e espie o dia-a-dia de um arquiteto de lá, vai começar a entender que o buraco é mais embaixo.

PS2: As duas empresas citadas, conheço seus respectivos arquitetos e problemas que caem no colo deles, todo dia.Vai desde Match de operações em tempo real à projetos de Billing para milhões de transações por dia…Aí, não tem tempo mesmo pra fazer qualquer telinha que seja.

O arquiteto tem q ser uma mistura de ler muito e saber colocar em prática (e quando colocar). Além disso ele precisa saber justificar bem as suas decisões para a equipe, acho que o status “pra que explicar se pode mandar” não cai bem nesse papel.

Eu lembro ter escutado num podcast que o responsável de TI do site Digg disse que recebia 100 currículos de pessoas com Doutorado em TI, mas pessoas que haviam gerenciado mais de 100 servidores ele nunca recebia, e era o que ele mais procurava.

Como já comentaram aqui, já peguei uma entrevista com esses picaretas que adoram falar bonito e citar livros. Bastou algumas perguntas mais técnicas, mais do conteúdo desses livros que a verdade apareceu. Esse tipo de gente faz parte do mercado infelizmente, e garanto que engana muito gerente por aí até hoje.

Não vejo o q uma coisa tem a ver com outra. Arquitetos não gerenciam servidores. Isso é responsa de infra…

Arquitetos gerenciam componentes, interfaces, padrões de desenvolvimento, ambientes de integração contínua…

Claro que é infra não é desenvolvimento, mas eu quis mostrar o tamanho do abismo entre o mundo acadêmico e o mercado.

Hoje eu não imagino alguém de TI sendo contratado pelo conhecimento que adquiriu em um mestrado/doutorado.

Se isso existir deve ser muito raro…

Olá

Isto é um problema. Mas há exceções.

O Vinicius Telles veio de mestrado. O José Valim ( http://blog.plataformatec.com.br/ ) deu uma palestra no DevInSampa justamente sobre a tese de mestrado dele (classificação de textos). Eu mesmo já vi gente acadẽmica sendo contratada a peso de ouro para fazer roteador de entrega de mercadorias (problema de caminho mínimo). E nossos amigos Paulo e Guilherme Silveira mantém um estreito contato com o meio acadẽmico. O professor Francisco Reverbel do IME/USP durante muito tempo foi o único brasileiro commiiter do JBoss. E a turma de estruturas de dados ex-alunos do prof Nivo Ziviani de BH que criaram o buscador Miner da Akwan, foram alguns dos primeiros brasileiros no Google quando este comprou a AKWAN. E há mais muitos outros exemplos por aí de várias partes do Brasil, inclusive alguns do nordeste (Campina Grande, Recife, etc.)

Na engenharia os acadẽmicos costumam ter importância maior. A Petrobrás usou e segue usando gente da COPPE, da PUC, da USP na pesquisa para chegar a liderança mundial na prospecção e produção de petróleo em águas profundas. No caso da futura exploração do pré sal isto se repetirá e com mais orgãos envolvidos.

Sempre recomendo aqui que insistam em fazer mestrado. É um sacrifício, mas vale a pena ter contato com gente inteligente e muiotas vezes de valor reconhecido internacionalmente. Meu mestrado fiz ainda solteiro em 1971/72 ganhando uma bolsa que nem de longe passa perto do que ganha um desenvolvedor pleno. Mas foi uma das melhores coisas que fiz na vida.

[]s
Luca

Luca:

Olá

Isto é um problema. Mas há exceções.

O Vinicius Telles veio de mestrado. O José Valim ( http://blog.plataformatec.com.br/ ) deu uma palestra no DevInSampa justamente sobre a tese de mestrado dele (classificação de textos). Eu mesmo já vi gente acadẽmica sendo contratada a peso de ouro para fazer roteador de entrega de mercadorias (problema de caminho mínimo). E nossos amigos Paulo e Guilherme Silveira mantém um estreito contato com o meio acadẽmico. O professor Francisco Reverbel do IME/USP durante muito tempo foi o único brasileiro commiiter do JBoss. E a turma de estruturas de dados ex-alunos do prof Nivo Ziviani de BH que criaram o buscador Miner da Akwan, foram alguns dos primeiros brasileiros no Google quando este comprou a AKWAN. E há mais muitos outros exemplos por aí de várias partes do Brasil, inclusive alguns do nordeste (Campina Grande, Recife, etc.)

Na engenharia os acadẽmicos costumam ter importância maior. A Petrobrás usou e segue usando gente da COPPE, da PUC, da USP na pesquisa para chegar a liderança mundial na prospecção e produção de petróleo em águas profundas. No caso da futura exploração do pré sal isto se repetirá e com mais orgãos envolvidos.

Sempre recomendo aqui que insistam em fazer mestrado. É um sacrifício, mas vale a pena ter contato com gente inteligente e muiotas vezes de valor reconhecido internacionalmente. Meu mestrado fiz ainda solteiro em 1971/72 ganhando uma bolsa que nem de longe passa perto do que ganha um desenvolvedor pleno. Mas foi uma das melhores coisas que fiz na vida.

[]s
Luca

Muito bom Luca!

Também recomendo o mestrado, apesar de assumir que, no geral, não seja tão valorizado na nossa área pelas empresas quanto poderia ser aqui. Mas pela experiência acadêmica vale muito a pena.

abracos

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a “arquitetura da aplicação” (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

Uma equipe de 6 profissionais, concordo com você. Agora quando passa dos 40, se o cara ficar programando não faz coaching por exemplo e no mercado, o valor hora de um arquiteto é maior, logo seria um disperdício de dinheiro se ele ficasse programando igual a um programador Sr. e realmente ele terá inúmeras atribuições, pode acreditar.

PS: Dá um pulo em empresas de grande porte como Claro ou Bovespa e espie o dia-a-dia de um arquiteto de lá, vai começar a entender que o buraco é mais embaixo.

PS2: As duas empresas citadas, conheço seus respectivos arquitetos e problemas que caem no colo deles, todo dia.Vai desde Match de operações em tempo real à projetos de Billing para milhões de transações por dia…Aí, não tem tempo mesmo pra fazer qualquer telinha que seja.

Então a equipe tem 40 pessoas (!) alocadas no projeto e pra vc desperdício está em 1 arquiteto ficar programando?

O fato de uma empresa ser de grande porte não justifica projetos com 20, 30, 40 pessoas. Nem mesmo o google tem esse monte de gente trabalhando no mesmo projeto. Se esse é o dia-a-dia das empresas citadas eles não servem como exemplo como desenvolvimento de software pra ninguém.

É verdade…

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a “arquitetura da aplicação” (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

Uma equipe de 6 profissionais, concordo com você. Agora quando passa dos 40, se o cara ficar programando não faz coaching por exemplo e no mercado, o valor hora de um arquiteto é maior, logo seria um disperdício de dinheiro se ele ficasse programando igual a um programador Sr. e realmente ele terá inúmeras atribuições, pode acreditar.

PS: Dá um pulo em empresas de grande porte como Claro ou Bovespa e espie o dia-a-dia de um arquiteto de lá, vai começar a entender que o buraco é mais embaixo.

PS2: As duas empresas citadas, conheço seus respectivos arquitetos e problemas que caem no colo deles, todo dia.Vai desde Match de operações em tempo real à projetos de Billing para milhões de transações por dia…Aí, não tem tempo mesmo pra fazer qualquer telinha que seja.

Então a equipe tem 40 pessoas (!) alocadas no projeto e pra vc desperdício está em 1 arquiteto ficar programando?

O fato de uma empresa ser de grande porte não justifica projetos com 20, 30, 40 pessoas. Nem mesmo o google tem esse monte de gente trabalhando no mesmo projeto. Se esse é o dia-a-dia das empresas citadas eles não servem como exemplo como desenvolvimento de software pra ninguém.

Normalmente são projetos Correlatos, vide Grupo Sem Parar, que na “nova plataforma” há mais ou menos esse número de pessoas envolvidas, e fui 1 dos arquitetos no primeiro ano.

Outra empresa era a YMF que tinha um software sendo produzido por uma equipe de 20 profissionais. Se justifica ou não, acho que é muito empírico julgar dessa maneira, sem conhecer os fatos.

PS: Bovespa a equipe de Match tem aproximadamente 20 pessoas também, detalhe, levam 8 meses só para preparar um profissional para depois desse período ele de fato começar a produzir, dado a complexidade técnica-negócio.

Só pra fechar, a equipe de desenvolvimento de jogos modernos como Gran Turismo 5 (PS3) está por volta de 150 pessoas. O time que trabalha no produto WebLogic está por volta disso e poderia ficar aqui citando muitos exemplos, que serveriam sim de exemplos e projetos bem sucedidos, mas acho que esse não é o ponto da discussão e sim o papel do arquiteto e creio que coloquei minha posição. Ninguém precisa aceitá-la, apenas é minha ótica e como encaro a função.

Não duvido que existam projetos com essa quantidade de gente alocada, mas é importante ressaltar que nestes casos, o que importa não é a qualidade dos seus programadores e arquitetos, mas sim da capacidade do gerente de bolar um processo capaz de tornar as pessoas em recursos humanos substituíveis. Todos sabem que, a não ser que vc utilize alguma inovação em termos de comunicação (telepatia?), um projeto com mais de 10 programadores provavelmente a dificuldade técnica do problema que eles resolvem é zero. São simplesmente code monkeys cumprindo checklists. Não existe maneira de um líder técnico, por mais competente que seja, dar conta de tanta gente para liderar/guiar, sem falar em ter que garimpar no mercado 10 (30, 40, 150!) profissionais realmente experts.

Dito isso, não entendo porque chamar um “arquiteto com perfil gerencial” de arquiteto ao invés de gerente junior e, CASO NECESSÁRIO, passe a bola da arquitetura para o programador Senior, mas não misture as funções.

Kenobi:

Só pra fechar, a equipe de desenvolvimento de jogos modernos como Gran Turismo 5 (PS3) está por volta de 150 pessoas. O time que trabalha no produto WebLogic está por volta disso e poderia ficar aqui citando muitos exemplos, que serveriam sim de exemplos e projetos bem sucedidos, mas acho que esse não é o ponto da discussão e sim o papel do arquiteto e creio que coloquei minha posição. Ninguém precisa aceitá-la, apenas é minha ótica e como encaro a função.

ps: Alguma referência/link para essas informações da equipe do GT5 e WebLogic?

mochuara:

Não duvido que existam projetos com essa quantidade de gente alocada, mas é importante ressaltar que nestes casos, o que importa não é a qualidade dos seus programadores e arquitetos, mas sim da capacidade do gerente de bolar um processo capaz de tornar as pessoas em recursos humanos substituíveis. Todos sabem que, a não ser que vc utilize alguma inovação em termos de comunicação (telepatia?), um projeto com mais de 10 programadores provavelmente a dificuldade técnica do problema que eles resolvem é zero. São simplesmente code monkeys cumprindo checklists. Não existe maneira de um líder técnico, por mais competente que seja, dar conta de tanta gente para liderar/guiar, sem falar em ter que garimpar no mercado 10 (30, 40, 150!) profissionais realmente experts.

Na verdade não estamos falando de um único profissional para a equipe toda e sim o papel do arquiteto. Talvez nesse caso explicitado seja mais de um ( o mais provável), cada qual cuidando de uma parte específica do problema, seu domínio.

Não vejo como um Gerente poderia conhecer sobre problemáticas técnicas, como latência, escabilidade, segurança e resolver essas questões para sua equipe.

ps: Alguma referência/link para essas informações da equipe do GT5 e WebLogic?

GTA: http://www.develop-online.net/news/29626/Polyphony-looks-to-PC-game-development#after_ad

Na verdade havia lido em outro site, até detalhava funções, como programdores especializados em física, outros em inteligência artificial, outros em iluminação e por aí vai …

WebLogic, havia ouvido dentro da BEA e com a compra da Oracle soube que aumentaram o quadro, pois dobraram o investimento no produto.

Como disse esse é meu ponto de vista, mas existem outros. Seria legal também ouvir o resto do pessoal do fórum para saber o que acham. Já percebi que temos pontos divergentes e essa discussão não tem condições de prosseguir, ou vai ficar repetitiva…

E qual a diferença entre um gerente e um arquiteto que não programa?

ai tem a pergunta: “Você já viu mestre de obra que antes não foi pedreiro ?”

É mais fácil para o mestre de obra garantir a qualidade do serviço prestado pelos pedreiros sem por a mão na massa. Com relação a software a coisa muda. Um arquiteto que não esta em contato diariamente com o código que esta sendo produzido não esta em condições de garantir a qualidade da arquitetura que ele definiu. Experiência técnica anterior não garante qualidade aqui.

Não.

Mas eu nunca vi um grande cozinheiro que tivesse deixado de cozinhar.

Vc não pode comparar um pedreiro com um programador, um cozinheiro sim…

mochuara:

Kenobi:

Não vejo como um Gerente poderia conhecer sobre problemáticas técnicas, como latência, escabilidade, segurança e resolver essas questões para sua equipe.

E qual a diferença entre um gerente e um arquiteto que não programa?

Eu nunca disse que um arquiteto não deve saber programar, pelo contrário, ele deve fazê-lo e bem !! Mas usando a analogia, seria como uma evolução - pedreiro - mestre de obras - arquiteto - engenheiro (embora arquiteto e engeheiro tenham papéis distintos sei disso, foi só para um exemplo).

Ele pode fazer “coching”, fundição de infraestrutura para a equipe ( como um framework), ensinar como se faz um grid de memória por exemplo com Hadoop - MapReduce para match de operações, Complex Events - EDA, quando e como utilizar e por aí vai. Só não vai ficar no dia-a-dia fazendo “telinha”, “regras de negócio”. Faz uma poc junto à equipe e deixa os caras tocarem o resto.

Ao menos minha idéia e pode olhar o repositório de temos em tempos pra ver como anda a qualidade do design, código, entre outros…

O carinha afundando em regras de negócio, fazendo telas por exemplo, não tem tempo de olhar nada, pois está preocupado em fazer a sua entrega e como disse, quando a equipe aumenta o arquiteto precisa ter um olhar mais de cima.

Pega um exemplo, uma arquitetura SOA por exemplo, deve-se utilizar SOAP + WSDL ou REST + Hypermedia ? Quem vai responder a este tipo de questão, com certeza não é o programador, pois dificilmente eles tem tempo pra se reciclar, estudar ou fazer pesquisas. Se a equipe tiver bons programadores, como citei anteriormente ótimo, dá pra criar um comitê que sou bastante favorável, senão, sobra mesmo pro coitado do arquiteto arcar com todas as decisões e pagar o seu devido preço. Aliás, alguns dizem que a diferença salarial está muito mais na responsabilidade do que no conhecimento técnico.

Kenobi:

Eu nunca disse que um arquiteto não deve saber programar, pelo contrário, ele deve fazê-lo e bem !! Mas usando a analogia, seria como uma evolução - pedreiro - mestre de obras - arquiteto - engenheiro (embora arquiteto e engeheiro tenham papéis distintos sei disso, foi só para um exemplo).

Voce esta confundindo consultor com arquiteto. Consultor não implementa as soluções, enquanto arquiteto que não programa é conhecido como “arquiteto astronauta” (só ve as coisas de longe).

Kenobi:

Ele pode fazer “coching”, fundição de infraestrutura para a equipe ( como um framework), ensinar como se faz um grid de memória por exemplo com Hadoop - MapReduce para match de operações, Complex Events - EDA, quando e como utilizar e por aí vai. Só não vai ficar no dia-a-dia fazendo “telinha”, “regras de negócio”. Faz uma poc junto à equipe e deixa os caras tocarem o resto.

Pra que se preocupar com regras de negócio e experiência do usuário quando pode ficar viajando na ultima tecnologia da “moda” ne?

Kenobi:

Quem vai responder a este tipo de questão, com certeza não é o programador, pois dificilmente eles tem tempo pra se reciclar, estudar ou fazer pesquisas.

:shock: Agora entendi qual o nível dos programadores que vc esta falando.

Kenobi:

Se a equipe tiver bons programadores, como citei anteriormente ótimo, dá pra criar um comitê que sou bastante favorável, senão, sobra mesmo pro coitado do arquiteto arcar com todas as decisões e pagar o seu devido preço.

Bons programadores não podem ter líderes que tomam as decisões de arquitetura (aka arquiteto)? Não entendi essa de comite.

Pode ser. Mas o que isso tem a ver? Estamos discutindo a melhor configuração para um projeto ou quem ganha mais?

E pela sua linha o gerente de projetos seria a evolução do arquiteto/engenheiro… rsrsrs

A Engenharia Civil não é parâmetro de comparação. Ela FOI parâmetro na Idade Média quando os “pedreiros” (maçons) arquitetavam e ao mesmo tempo construíam grandes projetos. A história mudou completamente devido ao alto grau de padronização que foi criado para atender às necessidades da Engenharia Civil. Padronização nos materiais, nas medidas, nos processos e nas ferramentas. Isso permitiu que o Arquiteto pudesse ter uma visão completa do projeto, antes mesmo de que o terreno fosse escolhido. Isso permitiu que o canteiro de obras fosse transformado numa grande linha de produção. Isso permitiu a separação das responsabilidades dos envolvidos no projeto.

Programação ainda é diferente. Programação ainda não é repetitivo. Programação ainda é arte. Vc como artista precisa evoluir. Portanto, precisa continuar praticando a arte e ensinando-a a outros.

Mais uma vez: compare um projeto de software com uma cozinha e não com um canteiro de obras.

mochuara:

Pior que tb é verdade…

Exato, não disse que o Arquiteto não vai programar, ele apenas vai “inventar” os pratos, criar o cardápio, pra isso ele deve saber cozinhar e bem não ? Pode fazer até um prato ou outro, mas não vai ficar cozinhando o dia todo…minha visão vide Alex Atala

Exato, não disse que o Arquiteto não vai programar, ele apenas vai “inventar” os pratos, criar o cardápio, pra isso ele deve saber cozinhar e bem não ? Pode fazer até um prato ou outro, mas não vai ficar cozinhando o dia todo…minha visão vide Alex Atala

Então vc quis dizer que o engenheiro civil também pega na pá e no martelo, certo? :roll:

Virou papo de boteco, parei por aqui … sem cerveja, não dá

Opá. Se quiser combinar, tamos aí.

Mas não me vai falar que programador = pedreiro e que projeto de software = canteiro de obra. Eu só aceito isso depois de tomar umas caixas.

Opá. Se quiser combinar, tamos aí.

Mas não me vai falar que programador = pedreiro e que projeto de software = canteiro de obra. Eu só aceito isso depois de tomar umas caixas.
A coisa que acho mais estúpida é querer comparar banana com limão. Mas vamos lá:
Existem diversos tipos de profissões e algumas sim, necessitam de experiência prévia antes de sair fazendo. Por exemplo, piloto de avião. Aprende a pilotar um “teco-teco” e vai pegar um jumbo pra ver se vc consegue. Pra mim, se o cara chega a arquiteto sem ter “machucado” os dedos programando, é como pegar um jumbo sem antes ter aprendido a pilotar aviões menores. Vai com certeza ter problemas (se não é na subida, é na descida - piadinha podre :lol: ). Se comparar com medicina, a mesma coisa, ninguém se torna cirurgião chefe antes de ter passado por vários estágios e muitos, mas muitos anos de experiência de atendimentos de primeiros socorros até pequenas cirurgias (e ainda assim, erram).
Claro que vai vir um aqui e dizer: ótimo, são profissões de risco e ambas causariam desastres se não tivesse experiência. Concordo. Mas estou apenas mostrando que comparar um tipo ou outro de profissão não explica as barbáries que vejo.
Também concordo que cada profissão tem sua forma de avaliar um líder, um experiente e um qualquer que acha que é arquiteto.
Aqui neste fórum mesmo percebo que tem gente que busca um status de arquiteto mas que não tem muita noção do que fala se você começa a pressionar. Vivenciou poucos problemas, poucas situações (se é que vivenciou). Logo, falar é fácil, fazer é complicado e explicar a cagada é colocar a culpa no programador. Assim, até eu viro arquiteto, afinal, não precisa saber programar o que está sendo feito, não precisa sentar de vez em quando ao lado do desenvolvedor e lhe apontar erros de patterns e problemas que aquela forma de codificar podem causar ao longo do processo do software e da sua vida útil. Basta mandar fazer e se estiver errado, a culpa não é minha, não é verdade?

Opá. Se quiser combinar, tamos aí.

Mas não me vai falar que programador = pedreiro e que projeto de software = canteiro de obra. Eu só aceito isso depois de tomar umas caixas.
A coisa que acho mais estúpida é querer comparar banana com limão. Mas vamos lá:
Existem diversos tipos de profissões e algumas sim, necessitam de experiência prévia antes de sair fazendo. Por exemplo, piloto de avião. Aprende a pilotar um “teco-teco” e vai pegar um jumbo pra ver se vc consegue. Pra mim, se o cara chega a arquiteto sem ter “machucado” os dedos programando, é como pegar um jumbo sem antes ter aprendido a pilotar aviões menores. Vai com certeza ter problemas (se não é na subida, é na descida - piadinha podre :lol: ). Se comparar com medicina, a mesma coisa, ninguém se torna cirurgião chefe antes de ter passado por vários estágios e muitos, mas muitos anos de experiência de atendimentos de primeiros socorros até pequenas cirurgias (e ainda assim, erram).
Claro que vai vir um aqui e dizer: ótimo, são profissões de risco e ambas causariam desastres se não tivesse experiência. Concordo. Mas estou apenas mostrando que comparar um tipo ou outro de profissão não explica as barbáries que vejo.
Também concordo que cada profissão tem sua forma de avaliar um líder, um experiente e um qualquer que acha que é arquiteto.
Aqui neste fórum mesmo percebo que tem gente que busca um status de arquiteto mas que não tem muita noção do que fala se você começa a pressionar. Vivenciou poucos problemas, poucas situações (se é que vivenciou). Logo, falar é fácil, fazer é complicado e explicar a cagada é colocar a culpa no programador. Assim, até eu viro arquiteto, afinal, não precisa saber programar o que está sendo feito, não precisa sentar de vez em quando ao lado do desenvolvedor e lhe apontar erros de patterns e problemas que aquela forma de codificar podem causar ao longo do processo do software e da sua vida útil. Basta mandar fazer e se estiver errado, a culpa não é minha, não é verdade?

Sem falar que, independente do avião, as leis da fisica que permite algo levantar voos são sempre as mesmas. Da mesma forma o funcionamento de um rim ou coração é sempre o mesmo entre diferentes pessoas e até mesmo outras especies. O mesmo não pode ser dito de programadores de software que podem lidar com domínios completamente diferentes a cada novo projeto (e até inventar novos domínios!).

Esse é o problema de quem defende regulamentação da profissão, eles não entendem que o mundo da TI não se resume a aplicações web e ERPs.

Gostaria de dizer que não tenho nada contra o processo descrito pelo Kenobi, apenas discordo que um gerente deva ser chamado de arquiteto só porque foi programador alguma vez no passado.