Passos para Arquiteto?

quantos projetos de verdade você já atuou?

jjose:

Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.

Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring

Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)

Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).

Vc pode usar o método Constanza, que tem esse nome inspirado no personagem George Constanza, do seriado Seinfield. Ele não era arquiteto, mas vivia dizendo que era.

Então começe a assinar emails e post como arquiteto que quando vc ver, todo mundo vai penasr que vc é um. :lol: :lol:

victorwss:

jjose:

Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.

Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring

Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)

Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).

Um arquiteto se forma com teoria e prática. Vai precisar lidar com diversos protocolos, problemas de comunicação, técnicas de design de software e por aí vai. Um conselho é literatura, comece pelos principais arquitetos - Eric Evans como citado, Martin Fowler, Thomas Erl, Neal Ford, Andrew Hunt da série pragmática e por aí vai.

Precis estar com a mente aberta à novas metodologias e tecnologias como SOA ( BPM, BPA, BPEL, JBI JCA, ESBs, Repositories) , conceitos de transacionalidade, cluster e loadbalance, grid e por aí vai.

Um arquiteto se forma ao longo do tempo, então não tenha pressa e saiba que esse caminho leva aproximadamente uns 10 anos pra chegar lá ou mais :-).

para ser um arquiteto de titulo nao há segredos! Faça as certificacoes da sun, ate a de arquiteto e pronto! (antes leia como ela cobra e o quanto tera q estudar)

Lembrando que na certificacao da sun de arquiteto ela cobra um poquinho de cada area. movel, j2ee, j2se, padroes de projeto etc…

agora lembre-se o mercado nao quer o arquiteto apenas com titulo… a experiencia é fundamental(isso ja é cobrado desde programador junior qto mas para arquiteto) e apenas uma pequena experiencia e sim uma boa experiencia em um projeto solido.
E um arquiteto é so tecnico, há outras qualidades que se adquire com tempo, com relacionamento etc. Assim lembrando que ter ingles fluente(nao somente na leitura/escrita) eh um ponto forte no arquiteto.Não vejo vaga de arquiteto sem pedir ingles fluente, ate pq a maioria dos projetos envolve ir para fora do BR, mas nao so por isso nao. E outro detalhe na vaga solicita no minimo ai 5 para cima como experiencia e informar sua participação no projeto.

flw! espero ter ajudado

Kenobi:

victorwss:

jjose:

Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.

Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring

Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)

Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).

Um arquiteto se forma com teoria e prática. Vai precisar lidar com diversos protocolos, problemas de comunicação, técnicas de design de software e por aí vai. Um conselho é literatura, comece pelos principais arquitetos - Eric Evans como citado, Martin Fowler, Thomas Erl, Neal Ford, Andrew Hunt da série pragmática e por aí vai.

Precis estar com a mente aberta à novas metodologias e tecnologias como SOA ( BPM, BPA, BPEL, JBI JCA, ESBs, Repositories) , conceitos de transacionalidade, cluster e loadbalance, grid e por aí vai.

Um arquiteto se forma ao longo do tempo, então não tenha pressa e saiba que esse caminho leva aproximadamente uns 10 anos pra chegar lá ou mais :-).

concordo com o kenobi e discordo do victorws no seguinte: framewok é coisa de desenvolvedor, tal como DDD e TDD já que “Developement” e “Design” são responsabilidades do desenvolvedor. Concordo com a diferença teoria-pratica. Arquiteto tem que entender de tecnologias genércias e requisitos não-funcionais como o kenobi mencionou. Não sei como vc vai ter estomago para isso tudo sem ser um bom desenvolvedor primeiro.

Se vc quer apenas tirar a certificação Sun de arquiteto isso são outros 500. Isso lhe dá uma certificação de arquiteto “junior” , é a experiencia em projetos reais que o torna um arquiteto realmente.

sergiotaborda:

Kenobi:

victorwss:

jjose:

Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.

Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring

Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)

Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).

Um arquiteto se forma com teoria e prática. Vai precisar lidar com diversos protocolos, problemas de comunicação, técnicas de design de software e por aí vai. Um conselho é literatura, comece pelos principais arquitetos - Eric Evans como citado, Martin Fowler, Thomas Erl, Neal Ford, Andrew Hunt da série pragmática e por aí vai.

Precis estar com a mente aberta à novas metodologias e tecnologias como SOA ( BPM, BPA, BPEL, JBI JCA, ESBs, Repositories) , conceitos de transacionalidade, cluster e loadbalance, grid e por aí vai.

