diferença entre projetista e arquiteto

Alguem poderia me explicar a diferença entre projetista e arquiteto ?? Eu entendo que o arquiteto é quem faz o projeto do software, não ??

Ate onde eu sei arquiteto eh quem define frameworks, estrutura, divisao de componentes do sistema, essas coisas mais alto nivel.

Projetista pega um caso de uso, le e escreve um projeto (diagrama UML por exemplo) explicando como deve ser codificado.

Algo assim.

[quote=microfilo]Ate onde eu sei arquiteto eh quem define frameworks, estrutura, divisao de componentes do sistema, essas coisas mais alto nivel.

Projetista pega um caso de uso, le e escreve um projeto (diagrama UML por exemplo) explicando como deve ser codificado.

Algo assim.[/quote]

Nao é por ae não… Arquiteto não é só isso não, é MUITO mais alem… Definir frameworks é só detalhe. Bom arquiteto se preocupa sim dim divisão de componentes, suas interfaces, etc… o que vale dizer é que arquiteto se preocupa principalmente com coisas importantes no sistema… Enfim… há muito que o arquiteto deve fazer, existem muitos artigos da IBM, etc que explica isso de forma mais correta (to com preguiça de ser mais detalhista), enfim…

Mas NUNCA confunda desenvolvedor senior com arquiteto… existem muitos desenvolvedores seniors aqui que se considera arquiteto, principalmente no que se trata de tecnologia… Tem uma cambada de baba ovo de Spring aqui que mostra como qualquer idiota pode pegar um cracha e escrever arquiteto nele… Arquitetura é principalmente tomada de decisão, e não ‘Eu sei Spring, babo ovo de Spring, e qualquer idiota que nao gosta é imbecil que nao sabe o que é AOP, IoC, etc bem feito e bla bla’ … Some desse tipo de arquiteto, ele nao é arquiteto, é um idota como varios em nossa profissao que nem sabe o que faz… Desenvolvedores não adoram falar mal de gerente de projeto que nao sabe o que é projeto de tecnologia? Entao esse gerentes sao idiotas e todo muito sabe… Da mesma forma existem arquitetos que nem sabe o que é ser um arquiteto, o problema é que ainda ninguem falou isso pra ele.

bom, tá aqui um doa artigos que estou falando:

http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/apr01/CommonMisconceptionsaboutSoftwareArchitectureApr01.pdf

[quote=Hal Jordan][quote=microfilo]Ate onde eu sei arquiteto eh quem define frameworks, estrutura, divisao de componentes do sistema, essas coisas mais alto nivel.

Projetista pega um caso de uso, le e escreve um projeto (diagrama UML por exemplo) explicando como deve ser codificado.

Algo assim.[/quote]

Nao é por ae não… Arquiteto não é só isso não, é MUITO mais alem… Definir frameworks é só detalhe. Bom arquiteto se preocupa sim dim divisão de componentes, suas interfaces, etc… o que vale dizer é que arquiteto se preocupa principalmente com coisas importantes no sistema… Enfim… há muito que o arquiteto deve fazer, existem muitos artigos da IBM, etc que explica isso de forma mais correta (to com preguiça de ser mais detalhista), enfim…
[/quote]

O que seriam essas “coisas importantes do sistema”?

[quote=Hal Jordan]
Mas NUNCA confunda desenvolvedor senior com arquiteto… existem muitos desenvolvedores seniors aqui que se considera arquiteto, principalmente no que se trata de tecnologia… Tem uma cambada de baba ovo de Spring aqui que mostra como qualquer idiota pode pegar um cracha e escrever arquiteto nele… Arquitetura é principalmente tomada de decisão, e não ‘Eu sei Spring, babo ovo de Spring, e qualquer idiota que nao gosta é imbecil que nao sabe o que é AOP, IoC, etc bem feito e bla bla’ … Some desse tipo de arquiteto, ele nao é arquiteto, é um idota como varios em nossa profissao que nem sabe o que faz… Desenvolvedores não adoram falar mal de gerente de projeto que nao sabe o que é projeto de tecnologia? Entao esse gerentes sao idiotas e todo muito sabe… Da mesma forma existem arquitetos que nem sabe o que é ser um arquiteto, o problema é que ainda ninguem falou isso pra ele.[/quote]

Quanta mágoa no coração!

Agora sério, se arquitetura é tomada de decisão, acredito que isto pode ser feito até pelo programador júnior, se ele tiver embasamento o bastante para isso e o resto da equipe for inteligente o bastante para dar ouvidos a ele neste caso. Então, qual a necessidade de se diferenciar tanto desenvolvedor de arquiteto afinal?

