Publicações arquivadas sob BPEL
Eu odeio o BPEL. Pronto. Falei.
Para quem trabalha com BPM, sempre existiram dois times: os que adoram o BPEL e os que odeiam. É como a rivalidade Inter X Grêmio aqui no Sul, não tem como ficar em cima do muro. E todo mundo sabe que o Inter é melhor que o Grêmio…..menos os gremistas, é claro J.
Na verdade, vamos dar “nome aos bois”: no mundo, quem levanta a bandeira BPEL sempre foi a Oracle, IBM, e talvez a SAP (a SAP tá mais pra Juventude, de Caxias, meio indefinida ainda, mas no fundo gremista). O Intalio também torce para esse time, bastante. Com exceção desse último, os demais gostam porque o BPEL é uma coisa de infra-estrutura, um padrão técnico, robusto, que executa milhões de vezes a mesma coisa e vem junto com o pacotão deles. E a ferramenta fica na mão da TI, que é o foco comercial do pessoal.
Quem não gosta de BPEL são os chamados pure-play BPMS: empresas menores que esses gigantes, que desenvolveram softwares mais colaborativos, que não executam BPEL mas que foram construídos sobre casos práticos de processos interativos de clientes. A gente se enquadra nesse segmento. Nos EUA existem algumas dezenas desses softwares, aqui no Brasil, uns dois ou três.
E por quê eu odeio o BPEL? Porque eu simplesmente não consigo fazer o que eu quero no BPEL, não consigo pegar o meu modelo de negócio e executar nele. Não consigo. E você também não consegue. Nesse momento alguém pode gritar: “Aahh mas eu fiz um curso de uma ferramenta que eu desenho em BPMN e executo em BPEL”. Não é bem assim. Para processos da vida real, existem dezenas de procedimentos técnicos que devem ser realizados antes do processo conseguir executar. Um exemplo está nesse artigo. O autor desenhou um processo (simples, diga-se de passagem) em BPMN e na hora de gerar o BPEL “gerou” um processo errado. Um processo diferente do que ele tinha feito antes. Não só visualmente diferente (isso é o de menos, seria pedir demais), mas logicamente diferente. E isso sim é grave. Mas é previsível também se pensarmos na diferença estrutural dos dois modelos: bloco-estruturado (BPEL) X grapho (BPMN). Simplesmente não combina.
Por sorte, está cada vez mais claro para as empresas e consultores essas limitações. A falta de casos de sucesso é mais um fator determinante. As próprias empresas que se limitavam ao BPEL, por exemplo, estão tentando buscar alternativas mais flexíveis. Tenho certeza de que estamos em um bom caminho e teremos boas novidades nos próximos meses.
21 de Novembro de 2008 às 14:25
Rafael Bortolini
“O padrão BPEL geralmente aplica-se melhor a processos centrados em INTEGRAÇÃO (processos que coordenam interações entre SISTEMAS ao invés de PESSOAS) pois isso está mais ligado ao intento original dessa linguagem.”
Tradução livre. Grifo nosso. Relatório “State of the Business Process Management Market 2008″, pág. 17, by Oracle Corporation - uma das empresas que mais defendem o BPEL como padrão global para o BPM
20 de Setembro de 2008 às 14:46
Rafael Bortolini
Você já ouviu - ou já falou - alguma das seguintes frases:
“- Tenho meus processos mapeados no Visio. O seu BPMS importa de lá para executá-los?”
“- Será muito simples. É só clicar em um botão no Aris e BUM!!, meus processos serão executados no BPMS”
“- Vai ser fácil o projeto. Ano passado uma consultoria mapeou os nossos processos, está 50% pronto.”
“- Não quero retrabalho. Não quero ter que desenhar de novo os meus processos só para automatizar”.
“- Quero uma ferramenta onde o usuário desenhe em BPMN e depois a TI só execute o BPEL gerado sem trabalho”
Eu ouço isso praticamente todo o dia. Essas questões, de um jeito ou de outro, refletem uma ansiedade comum em relação a existência do que chamo de “mito do elo perdido de processos”. Como venho da área de TI, que gosta de colocar siglas em tudo, vou chamar amistosamente de “MEPP“.
Assim como os evolucionistas procuram em vão a séculos o elo perdido entre os macacos e os homens, o MEPP representa a busca sem fundamento do elo direto entre o mapa do processo de negócio e a sua execução, ou o processo automatizado. Explico.
Mapear (desenhar) um processo é um meio, e não um fim. Isso está mais que provado e discutido. Antes de iniciar o desenho de um processo, ou mesmo uma iniciativa de processos, tenho que me perguntar: “OK, processos. Mas para quê quero processos? Qual é o objetivo do meu desenho, do meu mapeamento, da minha modelagem?”. Algumas respostas poderiam ser, entre outras:
- Para entender melhor como minha empresa funciona e descobrir gargalos;
- Para entender melhor porque esse processo leva tanto tempo e melhorá-lo;
- Para otimizar o fluxo de informações e pessoas envolvidas no processo;
- Para gerar uma documentação completa de modo que um funcionário novo seja facilmente treinado;
- Para obter a certificação X, Y ou Z;
- Para selecionar e customizar um ERP;
- Para automatizar em um BPMS;
- etc…
O fato é que, dependendo do objetivo selecionado, o analista de processos deve adaptar sua ferramenta - o mapa do processo - para um maior ou menor nível de detalhe. Dependendo do objetivo, determinadas interações deverão ser contempladas ou não. Você já se deparou com a questão “será que junto essas duas atividades em uma só no meu mapa” ou mesmo “o que representa uma atividade?”. A resposta para tudo sempre será: depende do seu objetivo.
Isso significa que o seu processo de compras, por exemplo, pode ser desenhado de 10 maneiras diferentes, e todas podem estar certas. Vai depender do objetivo. Arrisco dizer que, mesmo seguindo o mesmo objetivo, duas pessoas podem desenhá-lo diferente, e ainda assim as versões estarem corretas. Um dia vou fazer esse teste.
Vamos a um exemplo prático. Veja o fluxo abaixo:
Simples, não? Tão simples que nem precisa de explicação. Agora imagine utilizarmos o botão mágico para extraordinariamente automatizá-lo no BPMS, usando o conceito de MEPP. Sabe o que irá ocorrer? Isso:
1. Seu João, responsável pelo setor de entregas, recebe uma tarefa no BPMS dizendo pra ele pegar uma televisão 21 polegadas de código XY1234 no estoque;
2. Seu João pega a TV, volta ao computador e avisa ao BPMS que terminou a atividade;
3. Imediatamente o BPMS avisa seu João que agora ele deve imprimir e anexar a nota fiscal de transporte na caixa da TV;
4. Seu João, um cara obediente, faz exatamente o que o BPMS manda e depois de anexar a NF, orgulhosamente avisa o BPMS que concluiu no prazo a atividade;
5. O BPMS lembra Seu João que ele tem que levar a TV para dentro do caminhão;
6. Seu João coloca a TV dentro do caminhão e volta feliz ao computador, avisando ao BPMS que concluiu com sucesso a operação!
E isso ocorre para todos os produtos que a empresa vende em um dia.
Rídiculo, não? Apesar de o mapa do processo estar correto e coerente com o negócio, e talvez coerente com um objetivo de “entendimento ou treinamento no processo”, obviamente esse mapa não serve de nada para a automação. Parece simples vendo isso agora, mas muitas vezes no meio de um grande processo isso passa despercebido.
O problema é que, ao final, existem dezenas de incoerências como essa em um processo desenhado, e a ligação entre os dois modelos é exatamente o elo perdido, ou MEPP, dos processos - algo que nunca existiu.
Fornecedores vendem softwares com botões mágicos que transformam o “modelo de negócio” para o “modelo de automação”. Clientes não querem retrabalho de tirar o seu processo da ferramenta de mapeamento para a ferramenta de execução; querem que isso seja automático. Conhece a fábula da fome e da vontade de comer? Você acredita que exista software tão inteligente a ponto de automaticamente compreender a semântica do processo - ou seja, o que ele significa - e magicamente convertê-lo para um modelo executável? Não existe.
Por isso a pergunta “o BPMS importa meus processos do Visio ou do Aris?” na grande maioria das vezes é irrelevante frente a diferença semântica entre o processo originalmente desenhado e o processo a ser executado. A não ser, é claro, que o processo tenha sido, desde o princípio, desenhado para o fim de automação.
Então terei retrabalho de desenhar de novo, só que dessa vez diferente, os meus processos? Sim, terás. A questão é como você irá abordar isso. Em minhas experiências observei que esse é um trabalho 50% braçal, 30% seguir regras e 20% pensar. Cabe a você decidir se irá fazer isso por si mesmo ou irá passar para outra pessoa fazer - alguém que tenha mais tempo livre e custo (valor-hora) inferior ao seu.
11 de Agosto de 2008 às 00:57
Rafael Bortolini
Pesquisando SCRUM pela internet encontrei o blog Architecture Journal, que fala sobre arquitetura de sistemas com frameworks Java. Vale a pena ler o artigo “BPEL não é BPM e Vice-Versa”. Confira!
28 de Novembro de 2007 às 10:17
Rafael Bortolini
Um dos assuntos mais importantes em BPM, com certeza, é a integração entre o modelo de negócio do processo, desenhado por um analista, e o modelo de execução, gerenciado por um técnico. Para grande parte das plataformas e projetos hoje, é integração entre o desenho BPMN e a execução BPEL do processo. O fato é que, apesar do que vemos com grande destaque no mercado, essa integração não é nada, nada, nada simples e direta, dando origem ao conhecido problema de round-tripping.
O round-tripping consiste na possibilidade de manter sincronizado o desenho de negócio, feito em BPMN, e a aplicação de execução do processo, em BPEL. Consiste em poder alterar o modelo de negócio do processo e que essa mudança seja facilmente replicada para o sistema. E vice-versa também, ou seja, que a alteração de um processo que está sendo executado em um sistema seja automaticamente propagada para o modelo de negócio, ou BPMN (deixando assim a “documentação” sincronizada com o “sistema”). Qualquer semelhança com o problema de atualização dos modelos UML de uma aplicação em manutenção não é mera coincidência.
A boa notícia é que diversas ferramentas de mercado destacam que conseguem fazer esse processo de sincronização “nativamente”. A má notícia é que em muitos casos isso não é tão “nativo” e direto assim. Na prática, quero mostrar que esse round-tripping é um assunto extremamente complexo e que deve ser levado muito a sério.
Vamos a um exemplo prático. Meu analista de negócio mapeou o seguinte processo seguindo a notação BPMN:
É um processo simples. Após o início uma condição é avaliada e o processo segue para um lado ou para o outro. Se o valor do investimento for menos do que 10.000 será enviado para um assessor, se for maior do que 10.000, para aprovador verificar. Se for para o assessor e for de alto risco, ainda assim o aprovador será acionado.
O fato é que, ao passar esse simples fluxograma para o modelo BPEL, “emperramos” e não conseguimos representá-lo nessa linguagem. Esse fluxograma simplesmente não é compatível com o modelo BPEL.
A representação de um processo em BPMN segue um modelo de desenho livre, onde posso abrir diversos “braços” no desenho que, eventualmente, não serão sincronizados ou unidos ao final, serão simplesmente finalizados . Além disso, no BPMN tenho a liberdade de, estando em uma determinada atividade, ir para qualquer outra atividade, mesmo que seja uma anterior no desenho.
Já o BPEL possui um formato bloco-estruturado, onde todo o braço que é aberto precisa necessariamente ser fechado e onde não posso diretamente fazer coisas simples como representar a volta para um ponto passado do processo.
Assim, é conhecido que todo o processo em BPEL pode ser representado graficamente em BPMN, mas nem todo desenho BPMN pode ser representado em uma estrutura BPEL. Não diretamente.
No caso do nosso exemplo, acima veja como ele ficaria para se transformar em BPEL-compliance:
Sim, é isso mesmo, você não está vendo errado. Os dois fluxogramas representam o mesmo processo de negócio, a diferença é que este último foi adaptado para funcionar em uma ferramenta de execução em BPEL. Existem várias outras formas, entretanto, que poderíamos usar para representar esse mesmo processo para se ele ser compatível com BPEL.
Alguns ferramentas que usam BPMN e BPEL, para evitar ter que tratar com esse problema, simplesmente bloqueiam o desenho BPMN impedindo que o usuário monte processos que não sejam compatíveis. Veja o exemplo do desenho abaixo: quando tento criar uma conexão entre a última tarefa e a primeira tarefa, representando uma volta a um ponto passado do processo, o sistema me diz que “preciso colocar as tarefas dentro de um sub-processo em loop”, ou seja, devo utilizar um artifício de sub-processo para poder representar esse retorno. Chato não?
Assim, infelizmente, concluímos que muitos diagramas BPMN não são compatíveis com o modelo BPEL e tem que ser reescritos ou repensados antes de serem automatizados. Como fazer essa transformação? A primeira opção é transforma-se em um expert em BPMN e BPEL e gênio em lógica de processos para conseguir fazer essas adaptações. A segunda opção é verificar alguma das ferramentas de mercado que, de modo bastante discreto, dizem que conseguem fazer essa transformação diretamente . Os mais sérios inclusive divulgam: conseguimos converter automaticamente X% dos diagramas que você possui, os restantes Y% você terá que redesenhar. A terceira e última opção é avaliar muito bem os seus requisitos e verificar se você realmente precisa de BPEL.
De um modo ou de outro, a verdade que fica é que BPMN e BPEL foram criados por instituicões diferentes, grupos de empresas diferentes, em momentos diferentes. Então, essa integração que parece a primeira vista tão natural pode representar uma grande dor de cabeça se não for bem avaliada desde o início.
2 de Outubro de 2007 às 00:40
Rafael Bortolini
Pela segunda vez nos últimos 2 meses recebi uma RFP de prospect onde, no detalhamento de requisitos, estava escrito que a ferramenta de BPM escolhida deveria possuir obrigatoriamente ” recurso para mapeamento de processos em linguagem BPEL”.
Como vimos em posts anteriores, o BPEL não é um padrão para modelagem de processos, e sim um padrão para execução de processos. O BPEL não tem representação visual, com caixinhas e setas ligando os elementos, o BPEL é um arquivo XML com uma lógica e um padrão. Se a sua ferramenta de BPM possui uma editor gráfico para montagem de BPEL, isso é outra história: esse editor assim como a notação utilizada é uma interpretação do fabricante para o modelo BPEL. Outras ferramentas terão outra notação gráfica, a não ser que , enfim, esteja-se utilizando um padrão de mapeamento e desenho de verdade, como o BPMN.
Por isso, em última instância, se eu fosse capacitar alguém em modelagem de processos com BPEL, eu usuaria o bloco de notas e digitaria um monte de tag’s no arquivo XML.
A dúvida que fica é: de onde essas empresas tem tirado essa idéia de que o BPEL é tão mágico assim?
1 de Outubro de 2007 às 23:43
Rafael Bortolini
Em mais um post da nossa super série de artigos sobre padrões de processos, vamos falar sobre um dos mais importantes e talvez mais polêmico padrão, o BPEL. Para relembrar, já falamos sobre BPMN e sobre XPDL.
A sigla WS-BPEL significa “Business Process Execution Language”. Atenção, o “E” significa “Execution” e não “Entity” como já vi escrito em alguns editais e sites pela Internet. O BPEL foi criado originalmente pela Microsoft (sim, ela mesma) e pela IBM, com o apoio de empresas como SAP e Siebel, no ano de 2003. Na verdade, o BPEL vem de uma combinação de padrões mais antigos, criados por essas empresas.
Após sua criação, esse consórcio passou o controle do padrão para a organização OASIS.
Entrando em mais detalhes, o BPEL é um padrão técnico, em formato XML. Se eu fosse enviar o BPEL por e-mail para você, eu iria atachar um arquivo (talvez com extensão .xml) e você poderia abri-lo no bloco de notas. O BPEL não possui notação gráfica, ele não possui uma “cara”. Aquele desenho de fluxograma que você viu na apresentação do fornecedor de ferramenta de BPM era uma interpretação visual do próprio fornecedor, ou era BPMN.
O objetivo principal do BPEL é descrever um processo de negócio que interaja com Web Services, internos ou externos. Isso significa definir e criar uma série de regras de fluxogramas, como seqüências, paralelismos, condicionais, loops, etc, para a execução de diversos Web Services em seqüência. Uma ferramenta de BPM que use o padrão BPEL por sua vez deve ser capaz de criar o modelo do fluxograma em BPEL e também de executá-lo, isso é, ler as regras definidas, executar as regras de negócio e invocar os Web Services (apesar de alguns fornecedores, como Microsoft, por exemplo, utilizarem o BPEL somente para importação e exportação de regras de fluxos para seus sistemas, similar ao XPDL).
Uma crítica antiga ao BPEL é que ele desconsidera um fator importante dos processos, que são as pessoas. No modelo básico, não existe um elemento ou regra que descreva uma tarefa que necessita a aprovação do diretor financeiro da empresa. Por outro lado, a maioria dos fornecedores já resolveu isso criando serviços (Web Services) de “notificação de pessoas”, que você acopla ao BPM. O problema vai ser quando for necessário usar o BPEL de uma ferramenta em outra…
Assim, talvez a maior questão envolvendo o BPEL, hoje, seja a relacionada a Web Services. O BPEL trabalha somente com Web Services. Se você não tem Web Services em seus sistemas, então terás problemas. Arquivos texto, tabelas de banco de dados, ftp, nada disso será possível usar sem programar Web Services antes.
Como conclusão, algumas opiniões próprias: o BPEL é muito legal mas hoje em dia me parece que sua importância está mais relacionada a divulgação por grandes fornecedores (Oracle, SAP, IBM…) do que a grandes cases de sucesso. A maioria absoluta das empresas não precisam ou não tem condições de usar BPEL hoje, e grande parte dos programas de BPEL que vemos são implementações mais complexas de processos de Workflow. O BPEL, hoje, me parece mais um padrão de integração de sistemas do que um padrão que poderia ser amplamente usado para montar processos de negócio das empresas.
27 de Agosto de 2007 às 10:25
Rafael Bortolini