Quais são as 10 razões que levam SOA ao fracasso?

Esta semana foi publicado no site da computerworld um artigo listando 10 motivos aparentes do fracasso do SOA, alguem concorda com os motivos do autor ?

flwsss

fonte: http://computerworld.uol.com.br/gestao/2008/07/30/quais-sao-as-10-razoes-que-levam-soa-ao-fracasso/

This message was edited 2 times. Last update was at 30/07/2008 08:32:18

Alguns que eu acrescentaria:

Não ter sempre em mente que SOA é diferente de SOAP

Achar que SOA é mudança técnica e não cultural

Querer transformar absolutamente tudo em serviço

Esperar que o fornecedor e seu 'middleware mágico' resolva os problemas da empresa

Esperar que SOA corrija os processos da empresa.

FOA(Faroest Oriented Architecture - Um bando de cowboys, a.k.a WebServices, dando tiro pra todo lado)

concordo plenamente Rafael. E reafirmo o último motivo do autor: Deixar os fornecedores direcionar a arquitetura. Isso é cruel...

Mas meu ponto de vista, no resumo da obra, é o seguinte. Se não entende o q é nem tente começar a fazer. SOA virou modismo, mecanismo de integração (???), etc. E quem espera isso de SOA, melhor abandonar o barco antes q afunde mesmo... hehehe

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

Bom,

Ele tudo o que foi escrito denota a visão de CIO q ele tem, mas eu concordo com o que ele diz sim.
Algumas itens eu acho que não são problemáticos apenas quando se lida com SOA, mas quando se lida com projetos de TI de modo geral.. como definir o valor do negócio, falta de capacitação das pessoas, subestimar a capacidade da arquitetura etc..

1. Valor de SOA para o negócio não é explicado
Concordo. Como eu disse em vários lugares ainda não ficou claro para as empresas o valor que um sistema de informação pode ter para o negócio, isso porque muitas vezes quem faz o software se preocupa com prazos, cronograma, custos, tecnologia e se esquece de estudar os processos de negócio do cliente e principalmente otimizar esses processos.

2. Subestimam a resistência contra as mudanças
Concordo. Isso com certeza acontece.

3. Não possuem patrocínio executivo
Esse também é um problema em todo projeto de sistemas de informação.

4. Tentam implementar ?mini SOA?
Sim, principalmente quando se trata de Economizar em ferramentas de gerenciamento do ciclo de vida ou em resolução de problemas não é boa idéia, assim como eliminar consultores.

5. Não têm as pessoas necessárias para SOA
Problema também ao usar qualquer outra tecnologia.

6. Fraca gerência de projetos
Problema também ao usar qualquer outra tecnologia.

7. Pensam em SOA como um projeto
É verdade

8. Subestimam a complexidade de SOA.
Sim

9. Não conseguem aderir a governança SOA
Concordo

10. Deixam os fornecedores direcionar a arquitetura
Cai naquela situação, se der M#)$( a culpa é do fornecedor..

Descendo para um patamar mais técnico, pelo que já passei em projetos SOA:

- Falta de visão na modelagem dos serviços
- Planejamento de versionamento dos serviços.
- Modelagem de Domínio competente, que gere de fato um modelo canônico imutável ( ou com poucas modificações).
- Falta de conhecimento da demanda gerada pelo negócio, a fim de provisionar controles de tráfego para o serviço
- Contratos entre os serviços "gerados" automaticamente, por alguma ferramenta.
- Política de segurança inexistente.

Nossa podia ficar até amanhã ...

Pergunta: Por que SOA não pode ser simplesmente:

Cliente

Objeto

Serializa para XML

Requisição HTTP passando o XML

Servidor Web

Volta de XML para Objeto

Faz o que tem que fazer

Gera um Objeto como resposta

Serializa para XML

Responde para o cliente

Cliente receber o XML

Passa para Objeto

Fica feliz

saoj wrote:
Pergunta: Por que SOA não pode ser simplesmente:

Cliente Objeto Serializa para XML Requisição HTTP passando o XML Servidor Web

Volta de XML para Objeto Faz o que tem que fazer Gera um Objeto como resposta

