O crescimento da importância das tecnologias de processos, aliado a um maior número de fornecedores e maior complexidade das demandas de grandes clientes impulsionaram nos últimos anos a criação de diversos padrões técnicos para esta indústria. Estes padrões visam, sobretudo, normalizar as soluções desenvolvidas contribuindo para interoperabilidade e comunicação entre diferentes plataformas de processos.
Como veremos ao longo deste artigo, os esforços realizados até agora sintetizam-se na necessidade de descrever um processo de negócio em um formato padronizado e inteligível tanto por analistas de processos quanto por sistemas. Este nobre objetivo, entretanto, não foi alcançado de maneira ampla por nenhuma especificação criada até agora, dada a complexidade da matéria. Além disso, o surgimento de diversas especificações diferentes, desenvolvidas por institutos e empresas diferentes, tem gerado uma grande confusão no mercado e dúvidas constantes sobre qual ou quais padrões adotar, e qual a aplicabilidade e uso de cada padrão.
XPDL
Talvez um dos padrões mais antigos do mercado, encontra-se atualmente em sua versão 2.0 e é capitaneado pela WfMC (Workflow Management Coalition), uma associação internacional de mais de 300 membros associados que vem promovendo o segmento de Workflow desde 1993.
Bruce Silver, renomado analista independente de softwares de BPM, em seu artigo intitulado "BPMS Watch: Is Visio Your Next BPMS Design Tool?", nos provê uma prévia da importância ainda atual do XPDL: "mesmo que os analistas do setor nunca comentem sobre isso, o XPDL é atualmente o padrão de muitas mais ferramentas de BPM do que a especificação BPEL." De fato, a história de sucesso da WfMC e os anos de desenvolvimento da especificação fizeram com que fosse adotado em diversas plataformas de processos ao longo dos anos. Isso é um ponto bastante positivo na medida em que a adoção de um padrão vem em grande parte da necessidade de comunicação entre diferentes sistemas, e a utilização de XPDL significa a certeza da existência de cases (de sucesso), base instalada e extensa documentação.
Em termos técnicos, o XPDL é um padrão XML de descrição de regras de processos de negócios. Sua especificação, um tanto simplificada em comparação aos próximos padrões que iremos analisar, baseia-se na descrição de um conjunto de "atividades" relacionadas entre si através de "transições". Para a WfMC, "atividade" significa uma unidade de trabalho que será processada por um recurso (um participante/usuário/ator) e/ou uma aplicação computacional.
O XPDL possui alguns conceitos interessantes que as demais especificações ainda não exploraram ou preferiram não desenvolver. Entre eles, destacam-se as idéias relacionadas a tarefas eminentemente humanas. Dada sua origem em Workflow e GED, o XPDL provê formas concretas de especificar regras relacionadas ao envio de tarefas para participantes definidos de maneira dinâmica ou estática. Ao contrário do BPEL, por exemplo, o XPDL contempla a análise da estrutura organizacional da empresa para determinar o ator de uma determinada tarefa.
Em termos práticos, a maior parte das soluções disponíveis no mercado utiliza o XPDL como um instrumento de intercâmbio de regras de processos, utilizando sistemas próprios de importação/exportação de especificações. Isso significa, por exemplo, desenhar e configurar um processo em uma ferramenta, exportá-lo para o padrão XPDL, e importá-lo para utilização em outra engine/ferramenta.
O XPDL 2.0, última versão da especificação, é totalmente compatível com outro padrão, o BPMN. Para os criadores do XPDL, o BPMN é o padrão ideal para modelar o processo em nível visual e o XPDL para definir suas regras em nível técnico.
Partimos então para o lado ruim da história, e história é principal problema do XPDL. Seu meta-modelo, ou seja, seu conjunto de estruturas que determinam sua especificação, está bastante ultrapassado. Os grandes esforços realizados para aproximar o XPDL dos conceitos e usos de WebServices não foram nem serão suficientes pois, como veremos adiante, os demais modelos surgiram justamente a partir do conceito de WebServices. Estamos falando aqui de um outro paradigma e, conseqüentemente, outro tipo de meta-modelo. O XPDL peca ao não compreender a arquitetura de modernos sistemas de processos atuais baseados em conjunto de serviços, SOA e EAI.
Em conversa com Mike Marin, um dos criados do XPDL 2.0, em setembro de 2005, ele me mostrou sua preocupação com a desatualização do meta-modelo e a necessidade eminente de criação de um novo paradigma para o XPDL. Mesmo ciente do grande trabalho que essa tarefa significa, a idéia da WfMC é que isso comece a ser trabalhado a partir de 2006.
BPML
A falta de uma estratégia de atualização da arquitetura do XPDL estimulou o nascimento de uma nova organização no ínicio desde novo século. Membros e dissidentes da WfMC uniram-se sob o guarda-chuva de uma nova instituição denominada BPMI.org (Business Process Management Initiative). O objetivo seria gerar uma nova e atualizada especificação para descrever processos de negócios.
A esse esforço de trabalho deu-se origem, em 2002, ao BPML (Business Process Modeling Language). Lançado com grande pompa e altos investimentos em marketing, o BPML contou inicialmente com o apoio de grandes empresas como a SAP.
Assim como o XPDL, a especificação BPML utiliza o padrão XML para descrever seus processos. As comparações terminam por aqui. O BPML, em sua tentativa de prover uma arquitetura para o futuro, distancia-se totalmente do XPDL criando um paradigma próprio e distante para si. Na época de seu lançamento, os fornecedores e analistas acostumados com o XPDL e ansiosos para ver o BPML ficaram bastante surpresos ao encontrar um ambiente totalmente inóspito onde os principais conceitos do XPDL foram esquecidos e ignorados - inclusive algumas inovações da WfMC consideradas muito boas.
Basicamente, o BPML ganha méritos por consolidar a idéia de orquestração de processos em um nível totalmente genérico. Isso significa um padrão baseada em WebServices onde as minúcias de cada tarefa do processo simplesmente não interessam para a especificação, que trata basicamente da relação entre chamadas, respostas e mensagens entre serviços na Web. Para ilustrar o que isso significa na prática, temos um exemplo de fácil entendimento: toda a especificação de "roles" e controle dinâmico/estático de atores de uma tarefa (quem vai fazer a tarefa) não existe no BPML. Aliás, o conceito de tarefa humana também não existe no BPML. Isso não significa que todas as tarefas no BPML são computacionais (sob a ótica da WfMC), mas sim que esse tipo de detalhamento não interessa para a especificação; todas as tarefas são serviços, e se o serviço vai alocar uma pessoa ou uma máquina para realizar a tarefa não é importante no momento.
Para surpresa de todos, o BPML, com este novo paradigma, não era capaz de superar o XPDL. O que deveria ser uma evolução acabou se tornando uma especificação diferente, com outro escopo e outro objetivo. Para piorar a situação, a maior parte das empresas simplesmente não conseguiu ver aplicação prática no BPML, muito distante da realidade de qualquer organização.
Hoje, o BPML está morto. É incrível como o marketing em torno dessa tecnologia foi forte: a especificação não é mais atualizada, não existem cases de sucesso, não existem ferramentas explorando a tecnologia, mas ainda assim alguns estudiosos do setor e fornecedores insistem em vinculá-la como "um dos padrões de BPM". Até mesmo a SAP, que ajudou a elaborá-lo, comunicou oficialmente que estava abandonando este padrão. Por isso, uma ferramenta que diga seguir os padrões técnicos de definição de processos da BPMI não é uma ferramenta de BPM e sim um sonho que não virou realidade. É engraçado quando aqui em nosso escritório recebemos convites para participar de "cursos de BPML, a linguagem de processos".
BPEL
O que não deixei claro ainda é o motivo real pelo sepultamento da especificação BPML. Não se deveu, necessariamente, pela falta de aplicação prática da especificação. O principal motivo chama-se BPEL.
Paralelamente as discussões XPDL x BPML, as empresas Microsoft, IBM, Siebel, BEA e SAP resolveram se unir e propor (ou impor) um novo modelo, mais completo e universal, denominado BPEL (Business Process Execution Language). O BPEL surgiu da união de outros padrões, mais especificamente o XLANG da Microsoft e o WSFL da IBM. Depois de concluído seu meta-modelo e especificação inicial, passaram o controle do padrão para a organização internacional Oasis
. Rapidamente, esta nova especificação começou a chamar a atenção dos principais players do mercado de gestão de processos. Amparado pelas grandes empresas de TI do mundo, ficou claro para muitos que o BPEL seria o padrão mais largamente aceito em curto espaço de tempo. Muito similar ao BPML, ao lançamento do BPEL seguiu-se uma enxurrada de anúncios de grandes corporações avisando que abandonariam o padrão BPML e passariam a adotar essa nova especificação.
Tecnicamente, como os demais modelos que estudamos, o BPEL é uma especificação em formato XML para definir as regras de negócio de um processo. Ao contrário do XPDL e similarmente ao BPML, o BPEL é totalmente compatível e criado a partir da especificação de WebServices, consistindo em um sistema de orquestração de uma rede de serviços na WEB.
Vislumbrando um futuro seguro para o BPEL, a start up norte-americana Collaxa foi uma das pioneiras a lançar uma engine de execução de processos em BPEL. O sistema incluiu uma ferramenta de modelagem, execução e monitoramento de processos de negócios. Em 2004, a Oracle, que até o momento era a única das grandes empresas de TI fora da especificação BPEL, comprou a Collaxa e integrou o produto a seu portfólio de soluções.
Como ponto essencialmente negativo, está também o fato de sua pouca aplicação prática. Não me refiro a falta de casos de utilização, e sim a que poucas organizações têm, hoje, uma infra-estrutura de serviços capaz de suportar uma arquitetura BPEL em toda sua plenitude. Assim como o BPML, o BPEL não possui uma diferenciação para tarefas humanas (o que é plenamente explicável pelo paradigma que adota, mas um ponto que torna sua utilização ainda mais complexa).
Atualmente, a utilização do BPEL passa por dois paradigmas: a das empresas que consideram o BPEL uma linguagem de programação e execução de processos (como a Oracle e IBM) e as que consideram o BPEL uma interface de comunicação e importação/exportação de regras de processos (como a Microsoft). Neste último caso temos como exemplo concreto o Biz Talk Server da Microsoft, solução para integração de sistemas e processos que pode exportar suas regras de negócio para o modelo BPEL.
BPMN
Ao contrário das especificações anteriores, o BPMN (Business Process Management Notation) é uma especificação para modelagem visual de processos. Seu objetivo é prover uma interface simples e poderosa que possa ser tanto utilizada por analistas de negócios quanto por analistas de sistemas, funcionamento como um contrato entre as partes.
O BPMN tal como o conhecemos hoje é sustentado e definido pela BPMI.org. Com o perda da especificação BPML, o BPMN tornou-se o único ponto de sustentação desta entidade, recentemente integrada a OMG.
De todos os padrões que hoje perfazem a área de gestão de processos, o BPMN parece ser a única unanimidade: é apoiado por todos os grandes players e não possui nenhuma outra especificação concorrente.
Na prática, o BPMN consiste em uma série de padrões de representação gráfica e de lógica no desenho de processos. Já existem diversos ferramentas de desenhos de fluxos que incorporaram o padrão BPMN e, devido a sua simplicidade, ele tem todas as condições de no futuro ser utilizado pelos usuários finais.
Para onde vamos?
As conclusões deste artigo parecem claras analisando-se o histórico e movimentos de players neste mercado: na mesma medida em que o SOA vai ganhando terreno nas organizações, o BPEL vai se transformando na principal especificação técnica de processos, e o BPMN a opção ideal para o desenho de fluxos.
O que não é possível prever é quanto tempo isso vai levar para acontecer, pois o BPEL parece ser mais capaz de resolver os problemas do futuro do que os problemas do presente. E, até lá, temos um grande gap que alguém precisa resolver.
Como observador, parece-me cada vez mais claro que uma aproximação ou futura integração do XPDL dentro do BPEL, como um sub-padrão, poderia resolver demandas atuais e deixar a infra-estrutura preparada para o que vier nos próximos anos. Nessa visão, o BPEL seria a especificação das regras de BPM, e o XPDL das regras de Workflow (que, como sabemos, é um dos componentes de uma estrutura de BPM).