Um arquiteto se forma ao longo do tempo, então não tenha pressa e saiba que esse caminho leva aproximadamente uns 10 anos pra chegar lá ou mais :-).

concordo com o kenobi e discordo do victorws no seguinte: framewok é coisa de desenvolvedor, tal como DDD e TDD já que “Developement” e “Design” são responsabilidades do desenvolvedor. Concordo com a diferença teoria-pratica. Arquiteto tem que entender de tecnologias genércias e requisitos não-funcionais como o kenobi mencionou. Não sei como vc vai ter estomago para isso tudo sem ser um bom desenvolvedor primeiro.

Se vc quer apenas tirar a certificação Sun de arquiteto isso são outros 500. Isso lhe dá uma certificação de arquiteto “junior” , é a experiencia em projetos reais que o torna um arquiteto realmente.

A questão dos frameworks da moda eu coloquei em segundo plano exatamente porque não é de fundamental importância. Porém, o arquiteto tem que conhecê-los para saber do que são e do que não são capazes, quais as limitações e quais as alternativas.
TDD é importante, pois sistemas que tem arquitetura para as quais é difícil escrever-se testes são comuns, e é necessário conhecer-se a TDD para entender o porque (eu mesmo estou apenas nos primeiros contatos com ela, mas conheço a sua importância).
E quanto a DDD, discordo de você, acho que design é mais responsabilidade do arquiteto do que do desenvolvedor (se os dois não forem a mesma pessoa).

Uma coisa tem que ser dita:

Arquiteto de Software tem que conhecer Hardware também!

Essa é a definição de Arquiteto de Software: Arquiteto é programador, analista, desenvolvedor e ainda analisa o hardware necessário para funcionar a aplicação!

(pelo menos isso foi o que disse meu professor que programava em 1970 e foi evoluindo junto com as linguagens…+ de 30 anos de experiencia como programador!)

segundo este autor, você tem que saber estas 97 coisas. link

claudneto:

Uma coisa tem que ser dita:

Arquiteto de Software tem que conhecer Hardware também!

Essa é a definição de Arquiteto de Software: Arquiteto é programador, analista, desenvolvedor e ainda analisa o hardware necessário para funcionar a aplicação!

(pelo menos isso foi o que disse meu professor que programava em 1970 e foi evoluindo junto com as linguagens…+ de 30 anos de experiencia como programador!)

Precisa ter uma boa visão de Hardware e OS, como fazer para olhar vazamento de memória - Solaris DTrace, Applications Servers também, pois há muita configuração que pode detonar sua aplicação.

victorwss:

sergiotaborda:

concordo com o kenobi e discordo do victorws no seguinte: framewok é coisa de desenvolvedor, tal como DDD e TDD já que “Developement” e “Design” são responsabilidades do desenvolvedor. Concordo com a diferença teoria-pratica. Arquiteto tem que entender de tecnologias genércias e requisitos não-funcionais como o kenobi mencionou. Não sei como vc vai ter estomago para isso tudo sem ser um bom desenvolvedor primeiro.

A questão dos frameworks da moda eu coloquei em segundo plano exatamente porque não é de fundamental importância. Porém, o arquiteto tem que conhecê-los para saber do que são e do que não são capazes, quais as limitações e quais as alternativas.
TDD é importante, pois sistemas que tem arquitetura para as quais é difícil escrever-se testes são comuns, e é necessário conhecer-se a TDD para entender o porque (eu mesmo estou apenas nos primeiros contatos com ela, mas conheço a sua importância).
E quanto a DDD, discordo de você, acho que design é mais responsabilidade do arquiteto do que do desenvolvedor (se os dois não forem a mesma pessoa).