[quote=Hal Jordan]
Nao é por ae não… Arquiteto não é só isso não, é MUITO mais alem… Definir frameworks é só detalhe. Bom arquiteto se preocupa sim dim divisão de componentes, suas interfaces, etc… o que vale dizer é que arquiteto se preocupa principalmente com coisas importantes no sistema… Enfim… há muito que o arquiteto deve fazer, existem muitos artigos da IBM, etc que explica isso de forma mais correta (to com preguiça de ser mais detalhista), enfim…[/quote]

Resumindo:

Em um ambiente onde as coisas são “jogadas por cima do muro” (coisa execrada em RUP, XP, Scrum e qualquer outra emtodologia séria) geralmente se chama de arquiteto o cara que toma macro-decisões sobre o projeto e de projetista o sujeito que tenta programar em UML.

Programadro é oc ara que pega toda a fanstasia e tenta criar a única coisa que importa: software.

‘Projetista’ é um papel que os gurus da ciência da computação já aboliram há décadas mas algumas empresas insistem em tentar mantêr. Fazia sentido quando você tinha uma śerie de transformações entre o modelo lógico e o físico mas hoje com um mapeamento quase 1-para-1 não faz qualquer sentido.

[quote=Leozin][quote=Hal Jordan]
Nao é por ae não… Arquiteto não é só isso não, é MUITO mais alem… Definir frameworks é só detalhe. Bom arquiteto se preocupa sim dim divisão de componentes, suas interfaces, etc… o que vale dizer é que arquiteto se preocupa principalmente com coisas importantes no sistema… Enfim… há muito que o arquiteto deve fazer, existem muitos artigos da IBM, etc que explica isso de forma mais correta (to com preguiça de ser mais detalhista), enfim…[/quote]

Resumindo:

hummm, não… Arquiteto ajuda a encontrar risco de projeto, procura principalmente necessidades não funcionais, promove conhecimento aos desenvolvedores, verifica se o plano de arquitetura/metricas/praticas esta sendo seguido pelos desenvolvedores, ajuda na formação da equipe (verificando qualificacao necessaria), ajudar a avaliar o planejamento do projeto (dando informações tecnicas ao gerente de projeto), enfim…

bom, mais 2 artigos que ajudam entender o que ´arquitetura:

http://www-128.ibm.com/developerworks/rational/library/feb06/eeles/

http://www-128.ibm.com/developerworks/rational/library/mar06/eeles/index.html

Ps: Ignorem o que o s4nchez disse sobre que qualquer um é capaz de tomar decisão

[quote=Hal Jordan]
hummm, não… Arquiteto ajuda a encontrar risco de projeto, procura principalmente necessidades não funcionais, promove conhecimento aos desenvolvedores, verifica se o plano de arquitetura/metricas/praticas esta sendo seguido pelos desenvolvedores, ajuda na formação da equipe (verificando qualificacao necessaria), ajudar a avaliar o planejamento do projeto (dando informações tecnicas ao gerente de projeto), enfim…

Ps: Ignorem o que o s4nchez disse sobre que qualquer um é capaz de tomar decisão[/quote]

Seria mais fácil você responder meus questionamentos, não?

Apropósito, você citou tarefas que podem muito bem ser executadas por qualquer desenvolvedor (ajudar na formação da equipe, encontrar risco de projeto, dar feedback técnico aos gerentes). Se a empresa precisa de uma pessoa específica para este fim e dá o nome de arquiteto tudo bem, mas ainda não entendi qual a necessidade de se diferenciar tanto este papel do resto da equipe (e por isso respondi em primeiro lugar)

[quote=Hal Jordan]Ps: Ignorem o que o s4nchez disse sobre que qualquer um é capaz de tomar decisão[/quote]Gente, vamos conversar sem brigas, OK? Não há necessidade nenhuma de bate-boca.

Eu concordo com a descrição que o Jordan deu sobre o “cargo” de Arquiteto. Mas também concordo com o Sanchez que não há nada que um Arquiteto faça que um Desenvolvedor experiente não possa fazer. Essa pode não ser a definição correta de Arquiteto, mas é o que eu vejo e vi nas empresas que passei.

A impressão que eu tenho é que o Arquiteto é o degrau acima do Desenvolvedor Sênior, e com a diferença de que o Arquiteto está muito mais focado na infraestrutura do sistema do que com a lógica de negócios que aquele sistema implementa.

