[LIVRO] INTRODUÇÃO AO BPMN

Prévia do material em texto

3Portal BPM - www.portalbpm.com.br
Sumário - Portal BPM
PortalBPM
Capa
Artigos
Principais problemas 
nas implementações
Pág. 16
Entrevista com 
Thomas Erl
Pág. 30
BPM e 
Arquitetura 
Orientada 
a Serviços
Pág. 42
Introdução ao 
BPM, BPMS 
e SOA
Pág. 22
Os 10 passos 
para implementação 
do SOA em 
Mainframes
Pág. 34
Quer desenvolver 
uma aplicação de 
negócio? Comece 
com um BPMS
Pág. 54
A tão sonhada 
compatibilidade de 
padrões existe?
Pág. 46
Introdução ao 
 BPMN 
Pág. 6
 Carta ao leitor
4 Portal BPM - www.portalbpm.com.br
 Nasce a revista 
PortalBPM. 
Bem-vindo à primeira publicação brasileira especializada 
nos temas BPM, BPMS e SOA.
Após quase dois anos de maturação e pesquisa dos refe-
ridos assuntos no site www.portalbpm.com.br, percebe-
se, como principal incentivo ao lançamento de uma re-
vista impressa, uma crescente busca pelo conhecimento 
por intermédio de outros meios de divulgação.
 
Os temas BPM, BPMS e SOA têm demandado estudo 
por parte dos gestores de TI, arquitetos e desenvolvedo-
res, além de um amplo rol de assuntos que compreende 
desde a área de administração de empresas até a área 
de informática.
Nesta e nas demais edições, discutiremos sobre mode-
lagem de processos, SOA, componentização, métricas 
para avaliação de processos, BI e mineração de dados. 
Sempre que possível, com ênfase no conhecimento acu-
mulado ao longo dos anos, de modo a explorar a pratici-
dade do tema.
Nesta edição, analisamos alguns dos pilares desta nova 
área por meio de Uma introdução ao BPMN, um eluci-
dador artigo sobre os problemas que podem surgir em 
uma implantação de uma solução BPM, além de outros 
artigos elaborados por uma equipe de prestígio.
Diante de todas essas possibilidades a serem explora-
das, contamos com você, no intuito de que compartilhe 
sua prática com outros leitores. Assim como o site, este 
é um espaço aberto à divulgação de conhecimento.
Uma excelente leitura a todos e até a próxima!
Editor-Chefe
Glauco Reis 
(glauco@portalbpm.com.br)
Publicidade e Comercial
 Valéria Pino Oliveira 
(valeria@portalbpm.com.br)
Jornalista Responsável
Marcela de Paula MTB 32.790 
Corpo Editorial
 Antonio Dutra Junior
 Glauco Reis
 Leandro Yung
Participaram desta edição
Glauco Reis
Antonio Dutra Junior
Thomas Erl
Daniel Raish
Leandro Yung
Helio Pereira
Preparação
Ana Elisa Araújo Souza
(ana.elisa@portalbpm.com.br)
Revisão 
Ana Elisa Araújo Souza
Diagramação e arte
Marcelo B. Lemes
(marcelo.lemes@portalbpm.com.br)
Capa e ilustrações internas 
Marcelo B. Lemes
Distribuição 
 Distmag
Distribuidora Magazine Express de 
Publicações Ltda.
A revista PortalBPM é uma 
publicação bimestral da Editora 
PortalBPM Ltda.
Av. Santa Catarina, 1396 
São Paulo - SP - CEP 04378-100
O conteúdo dos artigos é de 
responsabilidade dos autores.
Os sotwares distribuidos com a revista 
via CD-ROM e encartes são de 
propriedade e responsabilidade de seus 
fabricantes, assim como o suporte aos 
direitos autorais.
PortalBPM é marca registrada da 
Editora PortalBPM Ltda.
Glauco Reis
5Portal BPM - www.portalbpm.com.br
 Espaço PortalBPM 
 Fontes de informação
Como temos recebido, no site, diversas perguntas de leitores, sobre livros e cursos a res-
peito da notação BPMN, seguem algumas sugestões: 
http://www.omg.org/bpmn/: a atual fonte de referência para o tema é a especificação BPMN.
http://www.bpmessentials.com/bpmn/training/en/onlinetraining/onlinetraining.html: 
informe-se sobre o curso comercial de Bruce Silver.
http://www.bpmn.org: encontre documentos e tutoriais sobre o tema. 
 
http://www.bpminstitute.org: excelente fonte de conhecimento, com diversos docu-
mentos em formato PDF. 
Tanto nesta como nas próximas edições da revista PortalBPM, exporemos um curso sobre 
a notação e os padrões mais comuns utilizados na representação.
Nas próximas edições, disponibilizaremos uma ferramenta exclusiva para desenho BPMN, 
que será utilizada durante todo o curso.
 Acontece:
http://www.BPMInstitute.org: disponível uma versão digital da revista BPMStrategies Magazine.
http://br.groups.yahoo.com/group/BPM-Forum: site brasileiro com foro de 
discussões sobre BPM.
http://www.SOAInstitute.org: encontre diversas informações úteis e links para 
documentações sobre o tema. 
http://www.ideti.com.br/inteligenciacompetitiva: informe-se sobre o congresso 
de inteligência competitiva, Business Intelligence e Gestão por Indicadores, promovido pelo 
instituto IDETI, nos dias 28 e 29 de agosto, em São Paulo. 
http://www.bpmfocus.org: informe-se sobre o evento BPM Think Tank 2007, que 
acontecerá de 23 a 25 de julho, em San Francisco. 
 BPMN
6 Portal BPM - www.portalbpm.com.br
De todas as tecnologias que 
compõem uma solução BPMS, 
provavelmente o BPMN é a 
mais uniforme em sua utiliza-
ção. Neste artigo, analisare-
mos essa notação por meio 
da apresentação de seus 
elementos gráficos e de 
seus diversos aspectos 
favoráveis.
 Introdução 
 ao BPMN
Por Glauco Reis
Consultor em Java e metodologias OO, es-
pecializou-se em plataforma IBM. Com uma 
experiência de quase 10 anos em tecnologias 
Java e quase 20 anos em tecnologias OO, tem 
mais de 150 artigos publicados em revistas 
especializadas. Trabalhou em projetos de sele-
ção e implantação de soluções BPMS, além de 
ser especialista em Web Services e ter atuado 
como arquiteto principal na criação de uma 
solução BPMS nacional.
7Portal BPM - www.portalbpm.com.br
Introdução ao BPMN - Glauco Reis
 BPMN
O BPMN (Business Process Modeling Nota-
tion) é uma notação visual para representação 
de fluxos de processos que pode ser mapeada 
para diversos formatos de execução, como BPML 
e BPEL. Em uma analogia com a orientação para 
objetos, o BPMN seria como a UML, que define 
elementos gráficos para representar objetos e 
classes, como também sua interação. 
Por um lado, da mesma forma que a UML, o 
BPMN não define formatos de armazenamento 
nem elementos programáticos relacionados à im-
plementação, como por exemplo, as rotinas. Por 
outro lado, a especificação é completa o suficiente 
para permitir a representação de fluxos de processo 
pelas áreas de negócio, com detalhamento bem 
próximo das complexidades de um ambiente real, 
além de ter elementos que se aproximam de me-
canismos de execução, como veremos a seguir. 
Quanto à similaridade, o BPMN assemelha-se 
aos diagramas de atividade da UML que, por sua 
vez, assemelham-se aos antigos fluxogramas na 
programação tradicional. O BPMN é formado por 
um ou mais BPD (business process diagram), isto 
é, o “desenho” de uma parte ou visão de um pro-
cesso, que normalmente pode ser mapeado para 
um formato de execução, como o BPEL ou BPML. 
 Tipos de diagrama
Podemos ter diversas representações para os 
referidos desenhos, desde uma visão de mais alto 
nível até diagramas mais detalhados. Quando se 
está interessado no detalhe, pode-se visualizar um 
“pedaço” de um processo, sem se importar com seu 
modo de contextualização em relação ao restante 
do processo. Nesse caso, pode-se desenhar o que 
se chama de processo de negócio privado (private 
business process), conforme a figura 1: 
Figura 1 - Processo de negócio privado
Perceba que o processo se “inicia” com 
a escolha de uma forma de pagamento. 
Na verdade, apenas observando-se o fluxo 
conseguimos percebê-lo como parte de um 
fluxo maior, que pode ser, por exemplo, um 
processo de compra em uma loja. Nessa 
representação, não importa quem está 
envolvido com a tarefa nem quais outras 
atividades foram ou serão executadas.
No entanto, alguns elementos gráficos 
já ficam à mostra: os círculos em BPMN 
representam eventos que acontecem du-
rante um processo.No exemplo da Figura 
1, os círculos no início e no final do desenho 
representam, respectivamente, o início e o 
final do processo. Os losangos representam 
decisões simbolizadas por caminhos diver-
sos que podem ser percorridos por um fluxo 
ao longo do ciclo de vida. Os retângulos 
com bordas arredondadas representam 
cada “atividade” ou passo para execução 
de algo maior. Os símbolos são intuitivos 
e muito próximos das representações atu-
almente adotadas pela TI. Como veremos 
a seguir, naturalmente o poder da notação 
vai muito além dessa simples notação. 
Algumas vezes, é interessante repre-
sentar a comunicação de dois fluxos de 
processos, sendo relevantes apenas as in-
terações entre os dois. Trata-se de um nível 
mais alto de visualização. Nesses casos, 
a notação permite o uso de um diagrama 
sem tantos detalhes, chamado de processo 
abstrato (abstract process). Um exemplo 
desse tipo de diagrama pode ser visto na 
ilustração abaixo: 
 
Figura 2 – Processo abstrato
8 Portal BPM - www.portalbpm.com.br
Na figura 2, Banco representa um pro-
cesso abstrato; perceba que não aparecem 
detalhes de como a informação que está 
sendo processada, mas apenas a comuni-
cação entre os dois fluxos. Observe que 
a linha que conecta os dois processos é 
pontilhada, denotando uma “mensagem”. 
Mensagem é a forma de comunicação entre 
dois processos distintos, ou seja, não se 
pode ter linhas contínuas conectando o pro-
cesso de compra ao banco, no exemplo da 
figura 2. O inverso também é verdadeiro, 
isto é, não faz sentido enviar uma mensa-
gem de uma atividade para outra dentro de 
um mesmo processo privado. Isso pode ser 
feito por meio de uma linha de fluxo, que 
é contínua ao invés de pontilhada. 
Por fim, existe a situação mais com-
plexa, em que há a necessidade de se 
representar as etapas e a colaboração 
entre os elementos dos processos, o que 
é permitido mediante os processos de ne-
gócios colaborativos. Um exemplo desse 
tipo de representação pode ser visualizado 
na figura 3:
 
