Arquitetos que conheçam o Framework de integração

          Estou precisando de um feed back da comunidade que desenvolve
software em Java, a respeito da arquitetura montada pela PowerLogic.
Hoje eles tem um framework de integração que esta na versão 5.1, que
integra frameworks estabelecidos no mercado por sua excelência, como Hibernate e JBoss Seam.
Para que eu não fique só com a opnião dos vendedores do produto e com a experiência
da minha equipe técnica recorro a este fórum para saber a opinião de especialistas
em arquitetura.

          Para não ser tão restrito, se possível os que quiserem relatar sua experiência com outros
frameworks de integração ou em soluções próprias que fiquem a vontade para manifestar seu ponto de vista.

Olá

  1. Porque pagar por coisas gratuitas?

  2. Porque treinar em algo novo os programadores que normalmente já conhecem alguns dos frameworks de forma isolada e que podem evoluir separadamente?

  3. Pelas dificuldades oriundas da própria integração, não tem medo de que o uso destes frameworks engesse o processo de desenvolvimento?

De minha parte, que ainda não recebi nenhum assédio de vendedores de coisas deste tipo, não vejo nenhuma vantagem na sua adoção. Sugiro que procure aqui mesmo no GUJ por discussões que envolvam o uso deste tipo de framework de integração e lerá algumas opiniões não muito favoráveis.

Mas caso resolva adquirir este produto, tome muito cuidado para que ele não se transforme naquela coisa abominável que é o que alguns chamam de “framework de referência”, isto é, a plataforma única de desenvolvimento na empresa que rapidamente ficam obsoletos pela própria volatilidade das verdades dentro da área de TI. Para evitar cair nesta armadilha sugiro a leitura de http://blog.fragmental.com.br/2007/10/15/arquitetos-mcdonalds/

[]s
Luca

[quote]Estou precisando de um feed back da comunidade que desenvolve software em Java, a respeito da arquitetura montada pela PowerLogic[/quote]Há algumas discussões interessantes.:
https://soujava.dev.java.net/servlets/ReadMsg?list=java-list&msgNo=19724
http://www.guj.com.br/posts/list/64199.java#478843
http://www.guj.com.br/posts/list/67689.java#454156
Acho que já dá para vc. tirar as suas conclusões.

Mais qual o escopo de seu projeto para precisar de um produto desses.??

sds.

Oi Joseph Bettencourt,

Acho que conheço o "framework" da PowerLogic apenas pelo nome.

Mas lí os links indicados no forum e deu pra ter uma idéia do que se trata.

 Eu passei por 3 empresas que utilizavam coisas deste tipo:

 Na primeira utilizavam um mecanismo feito em clipper que não lembro o nome, todos analistas que fizeram curso e etc... reclamavam.

 Na segunda utilizavam uma ferramenta para implementar projetos J2EE parecida com esta da PowerLogic, o nome era APYON o nome da empresa acho que era APYON também, antes de eu chegar nesta empresa +ou- 20 profissionais foram demitidos ou pediram pra sair e no final a empresa teve que "abandonar o cliente", acredito que a coisa toda foi parar até na justiça; não fiquei para ter certeza disso. Foi vergonhoso, o projeto iria ser utilizado na Inglaterra, Espanha e Canadá.
  Detalhe, este projeto se fosse feito em Html, JavaScript, JSPs, Servlets etc... teria atendido o cliente em menos tempo com uma equipe bem mais reduzida.

 Na terceira, que estou hoje, utilizam ScriptCase, pelo que me contam atendeu no início mas parece que não conseguem fazer os ajustes necessários para atender os requisitos plenamente de forma rápida e satisifatória, planejam reformular o projeto e implementar em java, aliás foi por isso que entrei nesta empresa.

 Como vc pode ver eu tenho vários motivos (descrevi resumidamente porque a coisa foi bem pior) que me levam a não apoiar este tipo de "framework".

Abraços