Serializa para XML Responde para o cliente Cliente receber o XML Passa para Objeto Fica feliz

Não ter sempre em mente que SOA é diferente de SOAP
Achar que SOA é mudança técnica e não cultural

Porque serializar e trocar objetos em SOA é o menor dos problemas...

This message was edited 3 times. Last update was at 30/07/2008 16:30:11

Não ter sempre em mente que SOA é diferente de SOAP

Sei que existe o REST, só que tb dá para implementar REST com o esquema acima sem problemas. Uma estratégia legal é usar JSPs para gerar os XMLs a partir de objetos! Assim o JSP nada mais será que um template para a serialização de Objetos Java em XML. Mamão com açucar!

Alexandro.Almeida wrote:
Achar que SOA é mudança técnica e não cultural

Estou debatendo a complexidade técnica e não cultural.

Porque serializar e trocar objetos em SOA é o menor dos problemas...

Qual seria então o maior dos problemas do ponto de vista técnico?

This message was edited 1 time. Last update was at 30/07/2008 16:39:59

saoj wrote:
...
Estou debatendo a complexidade técnica e não cultural.

Mas SOA é cultura, um estilo de arquitetura de software.

SOA não precisa ser SOAP

saoj wrote:

Qual seria então o maior dos problemas do ponto de vista técnico?

Kenobi wrote:

- Falta de visão na modelagem dos serviços
- Planejamento de versionamento dos serviços.
- Modelagem de Domínio competente, que gere de fato um modelo canônico imutável ( ou com poucas modificações).
- Falta de conhecimento da demanda gerada pelo negócio, a fim de provisionar controles de tráfego para o serviço
- Contratos entre os serviços "gerados" automaticamente, por alguma ferramenta.
- Política de segurança inexistente.

Nossa podia ficar até amanhã ...

SOAP, REST são formas de implementar Serviços (WebServices), SOA é muito mais que isso.

Abraços,

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Em uma Palestra que estive na Oracle, ministrada por Jean Rodrigues o tema principal foi SOA utilizando os recurso da Suite Oracle como produtividade, o que era fácil algo de entender e ao mesmo tempo complexo de interpretar , era até a onde eu tinha serviço e aonde essa orquestração podia alcançar uma independência de estado objeto vs serviço e nisso em disposição ou não em alta produtividade em aplicações no Core Oracle. A visão de ter serviço podendo estar presente em outros sem afetar qualquer normalidade e esse se entender trocando serviços e depois esse irem e virem de qualquer estado é algo que envolvia alta tecnologia de ponta junto com BPM e BPEL juntas com nível de processo elevados. Fazer SOA ´não é migração é transformação é isso requer total descretalização e estado de normas dentro de uma corporação o que exige altos investimentos.

Java Ninja Membro desde: 10/06/2007 22:27:54 Mensagens: 283 Offline

Bom, acho que posso dar o meu palpite.

Estou terminando minha pós graduação em Engeharia de Software baseado em SOA, pelo IBTA, na qual tive aulas com excelentes professores que ja trabalham com isso, onde o principal objetivo deles e vender um projeto SOA para uma empresa.

Posso sim afirma que SOA é um grande investimento para o negócio que no futuro trará um excelente ROI. Mas como poucos sabem SOA pode ser implementando de diversas formas da mais simples arquitetura ate a mais complexa, que envolve ate infra-estrutura. SOA não é só serviço, é muito mais que isso. SOA é sim o futuro da TI, uma forma de alinhar as estratégias de negócio com a área de TI. Quando se fala em SOA não se fala somente em tecnologia, mas sim em negócio, pode ter certeza que isso vai muito alem de Web-Services e ESB. Mas por enquanto SOA ainda é para grandes empresas.
Tudo que fazemos tem um risco de não dar certo. Por isso para se implentar uma arquitetura SOA na empresa é necessário diversas fases de análise e levantamento de informações. Para isso existem diversas forma de implementar SOA nas empresas, sendo elas top-down ou botton-up.

Excelente apresentação sobre o assunto

http://www.infoq.com/presentations/soa-without-esb

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