Teve um tempo que usei o Together Architect. Era pesadão, mas bem interessante também. Um lance que achava legal nele, dependendo do propósito, claro, era que ele sinconizava o código com o diagrama e o diagrama com o código concomitantemente.
Me desculpe le-silva, mas você não entendeu direito o que o shoes quis dizer. Uma arquitetura mcdonalds é utilizada como pau para toda obra, uma arquitetura de referencia é utilizada para que os projetos de um mesmo negocio não precisem se preocupar com o básico e sim no que difere da arquitetura, alem de ser algo passivel de modificações e melhorias.
E você não deve seguir a risca a opinião de todos que você respeita, tente ser mais critico e utilize a opinião dos outros para formar a sua, incluindo a propria experiencia. Por exemplo, no artigo do shoes ele comenta que nunca viu um projeto com ejb 2.1 ser um sucesso, pois esta e a experiencia dele, respeito isso e acredito ser a maioria no mercado, porem conheço muitos projetos que funcionaram e foram um sucesso(porem não é por isso que vou recomendar :p).
A verdade é que os desenvolvedores adoram usar o ambiente dos clientes para testar novas tecnologias/conceitos/etc e isso normalmente acarreta em um manutenção problemática, do contrário de uma arquitetura de referencia, onde a maioria das tecnologias e conceitos são os mesmos.
[]'s
[quote=aleck]Me desculpe le-silva, mas você não entendeu direito o que o shoes quis dizer. Uma arquitetura mcdonalds é utilizada como pau para toda obra, uma arquitetura de referencia é utilizada para que os projetos de um mesmo negocio não precisem se preocupar com o básico e sim no que difere da arquitetura, alem de ser algo passivel de modificações e melhorias.
E você não deve seguir a risca a opinião de todos que você respeita, tente ser mais critico e utilize a opinião dos outros para formar a sua, incluindo a propria experiencia. Por exemplo, no artigo do shoes ele comenta que nunca viu um projeto com ejb 2.1 ser um sucesso, pois esta e a experiencia dele, respeito isso e acredito ser a maioria no mercado, porem conheço muitos projetos que funcionaram e foram um sucesso(porem não é por isso que vou recomendar :p).
A verdade é que os desenvolvedores adoram usar o ambiente dos clientes para testar novas tecnologias/conceitos/etc e isso normalmente acarreta em um manutenção problemática, do contrário de uma arquitetura de referencia, onde a maioria das tecnologias e conceitos são os mesmos.
[]'s
[/quote]
Aleck, eu respeito o Shoes, sim. Assim como respeito vários outros caras aqui nesse forum. O Paulo Silveira, o CV, o Luca, em fim… Mas isso não significa que eu “vá pela cabeça deles”. É tão dificil entender isso?
Eu tenho minhas experiências pessoais, sim, como você e outros aqui do forum. Se você quiser, pode visitar meu blog (http://codezone.wordpress.com/about), você vai ver que eu não entrei nesse negócio ontem. Já passei por muitas empresas e projetos. Conheço bem o mercado. Mas e daí, não preciso ficar jogando isso aqui na mesa. Esse não é o assunto deste post.
Eu só citei opiniões desses caras, porque estas também são as minhas opiniões, e eu não queria ter que escrever tudo de novo o que alguém já escreveu muito bem. Não há por que. Não quero chover no molhado.
Eu sei muito bem o que o Shoes definiu como arquitetura de referência, ou Mc Donals, como queira. Aliás, antes de eu ler este post dele, eu já sabia do que se tratava. Não aprendi o que é arquitetura de referência com o post dele, ou com a discução que rolou aqui no GUJ. Mais uma vez, eu só citei, porque não queria escrever tudo que alguém já disse. Só isso.
Agora, cara, leia os meus post inteiros. Olha o que eu já havia dito…
A impressão que dá é que você não está lendo o meu post completo. Ou não está querendo entender o que eu escrevi. Aliás, leia todos os meus posts. Eu parabenizei o Rodrigo quando entendi qual era o objetivo dele. Entendi porque perguntei e ele respondeu sem qualquer flamewar, respondeu na boa.
É isso…
Olá Galera…
Aproveitando esse tópico aqui sobre arquitetura, queria uma ajudinha.
Alguem ai tem um link ou tutorial sobre Arquitetura usando Swing?
Valeu a ajuda.
8)
Eu acho que ele entendeu sim, Alexandre. Como citei no artigo uma arquitetura de referência é algo muito complicado exatamente orque ma boa arqutietura deve levar em conta as peculiariedades do problema sendo resolvido. Não falo especificamente do autor do tópico mas se você vai montar uma mesma arquitetura que serve para todos os problemas “dentro do mesmo negócio” então ou você está criando um arquitetura que não é eficiente ou está resolvendo todas as vezes o mesmo problema, no mesmo cenário, e se está resolvendo o mesmo problema pra quê criar outro sistema em primeiro lugar?
Você está distorcendo o texto.
Ou seja: nenhum projeto com o framework criado por aquela empresa foi um suceso até agora.
Trancar as soluções da empresa segundo um molde específico não é a solução. A solução é ter pessoas que entendam os problemas e que saibam buscar alternativas. E é exatamente sobre isso que o texto fala.
Empresas como as de seguros que possuem vários ramos dentro do mesmo negócio se beneficiariam de um arquitetura de referencia pois normalmente cada ramo possui sua equipe, um sistema único se tornaria um projeto monstro e de dificil manutenção.
Se deixarmos os desenvolvedores livres para usar as tecnologias e conceitos que preferem tornaria a manutenção ainda mais complicado, pois estes não poderiam trocar experiências na maioria dos casos.
Realmente, minha interpretação foi outra, desculpas
[quote=pcalcado]
Trancar as soluções da empresa segundo um molde específico não é a solução. A solução é ter pessoas que entendam os problemas e que saibam buscar alternativas. E é exatamente sobre isso que o texto fala.[/quote]
Eu em momento nenhum disse que uma arquitetura de referência deve ser imutável. pois sempre tem algum projeto que sai da regra, nestes casos uma variação é sempre bem vinda, desde que não perca o foco principal da arquitetura.
Pelo que entendi em seu artigo, “arquiteturas mcdonalds”, são aquelas criadas para atender qualquer negocio ou um negocio especifico, também sou contra este pensamento, pois uma mesma empresa(de seguros por exemplo) pode ter a necessidade de uma arquitetura completamente diferente de outra. O que defendo é a criação de arquiteturas próprias para cada cliente, levando em conta suas necessidades e particularidades.
Eu já trabalehi em diversas empresas onde uma aplicação fazia coisas bem aprecidas que as outras e quase todas tinham arquitetura sde referência e todas destas atrapalhavam mais do que ajudavam.
O desenvolvedor deve sim ser livre para escolher a melhor solução para aquele caso. Se você não confia no desenvolvedor para tomar esta decisão o que ele está fazendo construindo sistemas para você em primeiro lugar? Não entendi a questão da troca de experiência. Não é porque eu não uso a mesma arqutietura que você que eu não uso pedaços semelhantes ou iguais ou que eu não posso aprender com a sua experiência.
E quem decide que a arquitetura não é aplicável? os arqutietos que a desenharam? Na minha experiência os arqutietos que desenham a arquitetura de referência sempre querem que esta seja usada, mesmo porque isso justifica e valoriza seu trabalho. Se os desenvolvedores pensarem para que eu preciso de arquietos na torre de mármore?
Arquiteturas McDonald’s são aquelas que são criadas com um objetivo que por si só já mata a qualidade esperada em uma boa arquitetura: para serem usadas em sistemas de uma empresa. Você vai criar um projeto novo e rpecisa seguir aquela estrutura e muitas vezes utilizar aqueles frameworks e ferramentas. Como uma boa arquitetura sempre depende do poblema e o problema quase sempre vai ser diferente (ou a tecnologia ai ser diferente) você tem uma arquitetura que simplesmente não é eficiente na maioria dos casos.
A obrigação do arqutieto é procurar a melhor solução para o problma, e isso envlve a melhor técnica, a melhor solução olítica, financeira, de maior valor agregado e o melhor para seu time. Não é uma tarefa fácil e assumir que pode-se tomar esta decisão uma só vez para um grupo de sistemas que ainda vão nascer é fugir da realidade.
[quote=pcalcado]
O desenvolvedor deve sim ser livre para escolher a melhor solução para aquele caso. Se você não confia no desenvolvedor para tomar esta decisão o que ele está fazendo construindo sistemas para você em primeiro lugar? [/quote]
Infelismente não posso controlar a qualidade dos desenvolvedores nas empresas que presto serviço.
[quote=pcalcado]
Não entendi a questão da troca de experiência. Não é porque eu não uso a mesma arqutietura que você que eu não uso pedaços semelhantes ou iguais ou que eu não posso aprender com a sua experiência.[/quote]
Acho que a resposta anterior se aplica aqui. Infelismente a qualidade dos desenvolvedores não é algo simples de se controlar em empresas grandes, onde profissionais são contratados de diversas maneiras e por areas distintas.
[quote=pcalcado]
E quem decide que a arquitetura não é aplicável? os arqutietos que a desenharam? Na minha experiência os arqutietos que desenham a arquitetura de referência sempre querem que esta seja usada, mesmo porque isso justifica e valoriza seu trabalho. Se os desenvolvedores pensarem para que eu preciso de arquietos na torre de mármore?[/quote]
A cada projeto iniciado os desenvolvedores e arquitetos conversam sobre o projeto e os desenvolvedores expoem seu ponto de vista, se realmente for algo que a arquitetura de referencia nao abrange, ou atrapalha, ae sim temos um projeto diferencidado. Mas normalmente o que ocorre são desenvolvedores dizendo que querem usar x,y,z pq é melhor, porém muita das vezes não tem embasamento algum. O que tento implantar nas empresas é uma cultura de conhecimento, assim os desenvolvedores são forçados a pesquisar os beneficios e maleficios das tecnologias/padroes que desejam utilizar e o impacto disso no negocio antes de propor algo.
Muitas vezes a arquitetura e tecnologias propostas pelos bons desenvolvedores são levadas adiante, assim são lançadas versões novas para a “arquitetura de referencia”, este negocio do arquiteto ficar no topo da cadeia alimentar na minha opiniao não existe, pois conhecimento não é algo que um cargo possa definir, com isso a palavra final só é dada após todos os pontos serem discutidos.
Trabalhei em empresas em que o problema normalmente era o mesmo, o que mudava era o foco, entao a arquitetura de referencia era algo que ate ajudava. Em outras, era justamente o contrario, problemas diversos, arquiteturas totalmente distintas, muita analise, pesquisa e discussao para descobrirmos o que era melhor para cada caso(Desenvolvedores, arquitetos, infra)
Então minha conclusão é que não podemos generalizar e dizer que uma arquitetura de referencia não se aplica nunca, pois existem casos e casos. Eu mesmo conheço casos de sucesso e casos desastrosos, porém não levanto uma bandeira antes de analisar cada novo projeto.
[quote=pcalcado]
A obrigação do arqutieto é procurar a melhor solução para o problma, e isso envlve a melhor técnica, a melhor solução olítica, financeira, de maior valor agregado e o melhor para seu time. Não é uma tarefa fácil e assumir que pode-se tomar esta decisão uma só vez para um grupo de sistemas que ainda vão nascer é fugir da realidade.[/quote]
Vide resposta acima.
Mas quem define a arquitetura não e a empresa para quem você presta serviço? Não dá para culpar um prestador de serviço ou pessoa que não tem voz por usar um framework imposto por aguma organização mas a organização criar este formato é que é o erro. Em vez de prezar por ter serviço de qualidade praticamente se assume que estamos contratando um bando de macacos que não sabem tomar decisões, logo precisamos utilizar alo que possamos controlar.
Eu já fui contratado para desenhar arquiteturas de refrência para clientes e o que fiz foi simplesmente um blueprint com soluções arquiteturais que podem ser apliadas nos problemas típicos que a empresa tinha. O guia apenas descreve padrões que odem ajudar e não só cnvida pessoas a usarem soluções que acharem mais úteis no seu caso bem como incentiva que estas soluções sejam adicionadas ao catálogo. Em vez de uma arquitetura de referência cria-se uma base de conhecimento sobre experiências com arquiteturas dentro daqules sistemas.
Pode ser que funcione aí mas em dez anos nunca vi isso na prática. Em minha experiência a pessoa que desenha a arqutietura sempre insiste em reutilizá-la, porque ela é genérica, porque quer se mantêr o conrole, porque se quer justificar emprego do arquiteto-master, porque custou muito dinheiro, porque aqui sempre foi assim e etc.
No mais, ao lançar uma nova versão da arquitetura de referência você vai ter dois problemas. Primeiro porque acho que concordamos que uma boa arqutietura leva as características daquele problema em específico em conta e se você for criar uma nova versão cada vez que um projeto encontra problemas específicos certamente irá lançar uma versão nova quase que a cada projeto -lembre-se: projetos possuem necessidades diferentes e estas impactam na arqutietura.
O segundo problema é que se eu precisei de uma coisa específica no meu projeto e obtive a benção dos arquitetos para utilizar isso não justifica que aquela solução seja adicionada à arquitetura de referêcia para todos os projetos, ela pode só fazer sentido no meu caso.
Se você tem dois sistemas que possuem a mesma arquitetura e o mesmo negócio… por que você tem dois sistemas? Será que na verdade você não deveria ter apenas um sistema flexível para disponibilizar os dois ‘focos’? Ainda assim, eles são construídos pelo mesmo time? Se não são, como a arqutietura genérica leva em consideração o time? Não leva?
Como falei, a coisa da arquitetura de referência é um paradoxo. Uma arquitetura deve levar em conta os fatores específicos de cada sistema. Cada projeto possui fatores específicos próprios (se não não seria um projeto/sistema novo). Não há como definir algo genérico que ainda assim leve em conta necessidades específicas.
É claro que uma empresa pode optar por pagar o preço em qualidade e ter apenas uma arquitetura para ter os pseudo-benefícios que a uniformidade irá trazer, mas eu realmente não recomendo isso. No lugar eu recomendo:
- Bons desenvolvedores
- Manter uma base de conhecimento
Muitos dos problemas enrentados por um projeto já foram enfrentados por outros e a base de conhecimento abastece o time com a experiência passada. Muitos dos problemas são novos e boas pessoas vão saber adaptar e criar em cima da base.
Realmente, “nada substitui o talento”.
Porém já ouvi do responsável por uma grande fábrica de software que os programadores são apenas “[google]beiçudos[/google]” e a necessidade de diminuir o custo os levou a manter esta cultura. Claro que tentei explicar que os custos eram causados pelas centenas de processos inúteis no ciclo de desenvolvimento, mas depois de investir milhoes em processos e certificações será mesmo que ele assumiria o erro? 8)
Shoes, entendo seu ponto e concordo, porém, as fábricas são controladas por pessoas que se preocupam mais com o que o Gartner diz do que com a realidade do mercado e enquanto os clientes não se tocarem de que o custo vem da burocracia e de práticas defensivas e não dos salários dos desenvolvedores arquiteturas de referencia ainda terão seu uso.
Pois se este pensamento continuar, daqui uns anos não teremos mais programadores de verdade e por consequencia analistas e arquitetos serão algo raro no mercado, pois os novos não terão uma bagagem para tomar decisões como arquitetura ou tecnologia ideal.
Bem, acho que sai um pouco do assunto
De qualquer forma, tenho que concordar com seus argumentos, infelismente a visão de que pensar gera custo me faz cada vez mais ter certeza que as pequenas empresas são as que possuem produtos de melhor qualidade(aqui no Brasil).
Alexandre,
Eu já trabalhei em fábrica de software com CMMI, já trabalhei com waterfall, já trabalhei com seudo-RUP, com gente que ainda faz análise estruturada de sistemas e outros lugares e projetos onde eu sabia que estava errado. Acho que a solução é você sempre tentar ajudar, propôr coisas novas, estudar bastante para justificar porque uma abordagem X ou Y é melhor, mas quase sempre a coisa não vai para frente e você muda de empresa uma vez mais.
No fim das contas você aprende muito sobre como as coisas funcionam e as empresas aprendem que elas estão fazendo algo que está mais de vinte anos atrasado e existem alternativas com eficiência comprovada. Não é difícil que uma semana depois de você pedir demissão alguém te liga desesperado para te recontratar porque percebem que aquela parte da qual você cuidava só stava indo bem -ao contrário do resto- porque você não tinha medo de desafiar o status quo.
Blogar para mim, por exemplo, surgiu como meio de colocar por escrito soluções que muitas vezes ninguém aceitava nessas empresas.