Luca,

  1.  No caso de minha empresa ter foco no desenvolvimento de sistemas corporativos pode ser conveniente
    tercerizar a implementação da arquitetura e sua manutenção do que manter uma equipe dentro da empresa
    com este propósito. Posso garantir a manutenção do framework através de contrato com a empresa fornecedora,
    o que não posso garantir mantendo uma equipe de desenvolvedores, já que eles estão sujeitos a assédio do mercado
    e a continuidade do sistema fica comprometida já que os sistemas de minha empresa tem uma vida útil em media 15 anos.

 - Uma menor curva de aprendizado.
   Não é necessário uma equipe com um bom conhecimento em todos os frameworks para o desenvolvimento. Posso ter
uma equipe heterogênea em conhecimento, posso concentrar a maioria dos meus desenvolvedores na implementação dos
casos de uso em quanto 1 ou 2 desenvolvedores com mais conhecimento para auxiliar os desenvolvedores menus experientes.
 -  mais produtividade.
   Vou concentrar minha força de trabalho no desenvolvimento dos casos de uso. Possui wizard
para geração de artefatos comuns a todos os casos de usos e também a implementação de código reutilizável.
 - Padrão de desenvolvimento definido.
   O framework possui um conjunto de padrões para o desenvolvimento dos casos de uso, isto facilita a entrada
de novos programadores na equipe e diminui o tempo que ele para se engajar no projeto.
 - Documentação do framework.
   Com o framework bem documentado a saída de um desenvolvedor não acarretará uma perca insubstituível para o projeto.

3) Tenho a empresa fornecedora do framework para fazer as atualizações necessárias.

Sr Joseph, me desculpe a franqueza, mas acabou de dizer exatamente o que todos os administradores, vitimas dos vendedores de milagres disseram antes de construtir um projeto conturbado.

Porém a outra saída também não é, na minha opinião, menos complicada que é ter e manter uma equipe comprometida com o sucesso do projeto.

É possível fazer uma visita em um dos clientes da PowerLogic que tenha projetos com o perfil parecido com os teus e verificar os resultados?

[]'s

Eu conheço um cliente Powerlogic a Rhealeza www.rhealeza.com.br, acho que não custa buscar alguma informação sobre o powerlogic com eles.

Abraço

fantomas,

          Para tudo na vida existe uma boa razão para acontecer. Que explicações você teria para um “projeto conturbado”?

          O que esta sendo negociado é a compra de um produto com determinadas características, se uma delas não cumprir com
o seu propósito tenho o direito de revindicar melhorias, se não atendidas posso entrar com processo contra a empresa
fornecedora do produto.
" É possível fazer uma visita em um dos clientes da PowerLogic que tenha projetos com o perfil parecido com os teus e verificar os resultados? "
A verão 5.1 do JCompany é recente e poucas empresas adquiriram. Estou providenciando visitas as empresas.

[quote=Joseph Bettencourt]Luca,

  1.  No caso de minha empresa ter foco no desenvolvimento de sistemas corporativos pode ser conveniente
    tercerizar a implementação da arquitetura e sua manutenção do que manter uma equipe dentro da empresa
    com este propósito. Posso garantir a manutenção do framework através de contrato com a empresa fornecedora,
    o que não posso garantir mantendo uma equipe de desenvolvedores, já que eles estão sujeitos a assédio do mercado
    e a continuidade do sistema fica comprometida já que os sistemas de minha empresa tem uma vida útil em media 15 anos.
    [/quote]

ara um projeto dessa duração terceirizar não lhe garante nada. Você assume que a outra empresa vai durar 15 anos ou que ele vai manter o conhecimento do seu sistema durante 15 anos. Contratos foram feitos para serem desfeitos. Pode ser mais vantajoso a terceirizada pagar um multa que suportar o framework durante 15 anos. (em 15 anos as tecnologias evoluem para um patamar completamente diferente )

