As frases são tiradas de um contexto específico, mas podem tranquilamente ser usadas de maneira isolada para reflexão, aprendizado e até para fixar uma idéia.

Nessa “primeira edição”, vou me ater a frases que envolvam SOA e BPM.

Eis as frases:

“The first of those milestones has come to pass: process is not simply the way business operates itself, but manages itself.”
Phil Gilbert

“It’s been said, “If you can’t measure it, you can’t manage it.” It’s also been said, “Opinions are like a*******, everybody’s got one.” The ability to manage by fact (measurement), rather than opinion, is what sets the rare professional manager from the masses of loudmouth, intimidating, egotists who’ve been given the title Manager. Leaders, on the other hand, earn that title. And one of the most effective ways of earning that title is to learn to mange objectively, not subjectively. Objective management starts with identifying objective performance measurements.”
Jim Reardan

“Service Decomposition splits service, not function.”
Thomas Erl

“IT realizes the burden is not on them anymore. The business has to be the responsible party.”
Peter Woodhull

“Often when we look at business processes and SOA we ignore the information aspect and focus on the technology aspect. What’s important is that you have some vision of sets of services that you need now and then over time to meet your business requirements.”
Mike Rosen

“Unless you use SOA in the context of what you’re trying to do with the business, you can end up with just the new spaghetti to replace the old spaghetti.”
Marc Smith

“…often sees a team of business experts thinking in purely business terms and a team of developers thinking only in terms of what code they’ll need to write. But SOA is not the sort of architecture that one builds by throwing code at it. It is, at its core, very conceptual.”
Sandy Kemsley

“Using SOA as we do – as an architecture and business modeling approach – helps bridge the gap between traditional business process modeling and technology delivery.”
Steve Jones

“SOA is simply the technology architecture that defines how any technology is designed and deployed. BPM, on the other hand, represents how you link business strategy to business implementation… with [SOA-based] technology being a part of that implementation.”
Phil Gilbert

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

Recentemente recebi duas dúvidas de uma analista de processos confusa com os termos comuns usados dentro dessa área de processos e também em relação a adoção de processos negócio servindo como orquestrador de sistemas legados.

Eis as perguntas e as minhas respostas:

1) Qual é a diferença básica entre o BPMS e um Workflow?

Os softwares BPMS se assemelham com Workflow de diversas maneiras, a principal delas é que ambos servem como apoio para gestão de processos de negócio, onde você consegue fazer o mapeamento, modelagem e desenho desses processo de negócio. Entretanto os BPMS, por serem uma suite, oferecem mais opções que um Workflow. Com ambos, tanto BPMS e Workflow, você consegue fazer a modelagem dos processos, mas no geral os BPMS são mais usados para execução, monitoração e automação de processos de negócio. Já o foco principal dos Workflow é servir como um “tradutor” de processos de negócios (e todos seus usuários, regras e cenários) para uma notação visual, que irá servir como uma espécie de documentação para uma visão macro (ou até mesmo mais detalhada, dependendo do caso) do processo de negócio.

Apesar de ser possível executar e automatizar processos de negócio com a tecnologia Workflow, OS BPMS possuem alguns recursos como BAM, BRM, facilidade de integração entre sistemas através de adaptadores, padrão de notação visual (BPMN), facilidade para orquestração de serviços (BPEL), que por exemplo um Workflow não possui.

Processos de negócio mais complexos são melhores atentidos com uma solução BPMS do que com Workflow.

Abaixo, dois bons links como complementação de leitura para esse tópico:

Workflow? BPM? I’m So Confused!

Comparing BPA and BPMS is like comparing apples and oranges

2) Posso utilizar um BPMS apenas para controle do processo? E continuar utilizando meus sistemas legados normalmente, sem mudar o trabalho dos usuários?

Quanto aos sistemas legados, como eu disse anteriormente, os BPMS oferecem ótimos recursos para integração com sistemas legados, seja através de Web Services, Banco de Dados, Filas JMS, dentre outros. Por isso não há a necessidade de que esses sistemas legados deixem de existir, eles podem muito bem ser orquestrados no seu processo de negócio utilizando uma solução BPMS, mas o que é muito importante e nunca deve ser esquecido é o real motivo da existência desse processo: por que ele existe? Para que ele existe? Qual seu foco? Essas são perguntas que não podem deixar de ser respondidas.

Segue a chamada do Evento:

A ELO Group e o GPI/UFRJ estão promovendo o evento internacional ‘Elaboração e Implantação de Estratégias de Sucesso em BPM’, com a participação do Prof. Michael Rosemann, uma referência mundial no assunto. O evento será realizado nos dias 01, 06 e 07 de outubro de 2009, nas cidades de Brasília, Rio de Janeiro e São Paulo, respectivamente. INSCRIÇÕES ABERTAS!

