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

No final rolou uma rodada de perguntas, onde foram questionados assuntos como BDD, programação defensiva, contract by domain, dentre outras metodologias e padrões. Nesse ponto da apresentação, a maioria das pessoas que estavam presentes ficaram meio perdidas com as milhares de buzzwords associadas com as perguntas que foram feitas. O pessoal mais antigo ficou mais perdido ainda e até brincaram sobre a questão do “estamos ficando velho”.

Paralelamente a isso, começei a ler essa semana um livro do Tadeu Cruz sobre BPM e BPMS, onde no primeiro capítulo ele fala sobre a questão da desorganização informacional, muitas vezes causadas pelo excesso de informação e as novas ondas de TI que surgem a todo momento. Outra coisa que o autor do livro cita e crítica é que existem muitos casos de determinadas organizações, que forçam o uso de determinado software sem obter o real benenfício que esse software deveria oferecer, na maioria dos casos, por questões comerciais ou de interesse próprio dessas organizações. Questões como: para que determinada tecnologia foi criada, como deveria ser corretamente usada, como efetivamente está sendo usada, quais deveriam ser os resultados esperados do seu uso e quais são os resultados que estão sendo obtidos com sua utilização, orientariam de forma efetiva o profissional ou a organização com o intuito de medir se a adoção de determinada tecnologia está realmente sendo benéfica. Esse tipo de situação tem ocorrido muito com BPM, que é o novo hype do momento tratando-se de TI.

O que as duas histórias tem em comum e onde estou querendo chegar?

O que eu quero dizer é o seguinte: até onde vale apena conhecer N conceitos diferentes e até onde não vale a pena? Nos casos citados acima tem um pouco das duas coisas, bem como suas respostas. No caso específico do TDD, deveríamos considerar que o melhor a ser feito seria debater sobre as buzzwords que o assunto levantou, ou o melhor seria não conhecer muitos desses novos padrões e metodologias? Eu fico com a primeira opção, mas a segunda opção pode contradizer a primeira. Explico logo abaixo.

Vale a pena usar TDD e BDD em um projeto sem conhecer seus benefícios, o resultado a ser esperado e os possíveis obstáculos a serem vencidos? Não. Pois nesse caso tudo de positivo que TDD traria sendo usada da forma correta, traria inversamente em dobro no caso do seu mal uso, pois nesse caso o projeto acabaria tendo novos percalços (além dos já conhecidos), como: prazos atrasados, código mal estruturado, equipe perdida e etc. E isso acontece em larga escala em TI, não apenas no caso específico do TDD, já que o mais se vê são empresas gastando milhões em “soluções” de TI (CRM, ERP, BI, etc) – muitas vezes empurradas pelos ótimos vendedores dos grandes players do mercado – sem obter benefício algum sobre aquilo (ou até mesmo desconhecendo o porquê do seu uso). Na verdade muito pelo contrário, pois como muito desses processos são feitos sem estruturação alguma e demoram meses, anos… no final das contas a dor de cabeça e o custo envolvido não atingem nem de perto o custo x benefício esperado sobre aquele investimento.

Outro fênomeno interessante a ser observado e que de certa maneira ligam as duas histórias é a infobia. Infobia é uma palavra que o Tadeu Cruz usa para definir o medo por informação, ou seja, em determinado momento, com a enxurrada de tantas buzzwords, as pessoas acabam ficando reativas em absorver novas tecnologias e entender o seu significado, com isso de certa forma ficam estagnadas, pois deixam de absorver novos conhecimentos. Mas em compensação não adianta em nada conhecer várias palavrinhas mágicas superficialmente só para dizer que “domina” aquela tecnologia do momento. Por isso, acredito que dependendo do contexto, é válido ou não conhecer uma nova tecnologia. Esta aí mais um caso do paradoxo de TI. De certa forma, mas sem generalizar, a infobia consegue explicar a frase “estamos ficando velho”.

Devemos considerar que TI não irá salvar o mundo, TI pode ajudar de forma efetiva qualquer negócio de qualquer natureza, desde que seja aplicada da forma correta, e aplicar de forma correta envolve antes de mais nada: estruturação, disciplina, educação, mudança e planejamento. Ao mesmo tempo que sabemos de diversos casos onde TI trouxe um real benefício as organizações, sabemos de tantos outros onde TI acabou com negócios, projetos e sonhos. A bolha da internet talvez seja o melhor exemplo que ilustra essa situação das ondas de TI.

Muitas vezes as ondas de TI trazem a tona novas tecnologias que surgem apenas com o objetivo de remediar uma tecnologia já existente. O que as vezes é considerado como inovação, nada mais é que uma evolução de algo que tenha tido insucesso no passado, dessa forma uma tecnologia X surge apenas com o intuito de servir como “curativo” da tecnologia Y, que prometeu maravilhas e na verdade devido ao seu mal uso (ou não) só trouxe dores de cabeça.