Para sistema de longa duração vc deve dominar a arquitura sim, e as tecnologias sim. Se vc pensa que os seus desenvovedores o vão abandonar é porque não está pensando em incentivá-los. Ai sim vc merece que eles vão embora.

A forma como vc pensa pode ser válida para um projeto pequeno (menos de 5 anos) , mas não para um grande. Somando a isso existe a responsabilidade sua com o seu cliente. Se o seu sistema é o suporte do seu negocio e a evolução e suporte dele vão para o espaço, vc vai junto.

[quote] O que esta sendo negociado é a compra de um produto com determinadas características, se uma delas não cumprir com
o seu propósito tenho o direito de revindicar melhorias, se não atendidas posso entrar com processo contra a empresa
fornecedora do produto. [/quote]

Segunda vez que eu ouço essa história hoje!

Me desculpe, mas pense sobre o seguinte se a fornecedora te vender uma idéia fantosiosa sobre o produto, processa-la não vai impedir que a sua empresa sofra as consequências. Se for um sistema critico para sua empresa e você tiver problemas como que você ira justificar que foi o fornecedor que não lhe solucionou os problemas!???!

Exatamente! Deve ser considerado que vc pode ser um refem nas mãos dessa fornecedora, vc não terá recursos que tenham um conhecimento mais aprofundado sobre o produto e esse já encapsula muita coisa e se os seus recursos não tem um bom nivel de conhecimento nos frameworks e na ferramenta como eles irão resolver problemas complexos?

[quote]
Se vc pensa que os seus desenvovedores o vão abandonar é porque não está pensando em incentivá-los. Ai sim vc merece que eles vão embora. [/quote]

Concordo!

[quote=Joseph Bettencourt]Luca,

  1.  No caso de minha empresa ter foco no desenvolvimento de sistemas corporativos pode ser conveniente
    tercerizar a implementação da arquitetura e sua manutenção do que manter uma equipe dentro da empresa
    com este propósito. Posso garantir a manutenção do framework através de contrato com a empresa fornecedora,
    o que não posso garantir mantendo uma equipe de desenvolvedores, já que eles estão sujeitos a assédio do mercado
    e a continuidade do sistema fica comprometida já que os sistemas de minha empresa tem uma vida útil em media 15 anos.

 - Uma menor curva de aprendizado.
   Não é necessário uma equipe com um bom conhecimento em todos os frameworks para o desenvolvimento. Posso ter
uma equipe heterogênea em conhecimento, posso concentrar a maioria dos meus desenvolvedores na implementação dos
casos de uso em quanto 1 ou 2 desenvolvedores com mais conhecimento para auxiliar os desenvolvedores menus experientes.
 -  mais produtividade.
   Vou concentrar minha força de trabalho no desenvolvimento dos casos de uso. Possui wizard
para geração de artefatos comuns a todos os casos de usos e também a implementação de código reutilizável.
 - Padrão de desenvolvimento definido.
   O framework possui um conjunto de padrões para o desenvolvimento dos casos de uso, isto facilita a entrada
de novos programadores na equipe e diminui o tempo que ele para se engajar no projeto.
 - Documentação do framework.
   Com o framework bem documentado a saída de um desenvolvedor não acarretará uma perca insubstituível para o projeto.

3) Tenho a empresa fornecedora do framework para fazer as atualizações necessárias.[/quote]

Joseph, boa tarde.

Acredito que ter uma equipe interna ainda e a melhor solução…
Entendo que os riscos quando ao assédio do mercado, de fato são factíveis ,porem acredito ser mais vantajoso um processo bem documentado, isso porque não podemos ter medo dos profissionais irem embora, mas temos sim que trabalhar para que os mesmos documentem os processos(arquitetura, analise, motivos para tomada de decisões) em seu tempo de trabalho na empresa. As empresas que desenvolvem os frameworks também sofrem assédio do mercado que representam riscos para o desenvolvimento do projeto deles (framework no caso), sendo assim sabe-se lá Deus como esse framework vai estar funcionando ao longo do tempo.

