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

Alguns que eu acrescentaria:

:arrow: Não ter sempre em mente que SOA é diferente de SOAP
:arrow: Achar que SOA é mudança técnica e não cultural
:arrow: Querer transformar absolutamente tudo em serviço
:arrow: Esperar que o fornecedor e seu ‘middleware mágico’ resolva os problemas da empresa
:arrow: Esperar que SOA corrija os processos da empresa.
:arrow: 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

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… 8)

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ã … :roll:

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

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

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

Serializa para XML :arrow: Responde para o cliente :arrow: Cliente receber o XML :arrow: Passa para Objeto :arrow: 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…

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!

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

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

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

SOA não precisa ser SOAP

saoj:

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

Kenobi:

• 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ã … :roll:

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

Abraços,

:idea: 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.

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

Isso vai depender muito das tecnologias envolvidas.
Mas em suma, eu vejo segurança(autenticação/autorização), confiabilidade das mensagens, auditoria de serviços, gerenciamento do fluxo de serviços, monitoramento dos serviços…

Bem segundo esse artigo o crescimento do software como serviço está sendo quase astronomico, os projetos Saas tambem devem ser considerados nessa discursão.

Mas como foi dito o os projetos orientados a serviço parecem ser o futuro da TI.

flwsss

MauNunes:

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.

Ola,

Voce poderia dar exemplo de algum projeto baseado em SOA e reconhecido publicamente como tido sucesso? Algo como uma implementacao de referencia?

Ola,

Voce poderia dar exemplo de algum projeto baseado em SOA e reconhecido publicamente como tido sucesso? Algo como uma implementacao de referencia?

Olá Carlos,

Dá um olhada nesse link: http://www.oracle.com/customers/products/oracle-soa-customers.html Aqui tem uma lista de videos e pdf’s de casos de sucesso usando o SOA da Oracle.

Muito provavelmente no site da BEA você também vai encontrar algo parecido.

Um abraço,

Olá

glaucioguerra:

Dá um olhada nesse link: http://www.oracle.com/customers/products/oracle-soa-customers.html Aqui tem uma lista de videos e pdf’s de casos de sucesso usando o SOA da Oracle.

Muito provavelmente no site da BEA você também vai encontrar algo parecido.

Alguém lembra de algum caso de sucesso pelo ponto de vista de quem usa e não pelo ponto de vista de quem vendeu?

Sei que devem existir muitos mas bem menos do que contam os vendedores de ferramentas e empresas especializadas no vendor lock-in

[]s
Luca

Luca:

Olá

glaucioguerra:

Dá um olhada nesse link: http://www.oracle.com/customers/products/oracle-soa-customers.html Aqui tem uma lista de videos e pdf’s de casos de sucesso usando o SOA da Oracle.

Muito provavelmente no site da BEA você também vai encontrar algo parecido.

Alguém lembra de algum caso de sucesso pelo ponto de vista de quem usa e não pelo ponto de vista de quem vendeu?

Sei que devem existir muitos mas bem menos do que contam os vendedores de ferramentas e empresas especializadas no vendor lock-in

[]s
Luca

No exato momento estou num projeto para construção de uma Arquitetura SOA para o Grupo STP. Há muita expectativa sobre descentralização dos serviços, permitindo que os serviços sejam compostos apenas por processos - BPEL.

Acredito que se o modelo canônico for bem desenhado e os serviços também, isso pode ocorrer sem maiores traumas. O grande problema está na experiência dos arquitetos do projeto, meu ponto de vista, pois pode sair uma meleca geral

Isso vai depender muito das tecnologias envolvidas.
Mas em suma, eu vejo segurança(autenticação/autorização), confiabilidade das mensagens, auditoria de serviços, gerenciamento do fluxo de serviços, monitoramento dos serviços…

Ok, faz sentido. Mas se vc pensar bem tudo isso já foi resolvido no mundo web. Em qualquer projeto web temos que se preocupar com essas mesmas coisas.

Então pra que inventar um middleware gigantesco, complexo e proprietário no meio disso?

Por que não usar HTTPClient para trocar mensagens com o servidor e cair no vasto, seguro e livre mundo http?

Com HTTPClient por exemplo eu posso usar cookies para autenticação. Posso usar HTTPS. Posso usar 10000 frameworks web. E por aí vai…

Talvez porque um cliente não terá acesso a um HTTPClient. Tudo bem, mas entre um HTTPClient para os meus clientes e um elefante branco proprietário ou qualquer framework louco de web services, eu fico com o HttpClient…

E qual cliente não pode fazer uma forcinha para obter um HttpClient para suas requisições?

:arrow: Na grande maioria dos cenários que passei, o simples fato de não ter um ‘ecossistema’ de aplicações todo em Java já impossibilitaria isso. Certo que qualquer plataforma com um minimo de caráter e bons costumes consegue fazer uma requisição http. Porém até você fazer com que seu fornecedor implemente algo tão RESTful no produto dele já é um loooooongo caminho.
:arrow: Para você fazer com que a SAP implemente essa requisição HTTP no R3 dela já se vão alguns bons meses só para você saber se isso é possivel, e depois disso começar a testar -ou qualquer outro ERP famoso por aí-.
:arrow: Ou outro cenário em que aquele fornecedor de uma micro-nano-empresa que desenvolve em Delphi/VB/Clipper/etc até a equipe implementar essa chamada que nunca tentou já é um grande passo.
:arrow: Outro problema que tive em utilizar http era quando a carga de serviços era muito grande, na ordem de milhares/milhões de requisições
:arrow: E outro grande problema do HTTP é que ele é síncrono, e nem sempre você vai querer fazer isso com seus serviços.

Mas concordo contigo, esses middlewares-mágico-satânicos são mais promessas e dor de cabeça do que solução pra os problemas técnicos, a grande maioria que tive contato. E integrações consegue-se simplificar na maioria dos casos. Ou seja, a questão técnica sempre há alternativas, a gente sempre dá um jeito.

É como o Vinícius Teles sempre diz nas palestras de XP: ‘O grande problema é que seu chefe é uma besta, e pior ainda, o chefe do seu chefe é mais besta ainda…’