Vc está usando a palavra “arquitetura” como sinônimo de " estrutura de classes, bibliotecas e contratos: fornecer features" enquanto eu estou usando a palavra com significado de “escolha de tecnologias, divisão da solução em sistemas , divisão dos sistemas em aplicações, escolha de protocolos de comunicação, escolha de servidores: fornecer estrutura”
A sua forma de ver “arquitetura” é muito baseada em requisitos funcionais , codigo e design. A minha é baseada em requisitos não-funcionais: disponibilidade, performance, distribuição, até SLA e licenciamentos…
Do seu ponto de vista eu concordo que TDD e DDD e frameworks etc… são importantes e fazem parte. O que eu não concordo é que chame a isso de “arquitetura” e à pessoa que faz isso “arquiteto” quando isso são responsabilidades do desenvolvedor.
Veja, se o que diz fosse responsabilidade do arquiteto, quem seria responsável pelas partes que eu explicitei ? O arquiteto tb ? ( nesse caso não haveria distinção entre desenvolvedor e arquiteto , já todo o mundo seria arquiteto).
O arquiteto raramente precisa saber sobre o negocio ( requisitos funcionais) ele precisa saber muito mais sobre as expectativas não funcionais. É o desenvolvedor que transforma requisitos funcionais em codigo. É ele que lida com as entidades, persistencia, valdiação, etc… ( por isso ele precisa de DDD, TDD, Design Patterns … )

Sérgio, interessante seu ponto em dizer que o arquiteto é responsável pelos requisitos não funcionais (concordo plenamente), porém ele não deveria também se preocupar com os requisitos funcionais? Não digo a parte de implementação (apesar que para mim, o arquivo deve estar envolvido com o código de alguma forma), mas no quesito de escolha de ferramentas, frameworks, metodologias e etc? Por exemplo, o arquito diz: Para esse projeto, vamos utilizar TDD, DDD, Pair Programing, EJB3. Para o Projeto Y, o Pair Programing não é necessário e vamos apenas utilizar Swing e Spring… Isso não seria o papel do arquiteto também?

Sérgio, interessante seu ponto em dizer que o arquiteto é responsável pelos requisitos não funcionais (concordo plenamente), porém ele não deveria também se preocupar com os requisitos funcionais? Não digo a parte de implementação (apesar que para mim, o arquivo deve estar envolvido com o código de alguma forma), mas no quesito de escolha de ferramentas, frameworks, metodologias e etc? Por exemplo, o arquito diz: Para esse projeto, vamos utilizar TDD, DDD, Pair Programing, EJB3. Para o Projeto Y, o Pair Programing não é necessário e vamos apenas utilizar Swing e Spring… Isso não seria o papel do arquiteto também?

Quanto a mim não. Ele tem poder de veto das ferramentas que o desenvolvedor escolher se isso afetar os requisitos não funcionais ( performance, tempo de resposta, escalabilidade , etc… ) mas ele não pode - tiranicamente - decidir. Ele pode falar algo assim "Não use hibernate porque ele não é clusterizável e precisamos usar clusters para suportar os milões de acessos simultaneoas que teremos " ( é um exemplo, nem sei se é) É mais nesse sentido. Pair Programins , TDD , DDD completamente fora da responsabilidade dele.
Ele não se importa se o programa é feito a um, dois, três ou se é mágicamente criado , desde que cumpra os requisitos está bom.
Testes ? Só se for de performance, carga, etc… testes unitários não importam nada para uma visão macro que por definição não é únitária. Domain Design ? Modele como quiser.
Eu não estou a dizer que não ha uma conversa entre o arquiteto e o desenvolvedor e cada uma dá um palpite e um pitaco no que outro fala, o que estou dizendo é que a responsabilidade de cada um é diferente.

EJB é diferente. EJB é uma tecnologia. Usar ou não EJB pode ferir ou ajudar algum dos requisitos. Por exemplo, se o sistema não tem trnsacionalidade distribuida pessada, EJB é inutil. A maioria dos sistemas não precisa disso. No caso de EJB não ser um requisito e estar no mesmo patamar que , digamos, Spring, é o desenvolvedor que tem responsabilidade de escolher, já que isso afetará o design do codigo e não o como o sistema se comporta face a carga etc… claro que o arquiteto pode dizer algo como " nos 20 projetos que trabalhei com Spring tivemos problemas de escalabilidade acima de X usuários e tivemos que acabar usando uma amaração com EJB depois. Acho que é melhor já pensar nisso agora." Mas não é ele que vai dicidir. Ele só vai dicidir se X for menor que Y sendo Y o requisito: “Não vamos usar Spring porque ele não escala até Y usuários”

Em resumo, o arquiteto pode forçar o uso ou não uso de alguma coisa baseado exclusivamente em critérios de estrutura ( performance, carga, protocolo, etc…) nunca face a equipe, metodologia de desenvolvimento ou gerencia. O desenvolvedor dicidir as bibliotecas que vai usar e como elas funcionam juntas. Ambos devem conversas e acertas os ponteiros, mas no fim são responsabilidades diferentes. Veja assim , o arquiteto está preocupado com o que usuário vai sentir ao usar a aplicação ( lentidão, visual tosco - ergonomia tb é coisa de arquiteto - indisponibilidade, erros de exactidão, etc…) o desenvlvedor se preocupa com o que le vai fazer ( cadastrar usuário, receber email, acionar um processo, etc… )