Figura 3 - Processos de negócio colaborativos
Cabe salientar que a especificação não 
determina quando representar uma ou ou-
tra forma; ela sugere que se deve manter a 
simplicidade em favor do entendimento. A 
forma como as ferramentas tratam os diver-
sos tipos de diagrama também é determinada 
pelo fabricante da ferramenta, que pode, por 
exemplo, permitir a um processo privado uma 
 BPMN
vez clicado tornar-se um processo abstrato, 
desaparecendo as atividades e apenas mos-
trando os eventos, e vice-versa. 
Igualmente, o formato de arma-
zenamento é algo não-padronizado. 
Pode-se armazenar em um formato 
proprietário ou em XML. Isso faz que 
os desenhos criados entre as diversas 
ferramentas sejam freqüentemente 
incompatíveis. 
Não é incomum, no mercado, o forneci-
mento gratuito das ferramentas de desenho, 
pelos fabricantes, enquanto as ferramentas 
de simulação e execução de processos são 
tratadas de forma comercial. Isso incentiva 
o desenhista a utilizar a ferramenta gratuita 
para o desenho, com a expectativa de que, 
no momento da simulação e execução, 
qualquer outra poderia ser utilizada. Entre-
tanto, tenha cuidado, já que isso pode não 
ser verdadeiro.
Também são muito comuns, no mercado, 
empresas que adotam uma ferramenta pura-
mente de desenho e outra para execução e 
operacionalização dos fluxos. Dependendo da 
escolha, pode-se gerar a necessidade de se 
refazerem trabalhos, implicando-se, muitas 
vezes, o total redesenho do processo, a fim 
de permitir implantação na ferramenta de 
execução (Leia, nesta edição, o artigo Pro-
blemas na implantação de BPMS). Também é 
importante salientar que a notação completa 
BPMN tem mais elementos gráficos do que 
algumas notações, como o BPEL. Isso força 
as ferramentas de desenho que armazenam 
diretamente em um formato binário, como o 
BPEL, a utilizar um subconjunto das represen-
tações possíveis na notação BPMN. Embora 
traga a vantagem da portabilidade, uma vez 
que um BPEL editado em uma ferramenta vi-
sual pode ser visualizado em outra, empobre-
ce a representação gráfica do desenho. Há, 
ainda, o caso de soluções BPMS de mercado 
que não utilizam a notação BPMN em virtude 
das características internas.
9Portal BPM - www.portalbpm.com.br
A sugestão é que se faça a escolha da 
solução BPMS a ser utilizada na empresa 
antes mesmo de se iniciarem os desenhos 
dos processos. Para isso, deve-se adotar 
uma ferramenta de desenho compatível 
com a solução BPMS, o que reduzirá cus-
tos, de modo a evitar reajustes ou mesmo 
a necessidade de se redesenhar os pro-
cessos a serem executados.
 Escopos para os diagramas
A notação BPMN foi criada de forma a 
permitir a representação do negócio em um 
nível mais alto, mais próximo dos analistas 
de negócio, mas também com elementos 
que permitem a modelação das situações 
mais complexas de uma corporação. A 
fim de permitir essa dupla representação, 
existe um conjunto básico e um set com-
pleto que podem ser utilizados de acordo 
com o tipo de desenho e complexidade do 
processo. Pode-se observar o set básico na 
notação da figura 4:
 
Figura 4 - Set básico
Eventos indicam acontecimentos que, de 
alguma forma, podem alterar a seqüência 
de execução em um fluxo, sendo que, ini-
ciar ou terminar a realização de um pro-
cesso são exemplos de eventos. 
Os losangos indicam tanto pontos em que o 
fluxo pode divergir ou convergir, como pontos de 
tomada de decisão. 
Cada atividade executada em um fluxo é 
representada por um retângulo com bordas ar-
redondadas. A especificação é rígida no que se 
refere ao formato dos desenhos. Entretanto, per-
mite-se às ferramentas a criação de novos sím-
bolos, de modo a possibilitar, na implementação, 
particularidades não-previstas pela notação.
A seqüência em que os elementos são execu-
tados dentro de um fluxo é indicada pelas setas 
de fluxo, e dois elementos conectados indicam 
o sentido deste.
Existem, ainda, os elementos de dados, que 
fornecem informações a serem compartilhadas 
entre várias atividades em um fluxo. Dados 
como valores de cartões de crédito, carrinhos de 
compras, podem ser, por exemplo, indicados por 
essa notação. Normalmente, denomina-se esse 
tipo de elemento de artefato, uma vez que não 
altera o fluxo de execução. Além disso, o trata-
mento desses elementos não é determinado pela 
especificação, ficando a critério dos fabricantes 
de solução BPMS.
 
Figura 5 - Artefatos
Observando-se a figura 5, embora o valor 
somado não afete a execução do processo, 
em algum momento ele foi utilizado por um 
elemento de decisão como informação para 
mudança de sentido no fluxo. Dessa forma, 
um dado serve como auxiliar para o arma-
zenamento de alguma informação e para o 
envio desta entre as atividades. No entanto, 
a informação por si só não pode ocasionar 
alterações na execução do fluxo. Veremos 
mais adiante que efeito semelhante pode-se 
obter com um evento especial.
Introdução ao BPMN - Glauco Reis
10 Portal BPM - www.portalbpm.com.br
 BPMN
Os elementos explorados até o momento 
indicam o modo como o fluxo será execu-
tado. É necessário, ainda, definir quem 
executará cada uma das atividades, fun-
ção primária das pools e lanes. Uma pool 
é um elemento que engloba um processo 
privado (veja definição acima) e fornece-
lhe uma identificação. Uma lane permite 
criar subdivisões dentro de uma pool, que 
poderia se chamar “processo de compras”, 
enquanto cada lane poderia significar cada 
um dos participantes, como o vendedor, 
o cliente, o caixa, etc. Normalmente, as 
atividades executadas por cada perfil fi-
cam dentro da respectiva lane, conforme 
a figura abaixo:
Figura 6 – pools e lanes
Quando se utiliza o conceito de pools e la-
nes, cada atividade dentro de uma lane é de 
responsabilidadedo elemento indicado por ela. 
Na figura acima por, exemplo, é desnecessário 
informar que o “cliente entra na loja”, visto que a 
atividade “entrar na loja” está atada à lane clien-
te, e isso é o suficiente para a identificação.
Em um sistema computadorizado, a utiliza-
ção das lanes proporciona a identificação do 
perfil executor de cada etapa de um workflow. 
Imagine um sistema colaborativo formado 
por telas que podem ser vistas por grupos 
de usuários (um workflow típico). Para uma 
determinada atividade, aparecerá uma tela ao 
cliente (um dos perfis ou lanes). Após a apro-
vação, o sistema direciona a execução para a 
próxima atividade, que pode estar associada 
a outro perfil. Dessa forma, será apresentada 
uma tela para outro participante do workflow, 
como o vendedor (outro perfil ou lane). Siste-
mas colaborativos utilizam esse mecanismo, 
apontados por lanes e pools.
Normalmente, considera-se o pool como 
todo o processo. Perceba que a ligação 
de linhas de fluxo entre lanes é permitida 
pela notação. Porém, a única forma de se 
conectar duas atividades em duas pools 
distintas é mediante o envio de uma men-
sagem entre uma e outra. Nesse conceito, 
deve-se enxergar um pool como uma uni-
dade isolada que se comunica com outras 
unidades por meio de mensagens. Como a 
notação não especifica detalhes de imple-
mentação, diversas são as possibilidades 
de utilização de pools e lanes.
 Set completo
Quando se adota o set completo do BPMN, 
cada um dos símbolos se desdobra em várias 
representações possíveis. É nesse conjunto 
que o BPMN se torna realmente completo.
Como exemplo, todos os eventos são re-
presentados por círculos, mas para se dife-
renciar visualmente a etapa do processo em 
que eles foram gerados, existem notações 
diferentes, de acordo com a figura 7:
 Figura 7 - Tipos de eventos
Quando um evento inicia um proces-
so, este é indicado por um círculo de linha 
simples. Eventos que acontecem durante 
a execução de um fluxo são indicados por 
dois círculos de linhas simples, um dentro 
do outro. Exemplos desse tipo de ocorrência 
podem ser a chegada de uma mensagem, a 
ocorrência de um tempo determinado (dia 
10, às 9 horas), as mudanças nos valores de 
dados pertinentes ao fluxo (dólar acima de 
dois reais), e várias outras ocorrências que 
podem, de alguma forma, influenciar a sequência 
ou causar algum tipo de desvio no seu ritmo 
natural. Já quando um evento finaliza a exe-
cução de um fluxo, indica-se por uma linha 
de espessura dupla. 
11Portal BPM - www.portalbpm.com.br
Esse tipo de representação facilita a 
visualização, tornando claras as identifica-
ções de início e fim de execução. Sobre os 
eventos de início e finalização, a notação 
não obriga que se os adote, mas caso exista 
o evento de início, deve-se, obrigatoria-
mente, existir o evento de finalização. 
Caso não exista um evento de inicializa-
ção, todas as atividades que não tiverem 
uma seta chegando a ela serão realizadas 
ao início da execução de um processo.
Figura 8 – Início e fim de execução 
de fluxo
Embora de representações distintas, em se 
tratando de execução, a figura 8 representa dois 
fluxos similares. Quando a execução do fluxo à 
esquerda se iniciar, tanto as atividades A como 
B serão executadas, uma vez que não há setas 
chegando a elas. Isso indica que ambas devem 
gerar tokens de execução, pois só há setas saindo 
delas. Nesse exemplo, a segunda representação 
da figura 8 é mais clara, por indicar, precisamente, 
os pontos de início e término do fluxo.
Além das notações de início, intermédio e final, 
os eventos podem associar um fato gerador, con-
forme os elementos representados na figura 9:
 