Uma das organizadoras do evento será a ELO Group, que vem tendo algumas iniciativas legais de BPM em prol da disseminação do conhecimento, duas dessas iniciativas são a publicação BPM 360 e também Webinars gratuitos.

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.

O início

Ao iniciar o projeto que estou atualmente, confesso que fiquei no impasse de “qual versão usar?”, pois o BPM Server (enterprise) de produção ainda é o 6, ou seja, Aqualogic. Paralelo a isso, comecei a ter alguns problemas com a versão 6.03 do Aqualogic BPM Studio na minha máquina, pois como tenho dois localhost (alias) apontando para o mesmo IP local (127.0.0.1), ao subir a engine um erro com a mensagem “server has exited” começou a ocorrer e com isso não conseguia “startar” a ferramenta. Pesquisando no Google, vi no falecido fórum da BEA, uma thread dizendo que para resolver esse problema bastaria eu comentar uma das linhas que apontam para o meu IP local no arquivo de hosts do meu SO. Fiz o procedimento e… nada! Ainda nessa mesma thread, havia outro comentário informando que na versão nova (Oracle) a engine estava mais esperta e resolvia esses tipos de problemas, foi a partir disso que resolvi usar a nova versão, ainda meio que ressabiado.

O problema e a segurança

Mas aí surge um novo problema: a incompatibilidade entre versões. Meu ambiente de desenvolvimento usa a versão nova e o meu ambiente de produção usa a versão mais antiga, será que com isso terei problemas em fazer deploy? A princípio não deveria ocorrer problema algum, pois na verdade o que mudou foi basicamente a skin da ferramenta, o workspace (skin também) e a engine que ficou mais esperta. Nesse meio tempo, por coinciência, tive um treinamento de BPM aqui no RJ com o pessoal da Oracle e ao perguntar pra eles se esse problema poderia se concretizar, fui respondido que não, apesar de nunca terem feito esse teste. Confirmaram ainda, que realmente quase nada havia mudado de uma versão para outra. Foi o suficiente para eu ter segurança na minha decisão.

A realidade

Mas no decorrer do projeto, tenho percebido que o buraco é um pouco mais embaixo hehe, nada que comprometa o desenvolvimento, mas alguns cuidados precisam ser tomados e como estou passando pela experiência, acho válido relatar para quem possar vir a passar pelas mesmas situações que eu. Só gostaria de ressaltar, que os testes que tenho feito não são os ideais, pois o que estou testando é o projeto sendo executado no Studio BPM na versão Oracle (nova) e também no Aqualogic (antiga), mas ainda não tentei fazer deploy em uma versão enterprise, pois ainda estou sem ambiente para isso, quando tiver esses testes, atualizo esse post.

Abaixo irei enumerar as diferenças que notei até agora com suas devidas observações.

Controle de Versão
Na versão 6.03 (Aqualogic), a ferramenta ainda não possuia um controle de versão embutido para SVN, se fazia por necessário instalar um plugin (Subversive) para ter essa funcionalidade, agora isso já vem de graça! Essa sem dúvida foi uma melhoria muito positiva na qual não tive problema algum entre as versões.

Connectors
O BPM Studio, em ambas as versões, tem uma coisa muito legal chamada connectors. Com os connectors é possível criar um atalho para determinada atividade sem ter que puxar uma transition para a mesma, isso é muito bom para ajudar na organização do processo, pois com isso evita-se que um monte de transitions fiquem entrelaçadas deixando o processo uma verdadeira zona.

Com connectors comecei a ter alguns problemas, pois processos que possuiam connectors na versão nova simplesmente não funcionavam na versão antiga. Pior do que isso, processos com connectors na versão nova não abrim na versão antiga! Não consegui descobrir o motivo, a única conclusão que cheguei é que geralmente o problema ocorria com connectors que linkavam para uma atividade final (End) do processo.

Conclusão: não uso mais.

Instanciar Variáveis
Esse foi um comportamento que eu sinceramente prefiro da versão antiga, pois acho mais correto.

O que ocorre é que algumas variáveis de instância eu não preciso instanciar, então em um array de BPMObject eu consigo ter algo do tipo:

bpmObject[i].nome = "Marcus Cavalcanti";

Ou seja, não precisei instanciar aquele índice corrente do array. Já na versão antiga isso não funciona, obviamente ocorre um NullPointerException, então para resolver isso eu preciso fazer:

bpmObject[i] = new MeuBpmObject();
bpmObject[i].nome = "Marcus Cavalcanti";

Eu prefiro a segunda opção, mais conservadora. Sinceramente não sei como e porque a primeira opção funciona na versão nova, pois não deveria.

Activity x Transitions
Uma mudança simples, mas muito significativa ocorreu nessa nova versão. Toda vez que uma atividade é adicionada ou removida, automaticamente o layout se ajusta e na maioria das vezes bagunçando as transitions entre uma atividade e outra. Agora na nova versão existe a possibilidade de habilitar/desabilitar esse “recurso”. É muito simples, basta ir em:

Window > BPM Preferences > Activity > General

Seguido os passos acima, basta apenas desmarcar o último checkbox. Fichinha!

Gráficos e Skin
Nossa… esse foi um avanço e tanto! Na versão para Linux os ícones ficavam horrorosos! Ficavam sem transparência por causa do PNG, então ficava aquele fundo preto e era horrível, além do mais os ícones agora estão bem mais trabalhados e bonitinhos :)

O Workspace foi outra coisa que mudou, achei a nova skin bem melhor e funcional, parece que cabem mais informações.

Conclusão

Conforme dito no começo, mudanças em relação a features não existem de uma versão para outra, mas percebi algumas pequenas mudanças ao executar o mesmo projeto em versões diferentes, o que pode trazer pequenos problemas.

Acredito que a principal questão seja em relação a diferença entre versões de desenvolvimento e enterprise, mas esses testes ainda não possuo e assim que possuir atualizo esse post. Da mesma forma, se surgirem novas diferenças entre as “versões Studio”, esse espaço será atualizado.

PS: se alguém tiver percebido mais algum comportamento estranho, fique a vontade para compartilhar, os comentários estão aí pra isso!

BPM

BPM é o acrônimo de Business Process Management, que traduzindo para o português seria Gerenciamento de Processos de Negócio.

Definir o termo BPM não é uma tarefa trivial, pois como se trata de um assunto amplo e recente, cabem mil definições, algumas não tão boas, de cunho mais comercial e outras mais simples. Porém acredito que as explicações mais simples, não conseguem dar um overview sobre BPM para uma pessoa leiga no assunto, portanto tentarei usar exemplos e conceitos para tentar passar melhor esse significado.

BPM tem a ver com processos, e BPMS com processos e software. Sendo prático, eu diria que BPM é uma metodologia, um conjunto de boas práticas, com o o intuito de mapear e gerenciar processos de negócio, onde são (ou não) envolvidos clientes, usuários, fornecedores e atividades automáticas (informatizadas), onde o principal objetivo do BPM seria obter uma melhoria desse processo.

Se ainda não ficou muito claro, para facilitar as coisas, darei um exemplo real. Imagine o seguinte cenário:

• Departamento comercial da empresa X identifica que o produto Y é um produto com forte potencial de venda;
• Departamento comercial solicita ao departamento de compra/venda o produto Y;
• Departamento de compra/venda vai em busca de fornecedores fazendo cotação de preços em busca do melhor custo x benefício;
• Departamento de compra/venda define o fornecedor Z como escolhido e esse fica de fazer a entrega dos produtos em 15 dias;
• Na data estipulada, o setor de logística da empresa X, recebe o produto do fornecedor Z e assim comunica ao departamento comercial que este está disponível para venda;
• Departamento comercial da empresa X, então comunica ao departamento de marketing, que nesse caso irá bolar um campanha de divulgação desse novo produto;
• Campanha criada, produto finalmente é lançado.

Repare no fluxo acima e perceba que isso é um processo de negócio, pois ele possui um começo, envolve pessoas, pode envolver outros recursos, tem um objetivo bem definido e provavelmente ocorre com certa frequência. Esse processo pode ser melhorado, se tornar mais eficiente? É provável que sim e é nesse ponto que entram o BPM e o BPMS. O BPM seria uma forma de mapear esse processo, identificar gargalos, pontos falhos afim de melhorá-lo e para isso a ajuda de um (bom) software BPMS é muito importante.

BPMS

BPMS (Bussiness Process Management Software) seria o braço direito do BPM na melhoria do processo exemplificado acima, através do BPMS seria possível modelar esse processo visualmente e com recursos específicos de uma ferramenta BPMS é possível ter métricas e controles de todo fluxo do processo, dessa forma seria possível, por exemplo, simular esse processo de diversas maneiras, criar mecanismos de automação e fornecer relatórios específicos para tomadas de decisão. Tudo isso com o objetivo único e exclusivo da melhoria desse processo.

É difícil falar sobre BPM sem ser um pouco repetitivo, sem deixar a leitura cansativa, pois trata-se de um assunto muito teórico e abstrato, mas a melhor forma de falar sobre BPM é com exemplos, portanto, com o assunto introduzido, no próximo post mostrarei um cenário de um processo real em que estou trabalhando atualmente e a necessidade do uso de uma ferramenta BPMS.

Só para finalizar, BPM hoje em dia é um dos “componentes” que fazem parte de uma arquitetura SOA completa, o que não significa que para ter uma solução SOA eu tenha que fazer o uso do BPM, porém se usados juntos da forma correta, tornam-se uma poderosa dupla na gestão, automatização e melhoria de processos de negócios.