Esse texto realmente resume muito bem. Ficou muito claro para mim.

Embora eu nunca achei que o arquiteto deveria IMPOR quais frameworks, metodologias, ferramentas devem ser usadas ou não, eu acho que é importante ele trabalhar juntamente com os desenvolvedores para definir um ambiente apropriado para cumprir os requisitos do sistema. E como você mesmo disse, cada um tem responsabilidade diferente dentro do projeto. Apesar que eu acho que seria interessante um arquivo também estar envolvido com o código, envolvido diretamente com os desenvolvedores e etc.

Sérgio, interessante seu ponto em dizer que o arquiteto é responsável pelos requisitos não funcionais (concordo plenamente), porém ele não deveria também se preocupar com os requisitos funcionais? Não digo a parte de implementação (apesar que para mim, o arquivo deve estar envolvido com o código de alguma forma), mas no quesito de escolha de ferramentas, frameworks, metodologias e etc? Por exemplo, o arquito diz: Para esse projeto, vamos utilizar TDD, DDD, Pair Programing, EJB3. Para o Projeto Y, o Pair Programing não é necessário e vamos apenas utilizar Swing e Spring… Isso não seria o papel do arquiteto também?

Quanto a mim não. Ele tem poder de veto das ferramentas que o desenvolvedor escolher se isso afetar os requisitos não funcionais ( performance, tempo de resposta, escalabilidade , etc… ) mas ele não pode - tiranicamente - decidir. Ele pode falar algo assim "Não use hibernate porque ele não é clusterizável e precisamos usar clusters para suportar os milões de acessos simultaneoas que teremos " ( é um exemplo, nem sei se é) É mais nesse sentido. Pair Programins , TDD , DDD completamente fora da responsabilidade dele.
Ele não se importa se o programa é feito a um, dois, três ou se é mágicamente criado , desde que cumpra os requisitos está bom.
Testes ? Só se for de performance, carga, etc… testes unitários não importam nada para uma visão macro que por definição não é únitária. Domain Design ? Modele como quiser.
Eu não estou a dizer que não ha uma conversa entre o arquiteto e o desenvolvedor e cada uma dá um palpite e um pitaco no que outro fala, o que estou dizendo é que a responsabilidade de cada um é diferente.

EJB é diferente. EJB é uma tecnologia. Usar ou não EJB pode ferir ou ajudar algum dos requisitos. Por exemplo, se o sistema não tem trnsacionalidade distribuida pessada, EJB é inutil. A maioria dos sistemas não precisa disso. No caso de EJB não ser um requisito e estar no mesmo patamar que , digamos, Spring, é o desenvolvedor que tem responsabilidade de escolher, já que isso afetará o design do codigo e não o como o sistema se comporta face a carga etc… claro que o arquiteto pode dizer algo como " nos 20 projetos que trabalhei com Spring tivemos problemas de escalabilidade acima de X usuários e tivemos que acabar usando uma amaração com EJB depois. Acho que é melhor já pensar nisso agora." Mas não é ele que vai dicidir. Ele só vai dicidir se X for menor que Y sendo Y o requisito: “Não vamos usar Spring porque ele não escala até Y usuários”

Em resumo, o arquiteto pode forçar o uso ou não uso de alguma coisa baseado exclusivamente em critérios de estrutura ( performance, carga, protocolo, etc…) nunca face a equipe, metodologia de desenvolvimento ou gerencia. O desenvolvedor dicidir as bibliotecas que vai usar e como elas funcionam juntas. Ambos devem conversas e acertas os ponteiros, mas no fim são responsabilidades diferentes. Veja assim , o arquiteto está preocupado com o que usuário vai sentir ao usar a aplicação ( lentidão, visual tosco - ergonomia tb é coisa de arquiteto - indisponibilidade, erros de exactidão, etc…) o desenvlvedor se preocupa com o que le vai fazer ( cadastrar usuário, receber email, acionar um processo, etc… )