Existe uma definição de Arquiteto?

[quote=s4nchez][quote=Hal Jordan]
hummm, não… Arquiteto ajuda a encontrar risco de projeto, procura principalmente necessidades não funcionais, promove conhecimento aos desenvolvedores, verifica se o plano de arquitetura/metricas/praticas esta sendo seguido pelos desenvolvedores, ajuda na formação da equipe (verificando qualificacao necessaria), ajudar a avaliar o planejamento do projeto (dando informações tecnicas ao gerente de projeto), enfim…

Ps: Ignorem o que o s4nchez disse sobre que qualquer um é capaz de tomar decisão[/quote]

Seria mais fácil você responder meus questionamentos, não?

Apropósito, você citou tarefas que podem muito bem ser executadas por qualquer desenvolvedor (ajudar na formação da equipe, encontrar risco de projeto, dar feedback técnico aos gerentes). Se a empresa precisa de uma pessoa específica para este fim e dá o nome de arquiteto tudo bem, mas ainda não entendi qual a necessidade de se diferenciar tanto este papel do resto da equipe (e por isso respondi em primeiro lugar)
[/quote]

Existe uma grande diferença entre papel e cargo… Vc pode possuir um cargo de desenvolvedor e executar o papel, as tarefas, ou como vc quiser chamar, de um arquiteto e de um desenvolvedor… e contrario tb…

E em relação de seus ‘questionamentos’, se isso pode-se chamar de questionamento, eu postei 3 links e se pesquisar possuem vários na internet…

Bom, coisas importantes no sistema que o PAPEL de arquiteto deve verificar é POR EXEMPLO, é a interação entre alguns componentes. O componente de venda precisa do componente de clientes e do componente de produtos… Pronto.

Perfeito… E que eu me lembre nunca disse que eram a mesma coisa. Minha dúvida é só no que se refere a necessidade deste rótulo de “Arquiteto”, uma vez que até onde eu vi ele não faz nada além do que os desenvolvedores mais experientes já fazem.

Se não quer responder basta ignorar. É mais fácil e fica menos feio do que desmerecer a pergunta.

[quote=Hal Jordan]
Bom, coisas importantes no sistema que o PAPEL de arquiteto deve verificar é POR EXEMPLO, é a interação entre alguns componentes. O componente de venda precisa do componente de clientes e do componente de produtos… Pronto.[/quote]
Mais uma vez, isso é coisa que o PAPEL de desenvolvedor já inclui :wink:

Questionamento geralmente ocorre quando vc ‘vai contra’ contra um ideia… Aquilo foi uma simples pergunta

[quote=s4nchez]
Mais uma vez, isso é coisa que o PAPEL de desenvolvedor já inclui ;)[/quote]

Hummm, não… uma das coisas que discutimos na pos de arquitetura é exatamente isso. Maioria NÃO consegue entender e NUNCA vai entender… Bom, go learn : http://www.sei.cmu.edu/architecture/arch_duties.html

PS: essa sua ultima frase foi um questionamento

[quote=Hal Jordan][quote=s4nchez]
Mais uma vez, isso é coisa que o PAPEL de desenvolvedor já inclui ;)[/quote]

Hummm, não… uma das coisas que discutimos na pos de arquitetura é exatamente isso. Maioria NÃO consegue entender e NUNCA vai entender… Bom, go learn : http://www.sei.cmu.edu/architecture/arch_duties.html

PS: essa sua ultima frase foi um questionamento[/quote]

Qual o curso de pós que você faz? Gostaria de ler a ementa do curso para entender do que se trata. No link que você me mandou há uma discussão sobre os deveres do Chief Software Architect, o que me parece ir mais além ainda do que o papel do Arquiteto, não?

Pra mim o difícil de entender não é o que é o Arquiteto, e sim o que justifica ter este papel destacado dentro da equipe, inclusive separando uma pessoa exclusiva para esta função.

[quote=s4nchez][quote=Hal Jordan][quote=s4nchez]
Mais uma vez, isso é coisa que o PAPEL de desenvolvedor já inclui ;)[/quote]

Hummm, não… uma das coisas que discutimos na pos de arquitetura é exatamente isso. Maioria NÃO consegue entender e NUNCA vai entender… Bom, go learn : http://www.sei.cmu.edu/architecture/arch_duties.html

PS: essa sua ultima frase foi um questionamento[/quote]