Figura 9 – Eventos do conjunto completo
Uma possível confusão quando se utiliza 
a notação BPMN de modo completo é o fato 
de um mesmo símbolo poder ser utilizado 
como gerador ou como receptor de eventos, 
de acordo com a figura 10:
Figura 10 – Envio de mensagem
Segundo a notação, o evento de início é 
sempre receptor. Entretanto, se o evento 
for intermediário, pode significar envio 
ou recepção de mensagens. No diagrama 
da figura 10, inicia-se o fluxo “gerador” 
rea l i zando-se a primeira atividade e 
executando o evento de mensagem. Essa 
representação indica o envio de uma men-
sagem para o fluxo “receptor”, que inicia 
uma instância totalmente independente 
da execução de “gerador”. Todavia, em 
paralelo, a instância de gerador que en-
viou a mensagem continua de forma in-
dependente até o final do processamento. 
Depende das ferramentas de execução a 
forma como estas tratarão esse mecanis-
mo de eventos.
Da mesma forma que se pode enviar e 
receber mensagens, pode-se utilizar me-
canismos temporizados para execução de 
processos. Podemos iniciar a realização 
de um processo em determinados inter-
valos de tempo ou suspendê-la por certo 
período de tempo.
 
Figura 11 – Exemplos de temporização
Introdução ao BPMN - Glauco Reis
12 Portal BPM - www.portalbpm.com.br
 BPMN
No exemplo da figura 11, o processo cria 
uma instância que inicia a execução todo 
dia 30 do mês e que, após a realização da 
atividade A, ficará suspensa por dez minu-
tos, continuando-se a execução após o fim 
desse intervalo.
Pode-se iniciar uma atividade de forma re-
petitiva em certos períodos de tempo, como 
os processamentos batch das empresas para 
rodar a folha de pagamento todo mês, ou 
pode-se definir uma data e hora específicas 
para execução, como um lembrete no ca-
lendário. Pode-se, ainda, definir um período 
de tempo relativo em relação à data e hora 
atuais, como aguardar por uma hora para 
prosseguir a execução. Outra forma de re-
presentação é a indicação de uma condição 
de saída por intermédio do timer.
Também podemos gerar eventos a partir 
de informações de dados. 
 
Figura 12 – Eventos a partir de dados
No exemplo da figura 12, foram colo-
cados dois eventos de início de processo, 
cada um deles gerando, como resultado, 
a criação e a execução de uma nova ins-
tância de processo. Variações nos valores 
de informações de uma base de dados 
podem servir de trigger para o início da 
execução. Talvez não seja tão óbvio, 
mas diversas instâncias de processos 
podem estar em execução em um dado 
momento, cada uma delas em um ponto 
distinto de execução.
Além desses tipos de eventos, tam-
bém pode-se controlar a execução e a 
restauração dos dados por meio de um 
mecanismo de exceções implementado 
como eventos. Exploraremos os me-
canismos de exceção em uma edição 
futura. 
A notação completa também permite 
um rico conjunto de possibilidades em 
desvio de fluxos. 
Figura 13 – Tipos de desvio
Provavelmente, o desvio mais comum 
encontrado em programação é aquele 
em que apenas um dos possíveis cami-
nhos será seguido. É o famoso if-else. 
Na notação BPMN, o losango vazio ou 
com um X interno indicam essa opção.
No entanto, algumas vezes é interes-
sante termos vários caminhos execu-
tados ao mesmo tempo. Isso pode ser 
visto como uma forma de se executar 
at iv idades em parale lo, a f im de se 
conseguir uma melhor performance em 
sistemas multiprocessados. Quanto à 
execução, a notação BPMN não define a 
forma como se deve executar, mas sim 
o resultado esperado. 
 
Figura 14 – Exemplo de evento
13Portal BPM - www.portalbpm.com.br
No exemplo da figura acima, quando o 
cliente efetiva uma compra com cheque, faz-se 
uma consulta aos órgãos competentes, como 
forma de se resguardar o valor da compra. 
Como essa consulta pode ser um tanto demo-
rada, iniciam-se duas frentes de execução em 
paralelo: uma para consultar a idoneidade e 
outra para efetuar outras atividades pertinentes 
à venda. Apesar de duas execuções de forma 
simultânea, continuamos com uma instância de 
processo. A documentação oficial BPMN refere-
se a essetipo de situação como token. Trata-se 
de uma unidade de execução de uma instância 
de um processo, algo como uma thread para 
um programa em atividade, o qual terá sempre 
uma ou mais threads em execução e, de forma 
similar, uma instância de fluxo terá um ou mais 
tokens ativos no momento. 
Como não é possível garantir a disponibi-
lização do multiprocessamento por qualquer 
solução BPMS, a notação concebe a junção 
como o mecanismo que irá unir tokens de 
execução em paralelo. Para o exemplo da fi-
gura 14, tem-se como possibilidade a seguinte 
seqüência de execuções em um ambiente não 
multiprocessado: 
• Efetiva a compra com cheque
• Confere cheques e emite nota
• Retira o produto do estoque
• Chega à junção e aguarda a 
 execução do outro caminho
• Consulta nome negativado
• Chega à junção e continua
• Cliente leva mercadoria
Perceba que, embora não seja uma execu-
ção realmente em paralelo, há a garantia de 
que, após a junção, a execução das atividades 
apenas acontecerá quando os dois braços 
tiverem terminado. Isso garante a integrida-
de do que se projetou graficamente, mesmo 
sendo impossível uma execução em paralelo 
pela solução de implantação.
Naturalmente, quanto à performance, a 
solução de BPMS ideal seria aquela em que os 
dois caminhos fossem realmente executados 
em paralelo. 
Além de bifurcações no processamento 
(AND) e escolha de caminhos (XOR), tem-
se outros exemplos mais complexos para 
a tomada de decisão. Uma das estruturas 
peculiares, notadamente influenciada pela 
especificação do BPEL, é a decisão base-
ada em mensagens. Veja um exemplo na 
figura 15: 
 
Figura 15 – Pick de eventos
Nesse tipo de estrutura, quando se chega 
à bifurcação, o processo fica aguardando 
uma das ocorrências dos eventos conecta-
dos na saída. Qualquer ocorrência, e apenas 
a primeira será executada, faz que o pro-
cessamento continue a partir da atividade 
posterior ao evento, descartando-se todos 
os outros caminhos. Se o valor do dólar 
atingiu um patamar acima de dois reais, 
por exemplo, não importa a ocorrência dos 
outros eventos, uma vez que o fluxo cami-
nhará pela execução da atividade “Dólar > 
2.0”. Os outros eventos são descartados. 
Existe uma estrutura idêntica a essa na 
especificação BPEL, e a notação se com-
patibilizou de forma a tornar mais fácil um 
mapeamento de BPMN para BPEL. 
Quando nos referimos às atividades, o 
leque de possibilidades no set estendido 
também é grande. 
Introdução ao BPMN - Glauco Reis
14 Portal BPM - www.portalbpm.com.br
 BPMN
 
Figura 16 – Tipos de atividades
Atividades podem ser vistas como 
blocos funcionais de execução, os quais 
podem ser subdivididos em blocos meno-
res. O menor bloco representável seria 
uma atividade simples. Um pedaço de um 
fluxo ou mesmo um fluxo inteiro pode 
ser representado por um subprocesso 
ao qual a notação sugere a existência 
de um sinal de soma interno. Quando o 
subprocesso fosse acionado pelo mouse, 
a imagem se “expanderia”, passando a 
representar uma miniatura do desenho 
do processo contido nesse subprocesso. 
Não é parte da especificação o modo 
como se editará um subprocesso, mas 
é importante, durante o desenho, ter-se 
em mente que os blocos serão subdividi-
dos em blocos menores até se chegar a 
uma unidade de processamento não mais 
subdivisível, que pode ser uma tela, uma 
interação ou um Web Service. 
Existem situações em que uma ativi-
dade deve ser executada repetidamente 
para uma massa de dados, o que pode 
ser feito por meio de um loop. Além 
de realizada repetidas vezes, tem-se a 
possibilidade de executar as várias re-
petições em paralelo. Quando se inicia 
uma atividade loop em paralelo, diversos 
tokens (tantos quantos forem os dados) 
serão criados e processados. A forma 
pela qual forneceremos informações aos 
elementos loop e paralelo é dependente 
de cada uma das ferramentas. 
Uma estrutura particularmente útil é 
a do tipo AdHoc. Todas as atividades em 
seu interior deverão ser executadas, a 
fim de que o processamento siga adian-
te. Isso nos permite deixar a seqüência 
das execuções fora do controle da no-
tação, atentando-se apenas para que 
todas as atividades sejam executadas 
antes de o fluxo seguir a diante. 
Figura 17 – Ad Hoc
Estruturas do tipo AdHoc são úteis em 
ambientes em que existem diversas ati-
vidades a serem executadas, mas não se 
tem controle sobre a sua ordem. Imagine 
um escritório de advocacia cujas diversas 
partes de um processo, como a obtenção 
de uma certidão, a elaboração de um con-
trato, as cópias de documentos e as demais 
atividades precisam ser executadas. Não se 
pode estipular a ordem em que ocorrerão. 
Ao final, para seguir adiante, importa que 
todas as atividades tenham sido executa-
das. A estrutura do tipo AdHoc garantirá 
esse tipo de comportamento.
15Portal BPM - www.portalbpm.com.br
 Conclusão
Neste artigo, apenas se descreveu o set de elementos gráficos 
da BPMN, sendo que cada um deles ainda tem particularidades na 
execução, permitindo-se um rol muito variado de possibilidades 
na representação, se comparado aos diagramas de atividade da 
UML (criados com outra finalidade). 
Diante dessas valorosas possibilidades, a notação BPMN 
proporciona às ferramentas de desenho o uso de uma repre-
sentação gráfica padronizada. Os benefícios em médio prazo 
será a adoção de uma mesma linguagem visual para desenho 
de processos, de modo a facilitar a comunicação entre equipes 
ou mesmo entre empresas.
Nas próximas edições, analisaremos 
cada um dos elementos com exemplos 
de utilização, bem como os principais 
padrões que podem ser utilizados. 
Além disso, disponibilizaremos uma 
ferramenta de desenho BPMN ex-
clusivamente criada para os lei-
tores do PortalBPM, totalmente 
livre de qualquer tipo de licen-
ça, a fim de que seja possí-
vel explorar essa notação 
de forma conveniente.
Introdução ao BPMN - Glauco Reis
A indústria de soluções de BPMS tem ofertado 
ao mercado brasileiro um número crescente 
de soluções, muitas delas desenvolvidas em 
nosso país. 
 Projetos de BPM