Eu não acho que seja só isso. O arquiteto tem que saber também como que o código funciona, quais são os problemas e porque que eles acontecm, tendo um conhecimento profundo do código inclusive. E não simples e puramente delegar isso ao desenvolvedor ou então fazer pouco caso. Ele tem que saber que “ah, o acesso da tela de relatórios gerenciais está lento porque o programa não usa uma estrutura de dados adequada, então vamos bolar uma forma melhor” e não simplesmente “ah, acesso da tela de relatórios gerenciais está lento, desenvolvedor arrume isso”. Arquiteto não é um cara que decide que tecnologias vão ser usadas, vê o que o cliente quer, delega para o desenvolvedor fazer e vê se o resultado está bom. O arquiteto tem que liderar o desenvolvimento, estar a par e a frente dele e garantir a qualidade do desenvolvimento que se reflete no código.

Esse texto realmente resume muito bem. Ficou muito claro para mim.

Embora eu nunca achei que o arquiteto deveria IMPOR quais frameworks, metodologias, ferramentas devem ser usadas ou não, eu acho que é importante ele trabalhar juntamente com os desenvolvedores para definir um ambiente apropriado para cumprir os requisitos do sistema. E como você mesmo disse, cada um tem responsabilidade diferente dentro do projeto. Apesar que eu acho que seria interessante um arquivo também estar envolvido com o código, envolvido diretamente com os desenvolvedores e etc.

Acho que vc quiz dizer que o arquiteto deve estar envolvido com o codigo.
Sim e não. Se ele fizer isso as decisões não serão imparciais no sentido que não serão apenas baseadas nos requisitos. Ele vai escolher o que é mais facil. Ou seja, irá corromper o sistema. Contudo, não vejo problema em a mesma pessoa ter papeis difentes em pontos diferentes do projeto. No inicio ele é arquiteto, no fim ele é programador. Aliás o que se procura é ter uma pessoa Desenvovledor Analista que possa incluir tanto os papeis de desenvolvedor, como de arquiteto como de analista. O único problema com isso é que é demasiada responsabilidade para uma pessoa só. Coisa que ninguém paga direito.

victorwss:

Eu não acho que seja só isso. O arquiteto tem que saber também como que o código funciona, quais são os problemas e porque que eles acontecm, tendo um conhecimento profundo do código inclusive. E não simples e puramente delegar isso ao desenvolvedor ou então fazer pouco caso. Ele tem que saber que “ah, o acesso da tela de relatórios gerenciais está lento porque o programa não usa uma estrutura de dados adequada, então vamos bolar uma forma melhor” e não simplesmente “ah, acesso da tela de relatórios gerenciais está lento, desenvolvedor arrume isso”. Arquiteto não é um cara que decide que tecnologias vão ser usadas, vê o que o cliente quer, delega para o desenvolvedor fazer e vê se o resultado está bom. O arquiteto tem que liderar o desenvolvimento, estar a par e a frente dele e garantir a qualidade do desenvolvimento que se reflete no código.

Se a tela está lenta agora, é porque o arquiteto falhou no inicio durante a discussão com o desenvovedor e deixou o desenvovedor usar uma idéia que não funcionava. Quem sabe os truques para fazer as coisas irem mais rápido é o desenvolvedor sim. É da responsabilidade dele que o codigo escrito esteja no nivel desejado.
O que eu quero dizer é que o arquiteto não fica feito urubu em cima do desenvovledor. O arquiteto define a arqutietura e os testes necessários para garantir os requisitos não-funcionais, por exemplo seta o JMeter para certos parametros.
O desenvolvedor ignorando esses parâmetros irá codificar para que o teste passe. É dessa forma que o arquiteto controla. Quem tem que correr atrás é o desenvolvedor. O código é responsabilidade dele.

O arquiteto não tem que liderar. Quem tem que liderar é o Lider. Pode ser a mesma pessoa que desempenhou o papel de arquiteto, ou não, não importa. O Lider tem responsabilidades diferentes do arquiteto e do desenvolvedor. Para começar, ele tem, por exemplo, que moralizar a equipe.

Lembremo-nos que as pessoas não são X ou Y , elas representam o papel de X ou Y conforme as circunstâncias.
Ou seja, o arquiteto o desenvolvedor, o lider, o gerente e o programador podem ser todos o mesmo cara. Isso é possivel, mas não é recomendado. As responsabilidades de cada papel às vezes são antagónicas e a menos que pessoas desenvolva multiplas personalidades, ela irá ter problemas consigo mesma. normalmente, para a pessoa se livrar desses problemas ela cede ao mais fácil e o sistema vira gambiarra. É por isso que a probabilidade de um sistema ser gambiarra é tanto maior quanto menos pessoas ha na equipe ( quanto menos os papeis estão distribuídos)

