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

Web Services são componentes que permitem que duas aplicações troquem informações entre si utilizando um canal de comunicação (network), na maioria das vezes o protocolo HTTP. Existem alguns tipos de Web Services, mas os mais conhecidos e usados hoje em dia são: RPC, WS-* (WSDL/SOAP) e REST.

Dos padrões citados, provavelmente o formato mais conhecido e usado hoje em dia é o WS-*, que define que um serviço deve receber/responder mensagens no formato XML (SOAP) e deve possuir um contrato que defina os seus serviços (WSDL). Só que esse formato, principalmente depois da popularização do REST, vem sofrendo pesadas críticas de toda comunidade de desenvolvimento, que alega que esse formato é burocrático e complicado, enquanto o REST é um formato mais simples e objetivo.

Minha opinião é que tanto o padrão WS-* como o padrão REST não se substituem, pelo menos não por enquanto, e que tentar fazer essa comparação ainda não agrega, pois existem casos específicos onde REST é muito bem-vindo, assim como existem casos onde o padrão WS-* é muito bem-vindo.

WS-* – Vantagens e desvantagens

Uma das principais reclamações em relação a esse formato é que o mesmo possui N especificações e que isso o torna complexo e burocrático, e de certa forma eu concordo. Só para se ter uma idéia existem mais de 15 especificações para esse formato e conhecer todas é humanamente impossível e inviável.

Outra reclamação é em relação ao overhead que a troca de mensagens de um serviço no padrão WS-* pode causar, pois todas as mensagens precisam ser envelopadas dentro de um pacote SOAP, que nada mais é que um XML padronizado. Esse overhead é causado, pois dentro de um envelope SOAP, o que é usado é a menor parte do conteúdo que está ali contido, dessa forma há muito “lixo”.

Essas duas reclamações citadas acima, são as maiores reclamações dos desenvolvedores em relação a serviços WS-*, contudo no meu modo de ver existem também muitas vantagens no uso do formato WS-*, principalmente no que diz respeito a integração entre aplicações corporativas e também em relação a SOA.

Por exemplo, eu trabalho em um ambiente onde existem muitos serviços, muitos mesmos, e esses serviços são desenvolvidos por N fornecedores, em N plataformas distintas e são usados por N por aplicações. É um cenário bem complexo e eu não imaginaria esse cenário sem o uso do formato WS-*. E por quê? Em primeiro lugar porque ter um contrato formal desses serviços é totalmente necessário, afinal eu preciso saber o nome desses serviços, preciso saber o que eles estão esperando receber, o que eles irão me responder e como serão esses dados. Imagine se um serviço desses mudar o caos que seria?

Outro fator muito importante são as ferramentas de apoio, afinal elas além de facilitar o trabalho, trazem também produtividade. Existem N ferramentas que ajudam na simulação, testes, geração de Mock’s, teste de carga, debug e tantas outras atividades necessárias no desenvolvimento/acesso a esses serviços. A principal ferramenta free usada hoje em dia é o soapUI.

Em relação a SOA, o formato WS-* também se mostra a melhor opção. SOA é uma maneira de se construir softwares baseado no conceito de serviços, onde esses serviços devem possuir um contrato formal, devem ser independentes (possuir baixo acoplamento) e devem ser reutilizáveis. Outro princípio de SOA diz que esses serviços devem ter a capacidade de serem descobertos e nesse ponto o WS-* mais uma vez sai na frente, pois o mesmo possui o protocolo UDDI, que é um método utilizado para publicar e descobrir diretórios de serviço em uma arquitetura SOA.

REST – O que é, vantagens e desvantagens

REST é o acrônimo de Representational State Transfer, que é um modelo de arquitetura baseado no protocolo HTTP e que utiliza URI para identificação dos seus serviços. REST é uma maneira de construir serviços usando o protocolo HTTP como ele foi concebido, ou seja, usando: POST, GET, DELETE e PUT.

Serviços RESTful (serviços REST) partem do princípio que o protocolo HTTP é rico o suficiente para que seja criada uma abstração – no caso WS-* seria uma abstração – para construção de serviços.

Uma das vantagens em utilizar serviços REST sem dúvida nenhuma é a simplicidade, afinal criar serviços REST é usar de maneira parecida o protocolo HTTP como usamos atualmente no desenvolvimento de aplicações Web, ou seja, se você usa o método POST em um formulário, você consequentemente está usando REST, a única diferença é que o submit desse formulário devolveria um conteúdo HTML, quando que em um serviço RESTful o indicado seria devolver uma estrutura mais padronizada, no caso um XML ou um JSON, por exemplo.

