Existe SOA sem BPM?
Recentemente fiz uma apresentação sobre BPM na empresa onde eu trabalho e o meu foco foi explicar o que são processos de negócio, o que é BPM e para que serve, quais são seus benefícios, além de mostrar todo o suporte que BPM dá para uma organização migrar e utilizar SOA, que é exatamente sobre o que eu vou falar neste tópico.
BPM pode muito bem existir sem SOA, já que BPM é uma modalidade que foca na aplicação de práticas e conceitos para melhoria e absorção de processos de negócios por parte de uma organização, mas e SOA, pode existir sem BPM?
SOA é um modelo arquitetural de construção de software que possui alguns pilares, dentre eles:
- Interoperabilidade
- Flexibilidade e agilidade a mudanças
- Alinhamento entre TI e negócio
- Redução de custos
- Exposição no formato de serviços das principais atividades/operações da empresa
- Reutilização e re-aproveitamento
- Baixo acoplamento
Dentre os pilares citados acima, é fácil perceber que SOA gera valores semelhantes ao que aplicação adequada de uma solução BPM geraria, entretanto BPM não é uma maneira de se construir software, BPM está muito além disso, está no topo, mas deve atuar lado-a-lado a SOA para produzir resultados mais duráveis, que gerem mais valor ao negócio, que sejam mais fáceis de manterem e de darem manutenção. E o somatório disso tudo proporciona resultados mais efetivos.
Certa vez li uma analogia sobre uso de SOA sem BPM e que de certa forma ajuda a esclarecer a importância da aplicação de BPM junto a SOA. Era mais ou menos assim: “Usar SOA sem BPM seria como um malabarista com uma mão atada atrás das costas. Ele poderia ainda fazer alguns malabarismos, mas não seria tão eficaz e nem tão rápido como poderia ser”.
E na prática como BPM complementa SOA?
Um dos pilares citados em uma arquitetura SOA é a possibilidade do alinhamento entre TI e negócio, e BPM ajudaria isso de forma efetiva através de uma notação para mapeamento de processos, no caso BPMN. Existe forma mais efetiva do que representar ações no formato de desenhos e diagramas? Dessa forma analistas de negócio e analistas de processos conseguem trabalhar juntos com times de TI na implantação e implementação de uma arquitetura SOA, onde através do mapeamento dos processos de negócio, conseguiriam identificar serviços que agreguem e tenham importância para o negócio de uma organização, identificando assim a necessidade de implementá-los.
Em relação a possibilidade de mudanças, BPM oferece todo suporte e facilidade para mudanças através da visão holística que o mapeamento de um processo de negócio proporciona, dando a possibilidade de visualização de papéis, atividades, setores, departamentos e parceiros de uma organização, ou seja, todos os stakeholders, além do conhecimento de todo fluxo da informação.
Do ponto de vista da automatização de processos de negócio, através dos softwares BPMS, BPM oferece adaptadores e conectores para realizar a integração entre sistemas legados através da exposição de serviços e atuando na composição e orquestração desses serviços, BPM proporciona uma “API visual” de toda as integrações e uma facilidade maior de manutenção e mudança.
BPM no topo de uma arquitetura SOA
BPM deve atuar no topo de uma arquitetura orientada a serviços, pois uma arquitetura SOA deve focar de ponta-a-ponta no negócio, e dessa forma BPM atuaria do ínicio ao fim em uma arquitetura SOA.
BPM proporciona o melhor uso de serviços de negócio oferecidos por SOA gerenciando a relação entre eles sob o ponto de vista de processos de negócio.
BPM ajuda na Governança de SOA
Numa arquitetura SOA, consumidores e fornecedores de serviço são executados em diferentes processos de negócio, são desenvolvidos e gerenciados por diferentes departamentos e exigem um grande número de coordenação para trabalhar juntos com sucesso.
Para SOA ter êxito, múltiplas aplicações precisam compartilhar serviços comuns, o que significa que eles precisam ser coordenados para tornarem estes serviços comuns e reutilizáveis (olha o BPM aí!). Estes são os problemas de governança e eles são muito mais complexos do que problemas de aplicações monolíticas ou mesmo problemas de componentes e códigos reutilizáveis.
Exemplo real
Fiz um rascunho simples de uma arquitetura em camadas que utiliza BPM, SOA e BPEL e que estará exemplificada logo abaixo. O processo é para um banco e o intuito é fornecer o empréstimo de uma quantia em dinheiro para um cliente, que no caso é quem faz essa solicitação. Tudo começa e termina no BPM, que atua como um orquestrador de serviços.
Nesse exemplo temos serviços em um nível mais baixo, que no caso são serviços expostos por sistemas de terceiros, módulos de ERP, CRM, etc. Temos nível intermediário com um processo de negócio BPEL que faz a composição de alguns serviços presentes no nível mais baixo e no topo de tudo temos o BPM orquestrando todos os serviços e controlando todo o processo.
clique para ampliar
Para finalizar, é importante ressaltar que através do uso de BPM e de BPMS, é possível definir métricas e indicadores, comos os KPI’s (Key Performance Indicators) e utilizar ferramentas que dão todo suporte para acompanhamento de nossos processos de negócio, como as ferramentas de BAM, onde o intuito seria fornecer relatórios em tempo real que podem servir como caráter estratégico e para tomadas de decisão, além também da possibilidade de usar as informações geradas para alimentar ferramentas de BI (Business Inteligence) e consequentemente obter resultados mais completos para a organização.
Se você gostou desse tópico, por favor considere deixar um comentário ou se inscreva no feed e tenha no futuro todos os tópicos entregues diretamente no seu agregador.
Muito bom o post.
Acho que uma das dificuldades seria determinar o que exatamente seria tratado usando BPM e o que seria executado usando BPEL. Voce definiu que BPEL no seu exemplo seria usado para operações de baixo nivel. Mas esse conceito eu acho um pouco vago.
É claro que no mundo ideal tudo é mais simples mas no mundo real acho que BPM e BPEL ainda são muito confundidos como ferramenta porque na hora de executar tarefas conseguimos o mesmo resultado com ambos. De qualquer forma não podemos esquequer que cada ferramente tem um proposito.
Só complementando sobre esse aspecto de BPM e BPEL. Se considerarmos que o uso de BPM nao traria um simples alinhamento entre TI e negocios e sim uma transparencia na implementação de negocios usando BPM, podemos ver que de certa forma o BPEL fica no meio do caminho.
Baixo nivel? Eu fico com Java.. e muitas outras pessoas também.
http://blog.lombardicto.com/2006/03/more_bpmn_vs_bp.html
Quote: “BPEL is expressive, it just is too little, too late. Stick with Java and C# for the short-term, and move to a truly services-oriented representation strategically. This will result in the quickest move to the next-gen architecture, and the lowest cost, most scalable implementations in the short run. “
BPEL tem o propósito de processos de negócio assim como BPM, a diferença é que BPEL é focado na questão técnica enquanto BPM é mais voltado para pessoas.
No exemplo eu usei BPEL para um processo de negócio, mas que só envolvia questões técnicas (serviços) e BPM ficou em um nível mais acima, por envolver pessoas, setores, departamentos, etc..
Complementando… BPEL não e baixo nivel, é nivel intermediário, focado também no negócio, mas eu concordo que BPEL tem alguns aspectos técnicos que deixam um pouco a desejar, mas no meu modo de ver a comparação com Java não é válida, pois Java (puramente códigos) não te dá uma visão de negócios como um processo BPEL te daria e esse é o seu intuito, BPEL é aproximar o ponto de visto técnico com o ponto de vista de negócio.
Java te daria a possibilidade de um analista mapear todo um processo para TI implementar? Acho difícil…
Concordo quando voce diz que BPEL é nivel intermediário.. eu disse baixo mas na verdade não é.
Só não vejo porque ficar no meio do caminho. BPEL não tras os beneficios do BPM na questão de visualização dos negócios nem na implementação.
Porque nao Java JPD? http://en.wikipedia.org/wiki/JPD
É melhor manter uma parte tecnica(sim, código) sem BPEL e tentar introduzir o BPM efetivamente do que perder tempo e dinheiro com BPEL.
Se é pra ter alguem técnico na equipe, prefiro que essa pessoa seja mais efetiva com codigo (pode ser anotado com JPD para dar a visualização gráfica do processo de negocio) do que ocupa-la com BPEL.
Na hora de mapear os processos de negocio realmente importantes(macros) usamos o BPM.
BPEL é totalmente compatível e criado a partir da especificação de WebServices e é voltado para Webservices e isso não pode ser esquecido (o que se enquadra na questão de SOA) enquanto JPD apesar de certa forma dar uma visão de processos é uma visão totalmente técnica, totalmente voltada para TI e não para o negócio, BPEL é mais human-readable.
Não vamos confudir as coisas, BPEL serve para orquestração e coreografia de Webservices, ou seja, é fazer com que cenários complexos de negócios sejam convertidos para um formato mais amigável de ser entendido e modelado.
Sem contar outras questões que BPEL te oferece como ferramentas para acompanhamento, controle e execução dos processos.
Felipe, para complementar, aconselho essa leitura:
http://architecture-journal.blogspot.com/2007/07/bpel-no-bpm.html
O WLI também. E é Java puro. Tem controle, monitoramentoe é human-readable.
Java assim como Python são totalmente compativeis com webservices WS-*, SOAP etc..
O meu questionamento não é com relação ao papel do BPEL e sim com a sua adoção.
Simplesmente não vale a pena..
Você acha o WLI human-readable? Já tentou mostrar para alguém não técnico?
A questão é que BPEL tem o seu propósito, que é composição de serviços, se vale a pena ou não, acho que depende da situação, é discutível.
Se considerarmos BPEL puro.. não é human readable também.
ESBs fazem composição também.. mas fazem muito mais do que isso..
Se BPEL serve na pratica so pra compor (coreografar e orquestrar) continuo achando q não vale a pena
Travel.wsdl
http://localhost:9700/orabpel/default/Employee/Employee?wsdl
http://localhost:9700/orabpel/default/AmericanAirline/AmericanAirline?wsdl
http://localhost:9700/orabpel/default/DeltaAirline/DeltaAirline?wsdl
Mas aí a gente volta na questão anterior.
O propósito de um service bus é outro, é fazer roteamento, transformação, mapeamento e também composição de serviços, mas não da mesma maneira que BPEL se propões fazer (aí entra questão de human-readable, e etc). O propósito principal de um service bus é catalogar servicos e permitir a integração entre eles em um paradigma baseado em mensagens.
BPEL possui por exemplo muitos mais recursos para implementação de regras de negócios complexas. Já um ESB é mais focado em integrações e não em modelagem como BPEL.
BPEL e ESB podem ser usados juntos, não é só pq vc usa um que não deva usar o outro, mais uma vez, o propósito de ambos são diferentes.
Veja bem, não estou defendendo BPEL, apenas estou dizendo que ele tem o seu propósito. Agora se ele pode ser substituído ou não, ou até se pode ser esquecido, aí é outro assunto.