Algo interessante, por exemplo, é que o Arquiteto do projeto X seja o desenvolvedor do projeto Y e lider do Z. Desta forma as capacidades da pesssoa são todas a aproveitadas mas não ha conflito de interesses ( aka corrupção , aka gambiarra).

sergiotaborda:

Acho que vc quiz dizer que o arquiteto deve estar envolvido com o codigo.
Sim e não. Se ele fizer isso as decisões não serão imparciais no sentido que não serão apenas baseadas nos requisitos. Ele vai escolher o que é mais facil. Ou seja, irá corromper o sistema.

O que você disse é em geral uma visão bem interessante, mas isto daí que você citou é uma falácia. Se o cara escolher o mais fácil é porque ele é simplesmente preguiçoso e não está fazendo o trabalho dele corretamente. Dizer que se ele estiver envolvido no código vai corromper o sistema é um absurdo. Tentação para ir do jeito mais fácil e preguiçoso e enfiar gambiarra todo mundo tem, mas não é só porque ele vê o código que ele vai ceder a isso. Muito pelo contrário, o fato dele estar uma espécie de QA no código do desenvolvedor evita que ocorram gambiarras ou que o desenvolvedor tome decisões erradas na codificação.

Esse texto realmente resume muito bem. Ficou muito claro para mim.

Embora eu nunca achei que o arquiteto deveria IMPOR quais frameworks, metodologias, ferramentas devem ser usadas ou não, eu acho que é importante ele trabalhar juntamente com os desenvolvedores para definir um ambiente apropriado para cumprir os requisitos do sistema. E como você mesmo disse, cada um tem responsabilidade diferente dentro do projeto. Apesar que eu acho que seria interessante um arquivo também estar envolvido com o código, envolvido diretamente com os desenvolvedores e etc.

Tem um ditado que resume bem isso:

• o programador é o cara que se preocupa com o que acontece quando 1 pessoa clica num botão;
• o arquiteto é o cara que se preocupa com o que acontece quando 1000 pessoas clicam num botão;

victorwss:

sergiotaborda:

Acho que vc quiz dizer que o arquiteto deve estar envolvido com o codigo.
Sim e não. Se ele fizer isso as decisões não serão imparciais no sentido que não serão apenas baseadas nos requisitos. Ele vai escolher o que é mais facil. Ou seja, irá corromper o sistema.

O que você disse é em geral uma visão bem interessante, mas isto daí que você citou é uma falácia. Se o cara escolher o mais fácil é porque ele é simplesmente preguiçoso e não está fazendo o trabalho dele corretamente. Dizer que se ele estiver envolvido no código vai corromper o sistema é um absurdo. Tentação para ir do jeito mais fácil e preguiçoso e enfiar gambiarra todo mundo tem, mas não é só porque ele vê o código que ele vai ceder a isso. Muito pelo contrário, o fato dele estar uma espécie de QA no código do desenvolvedor evita que ocorram gambiarras ou que o desenvolvedor tome decisões erradas na codificação.

Veja, se o cara não mexe no código que ele definiu ele não tem como cair em tentação. O ponto está em poder ou não cair e não se cai realmente. Por outro lado, na hora que ele é programador ele não é arquiteto. Se ele é QA não é programador.
Como arquiteto é provavelmente um não-programador é possivel que ele faça mais gambiarras que o verdadeiro programador porque ele não está habituado. Ou seja, ele vai trabalhar contra o que ele mesmo especificou. Tlv vc parta do principio que o arquiteto sabe programar na linguagem usada. Eu não parto desse principio porque a linguagem não é um fator na hora de escolher a arquitetura ( a plataforma sim, a linguagem não)

Eu entendo a sua idéia de “policiamento” que o arquiteto deveria manter do código, mas não concordo. Isso é o papel do desenvolvedor. Se o desenvovedor for ruim, o sistema não passa no teste definido pelo arquiteto , é tão simples assim. Se passa no teste não importa como ele passa. Ou seja, não importa funciona, desde que funcione.

O papel de verificar se por exemplo o checkstyle ou PMD está sendo respeitado , se os padrões estão bem implementados , etc… é do desenvolvedor ( na realidade é de todos os programadores, mas quem puxa a orelha é o desenvovledor)

