Demoiselle é um framework Open-Source Java, desenvolvido pelo SERPRO, com o objetivo de estabelecer uma arquitetura de referência, para todos os sistemas de órgãos federais. Seu nome foi inspirado no avião mais estável desenvolvido por Santos Dumont.


Baseado na documentação e no DAS (Documento de arquitetura de software) do Demoiselle, disponíveis para download no site do produto, gostaria de colocar de forma respeitosa as seguintes questões, para os arquitetos envolvidos com aplicações para este seguimento:

- A arquitetura "WEB-CENTRIC" do Demoiselle é adequada para as aplicações do governo?
- Não seria mais adequado adotar uma solução de mercado já testada e madura com garantias de suporte e evolução?
- O Demoiselle vai decolar? (ou melhor, vocês vêem algum entrave na adoção deste produto?)

de Pangea, Adriano.

Exibições: 75

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Flávio Gomes da Silva Lisboa em 29 agosto 2009 às 22:27
Os comentários foram muito interessantes.
Convido todos a interagir com a comunidade Demoiselle, por meio do portal www.frameworkdemoiselle.gov.br, a participarem da comunidade, e acompanharem a evolução dos projetos, dar sugestões e fazer críticas.
Comentário de Braulio Consani Moura em 20 abril 2009 às 16:09
Acho perigoso também a adoção de uma arquitetura única para o governo, ainda mais adotando soluções "caseiras". Creio que o fato de ser web-centric "engessa" bastante os futuros sistemas causando impactos negativos caso haja obrigação em adotar o framework.

Bem sabemos que, ainda mais no governo, nem sempre um padrão adotado é 100% padrão e aí caímos num campo pantanoso e num clima nebuloso.

Vamos ver no que dá... estaremos de olho...
Comentário de João David Sales Rosa em 6 abril 2009 às 10:44
Vejo dois problemas graves do Demoiselle:
* Ser uma arquitetura de referência, sendo que houve possibilidades do projeto ser um uma coleção de soluções para situações distintas, mas a visão de que a grande massa de desenvolvedores precisaria de algo "facil" impediu este caminho.
* Mesmo considerando que o framework é a primeira solução desta coleção, sua insistência em reivindicar a invenção da roda, negando a utilização de frameworks, atrasa muito a evolução do mesmo.
Comentário de Fabiano G. Souza em 4 abril 2009 às 11:51
Na minha visão criar frameworks proprietários dentro de orgão e empresas na maioria das vezes não é uma boa idéia. Evoluir um framework é coisa que dá muito trabalho, e nem sempre as empresas estão dispostas a isso. Aí você gera uma versão 1.0 dele mas não consegue evolui-lo, limitando suas decições de arquitetura às limitações do seu framework proprietário. Sou favorável a adoção de frameworks open source como base mas com o mínimo de customização, dentro do possível. Assim suas aplicações e arquitetura passam a realmente se beneficiar do modelo open source pois toda a maturidade de uma nova versão de um framework OS pode ser absorvida de forma muito mais rápida.
Comentário de Leonardo em 31 março 2009 às 22:02
No meu ponto de vista, não há informações suficientes pra responder a nenhuma das perguntas. Não estão detalhados os requisitos não funcionais e as necessidades dos diversos "consumidores" da aplicação logo, pode ser que a arquitetura WEB-CENTRIC seja suficiente.
Na segunda questão, é impossível identificar a causa da não adoção de frameworks consagrados! Problemas políticos, gerentes teimosos, modelos de licenças ou falta de entendimento delas, medo de não poder "batucar" o código dos outros, qualquer coisa pode interferir nessas decisões.
Quanto à terceira pergunta, se vai decolar eu não sei. Frameworks institucionalizados costumam decolar sim, trazendo com eles problemas como demora no ROI, baixo reuso, arquitetura imatura, bate volta no QA, problemas na contratação da mão-de-obra, dificuldade de terceirização (como uso de fábricas de software), custo de propriedade pra citar alguns.
Frameworks "genéricos" tendem a ser ilimitados quanto à quantidade de recursos que seus criadores querem adicionar. Quando imaturos, eles podem forçar toda uma série de de aplicações a estarem constantemente quebrando devido à mudanças continuas das suas APIs. O time-to-market, datas de entrega, cronogramas e roadmaps de módulos que dependem desses frameworks podem ser comprometidos gerando um efeito cascata desastroso pra corporação.
Se não existir um controle de releases eficientes, matriz de compatibilidades dos componentes, gerenciamento de configuração e versões, integração continua e nada disso foi mencionado no documento de arquitetura como garantir que o cliente vai receber o que ele quer, na hora que ele precisa e ainda mais funcionando ?
Pra finalizar, integração merece um documento à parte! É um lobisomem que não morre com bala de prata e merece muito cuidado. Integração pode significar o sucesso de um projeto ainda mais se vários orgãos distintos estão envolvidos.

Inté,
Comentário de Ricardo Ferreira em 31 março 2009 às 17:52
O fato de ser Web Centric já é um grande problema. Em alguns casos, pode atender, mas em outros, é um entrave muito grande. Se você começa a sua aplicação assim, mudar pra EJB Centric pode ser danoso. O principal ponto ruim disso é escalabilidade. Web Centric significa: Crescer aumentando os recursos da máquina. Isso é uma abordagem que funciona muito bem pra arquiteturas de mainframe, pois eles são projetados pra isso. Mas para aplicações de plataforma baixa, é o fim da picada IMHO.

Quanto a sua segunda pergunta ... acho que seria interessante sim. Um framework só se torna um bom framework depois que quem o fez já o usou em diversos cenários. O Hibernate é hoje um excelente framework ORM pois a anos ele é usado, e com base em feedbacks positivos e negativos (principalmente os negativos) ele tem melhorado. Criar algo do zero e achar que ele tem futuro ... hummmm ... sei não :P Prefiro apostar no que a anos está sendo maturado. Novamente, IMHO.

"O Demoiselle vai decolar?"

O ponto que acho que pode dificiltar isso é a cultura. Desenvolvedores ainda pensam em arquitetura com a oportunidade de ter orgasmos tecnológicos sobre criação. Software é uma área que envolve demais a criação, e se alguem se torna um programador, é porque ele adora criar. Tal como pintar, alguns querem apenas aprender técnicas simples para fazer uma parede, outros, preferem criar a ultima ceia. Neste caso, o uso de frameworks nunca é bem visto pelos desenvolvedores. A idéia de Software Product Lines pregada pelo SEI estimula o uso de soluções testadas, mas normalmente, tendemos (We, Developers) a querer criar nossas próprias soluções, pois essa é nossa unica chance de fazer o que dá tesão em software: Criar!

Em resumo ... o impeditivo é humano, cultural. O fato do framework em si ser bom ou ruim é apenas uma questão de ciclos de change requests para melhorá-lo. A não aceitação é um problema muito maior a ser resolvido.

Cordialmente,

RF

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço