BPM e SOA

Como já dizia o sábio: "Uma coisa é uma coisa. Outra coisa é outra coisa."

Fico imaginando quais foram as razões que levaram os dois temas a serem discutidos com tanta dependência um ao outro. Ou se quiser, com tal "nível de acoplamento". ;)

Talvez uma razão para isso é que as Suites de Produtos SOA de mercado possuem nativamente recursos também para BPM. Seja um motor de execução BPEL ("Business Process Execution Language"), monitoração de processos, ou qualquer outra funcionalidade específica. Aí a confusão já está pronta: como temos o mesmo produto sendo usado para os dois momentos, então um projeto SOA deve possuir, inerentemente, BPM.

SOA tem a ver com Serviços e Funcionalidades de Negócio. BPM ("Business Process Management") tem a ver com Processos de Negócios. Um nível de abstração acima dos Serviços. Um exemplo: em uma instituição financeira, é muito razoável imaginarmos "Análise de Crédito" como um dos seus Serviços de Negócio (a propósito, este tema é suficiente complexo para necessitarmos de conhecimentos específicos dos Analistas de Negócio para a sua elaboração). Agora, é fácil imaginar também que vários Processos de Negócios farão uso deste Serviço. Um exemplo de um processo de empréstimo bancário é exibido abaixo. Note que há referência não somente ao Serviço "Obtain Credit Score" como a diversos outros.


A questão é que os Processos de Negócio possuem uma complexidade específica e, por conta disso, deveriam ter o seu desenvolvimento conduzidos distintamente. Melhor seria um projeto próprio. Afinal, tipicamente, em relação aos Serviços de Negócio do projeto SOA, os Processos de Negócio possuem:

• Requerimentos diferentes.
• Modelagem, desenho, monitoração, implementação, execução diferentes.
• Tecnologias e produtos (eventualmente) diferentes.
• Usuários finais diferentes.
• Equipes de implementação (eventualmente) diferentes.
• Agendas e orçamentos diferentes

Por tudo isso, não vejo razão para termos, em um único projeto, SOA (com nível de complexidade não desprezível) e BPM (com complexidade igualmente importante). Se tomarmos a nossa estrutura de Arquitetura Orientada a Serviços, o ideal seria:

Custos e riscos, de ambos os projetos, dramaticamente reduzidos. Note que no meu "post" sobre a "estrutura", eu comentei que a Camada de Serviços, e só ela, é que é o resultado do projeto SOA. A Camada de Processos é resultado do projeto BPM. O analista JP Morgenthal, autor de "Enterprise Information Integration", escreveu em seu "blog" um artigo chamado "Keep Your SOA and BPM Initiatives Separate" que resume muito bem a questão. Em 21/10/2009, JP Morgental deu uma entrevista a respeito do tema.

De uma outra perspectiva, podemos considerar que uma Arquitetura Orientada a Serviços é construída para atender e ser consumida por uma infinidade de clientes. Processos de Negócio em um projeto BPM simplesmente são mais um dentre estes consumidores de Serviços de Negócio. BPM não é (e não deveria ser) a razão para a implementação de SOA. Claro que SOA ajudaria imensamente na materialização dos Processos de Negócio, mas é plenamente possível termos um projeto BPM sem a existência de SOA. Da mesma forma, empresas que implementaram SOA talvez nunca tenham a necessidade de projetos BPM.

Em outras palavras: o ciclo de vida de um Serviço de Negócio deveria ser independente do ciclo de vida dos Processos de Negócio. Incluindo especificações, desenhos, implementações, etc.
Em termos tecnológicos e Arquitetura de Software também há vantagens nesta abordagem. Decisões como produtos e ambientes operacionais para cada projeto podem ser tomadas isoladamente, reduzindo novamente os riscos.