sergiotaborda:

victorwss:

sergiotaborda:

Acho que vc quiz dizer que o arquiteto deve estar envolvido com o codigo.
Sim e não. Se ele fizer isso as decisões não serão imparciais no sentido que não serão apenas baseadas nos requisitos. Ele vai escolher o que é mais facil. Ou seja, irá corromper o sistema.

O que você disse é em geral uma visão bem interessante, mas isto daí que você citou é uma falácia. Se o cara escolher o mais fácil é porque ele é simplesmente preguiçoso e não está fazendo o trabalho dele corretamente. Dizer que se ele estiver envolvido no código vai corromper o sistema é um absurdo. Tentação para ir do jeito mais fácil e preguiçoso e enfiar gambiarra todo mundo tem, mas não é só porque ele vê o código que ele vai ceder a isso. Muito pelo contrário, o fato dele estar uma espécie de QA no código do desenvolvedor evita que ocorram gambiarras ou que o desenvolvedor tome decisões erradas na codificação.

Veja, se o cara não mexe no código que ele definiu ele não tem como cair em tentação. O ponto está em poder ou não cair e não se cai realmente. Por outro lado, na hora que ele é programador ele não é arquiteto. Se ele é QA não é programador.
Como arquiteto é provavelmente um não-programador é possivel que ele faça mais gambiarras que o verdadeiro programador porque ele não está habituado. Ou seja, ele vai trabalhar contra o que ele mesmo especificou. Tlv vc parta do principio que o arquiteto sabe programar na linguagem usada. Eu não parto desse principio porque a linguagem não é um fator na hora de escolher a arquitetura ( a plataforma sim, a linguagem não)

Eu entendo a sua idéia de “policiamento” que o arquiteto deveria manter do código, mas não concordo. Isso é o papel do desenvolvedor. Se o desenvovedor for ruim, o sistema não passa no teste definido pelo arquiteto , é tão simples assim. Se passa no teste não importa como ele passa. Ou seja, não importa funciona, desde que funcione.

O papel de verificar se por exemplo o checkstyle ou PMD está sendo respeitado , se os padrões estão bem implementados , etc… é do desenvolvedor ( na realidade é de todos os programadores, mas quem puxa a orelha é o desenvovledor)

Bem, temos duas visões diferentes do que um arquiteto vem a ser:

1. Você acha que ele não necessita saber programar na linguagem especificada.
2. Eu acho que ele deve saber programar melhor do que ninguém na linguagem especificada.

Em todos os outros aspectos, acho que concordamos com o papel do arquiteto, a divergência está neste ponto.
Se bem que não existe nenhum lugar onde haja uma definição formal e bem rígida sobre o que ele é. Então, acredito que poderíamos ficar discutindo isso eternamente ad infinitum. O fato é: não existe apenas um única tipo de arquiteto que faz um conjunto X de coisas e acabou. Você está falando na variante de arquiteto A e eu na variante B. Outras variantes devem existir por aí também que fazem alguma coisa a mais ou alguma coisa a menos.
É isso.

victorwss:

Bem, temos duas visões diferentes do que um arquiteto vem a ser:

1. Você acha que ele não necessita saber programar na linguagem especificada.
2. Eu acho que ele deve saber programar melhor do que ninguém na linguagem especificada.

Em todos os outros aspectos, acho que concordamos com o papel do arquiteto, a divergência está neste ponto.
Se bem que não existe nenhum lugar onde haja uma definição formal e bem rígida sobre o que ele é. Então, acredito que poderíamos ficar discutindo isso eternamente ad infinitum. O fato é: não existe apenas um única tipo de arquiteto que faz um conjunto X de coisas e acabou. Você está falando na variante de arquiteto A e eu na variante B. Outras variantes devem existir por aí também que fazem alguma coisa a mais ou alguma coisa a menos.
É isso.

Só vi a sua mensagem hoje…

Realmente é essa a diferença entre as opiniões.
Agora tome nota do seguinte : Um arquiteto tem que escolher tecnologias que cumpram os requisitos não-funcionais do sistema.
Estas tecnologias podem ser muito diferentes do que vc e eu estamos habituados. Ele pode ter que recorrer a produtos especificos para a area em que o sistema atuará. Acho que vc concorda com isto. A
gora imagine que a sua regra é válida e o arquiteto tem que saber muito bem programar na plataforma escolhida. Bom, então isso significa que: ele só pode escolher tecnologias que domina completamente.
Obviamente isso é contrário ao objetivo principal do arquiteto.

