Passos para Arquiteto?

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

quantos projetos de verdade você já atuou?

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

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.

victorwss wrote:

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

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

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

Kenobi wrote:

victorwss wrote:

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

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

Kenobi wrote:

victorwss wrote:

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

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

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

victorwss wrote:

sergiotaborda wrote:

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

sergiotaborda wrote:...

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?

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

ManchesteR wrote:

sergiotaborda wrote:...

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

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

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