Mesmo que você tenha a possibilidade de processar a empresa que desenvolveu o framework por algum problema técnico isso garante que você não vai perder o seu cliente?

Outro grande ponto a ser ponderado em frameworks de mercado na minha opinião e que você fica dependente de uma empresa , isso a longo prazo não e bom, sem contar que as soluções tecnológicas desenvolvidas pela sua equipe estarão sujeitas aos avanços tecnológicos do framework de mercado o que não e sábio.

Como os frameworks são feitos para atender a um grande numero de clientes você não vai poder desenvolver soluções customizadas sobre esse framework, e mais, caso possa, você estará novamente na mão de um profissional(empresa) que desenvolveu o modulo para sua empresa, o que não e muito vantajoso mesmo.

Acredito que desenvolver uma documentação adequada, e adotar padrões de projetos simples, com frameworks open source amplamente conhecidos no mercado podem ser uteis para minimizar os riscos que você tem visto em seu processo.

Caso queira conversar com pessoas na sua posição que passaram pelos menos problemas(framework de mercado ou desenvolvimento próprio) que você posso indicar algumas.

Atenciosamente,
Eduardo

[quote=Joseph Bettencourt]Luca,

  1.  No caso de minha empresa ter foco no desenvolvimento de sistemas corporativos pode ser conveniente
    tercerizar a implementação da arquitetura e sua manutenção do que manter uma equipe dentro da empresa
    com este propósito.

  2. Posso garantir a manutenção do framework através de contrato com a empresa fornecedora,
    o que não posso garantir mantendo uma equipe de desenvolvedores, já que eles estão sujeitos a assédio do mercado
    e a continuidade do sistema fica comprometida já que os sistemas de minha empresa tem uma vida útil em media 15 anos.

…[/quote]

  1. Nao seria o correto uma empresa de desenvolvimento de sistemas desenvolver o seus sistemas?

  2. Eu não vejo como um nivel de indirecao a mais entre o produto e o cliente poderia resolver este problema para o seu fornecedor. Sem dúvida o problema é dele mas as implicacoes são mais gerais.

Oi Joseph,

[quote]Joseph Bettencourt wrote:
O que esta sendo negociado é a compra de um produto com determinadas características, se uma delas não cumprir com
o seu propósito tenho o direito de revindicar melhorias, se não atendidas posso entrar com processo contra a empresa
fornecedora do produto.[/quote]

Dificilmente o fornecedor irá lhe dizer que determinada caracteristica não cumpre com o propósito, o que já vi acontecer nestes casos é o seguinte:

a) Dependendo da questão alega-se que seus profissionais apesar de ter recebido treinamento etc…ainda não são capazes de aplicar a customização para resolver o problema e então lhe é oferecido alguns profissionais que já conhecem profundamente a ferramenta para “ajudar” (a pêso de ouro).

b) Se o item (a) se concretizar vc irá notar uma certa demora no cumprimento das tais caracteristicas isso poderá levar a um aumento do número de profissionais no projeto (injetado pelo fornecedor), porque irão lhe dizer que a demora é devido a alta complexidade das customizações porisso é necessário mais profissionais (e dá lhe dinheiro).

Trocando em miúdos, o fornecedor nunca irá adminitir que a ferramenta é deficiente, eles não são bobos, vão tentar compensar com alocação de profissionais lembrando que os prazos dos teus projetos NÃO TEM NENHUMA RELAÇÃO com os prazos dos projetos do seu fornecedor. Por exemplo, se eu tiver um certo problema com o meu sistema operacional eu vou ter que ESPERAR a próxima versão, se eu precisar da solução “prá ontem” problema meu.

Desculpem só apontar o lado ruím da idéia, só quero ficar tranquilo sabendo que alertei sobre algumas coisas que acontecem por ai e que estou ajudando alguém a ter uma certeza maior sobre sua decisão.

Aquele abraço Joseph