BPMN
Versus ARIS, HIM, UML, notações proprietárias
Quanto à linguagem de execução de processos, os produtos recentes de BPM ostentaram muitas notações diferentes, com formas pequenas e cores extravagantes. Alguns eram muito centrados no workflow como HIM, outros mais orientados aos técnicos, como diagramas da atividade da UML, mas a maioria eram totalmente proprietários, incompletos, e incompatíveis uns com os outros. A BPMI.org reparou isto, mas desta vez aprendeu com seus de seus erros, se adiantou e certificou-se de que IBM estivesse envolvida o mais cedo possível no desenvolvimento do processo. Um cavalheiro, chamado Stephen White, fez sua mágica e desenvolveu a BPMN, que se estabeleceu rapidamente como a notação padrão para modelar processos executáveis do negócio. A BPMN suporta o orquestração de serviços web service e a execução de tarefas humanas do workflow, ao permitir coreografia de múltiplos processos de negócio através da metáfora da raias de uma piscina. BPM 2.0 funciona porque um pode ir da BPMN ao BPEL sem ter que escrever código. A BPMN não é perfeita e deve aprender um par dos truques do HIM, mas seu suporte para transações de compensação, eventos não solicitados, laços complexos, múltiplas raias de uma piscina é o que a faz original, eficaz e insubstituível.
Mas por que BPMN importa? Até agora, não houve nenhuma notação padrão para projetar processos do negócio. ARIS . o Brainchild do Dr. August-Wilhelm Scheer . é uma grande notação, mas é muito proprietária, que não permite ser suportada por nenhuma outra ferramenta que não IDS Scheer ARIS. Os diagramas da atividade de UML são simples, mas os analistas do negócio de algum modo não podem usá-los. Os fluxogramas são um tanto limitados para modelar processos, que não acomoda as exigências de uma arquitetura orientada serviço (SOA). Algo melhor era necessário, e por este motivo a BPMI.org desenvolveu BPMN um par dos anos atrás.
Ao contrário da BPML, a BPMN recebeu imediatamente o suporte de gigantes da indústria como IBM, que facilitaram o estabelecimento como um padrão. Também, ao contrário da BPML, não havia nenhuma competição real para BPMN.
Para ser justo, a BPMN não é perfeita ainda, e a versão 2.0 está adicionando muito pouco à versão 1.0. Um formato padrão de serialização é necessário (XMI não é o bastante), e a maneira com que a BPMN gera BPEL não está especificada inteiramente. Adicionando à complexidade, ninguém ainda sabe fazer o caminho inverso da BPEL para a BPMN, porque ainda não é nenhuma maneira de fazer isto. Tal problema é sabido também como BPMN-BPEL rodam, meu amigo Bruce Silver fez um trabalho descrevendo e depois de um grande artigo de John Deeb e de Devesh Sharma publicado pelo Business Integration Journal. As convenções deverão ser definidas, e eu estou disposto a apostar que um trajeto do padrão estará definido somente em 2007. Enquanto isto, fornecedores que suportam BPMN e BPEL terão que dar seu melhor acerto. O ruim é que poucos trabalham no problema hoje.
Mesmo que a BPMN necessite ainda mais trabalho, tem o mérito a existir, e não tem nada perto. É a primeira notação que eu vi que pode ser usada por analistas do negócio, por analistas de processos, e por engenheiros de software igualmente, sem muita ambiguidade que propicia a colaboração de seus esforços. É também uma destas notações muito raras que podem fornecer um trajeto desobstruído à execução, algo imprescindível para quem necessitar de um BPM que vai ale de desenhos de diagramas bonitos. A BPMN realmente importa e é uma das mais poderosas partes para possibilitar o BPM 2.0.