Qual o curso de pós que você faz? Gostaria de ler a ementa do curso para entender do que se trata. No link que você me mandou há uma discussão sobre os deveres do Chief Software Architect, o que me parece ir mais além ainda do que o papel do Arquiteto, não?

Pra mim o difícil de entender não é o que é o Arquiteto, e sim o que justifica ter este papel destacado dentro da equipe, inclusive separando uma pessoa exclusiva para esta função.
[/quote]

Por isso que eu disse que ser arquiteto é muito alem de escolher frameworks e é muito alem de ser desenvolvedor senior…

Bom, eu faço na puc, nao to achando a ementa do curso pq acho q eles tiraram da internet… bom, te falo q é muito bom, te dá um otima visão sobre arquitetura, algo que nunca tinha imaginado…

Ei, calma rapazes.

Para inicio de conversa, não existe definição oficial do que é arqutietura porque não existe orgão oficial. Honestamente: a bibliografia do SEI sobre arquitetura é horrivel. CBAN, por exemplo, é algo que merece ser catalogado de anti-pattern.

Seria esse o seu curso -> http://www.pucminas.br/cursos/dados_cursos.php?tipo=2&pai=52&pagina=5&ordem=alfa&curso=1196&PHPSESSID=502c16abb86b681901a52f31521d489e

[quote=pcalcado]Ei, calma rapazes.

Para inicio de conversa, não existe definição oficial do que é arqutietura porque não existe orgão oficial. Honestamente: a bibliografia do SEI sobre arquitetura é horrivel. CBAN, por exemplo, é algo que merece ser catalogado de anti-pattern.[/quote]

Ia comentar isso agora shoes… rs

Cara, na minha opinião, essas nomenclaturas são podres demais.

Uma leitura legal é a seguinte:

Code Complete:

Na fase de arquitetura definem-se:

Componentes arquiteturais típicos, organização do programa, as classes principais, design dos dados, regras de negócio, design de interface com o usuário, gerenciamento de recursos, segurança, performance, escalabilidade, interoperabilidade, internacionalização/localização, I/O, processamento de erros, tolerância à falhas, viabilidade do projeto, robustez, decisões “comprar pronto” vs. “desenvolver do zero”, decisões de reúso, estratégia de mudanças e qualidade geral.

E uma lista de tópicos que o arquiteto tem que pensar (em inglês, preguiça de traduzir):

[quote]
Here’s a list of issues that a good architecture should address. The list isn’t intended to be a comprehensive guide to architecture but to be a pragmatic way of evaluating the nutritional content of what you get at the programmer’s end of the software food chain. Use this checklist as a starting point for your own checklist. As with the requirements checklist, if you’re working on an informal project, you’ll find some items that you don’t even need to think about. If you’re working on a larger project, most of the items will be useful.

Specific Architectural Topics

Is the overall organization of the program clear, including a good architectural overview and justification?

Are major building blocks well defined, including their areas of responsibility and their interfaces to other building blocks?

Are all the functions listed in the requirements covered sensibly, by neither too many nor too few building blocks?

Are the most critical classes described and justified?

Is the data design described and justified?

Is the database organization and content specified?

Are all key business rules identified and their impact on the system described?

Is a strategy for the user interface design described?

Is the user interface modularized so that changes in it won’t affect the rest of the program?

Is a strategy for handling I/O described and justified?

Are resource-use estimates and a strategy for resource management described and justified for scarce resources like threads, database connections, handles, network bandwidth, and so on?

Are the architecture’s security requirements described?

Does the architecture set space and speed budgets for each class, subsystem, or functionality area?

Does the architecture describe how scalability will be achieved?

Does the architecture address interoperability?

Is a strategy for internationalization/localization described?

Is a coherent error-handling strategy provided?

Is the approach to fault tolerance defined (if any is needed)?

Has technical feasibility of all parts of the system been established?

Is an approach to overengineering specified?

Are necessary buy-vs.-build decisions included?

Does the architecture describe how reused code will be made to conform to other architectural objectives?

Is the architecture designed to accommodate likely changes?

General Architectural Quality

Does the architecture account for all the requirements?

Is any part overarchitected or underarchitected? Are expectations in this area set out explicitly?

Does the whole architecture hang together conceptually?

Is the top-level design independent of the machine and language that will be used to implement it?

Are the motivations for all major decisions provided?

Are you, as a programmer who will implement the system, comfortable with the architecture?[/quote]

Arquiteto é o cara responsável por pensar e responder, por si e pela equipe, sobre tudo isso.