Outra vantagem no uso de serviços REST é a performance, pois os seus request/response são infinitamente menores se comparados com os do formato WS-*, e são menores, porque não precisam ser envelopados dentro de um pacote SOAP, serviços REST apenas recebem o que precisam e consequentemente respondem o que é necessário.

Serviços construídos no formato REST também são mais humanos, ou seja, são mais compreensíveis que serviços WS-*. Isso se deve ao fato de que para construir um serviço REST não é necessário conhecer N especificações, não é necessário saber o que é WSDL, assim como também não é necessário conhecer um pacote SOAP. São mais humanos também, pois são identificados através de URI’s.

Dentre outras vantagens de serviços RESTful destaco a possibilidade de fazer cache das operações, possibilidade de criar camadas intermediárias (proxy, gateway, cache servers) com o intuito de aumentar a performance ou segurança e possibilidade de usar HTTPS nativamente.

Pensando em um ambiente corporativo, em aplicações enterprise e em arquitetura SOA, começam a surgir alguns problemas em relação a adoção de serviços REST, a começar pelo fato de que REST não possui um padrão oficial para descrição dos seus serviços, até existe uma frente interessada em criar esse padrão utilizando WADL, mas ainda não existe nada oficial, portanto essa é uma grande desvantagem.

Serviços REST também não possuem estado, são stateless, ao contrário de serviços WS-*, pois os mesmos podem possuir estado entre uma chamada e outra. Serviços REST também não permitem requisições assíncronas e utilizando o formato WS-* é possível fazer requisições sem que seja necessário esperar uma resposta.

Pensando em SOA, REST não é a melhor opção, afinal, conforme citado anteriormente, REST não possui um contrato formal para definir a interface dos seus serviços, assim como também não possui uma maneira para que esses serviços possam ser publicados e descobertos.

Outra desvantagem no meu modo de ver, é que para construção de um processo BPEL, se faz por necessário que os serviços possuam uma interface que os descreva (WSDL), nesse caso serviços REST não seriam os mais indicados para serem usados dentro de um processo BPEL, contudo existem algumas maneiras de realizar esse workaround para usar serviços REST dentro de um processo BPEL. Dependendo da ferramenta escolhida, algumas fornecem soluções como a criação de Partner Links HTTP, ou seja, são Partner Links próprios para serviços REST, ou então, algumas outras ferramentas fornecem maneiras um pouco mais trabalhosas como a criação de um WSDL que descreva o serviço HTTP (REST).

Afinal, qual devo usar?

Sinto lhe frustrar, mas a resposta para essa pergunta é: depende, cada caso é um caso.

Não é inteligente ignorar uma ou outra opção, ou ser cego a ponto de desconsiderar os benefícios e vantagens de cada uma. Na minha opinião, fomentar essa discussão é cair no mesmo de discutir “qual linguagem é melhor”, afinal cada uma tem seu propósito.

Os fanáticos por REST costumam dizer que o formato WS-* só existe, pois os grandes players do mercado (Oracle, IBM, Microsoft, etc) estão envolvidos, já que esses grandes players desenvolvem ferramentas específicas para facilitar a criação e a manutenção a serviços construídos dessa maneira. Quem faz essa afirmação está completamente equivocado, pois por mais burocrático que serviços WS-* possam ser, eles ainda possuem uma enorme utilidade que serviços REST ainda não satisfazem.

Agora, no caso de serviços para celulares, PDA’s, e outros dispositivos móveis, onde cada dado enviado/recebido tem um custo alto, utilizar serviços REST é sem dúvida a melhor opção. Da mesma maneira que para prover serviços de aplicativos web, como mashups, REST também é a melhor opção, a maior prova disso é que em serviços como Twitter, Facebook, Amazon e até mesmo o Google, estão usando REST em larga escala.

Mas também existe o outro lado da moeda, pois pensando em um ambiente complexo, com muitos serviços, repositórios, ainda não dá para pensar em outro formato que não seja WS-*.

Enfim, mais uma vez volto ao ponto de que devemos conhecer as opções para tomar a decisão de escolher o que é mais adequado, REST não substitui WS-* e vice-versa, insistir nessa rixa não agrega e quem não enxerga dessa maneira, precisa rever seus conceitos, ou então estudar mais.

Aproveito para deixar o link para download de uma apresentação sobre REST, que fiz no meio do ano passado, na empresa que eu trabalho: clique para fazer download.

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.