Uma Pequena Provocação aos Arquitetos

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

rodrigoy wrote:

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

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3009 Offline

concordo em genero, numero e grau!!!

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

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

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

rodrigoy wrote:

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

This message was edited 1 time. Last update was at 02/12/2009 10:28:35

andre_salvati wrote:

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

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

garcia-jj wrote:
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?

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

garcia-jj wrote:

andre_salvati wrote:

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

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

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

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

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

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

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

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.

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

ViniGodoy wrote:

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

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

garcia-jj wrote:

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

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.

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

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

This message was edited 1 time. Last update was at 03/12/2009 01:45:02

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

http://blog.aspercom.com.br/2007/09/20/opapeldoarquiteto/

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?

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