BPM sem BPEL Parte 2
No post anterior, escrevi um pouco sobre BPM e bem como andam os padrões que seguem esse modelo, neste post pretendo falar sobre a ligação de BPEL com BPM. Vou citar outras referencias que confiram a minha visão de que BPM e BPEL talvez não seja o casamento perfeito.
Quando falamos de BPMN, BPMS, simulação, estamos falando obrigatoriamente de BPM. Se falarmos de WS-BPEL, WebServices, WSDL podemos estar falando de SOA, mas nem sempre, usar WS-BPEL, WebServices, WSDL não significa ter SOA. Se você quiser saber mais sobre SOA pode ler esses posts:
Nos posts anterior sobre BPEL falei dos pontos positivos e neste post vou mostrar os pontos negativos do uso de BPEL em conjunto com BPM. Não digo que é de todo o mal a abordagem mas o mercado já salienta diversos problemas os quais alguns vi na prática.
O Casamento de SOA com BPM
BPM é negócio, é o fluxo da sua empresa, é gestão de processos, SOA é arquitetura corporativa, ou pelo menos uma parte dela, focada em serviços, serviços estão relacionados a processos, então BPM e SOA são feitos um para o outro? Em alguns casos essa abordagem pode ser muito produtiva, implantar os dois do zero pode ser um grande risco. Por que SOA vai mexer muito com a TI e BPM vai mexer muito com o negócio.
Você pode realizar uma implantação parcial e primeiro colocar BPM e depois disso ir para SOA, para mim é o melhor cenário, não digo que seja impossível colocar os dois ao mesmo tempo mas aos meus olhos acredito que só aumenta a complexidade e os riscos de se ter sucesso e ROI em curto prazo.
Mas como juntar BPM e SOA?
Na verdade é simples, essa cola pode existir apénas em tempo de análise/design, tudo tem inicio do processo da empresa, do fluxo, desse fluxo se derivam, aplicações, serviços, sistemas legados, sistemas de terceiros, tarefas manuais do negócio, tarefas manuais da TI, etc...
Tudo isso pode ser controlado com uma boa ferramenta de metadados. Um exemplo é o ORACLE Design que não deixa de ser uma ferramenta de metadados para o banco ORACLE, você pode fazer esse sistema com meia dúzia de cadastros, ainda é possível usar algum sistema de gestão de assets.
Porem essa não é a única abordagem, existe outra vertente que é até defendida por grandes players como IBM e ORACLE a idéia de gerar o BPEL a partir de um diagrama de processo do BPM.
Esse casamento pode dar divorcio ou até mesmo...
Se existisse só um problema eu não estava falando disso :). São vários os problemas, primeiro é que um processo BPM pode não ser 100% mapeavel do BPM para o BPEL. Se vocês tem suas dúvidas confiram esses outros posts/artigos:
Eles querem fazer o bom e velho lock-in e prender vocês ao ferramental deles, por sinal o IBM Modeler 6.0 nem implementar BPMN implementa, voltando a falar de BPEL, existem outros problemas sérios no uso de BPEL:
E o Pega Gerente?
Esse é o problema. Todo esse papo furado de gerar o BPEL pelo BPM é algo que os gerentes adoram, ou seja, uma solução mágica que com ferramentas vai eliminar, erros, descuidos, dar flexibilidade e até tirar o peso da responsabilidade das pessoas. É um mundo mágico que infelizmente não existe. Existe apoio dos gerentes por que as grandes empresas estão jogando nisso, mas o mercado não está comprando, a prova disso é esse gráfico:
Gráfico de tendências do site In Deed
Muitas vezes uma alternativa viável e simples é ao invés de fazer orquestração fazer roteamento de serviços, não resolve 100% dos casos, mas em alguns casos da no mesmo, isso pode ser feito com um bom ESB como o Apache Service Mix usando o Camel da Apache por exemplo.
Uma idéia que me agrada muito é, fazer orquestração de forma padronizada assim como no BPEL mas usando formas mais leves como interfaces java, ejbs, beans do Spring, apis REST, mas tudo isso de forma padronizada por alguma especificação. Mas nada indica que esse caminho ira surgir fora das extensões.
BPEL em DSL?
Essa seria uma coisa ótima, usar BPEL com schema XSD, xml e WSDL é algo muito ruim, muito pesado, que cria uma dependência muito forte com um ferramental se não é impossível faer algo que preste com o mínimo de produtividade.
Ouvi falar do SimPEL que seria um BPEL simplificado em forma de DSL, espero que isso vá para frente, confiram isso neste link: http://www.nabble.com/SimPEL-early-feedback-td19380187.html.
O SimPEL é muito novo, é do final de 2008, não sei se evoluiu muito, apareceu na lista de discussão de desenvolvimento do Apache ODE e está em passos de bebe, mas achei muito interessante e gostaria muito de ver as coisas evoluindo para esse lado, o SimPEL é algo tipo isso:
Como disse antes não sei se a iniciativa foi para frente, mas é algo muito legal. Mesmo com isso ainda não temos a tão sonhada cola do BPM com o BPEL e não vamos ter isso com ferramental nenhum, certas coisas ainda devem ser feitas da maneira antiga, com ferramentas sim, com pessoas e o bom e velho processo.
Abraços a até a próxima.
Quando falamos de BPMN, BPMS, simulação, estamos falando obrigatoriamente de BPM. Se falarmos de WS-BPEL, WebServices, WSDL podemos estar falando de SOA, mas nem sempre, usar WS-BPEL, WebServices, WSDL não significa ter SOA. Se você quiser saber mais sobre SOA pode ler esses posts:
- SOA: Cuidado com o Lock-In
- SOA sem BPMN e WebServices
- O papel do ESB em uma solução SOA
- SCA com Java Parte 1
- SCA com Java Parte 2
- A Diferença de EA e Arquitetura de Software
Nos posts anterior sobre BPEL falei dos pontos positivos e neste post vou mostrar os pontos negativos do uso de BPEL em conjunto com BPM. Não digo que é de todo o mal a abordagem mas o mercado já salienta diversos problemas os quais alguns vi na prática.
O Casamento de SOA com BPM
BPM é negócio, é o fluxo da sua empresa, é gestão de processos, SOA é arquitetura corporativa, ou pelo menos uma parte dela, focada em serviços, serviços estão relacionados a processos, então BPM e SOA são feitos um para o outro? Em alguns casos essa abordagem pode ser muito produtiva, implantar os dois do zero pode ser um grande risco. Por que SOA vai mexer muito com a TI e BPM vai mexer muito com o negócio.
Você pode realizar uma implantação parcial e primeiro colocar BPM e depois disso ir para SOA, para mim é o melhor cenário, não digo que seja impossível colocar os dois ao mesmo tempo mas aos meus olhos acredito que só aumenta a complexidade e os riscos de se ter sucesso e ROI em curto prazo.
Mas como juntar BPM e SOA?
Na verdade é simples, essa cola pode existir apénas em tempo de análise/design, tudo tem inicio do processo da empresa, do fluxo, desse fluxo se derivam, aplicações, serviços, sistemas legados, sistemas de terceiros, tarefas manuais do negócio, tarefas manuais da TI, etc...
Tudo isso pode ser controlado com uma boa ferramenta de metadados. Um exemplo é o ORACLE Design que não deixa de ser uma ferramenta de metadados para o banco ORACLE, você pode fazer esse sistema com meia dúzia de cadastros, ainda é possível usar algum sistema de gestão de assets.
Porem essa não é a única abordagem, existe outra vertente que é até defendida por grandes players como IBM e ORACLE a idéia de gerar o BPEL a partir de um diagrama de processo do BPM.
Esse casamento pode dar divorcio ou até mesmo...
MERDA!!!
Mas com o Problema dessa abordagem?
Mas com o Problema dessa abordagem?
Se existisse só um problema eu não estava falando disso :). São vários os problemas, primeiro é que um processo BPM pode não ser 100% mapeavel do BPM para o BPEL. Se vocês tem suas dúvidas confiram esses outros posts/artigos:
- Why BPEL is not the holy grail for BPM
- Eu odeio BPEL
- BPMN-BPEL round-tripping
- BPEL não é BPM e Vice-Versa!
- BPEL: Who Needs It Anyway?
- WS-BPEL FAQ
- What is the relationship between BPMN and WS-BPEL2.0?
- There is no direct relationship between BPMN and WS-BPEL 2.0. WS-BPEL is a standard from OASIS and the BPMN specification is currently an OMG standard for visual representation of Business processes.
Eles querem fazer o bom e velho lock-in e prender vocês ao ferramental deles, por sinal o IBM Modeler 6.0 nem implementar BPMN implementa, voltando a falar de BPEL, existem outros problemas sérios no uso de BPEL:
- Tudo é WebService, WDSL, XML, XPATH pra todo o lado
- Desenvolvimento pesado e complexo
- Problemas de performance e dimensionamento de máquinas
- Impossibilidade de forma portável de acessos mais leves
E o Pega Gerente?
Esse é o problema. Todo esse papo furado de gerar o BPEL pelo BPM é algo que os gerentes adoram, ou seja, uma solução mágica que com ferramentas vai eliminar, erros, descuidos, dar flexibilidade e até tirar o peso da responsabilidade das pessoas. É um mundo mágico que infelizmente não existe. Existe apoio dos gerentes por que as grandes empresas estão jogando nisso, mas o mercado não está comprando, a prova disso é esse gráfico:
Gráfico de tendências do site In DeedComo vocês podem ver o uso de BPM vem crescendo muito e assim como de forma menor a demande de BPEL mas ainda é grande, agora quando olhamos as duas coisas associadas que seria a linha verde vemos que isso é muito pequeno. BPEL pode ser usado mas tem que existir um cenário que justifique muito isso e de preferência com uma boa solução como o Apache ODE e usando o SOA Tools do eclipse que são ferramentas open source para BPEL.
Alternativas ao WS-BPEL
Alternativas ao WS-BPEL
Muitas vezes uma alternativa viável e simples é ao invés de fazer orquestração fazer roteamento de serviços, não resolve 100% dos casos, mas em alguns casos da no mesmo, isso pode ser feito com um bom ESB como o Apache Service Mix usando o Camel da Apache por exemplo.
Uma idéia que me agrada muito é, fazer orquestração de forma padronizada assim como no BPEL mas usando formas mais leves como interfaces java, ejbs, beans do Spring, apis REST, mas tudo isso de forma padronizada por alguma especificação. Mas nada indica que esse caminho ira surgir fora das extensões.
BPEL em DSL?
Essa seria uma coisa ótima, usar BPEL com schema XSD, xml e WSDL é algo muito ruim, muito pesado, que cria uma dependência muito forte com um ferramental se não é impossível faer algo que preste com o mínimo de produtividade.
Ouvi falar do SimPEL que seria um BPEL simplificado em forma de DSL, espero que isso vá para frente, confiram isso neste link: http://www.nabble.com/SimPEL-early-feedback-td19380187.html.
O SimPEL é muito novo, é do final de 2008, não sei se evoluiu muito, apareceu na lista de discussão de desenvolvimento do Apache ODE e está em passos de bebe, mas achei muito interessante e gostaria muito de ver as coisas evoluindo para esse lado, o SimPEL é algo tipo isso:
process HelloWorld {
receive(myPl, helloOp) { |msgIn|
msgOut = msgIn + \" World\";
reply(msgOut);
}
}
Como disse antes não sei se a iniciativa foi para frente, mas é algo muito legal. Mesmo com isso ainda não temos a tão sonhada cola do BPM com o BPEL e não vamos ter isso com ferramental nenhum, certas coisas ainda devem ser feitas da maneira antiga, com ferramentas sim, com pessoas e o bom e velho processo.
Abraços a até a próxima.