16 Portal BPM - www.portalbpm.com.br
 Principais problemas 
 nas implementações
Por Antonio Dutra
Antonio Dutra Junior tem 42 anos e é natural 
de Porto Alegre. Já trabalhou em desenvol-
vimento de software, foi instrutor, analista 
de sistemas, consultor de empresas e CIO. 
É membro do bpmg.org e atua com BPM 
desde 2002. Atualmente é diretor comercial 
da empresa Gesfin (http://www.gesfin.com.br/), 
que atua com foco em processos da área 
financeira.
17Portal BPM - www.portalbpm.com.br
Principais problemas nas implementações - Antonio Dutra
 Introdução
Nos últimos anos, o mercado saltou de alguns 
poucos produtos pioneiros para uma lista con-
sistente de fornecedores. Fusões ou aquisições 
feitas pelos grandes players de TI acrescentaram 
essas soluções ao seu portfólio, e produtos outro-
ra apenas promissores atingiram a maturidade.
Se, por um lado, a oferta de diversos produ-
tos, com suas características peculiares, é um 
ponto positivo para democratizar o processo de 
seleção, por outro lado, as diversas abordagens 
dos fornecedores para posicionar seus produtos 
vêm aumentando brutalmente a complexidade 
dessa escolha por parte do cliente. Infelizmente, 
ultrapassar bem esta etapa não garante o suces-
so do projeto para o cliente. 
Neste artigo, procuramos avaliar algumas das 
situações que representam as principais fontes de 
aborrecimentos ou mesmo de fracasso nos proje-
tos de BPM. Esses problemas serão posicionados 
em três etapas básicas de um projeto-padrão, 
envolvendo a seleção/projeto, o desenvolvimento 
e a utilização da solução de BPMS.
1. Problemas relacionados com a seleção da 
solução e com o projeto da aplicação de BPM
1.1. Exclusão ou diminuiçãodo papel da 
área de TI
Regra geral, toda a compra de produtos de 
software deveria ser uma iniciativa da área de 
TI, em especial quando nos referimos a produtos 
que atuam no âmbito estratégico e corporativo, 
como os produtos de BPMS.
No entanto, nem todas as empresas possuem 
essa política claramente definida, concedendo a uma 
diretoria de negócios o poder de patrocinar e mesmo 
de definir a compra de uma solução. Essa iniciativa, 
muitas vezes conduzida pela área de negócios com 
a melhor das intenções, coloca a área de TI numa 
posição coadjuvante num tipo de projeto em que 
ela deveria ser a protagonista.
Trabalhando incansavelmente na evangelização 
do mercado, hoje a indústria colhe seus frutos 
através de um número crescente de empresas que 
iniciam projetos de BPM. O termo evangelizar dá 
uma boa idéia do que representa para a indústria 
comercializar produtos vendidos mais como conceito 
do que como produtos. 
Pelas características do BPM, essa evangelização 
não se restringe à área de TI das empresas, pois 
muitos fornecedores orientam suas equipes co-
merciais para, especificamente, apresentarem suas 
ofertas diretamente às áreas de negócio dentro das 
organizações. Essa ação direta nas áreas de negócio 
dos prospects resulta na apresentação de templates, 
de melhores práticas, enfim, de aplicações-exemplo 
que realmente despertam os executivos de negócio 
para o mundo do BPM e seus benefícios. 
É desnecessário dizer que muitas vezes essa 
abordagem resulta em tensões internas, em 
expectativas excessivas e é mais um elemento 
com que a área de TI necessita lidar no seu dia-
a-dia. Além disso, é muito comum que, durante 
o processo de pré-venda e apresentação dos 
produtos, os fornecedores insistam na idéia de 
completa autonomia da solução em relação ao 
envolvimento da equipe de TI da empresa, de 
modo a minimizar ou transmitir a idéia de uma 
facilidade extrema na integração da solução de 
BPMS com os sistemas do cliente. 
Infelizmente, o projeto real se apresenta bem 
mais complexo do que todos gostariam. Projetos 
patrocinados por uma diretoria de negócios mal 
sintonizada com a área de TI darão origem a uma 
relação de dificuldades técnicas intermináveis. Os 
consultores externos pouco ou nada podem fazer 
para construir a necessária integração da aplicação 
de BPMS com os aplicativos do cliente, sem o apoio 
e, sobretudo, sem o comprometimento da área de 
TI com o projeto.
No sentido contrário, os projetos vencedores são 
geralmente conduzidos pela área de TI e se desen-
volvem com total comprometimento do CIO. Um 
CIO com atitude visionária, que não vê nesse tipo de 
projeto uma perda de poder ou de responsabilidades 
sobre os processos, mas sim uma tecnologia capaz 
de oferecer efetivas melhorias para o negócio.
18 Portal BPM - www.portalbpm.com.br
1.2 Ênfase no produto
Inegavelmente, quanto mais distante da área 
de TI o processo de seleção ocorra, maior a 
tendência de que a análise se torne superficial, 
com o enfoque direcionado para as questões de 
negócio, e reduzido finalmente a um comparativo 
de features das soluções. Infelizmente, o risco 
de a escolha recair unicamente pelas features 
do software de BPMS existe mesmo com o en-
volvimento de TI.
Desconsiderar aspectos técnicos da consulto-
ria de implementação, seu histórico de sucessos 
e insucessos, sua equipe técnica, sua capacidade 
de entrega, enfim, avaliar exaustivamente o 
componente de serviços é uma grande fonte de 
problemas para o projeto. Mesmo o melhor dos 
produtos pode ser completamente mal imple-
mentado, resultando num projeto fracassado. 
Em geral, todos os produtos possuem suas 
peculiaridades e existe uma curva de aprendizado 
nada desprezível. Muitos clientes não possuem, 
internamente, pessoal qualificado para resolver 
as questões de ambiente e de desenvolvimento, 
as quais podem ter sido, como dissemos, exclu-
ídas ou minimizadas pelo fornecedor. Estamos 
falando de produtos em franco desenvolvimento, 
com o lançamento de novas versões no mínimo 
anualmente, com o acréscimo de funcionalida-
des e complexidade crescente. Dessa forma, 
torna-se lugar comum que algumas consultorias 
utilizem no projeto mão-de-obra recentemente 
formada na solução ou mesmo ainda em fase de 
treinamento. Esse projeto terá, na melhor das 
hipóteses, o prazo comprometido e, na pior, seus 
objetivos não alcançados.
1.3 Indefinição quanto ao efetivo 
proprietário do processo
Quase todas as apresentações de BPM fazem 
referência à mudança promovida pela troca da 
visão de silos de informação para a visão dos 
fluxos de informação horizontal.
Embora essa mudança seja real, poucas empre-
sas avançaram para dar a efetiva importância aos 
seus macro-processos em detrimento da estrutu-
ra hierárquica tradicional. Ou seja, não realizam 
as mudanças fundamentais no gerenciamento 
das suas organizações. Na maior parte das em-
presas, o poder ainda reside nas suas unidades 
verticais, estruturadas em regiões, em produtos 
ou em funções. E esses feudos ainda guardam 
de modo ferrenho seus territórios, seus recursos, 
suas pessoas e seu conhecimento.
A relação entre Processos Horizontais X 
Empresa Verticalizada é uma contradição inte-
ressante. Os processos horizontais colocam as 
pessoas em uma direção, a administração vertical 
tradicional coloca-as em outra. Confusão e con-
flito que afetam diretamente o desempenho da 
organização. Mesmo nas empresas onde os pro-
cessos foram correta e extensamente mapeados, 
existem dúvidas quanto ao seu real proprietário, 
e mesmo quando ele existe, sua ação efetiva 
sobre o processo ainda esbarra na hierarquia do 
organograma funcional da empresa.
Implementar um projeto de BPM sem que 
exista um executivo do alto-escalão, responsável 
pelo macroprocesso em última instância, com 
força, determinação e autonomia para promover 
as indispensáveis mudanças ocasionadas pelo 
conceito, e, com sua influência, atuar horizon-
talmente durante o processo, vai sugar grande 
parte da energia do projeto e determinar seu 
descrédito na organização.
Empresas que já conduziram projetos vence-
dores elegeram alguns de seus melhores exe-
cutivos para liderar diretamente seus processos 
implementados na solução de BPMS, oferecen-
do-lhes autoridade inclusive sobre o budget do 
macroprocesso, sendo este um estágio bastante 
avançado na maturidade das organizações.
1.4 Seleção dos processos a ser 
implementados
Tão importante quanto a escolha da solução 
de BPMS no mercado é a seleção correta dos pro-
cessos a serem contemplados por ela. Nem todos 
os processos da organização são elegíveis para o 
projeto de BPM. Essa decisão irá, invariavelmen-
te, influenciar uma análise do custo-benefício do 
projeto. Nesse sentido, pode-se pecar por falta 
ou por excesso. 
 Projetos de BPM
19Portal BPM - www.portalbpm.com.br
Selecionando-se processos administrativos ex-
cessivamente simples, a empresa poderá adquirir 
know-how para projetos de maior visibilidade e 
de retorno efetivo para o negócio. Se essa for a 
intenção, não há problemas em se automatizar o 
famoso processo de reembolso ou de despesas 
com viagem. Se não for o caso, o investimento 
será certamente muito alto e o retorno insigni-
ficante, o que não corresponde ao propósito do 
BPM. Por outro lado, selecionar um macro-pro-
cesso gigantesco para o primeiro projeto também 
pode ser demasiado ambicioso e desafiador. 
Em geral a empresa deve considerar o primeiro 
projeto um aprendizado. Além disso, é saudável 
para a consultoria externa ser posta à prova em 
um processo menor. Sendo assim, minimizam-se 
os riscos da implantação imediata, em uma nova 
tecnologia, do processo mais importante para o 
negócio, e dentro de um conceito ainda não total-
mente entendido e absorvido pela empresa.
2 Problemas relacionados ao desen-volvimento da aplicação de BPM
2.1 Definição do escopo do projeto
Algumas empresas nem fazem idéia do conhe-
cimento técnico necessário para se desenhar os 
processos. Outras acreditam que com a contra-
tação de um ou dois estagiários é possível rea-
lizar tal atividade sem prejuízo algum. Diversas 
outras contrataram, em algum momento, uma 
consultoria de mapeamento de processos, a qual 
entregou ao final dos trabalhos diversos proces-
sos muito bem-desenhados. Tudo parece muito 
simples aos olhos da alta gestão.
Infelizmente, tomando-se por base essa docu-
mentação já existente para o projeto de BPM, o 
capricho na documentação encontrada é muitas 
vezes inversamente proporcional ao grau de 
assertividade desses processos. Mas não porque 
o trabalho foi mal feito pela empresa de consul-
toria. Simplesmente porque foram desenhados 
com foco na regra principal do processo e sem 
um completo detalhamento das exceções. Além 
disso, processos são organismos vivos, que evo-
luem e se modificam. Com isso, seus desenhos 
ficaram apenas desatualizados. 
À medida que o desenvolvimento vai se de-
senrolando, fica evidente um desencontro entre 
a teoria e a prática no dia-a-dia do processo 
documentado. Como neste momento o projeto 
já está a pleno vapor, é comum que a equipe 
de desenvolvimento faça essas modificações a 
quente, aumentando a complexidade do desenho 
do projeto e incrementando enormemente a lista 
de exceções. Descrever as exceções do processo 
deve ser sempre um momento para reflexão, e 
esse é o principal obstáculo para a validação dos 
processos desenvolvidos no projeto.
Outro ponto muitas vezes negligenciado diz 
respeito à escolha da notação a ser utilizada no 
mapeamento dos processos. Profissionais expe-
rientes da área de processos são cientes da im-
portância dos padrões escolhidos para a realização 
de um bom trabalho. A utilização de uma notação 
– sem entrar no mérito das vantagens e des-
vantagens de cada uma – deverá estar alinhada 
também com a escolha da solução de BPMS. De 
nada adianta desenvolver um excelente trabalho 
de mapeamento e documentação do processo 
na notação BPMN, por exemplo, e depois tentar 
implementá-lo através de uma solução que não 
oferece suporte ao set completo do BPMN, acar-
retando atrasos pelas alterações nos desenhos e 
codificação de elementos não previstos. 
Percebe-se que as empresas que iniciam um 
projeto de BPM por uma revisão efetiva dos pro-
cessos, desenvolvida por profissionais experien-
tes, independentes e conscientes das demandas 
desse tipo de projeto, diminuem drasticamente os 
problemas do desenvolvimento e o risco geral do 
projeto. Lamentavelmente, nem todas as empre-
sas, fornecedores ou consultorias especializadas 
responsáveis pelo projeto incluem essa etapa em 
seus custos e terminam por suprimi-la.
2.2 Grande complexidade do ambiente 
de desenvolvimento da aplicação
Ao se avaliar uma solução de BPMS, este é um 
dos elementos de mais difícil identificação pelo 
cliente, pois somente na prática serão expostos 
todos os detalhes pertinentes ao ambiente, sua 
infra-estrutura, controle de versão e manipulação 
dos objetos e bibliotecas do projeto.
Principais problemas nas implementações - Antonio Dutra
20 Portal BPM - www.portalbpm.com.br
Na prática, cada solução demanda um ambiente 
particular para o desenvolvimento da aplicação de 
BPM. Alguns desses ambientes apresentam-se ex-
tremamente complexos, e mesmo os projetos con-
duzidos por fornecedores e consultorias experientes 
não conseguem simplificar o ambiente que será 
futuramente administrado pela empresa-cliente. 
Um bom exemplo é a questão da integração 
entre os sistemas do cliente e a aplicação de BPM. 
É natural e muitas vezes obrigatório que os siste-
mas legados da empresa sejam sensibilizados pela 
execução das atividades do processo no nível do 
BPMS. Por mais que os fornecedores dos sistemas 
e da solução de BPMS garantam possuir tecnologia 
e conhecimento da conectividade que permita esse 
tipo de integração, é provável que essa integração 
não ocorra da forma simples e transparente como 
se supunha mas sim através da construção de uma 
camada intermediária de componentes. 
Não podemos deixar de lembrar que, como re-
sultado de um projeto de BPM, a empresa-cliente 
receberá, junto com sua aplicação desenvolvida, 
um novo ambiente para ser mantido pela área de 
TI, não apenas para a produção, mas também para 
o desenvolvimento e testes de integração. Esse é 
um ônus compreensível, mas muitas vezes oculto 
e que vai cobrar seu preço.
3 Problemas relacionados com a utiliza-
ção da aplicação de BPM
3.1 Desinteresse das pessoas
Este fator crítico pode ser mais bem descrito 
como sendo o “engajamento” das pessoas nos seus 
processos. Essa atitude não está associada ao pa-
trocínio da alta gestão ao projeto, mas decorre prin-
cipalmente da forma como o projeto foi conduzido 
e implementado pela equipe que o desenvolveu. É 
fundamental que, durante essa etapa, fique muito 
claro que “as pessoas são os processos”.
Se existe uma expectativa de mudança cultural 
e conseqüente melhoria nos processos que serão 
atendidos pelo projeto de BPM, é importante que 
se tenha também a expectativa de que haverá uma 
mudança envolvendo as pessoas e as maneiras 
como elas atuam na empresa. 
Haverá, certamente, uma alteração na usabi-
lidade da aplicação BPM em relação aos sistemas 
transacionais há muito utilizados pelas pessoas 
dentro da organização. Nesse sentido, pressões 
internas para que a aplicação de BPM se comporte 
como uma aplicação tradicional de um ERP, por 
exemplo, vão recair sobre a equipe do projeto. É 
importante esclarecer que são mundos diferentes 
e que uma aplicação de BPM não tem por objetivo 
substituir a camada transacional das aplicações 
mas sim interagir com ela. 
Ocorre que as pessoas criaram os processos 
e detêm o poder sobre eles. As pessoas estarão 
envolvidas emocionalmente com a mudança nos 
processos. Forneça a elas uma forma pior de se 
realizar as atividades e a organização será surpre-
endida pelo fato de que a pura e simples tecnologia 
não resolverá por si só seus problemas. Mesmo 
com toda a tecnologia disponível, ainda restarão 
as pessoas na base de tudo. Interfaces complexas, 
dificuldade de tratar as exceções e excesso de 
atividades manuais desnecessárias dificultam a 
assimilação da aplicação por aqueles que colabo-
ram no processo.
A própria atividade de revisão e atualização do 
mapa de processos da empresa deve considerar 
que muitos poderão sentir-se “pessoalmente” atin-
gidos pelo apontamento de problemas, gargalos ou 
falhas neste processo. Além disso, a grande maioria 
dos problemas nos processos não é culpa de nin-
guém. É resultado do tempo, da troca de gestão, 
do crescimento da empresa, de fusões e mudanças 
no próprio negócio da organização.
Um bom projeto de BPM deverá, ao seu final, 
obter naturalmente um forte comprometimento 
das pessoas envolvidas, e isso quase sempre só é 
obtido quando esse compromisso acontece desde 
o primeiro dia do projeto.
3.2 Dificuldade para implementação 
das mudanças
Um dos principais apelos do conceito de BPM 
é permitir a evolução progressiva e positiva dos 
processos, a chamada “melhoria de processos”. 
Uma vez que o projeto implementado seja exces-
sivamente rígido, mal documentado ou que seu 
ambiente de desenvolvimento seja demasiado 
complexo, a evolução do processo implementado 
será dificultada. 
 Projetos de BPM
21Portal BPM - www.portalbpm.com.br
Neste quesito, algumas soluções oferecem 
módulos ou funcionalidades de simulação ou 
até mesmo de auto-aprendizado, favorecendo a 
evolução do processo. Qualquer mecanismo que 
possa auxiliar a empresa a implementar melhorias 
contínuas nos processos será de extrema ajuda ao 
projeto. Acreditar na implementaçãode um pro-
jeto que envolva um macroprocesso fundamental 
para a organização e que poderá dispensar quase 
completamente os recursos que trabalharam em 
sua implementação, é um elemento comum em 
muitos projetos. 
É de extrema importância avaliar o quanto a em-
presa será dependente de recursos externos para o 
pós-projeto. Falta de capacidade ou disponibilidade 
de recursos internos para rapidamente implementar 
as mudanças é um problema que vai decretar a 
morte do projeto tão logo as pessoas encontrem ma-
neiras de contornar suas dificuldades e implementar 
as mudanças por meios próprios. As pessoas sempre 
descobrem meios de realizar o trabalho. 
Uma vez que o processo implementado esteja 
condenado, dificilmente será recuperado. 
3.3 Performance da aplicação
Existem processos altamente complexos que, 
no entanto, são executados poucas vezes ao dia. 
Existem outros mais simples, executados centenas 
de vezes ao dia. Entre esses extremos, existem 
processos de toda forma e função, porém cada 
instância de processo tem um ciclo que pode variar 
de horas a anos. O acúmulo dessas instâncias, dos 
documentos anexados em cada atividade, das suas 
trilhas de auditoria e controles internos pode ocasio-
nar uma sobrecarga no ambiente de produção.
Conforme a capacidade deste ambiente, o 
uso continuado da solução implementada poderá 
resultar numa degradação da aplicação, que vai 
determinar seu fim precoce ou onerar a empresa 
com maiores investimentos não previstos na in-
fra-estrutura do ambiente de produção. Durante 
o processo de seleção da solução de BPMS, é 
fundamental deixar o sizing dos ambientes de de-
senvolvimento, testes e produção ser determinado 
pelo fornecedor da solução, comprometendo-o com 
o desempenho das aplicações que serão desenvol-
vidas segundo os levantamentos dos processos, 
tarefas, usuários, papéis, anexos e instâncias que 
serão executadas.
Entretanto, de nada adianta chegar ao final do 
projeto com uma aplicação que apresente proble-
mas de performance, não importa se a responsa-
bilidade possa ser atribuída ou dividida com o seu 
fornecedor. Um mau desempenho é um forte indício 
de um mau projeto. Um desenvolvimento mal 
conduzido, por desconhecimento da solução ou das 
melhores técnicas de BPM pode ser a fonte da má 
performance. Nesse sentido, é muito importante 
realizar testes de carga ao longo do desenvolvimen-
to do projeto e, com eles, avaliar se os caminhos 
escolhidos são realmente viáveis do ponto de vista 
da produção. É muito provável que se identifiquem 
esses problemas ainda em tempo de encontrar 
soluções para contorná-los, evitando-se dividi-los 
com os usuários em tempo de produção, tirando 
a credibilidade do projeto. 
 Conclusão
Embora crescente, o número de projetos de BPM 
ainda está muito distante das previsões dos analistas e 
das necessidades dos fornecedores. Impressiona, en-
tretanto, por alguns dos elementos aqui apresentados, 
que um grande percentual desses projetos não atinja 
seus objetivos, independentemente do porte/segmen-
to do cliente, do quanto ele investiu na solução e de 
qual solução foi escolhida para o projeto. 
Também é importante perceber que boa parte 
dos problemas são inter-relacionados, ou seja, ao se 
incorrer em um dos erros aqui citados, certamente 
outros também virão à tona. Não foi nossa intenção 
abordar a totalidade dos problemas que possam 
eventualmente ser encontrados nos projetos de BPM. 
Procuramos relacionar os principais, aqueles sobre 
os quais tivemos a maior quantidade de relatos ao 
longo dos anos e que estão associados ao projeto 
em si e não a um determinado produto. 
Assim como os processos evoluem e se modifi-
cam, também as soluções de BPMS e a maturidade 
do mercado como um todo se modificam para me-
lhor a cada dia, reduzindo gradativamente o risco 
desse tipo de implementação. Apesar dos riscos e 
da necessária mudança dos paradigmas técnicos e 
organizacionais, acredito firmemente que um projeto 
de BPM ofereça enormes benefícios para a organiza-
ção, e hoje me parece apenas uma questão de tempo 
para sua adoção na maioria das empresas. 
Principais problemas nas implementações - Antonio Dutra
O mercado tem explorado os 
temas BPM, BPMS, SOA, Web 
Services, modelagem de processos 
e mais uma série de tecnologias que 
tem se popularizado mais recentemente. A 
toda essa inovação se mistura a evolução 
da orientação para objetos como prática de 
construção de sistemas, e a união de antigos 
e novos paradigmas vem acenando como 
uma possível nova forma de construir siste-
mas baseados em partes de todas es-
sas tecnologias. Vamos explorar 
um pouco desse novo mundo, 
prospectando possibilidades 
para um futuro próximo, bem 
como para a atualidade. 
 BPM BPMS SOA
22 Portal BPM - www.portalbpm.com.br
 Introdução ao 
BPM, BPMS e SOA
Por Glauco Reis
Consultor em Java e metodologias OO, es-
pecializou-se em plataforma IBM. Com uma 
experiência de quase 10 anos em tecnologias 
Java e quase 20 anos em tecnologias OO, tem 
mais de 150 artigos publicados em revistas 
especializadas. Trabalhou em projetos de sele-
ção e implantação de soluções BPMS, além de 
ser especialista em Web Services e ter atuado 
como arquiteto principal na criação de uma 
solução BPMS nacional.
23Portal BPM - www.portalbpm.com.br
Introdução ao BPM, BPMS e SOA - Glauco Reis
A orientação para objetos, como tec-
nologia, data da década de 1960. Em 
1969 já existiam compiladores comerciais 
para a linguagem Smaltalk, por exemplo. 
Durante muitos anos ela vem evoluindo, 
passando por novas abordagens como pa-
drões de desenvolvimento e arquiteturas 
componentizadas. Mas, se as linguagens 
OO existem desde a década de 1970, por 
que apenas recentemente temos visto o 
mercado manifestar-se em profundidade 
sobre esse tema? 
Embora a linguagem C seja um sucesso 
na criação de softwares de base (sistemas 
operacionais, servidores web, compilado-
res, etc.), os programadores em linguagem 
C não migraram para a linguagem C++, 
sobretudo no que se refere a software 
de base. Basta reparar que, ainda hoje, 
a maioria dos projetos de base ainda se 
baseia na linguagem C. 
A popularização e a massificação das 
linguagens OO aconteceram quando a Web 
se difundiu como uma tecnologia para cons-
trução de aplicativos. Como os servidores 
de aplicação são criados em linguagens OO 
(principalmente Java e agora C#), os blocos 
de código também foram forçados a adotar 
o mesmo paradigma, com APIs fortemente 
presas à arquitetura dos servidores. Como 
os servidores de aplicação trouxeram van-
tagens competitivas para a criação de apli-
cativos Web, se comparados a tecnologias 
mais “tradicionais”, como PHP, Perl e outras, 
houve um “impulsionamento” no caminho 
contrário, na tentativa de suprir a defici-
ência do mercado quanto ao conhecimento 
das tecnologias OO. 
Veja o caminho natural seguido pelo 
mercado: aplicativos para internet (Web) 
são os veículos mais promissores em pla-
taforma para criação de aplicações comer-
ciais. No entanto, a forma mais segura e 
portável para se criar um aplicativo Web 
é a utilização de servidores de aplicação, 
que forçam a rígidas práticas de desenvol-
vimento OO. Logo, precisamos aprender OO 
e as linguagens envolvidas, para estarmos 
“sintonizados” com esse tipo de aplicação. 
Perceba que o caminho é inverso, partindo 
do resultado final desejado até as necessi-
dades para sua realização. 
Por mais paradoxal que possa 
parecer, as l inguagens OO foram 
impulsionadas pela WEB!
Isso é até natural para quem desenvolve 
em Java, por exemplo, já que, ao menos no 
Brasil, a quase totalidade do mercado Java é 
absorvida por desenvolvimento Web, seguido 
de uma evolução surpreendente do J2ME.
Nesse caminho, o mercado tem vendido, 
ao longo dos anos, o que se concebiacomo 
os grandes benefícios da adoção das tec-
nologias OO, tais como maior facilidade na 
manutenção e evolução, melhor estruturação 
do código, maior qualidade e facilidade para 
evolução dos sistemas. Embora pouco com-
preendido pelas áreas de negócio, o capital 
vinha fluindo normalmente, uma vez que 
se acreditava ser essa a melhor forma de 
construir e manter sistemas.
No presente momento, acontece que os 
sistemas criados e mantidos nessa estru-
tura têm custos de manutenção mais altos, 
sendo que essa manutenção não é tão 
facilitada quanto se pregava. Adotar uma 
metodologia como a RUP (ou UP) envolve 
um conjunto de disciplinas tão grande, que 
a quantidade de especialistas envolvidos 
acaba algumas vezes tornando inviável a 
sua implantação. Como forma de economia, 
freqüentemente ouvimos o termo “custo-
mizar a UP” ao negócio. 
Entretanto, como em uma manutenção 
é necessário navegar por várias etapas do 
processo, é muito comum que os custos 
desses serviços também se elevem. Há 
ainda o fator profissional, que faz que um 
dialeto ou API utilizada por um programa-
dor leve algum tempo de assimilação por 
outro, de modo a dificultar a manutenção 
por qualquer membro da equipe. Além dis-
so, há o fator diversificação das APIs, quan-
do saímos das metodologias e estudamos 
as linguagens de programação.
 
Se olharmos apenas para as APIs que 
podem ser utilizadas como camada de apre-
sentação em um aplicativo Web em JAVA, 
teremos uma quantidade bastante grande 
de siglas, como JSP, AJAX, JSF, STRUTS, e 
por aí vai. Uma tecnologia como o Java é 
fascinante e rica, mas estamos chegando à 
beira de um colapso, visto que a diversidade 
é tamanha que algo pregado como benefício 
acaba dificultando a padronização de aplica-
ções. Talvez seja o mesmo problema ado-
tadodetectado pelo Linux, como tecnologia 
para desktop. A diversidade de possibilidades 
de interfaces gráficas é tão grande, que a 
média dos usuários prefere a interface pa-
drão do Windows, por exemplo.
Todas essas tecnologias e gastos associa-
dos (OO, Java, RUP, etc.) não têm uma visi-
bilidade considerável nas áreas de negócio. 
Atualmente, é difícil vender para a 
área de negócios um projeto com custos 
e prazos duas vezes maiores, acenando 
como vantagem competitiva, apenas 
a orientação para objetos. O mercado 
globalizado está forçando o ritmo de 
evolução dos sistemas, de modo a torná-
los mais ágeis, ainda que paguem como 
preço de perda de qualidade. Poucas 
metodologias OO pregam velocidade 
como benefício, e quando o fazem ex-
ploram uma grande versatilidade do 
programador, como a XP, por exemplo.
Em paralelo a tudo isso, mais ou me-
nos na época em que grandes avanços 
da OO aconteceram (1980/1990), co-
meçaram a surgir estudos para melhoria 
na qualidade das empresas (Davenport 
1990; Hammer 1990). Nessa época, ini-
ciou-se a discussão sobre o modo de gerir 
empresas, não de forma departamental, 
mas como processos. A idéia consistia 
em que cada funcionário – consciente 
de seu papel na empresa e de como este 
afeta o cliente de alguma forma – fizesse 
parte de um processo que vai além das 
atividades departamentais. Durante esse 
período, a gestão por processos teve uma 
grande evolução. 
As duas linhas tecnológicas seguiram ca-
minhos paralelos, porque, afinal de contas, 
não se relacionavam de forma alguma. As 
propostas de divisão por processos e me-
lhorias na gestão corporativa relacionavam-
se mais a disciplinas de administração, ao 
passo que as evoluções nas tecnologias OO 
estavam mais relacionadas à TI.
Em algum ponto da história, as evo-
luções em segmentos específicos da in-
formática começaram a fazer que a linha 
dos processos convergisse lentamente 
para a área de TI. Na verdade, os estudos 
ainda continuam restritos a áreas da ad-
ministração, mas surgiram ferramentas 
que permitiam à TI colocar as disciplinas 
mais facilmente em prática
 SOAP 
(Simple Object Access Protocol)
Um desses marcos evolutivos foi o 
SOAP, cr iado em 1998, em especia l 
para permitir interoperabil idade entre 
24 Portal BPM - www.portalbpm.com.br
 BPM BPMS SOA
25Portal BPM - www.portalbpm.com.br
Introdução ao BPM, BPMS e SOA - Glauco Reis
tecnologias OO. A Microsoft foi uma das 
criadoras e precursoras dessa evolu-
ção, visto que havia grande interesse 
para que o .NET fosse interoperável 
com objetos Java. O SOAP também 
permit ia comunicação sobre a inter-
net, algo muito desejável na época. 
Os protocolos de então (e a regra vale 
a té ho je) não t ra fegavam na rede, 
sendo que duas empresas parceiras 
que necessitassem da interação entre 
s istemas OO não t inham uma forma 
adequada para fazê-lo. 
Como o SOAP permitia comunicação 
entre tecnologias não OO, mudou-se o 
foco para serviços, em vez de objetos. 
Dessa forma, ficaram conhecidos como 
Web Services, uma alusão à capacidade 
de prover serviços por meio da Web. 
Também desapareceu qualquer alusão a 
ser ou não orientada para objetos, per-
mitindo diversif icação de l inguagem. 
Essa fo i uma adequação meramente 
mercadológica, já que não se alterou a 
tecnologia, mas apenas o foco de onde 
poderia ser aplicada. 
Naturalmente a tecnologia evoluiu 
ao longo do tempo, acrescentando-se 
outros protocolos como WSDL e UDDI, 
adicionando-se funcionalidades que es-
tavam deficientes em implementação. 
Mais recentemente, foram acrescidos 
de mecanismos de segurança, transa-
ção, entre outros.
O sucesso do SOAP foi duvidoso, uma 
vez que, até hoje, o protocolo demanda 
grande esforço computacional e ainda é 
pouco seguro. Mesmo assim, a tecnolo-
gia traz vantagens sobre a abordagem 
tradicional de conexão entre objetos. A 
maior delas, talvez, é a de criar um bai-
xo acoplamento entre os componentes, 
destacando-se que o SOAP conseguiu 
praticamente zerá-lo, meta que a OO 
vem buscando freneticamente. 
Os Web Services e SOAP permi-
tem que os objetos sejam comple-
tamente desacoplados, independen-
temente até mesmo da tecnologia 
adotada.
Isso é altamente desejável em um 
ambiente de mudanças freqüentes. An-
tes do SOAP, nenhuma tecnologia espe-
cífica obteve sucesso nesse segmento. 
Tecnologias específicas como EJBs, Cor-
ba, RMI, DCOM forçam um acoplamento 
entre o código do cliente e o código do 
objeto, mediante programação. Esses 
códigos precisam ser recompilados e 
republicados a cada mudança, de modo 
a forçar, também a cada mudança, um 
processo de manutenção que envolve 
diversas áreas, entre elas partes da TI. 
A idéia de se ter elementos localizáveis, 
totalmente desacoplados e passíveis de 
reutilização em diversas situações, foi 
tão bem aceita que se tornou a base 
para o SOA. 
 SOA
O SOA foi uma outra inovação advin-
da de uma nova visão computacional, 
cuja intenção é tornar disponíveis as 
principais idéias do SOAP em um am-
biente corporat ivo ( le ia o art igo de 
Leandro Yung nesta edição). Trata-se 
de uma arquitetura em que podem ser 
publicados serviços em um ambiente 
de fácil localização, comparti lhamen-
to, e ainda podem ser descritos inde-
pendentemente de programação e/ou 
l inguagens. 
Embora tecnicamente não sejam de-
pendentes (leia a entrevista com Tho-
mas Erl nesta edição), o SOAP é uma 
forma de implementar um ambiente 
SOA com todas as suas características 
26 Portal BPM - www.portalbpm.com.br
 BPM BPMS SOA
de disponibil ização, publicação, locali-
zação de serviços. Pode-se implemen-
tar esse ambiente de outras formas, 
por meio de outras tecnolog ias. No 
entanto, ter um ambiente com serviços 
reuti l izáveis, com acoplamento zero, é 
uma forma de reduzir custos de manu-
tenção, o que a TI vem perseguindo nos 
últimos anos. Uma vez que se tem um 
ambiente em que o acoplamento entre 
os objetos é zero, é possível agrupá-los 
de forma mais conveniente,“orques-
trando os serviços”.
 BPEL
Era necessária uma fórmula que permitisse 
a execução de serviços de maneira coorde-
nada, de modo a passar informações entre si 
e a gerar um resultado final mensurável. Na 
programação tradicional, isso se faz median-
te a criação de códigos que se conectam aos 
objetos. Esses códigos obtêm informações e 
as repassam a outros objetos. Um programa 
orientado para objetos é exatamente isso, ou 
seja, uma seqüência de objetos se comunican-
do e passando informações uns aos outros. 
A proposta do BPEL (Business Process Execu-
tion Language) ou BPEL4WS é executar esses 
serviços em seqüência, mas por meio de um 
mecanismo não programático, reduzindo cus-
tos de manutenção causados por alterações 
freqüentes nos códigos. Sua versão inicial 
foi liberada em 2002, exatamente como pro-
posta para a execução de serviços WEB em 
sequência.
O caminho adotado foi o de arquivos XML 
que descrevem como os serviços se comunicam, 
definindo-se mecanismos para armazenar infor-
mações de forma não programática, e criando-
se engines que interpretam o XML, de modo a 
atuar como se fossem o programa em si. 
Em resumo, os engines BPEL funcionam 
como grandes interpretadores de código 
XML, que executam atividades como se 
fossem um programa, mas de manutenção 
facilitada, já que apenas esses XML são 
afetados nesta atividade.
Não utilizar tecnologias programáticas nos 
traz o benefício de se ter ferramentas de 
criação gráfica mais simples, que podem 
ser geridas e até mesmo mantidas pelas 
áreas de negócio.
Talvez o segredo de toda essa revo-
lução por que estamos passando seja 
aproximar a TI da área de negócios. 
Mas não aproximar apenas de modo a 
permitir comunicação entre elas, mas 
também de forma que partes do siste-
ma possam ser criadas ou gerenciadas 
fora do ambiente de TI, pelos próprios 
profissionais de negócio.
 BPMN
As tecnologias gráficas para construção 
a que nos referimos anteriormente evo-
luíram intensamente pela notação BPMN. 
Enquanto o BPEL é um formato binário para 
execução de serviços em sequência, o BPMN 
(Business Process Modeling Notation) é a 
notação gráfica que nos permite representar 
como os serviços irão interagir (leia o arti-
go Introdução ao BPMN nesta edição). Elae 
define os símbolos e como estes devem ser 
conectados para gerar algo representativo 
visualmente. Por outro lado, o BPMN não 
define formatos de arquivos nem mesmo 
características particulares de ambientes de 
execução, como execução em multitarefa, 
tasks ou threads. 
Porém, nem tudo é tão maravilhoso assim, 
uma vez que tanto BPEL como BPMN evoluí-
ram de forma independente, e ainda hoje te-
mos algumas representações neste que não 
têm contrapartida naquele. Mas sem dúvida 
os dois padrões estão se unindo para tornar 
a execução de serviços uma tarefa visual. 
Talvez, por essa característica visual, hoje o 
BPMN seja o que mais se indentifique com as 
soluções BPMS. Há um consenso no mercado 
sobre o fato de que a notação gráfica para 
as soluções BPMS será o BPMN. 
27Portal BPM - www.portalbpm.com.br
Introdução ao BPM, BPMS e SOA - Glauco Reis
BPMS
Desenho
(BPMN)
Orquestração
(BPEL4WS)
Componentização
(SOA)
Realinhamento
BPMN + SOA
Monitoramento
(DashBoards)
 RETORNANDO AOS PROCESSOS
 A evolução dessas tecnologias que explo-
ramos, entre elas o BPEL, BPMN, SOA, SOAP, 
WSDL, UDDI, BPML e muitas outras, tornou 
possível a realização das teorias idealizadas por 
Davenport, Hammel e Porter. Antes, o que seria 
complicado de implementar por falta de ferra-
mental, começou a se tornar realidade. Com 
esse agregado de tecnologias, pode-se hoje de-
finir e orquestrar processos, desenhando-os em 
BPMN e colocando-os para executar em BPEL, 
pode-se simular ou acompanhar a execução dos 
processos obtendo-se métricas que auxiliam o 
realinhamento do negócio e, por fim, pode-se 
realinhar rapidamente o negócio alterando a 
forma como os serviços são orquestrados. Em 
um ambiente ideal, a área de TI torna-se uma 
fábrica de serviços, enquanto a área de negó-
cios conecta esses serviços de forma a gerar o 
resultado esperado ao negócio.
 
De modo geral, a indústria de soluções de CRM, 
ERPs e aplicativos corporativos está se aproximan-
do desse conceito de serviços, agregando produtos 
de mercado ou evoluindo para se tornar soluções 
BPMS por si. Isso traz grande valor agregado para 
as empresas, uma vez que permite a integração 
de diversos sistemas da empresa, ou até mesmo 
a criação de novos aplicativos a partir de blocos 
ou serviços já existentes. Sejam esses serviços 
criados pela TI ou os blocos fornecidos por uma 
solução ERP ou CRM, todos podem ser executados 
em seqüência (orquestrados) para a realização de 
uma atividade maior. Em curto prazo, existem os 
custos de implementação dessa nova abordagem, 
mas em médio e longo prazo, a tendência é de 
grande economia, já que os mesmos serviços 
serão reaproveitados diversas vezes. 
Além dos benefícios em se tratando 
de manutenção, como os serviços são 
orquestrados a partir de servidores es-
pecíficos, a maioria deles permite tomar 
métricas a partir de um determinado 
processo. Imaginemos um processo de 
vendas: o que toma mais tempo nesse 
tipo de processo? É a interação entre 
vendedor e cliente? É a liberação de cré-
dito? Quais vendedores conseguem uma 
melhor performance em um processo de 
vendas? Quais as principais razões para 
cancelamentos por parte do cliente?
Todas essas perguntas são muito per-
tinentes ao gestor do negócio, visto que, 
partindo-se dos pontos de falha ou lentos, 
pode-se otimizar um processo, reduzin-
do-se custos e aumentando-se os lucros. 
Esse é o discurso esperado pelas áreas 
de negócio, e não se utilizará o padrão de 
desenvolvimento (design pattern) Abstract 
Factory ou Memento, que não são com-
preendidos e, na verdade, nada têm a ver 
com o negócio. 
Com uma solução BPMS, pode-se colo-
car “termômetros” em pontos específicos 
de execução, coletando-se informações 
capazes de serem condensadas em gráfi-
cos de tempo real, utilizados na tomada 
de decisão. Isso a custo muito baixo, já 
que se exige um mínimo de envolvimento 
com códigos, normalmente criados de for-
ma visual, além de, usualmente, isso ser 
proporcionado pelos DashBoards, que são 
gráficos gerados a partir de informações 
de um processo ainda em execução. 
Atualmente, a tomada de informações 
pode ser feita num momento posterior, 
analisando-se logs após a execução do 
programa (algum programa de BI), o que 
é ruim visto que o cliente já foi afetado, ou 
solicitando-se à área de TI uma alteração 
para a inserção de um ponto de medida em 
algum código, o que também é ruim já que 
pode levar algum tempo para a implemen-
tação, podendo-se e causar erros (bugs) 
na execução do código alterado.
28 Portal BPM - www.portalbpm.com.br
 BPM BPMS SOA
Esse é o maior apelo que as soluções 
BPMS têm trazido ao negócio. Em vez 
de vender particularidades de uma im-
plementação, como faz a OO, elas se 
propõem a ser ferramentas de auxílio 
e otimização do negócio. 
Mesmo antes de um grupo de proces-
sos ser finalizado, pode-se tomar medi-
das corretivas com base nas informações 
de um DashBoard, por meio de painéis 
de controle a medirem pontos específicos 
na execução. É como se colocássemos 
termômetros em pontos específicos de 
execução, que podem ser inseridos ou 
retirados a qualquer momento, e que 
funcionam como os aparelhos que acom-
panham um paciente durante uma cirur-
gia. Se o médico for esperar o término de 
um procedimento cirúrgico para adotar 
uma medida corretiva, pode custar a 
vida do paciente, embora auxilie futuras 
experências médicas. Para isso existem 
especialistas que, durante a cirurgia, mo-
nitoram as condições vitais do paciente 
e tomam medidascorretivas para asse-
gurar o sucesso do procedimento. 
A meu ver, partes da metodologia OO e 
UML deverão se unir nos próximos anos, 
criando-se uma nova forma de se cons-
truir sistemas, talvez o POAD (Process 
Oriented Analisys and Design). 
Uma vantagem proporcionada pela 
maioria das soluções BPMS é que, uma 
vez encontrado um erro na execução de 
um processo, pode-se alterar o fluxo de 
execução, mantendo-se os processos já 
em execução no desenho antigo, e no-
vas execuções já adequadas ao desenho 
reajustado. Hoje, é muito complicado 
de se implementar esse tipo de fun-
cionalidade em soluções tradicionais. 
Normalmente, coloca-se o sistema em 
“BETA” teste para alguns clientes, de-
purando-se erros finais. Caso nenhum 
erro grave seja detectado, coloca-se o 
sistema em “PRODUÇÃO”. No entanto, 
uma vez encontrado algum problema 
no sistema em produção, não há outra 
solução a não ser retornar um passo, 
promovendo grande esforço para movi-
mentação de dados de uma versão atual 
para uma versão anterior. Isso envolve 
grande empenho da TI e, normalmente, 
não é computado no esforço de desen-
volvimento de um sistema.
Em soluções BPMS, esse tipo de ma-
nutenção é facilitada, uma vez que cada 
processo em execução tem um fluxo 
distinto de execução (Se BPEL, será um 
XML). Podemos ter diversas versões do 
processo em execução em um dado mo-
mento, sem que uma afete a outra. Isso 
é muito popularizado como vantagem 
das soluções BPMS e, normalmente, a 
velocidade com que as alterações são 
feitas permite alterações rápidas no ne-
gócio frente à concorrência. Usualmente, 
chamamos a isso de “realinhamento dos 
processos de negócio”. 
29Portal BPM - www.portalbpm.com.br
Introdução ao BPM, BPMS e SOA - Glauco Reis
 Conclusão
Naturalmente, nem todo esse caminho está consolida-
do, e diversas “estradas” ainda estão sendo construídas 
para a idealização desses modelos. Hoje, por exemplo, o 
tempo para a criação e operacionalização de cada um dos 
serviços ainda é mais lento do que nas abordagens tradi-
cionais. Ainda falta uma metodologia para identificação ou 
“granularização” desses serviços, falta experiência nos pro-
fissionais de TI para criação e manutenção dos serviços e, 
na maioria das soluções BPMS, eles devem ser codificados 
manualmente. Há divergência na notação gráfica adotada 
pelas soluções BPMS, e os formatos binários tendem a ser 
incompatíveis, tornando a empresa refém de uma solução, 
uma vez adotada. 
Entretanto, todo esse processo ainda está em 
desenvolvimento, e muito é esperado quanto à 
evolução nos ferramentais para suporte a essas tec-
nologias. A maioria dos fabricantes está orientada e 
comprometida em entregar soluções que permitam 
a operacionalização dessa visão.
Uma visão muito interessante proposta por Martin 
Fowler é que, embora a maioria dos sistemas com os 
quais interagimos seja puramente visual, a construção 
desses sistemas ainda demanda uma dispendiosa ma-
nutenção de arquivos textuais. Nenhuma das linguagens 
ou tecnologias para geração de código conseguiu, até o 
momento, adotar um paradigma totalmente visual de 
construção. 
Nesse sentido, as soluções BPMS têm buscado for-
mas visuais de representação, assim como o MDA e o 
UML executável. Há uma tendência de união entre elas, 
e devemos esperar, nos próximos anos, formas mais 
visuais, simples e rápidas de se construir sistemas. 
Thomas Erl, maior autoridade mundial em 
SOA e autor mais vendido sobre o tema pela 
Prentice Hall, é fundador da SOA Systems 
Inc., uma empresa com foco na implemen-
tação de SOA. Erl veio ao Brasil a convite 
da Savoir Faire, que tem poder tecnológico 
e foco estratégico de negócios na dissemi-
nação do SOA no país, e concedeu uma en-
trevista exclusiva a PortalBPM.
^ Entrevista
30 Portal BPM - www.portalbpm.com.br
^ Entrevista com 
 Thomas Erl
31Portal BPM - www.portalbpm.com.br
( PortalBPM - Você poderia des-
crever sua experiência nesta área, sobre-
tudo com o SOA?
) Thomas Erl - Minha experiên-
cia vem dos vários livros sobre SOA que 
venho escrevendo (www.soabooks.com), 
inclusive do novo livro chamado SOA: 
Principles of Service Design, que será 
publicado em julho de 2007 pela Prentice 
Hall. Nós temos uma empresa chamada 
SOA Systems Inc. (www.soasystems.com) 
em Vancouver, no Canadá, especializada 
em consultoria e treinamento em SOA. 
Além disso, fomos convidados pela Savoir 
Faire (www.savoirfaire.com.br) para apre-
sentar um Workshop sobre SOA, sobre 
computação orientada a serviços e sobre 
os princípios do SOA. 
( PBPM - Qual a importância, para 
uma empresa, da migração para o SOA? 
) TE - Cada organização tem suas 
metas, requisitos e circunstâncias únicas. 
O SOA nem sempre será a melhor esco-
lha para todas as empresas. Entretanto, 
recomenda-se que cada organização se 
aculture em torno da tecnologia, no in-
tuito de se fazer uma escolha consciente. 
Para empresas em uma fase avançada na 
transição para o SOA, existe um ótimo 
potencial para estabelecer uma transição 
fácil, efetiva em relação a custos e com 
excelentes respostas para a corporação. 
( PBPM - Freqüentemente os 
custos crescem quando o SOA é escolhido. 
Como reduzi-los em uma implementação 
de SOA?
) TE - Uma iniciativa SOA é tipica-
mente caracterizada como um investi-
mento de longo prazo. Normalmente ele 
necessita de mais tempo e dinheiro para 
criar um conjunto de serviços de qualida-
de dentro da empresa. Todavia, quando 
conduzido da forma correta, esse tipo de 
iniciativa resulta em repetidos retornos 
sobre investimento nos anos seguintes. 
Os serviços são padronizados e operacio-
nalizados de forma interoperável, propor-
cionando a eles repetidas combinações 
ao longo do tempo. Isso, adicionado à 
característica centrada no negócio da 
tecnologia, permite a uma empresa orien-
tada a serviços evoluir alinhada com o 
seu principal negócio. Um ambiente desse 
tipo pode oferecer vantagens competiti-
vas, incluindo o estado da arte quanto à 
agilidade organizacional. Se uma empresa 
está interessada em aprimorar seu am-
biente de TI e em investir em benefícios 
estratégicos, SOA e computação orientada 
a serviços são boas escolhas. Inicialmen-
te, se sua empresa deseja explorar o SOA 
sem promover grandes investimentos 
financeiros de imediato, deve-se consi-
derar a criação de um programa piloto, 
ou documentar um conjunto de serviços 
que seja aplicável à empresa como um 
todo. Essa abordagem pode também ser 
benéfica, pois permite que a área de TI 
se ambiente com a demanda e com a di-
nâmica dos projetos SOA.
( PBPM - A segurança e a perfor-
mance são dois dos principais pontos dis-
cutidos quando se fala sobre SOA. Como 
a tecnologia está evoluindo para resolver 
esses problemas?
) TE - A maioria das discussões nes-
sas áreas tem sido em torno do uso de 
serviços Web (Web Services). Antes de 
responder a esta questão, gostaria de 
atentar para o fato de que SOA e Web Ser-
vices são coisas diferentes. SOA e Com-
putação Orientada para Serviços (Service 
Oriented Computing) representam abor-
dagens para computação distribuída que 
são baseadas em um princípio chamado 
“orientação para serviços” (www.whatis-
soa.com). Você pode construir SOA a par-
tir de qualquer plataforma, incluindo Java, 
.NET, como também a partir de Web Ser-
vices. Portanto, Web Services fornecem 
uma das possíveis opções de implementa-
ção para esses serviços e representam a 
opção de implementação que a maioria 
Entrevista com Thomas Erl - PortalBPM
32 Portal BPM - www.portalbpm.com.br
^ Entrevista 
das empresas está interessada em explo-
rar. Quanto à performance, pode haver 
problemas na sua adoção, dependendo, 
em especial, do ambiente de execução 
e de sua escalabilidade. Algumas tec-
nologias utilizadas nos Web Services