O arquiteto não coloca a mão na massa. Baseado nos requisitos levantados pelo analista o arquiteto procura e escolhe a tecnologia que melhor se adequa ao sistema. Por exemplo, mesmo sem ter programado nunca em ruby eu nunca escolheria rubi para sistema de alta performance devido a relatos de que ele não escala bem. Mas para um protótipo seria aceitável. O mesmo para Groovy, por exemplo. Eu não escolheria uma interface web para um sistema com alta demanda de inserção de dados e sim algo como swing já que o ambiente web é inseguro por construção e nem sempre javascript e css ( e portanto ajax) estão disponíveis. E mesmo quando estão nem sempre ajudam muito. Por exemplo, teclas de atalha em javascript é um ó! Eu nunca escolheria Clipper, VB 6 , Delphi ou PHP para um projeto no panorama atual. E isso eu faço sem saber programar nessas plataforma. (Claro que existem exceções - se sua equipa so programa em clipper , fazer o quê ? despedi-los a todos ?)
Eu não preciso saber programar muito bem em javascritp , ruby, groovy, php, delphi , etc… para fazer estas escolhas.
Se eu precisar de um produto de streaming de audio eu não preciso conhecer , dominar e ter escrito o código do produto para o poder usar. Basta que existam algumas garantias como documentação farta, comunidade sociável e uso por outros partes ( peer review).

Arquitetura está um nivel acima de código assim como analise está acima de tecnologia. Tlv seja difícil para um desenvolvedor ou programador aceitar que ele não tem capacidade/poder para decidir certas coisas e que é necessário alguem com uma visão mais geral. Atualmente é raro se verem arquitetos verdadeiros inclusos nos projetos. O que vemos são Desenvolvedores Analistas que fazem suas escolhas muito rapidamente em base das tecnologias que conhecem. E junto com isso vemos programas que não escalam, que têm manutenção complexa, etc…

tudo bem que não ha uma carta magna definindo o que é um arquiteto de software, mas se vale alguma coisa, dê uma olhada nos objetivos para as certificações de desenvovledor e de arquiteto da sun. embora o arquiteto sun seja um tipo especifico de arquiteto muito ligado à plataforma java, dá para ver que não existem objetivos relacionados à linguagem em lugar algum.

Finalmente: Se o arquiteto sabe programar bem na linguagem causa, ótimo. Não digo que isso seja impeditivo para se ser arquiteto.
O que digo é que é impossível vc conhecer todas as plataformas com esse grau de conhecimento para fazer as suas escolhas.
Se fosse fácil ser arquiteto, todo o mundo seria.

Estou errado ao afirmar que,na “vida real”,a tecnologia que mais se adequa ao sistema é a que a equipe do projeto domina?Com budgets e prazos cada vez mais apertados,como um arquiteto pode impor uma linguagem nova para os membros da equipe e colher resultados satisfatórios,sem tempo para treinamento e maturação de pessoal?

raf4ever:

Estou errado ao afirmar que,na “vida real”,a tecnologia que mais se adequa ao sistema é a que a equipe do projeto domina?

Sim.

Com budgets e prazos cada vez mais apertados,como um arquiteto pode impor uma linguagem nova para os membros da equipe e colher resultados satisfatórios,sem tempo para treinamento e maturação de pessoal?

Você está falando em exceções. O fato da equipe disponível não saber programar a estrutura escolhida pelo arquiteto significa que essa equipa não pode programar aquele sistema e não que o arquiteto tem que olhar a equipe e escolher outras tecnologias.
O papel do arquiteto é agradar ao usuário final, não ao cliente nem aos programadores.

Agora, podem existir constangimentos conforme o contexto eas circunstancias a que o arquiteto está sujeito.
Nesse caso o arquiteto será instruído a criar “a melhor arquitetura para o sistema que seja compativel com a equipe”. Repare que isso é pedir muito. Muito mesmo.

Mas à medida que as plataformas padrão ( java, net, etc…) ganham dos seus concorrentes menos uniformizados e mais antigos é mais fácil que o arquiteto possa escolher livremente. contudo isso nem sempre é verdade. Imagine o arquiteto que tem que fazer uma integração com sistema de URA e o unico produto do mercado só permite interação com .NET (só um exemplo). Por muito que o arquiteto ou a equipe prefiram java, não ha nada a fazer.