6.

2 Componentes de uma
plataforma de BPMS

RESUMO
Aula: 6.2 Componentes de uma plataforma de BPMS
Tutor: Eduardo Britto, MSc, PMP, OCEB, CDIA+
Nmero de slides: 42

Durao da Aula: 55 min

SLIDE 1

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 2

Boa noite. Sejam bem vindos segunda aula do mdulo 6 do nosso curso sobre tecnologia e BPM.
Nessa aula ns iremos aprofundar um pouco mais os conhecimentos a respeito dos componentes tecnolgicos que
do apoio ao ciclo da gesto por processos.
Iremos tambm falar um pouquinho sobre a arquitetura orientada a servios ou SOA, e conhecer qual a relao
que existe entre SOA e BPM.
Finalmente, iremos fechar a aula dando um overview dos conceitos-chaves que apresentamos hoje.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 3

Ento, vamos comear conhecendo os componentes tecnolgicos e ferramentas que nos ajudam na gesto por processos.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 4

Existem inmeras ferramentas e tecnologias que apoiam o ciclo de gesto por processos, vamos separ-las em trs grupos,
que sero vistos ao longo deste captulo. O primeiro grupo o de ferramentas de BPA, ou Business Process Analys, que
ajudam o usurio do negcio a mapear, desenvolver, modelar e documentar o seu processo de negcio. O segundo grupo
so os padres utilizados na gesto por processos sendo que os dois mais difundidos so o padro BPMN, para modelagem
de processos, e o padro BPEL, para automao e integrao de sistemas. O terceiro grupo composto pelas ferramentas
que so utilizadas para automao e a melhoria continua dos processos onde podemos citar tecnologias como, BPMS, BRM,
BAM e SOA.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 5

Vamos comear ento pelos BPAs. Os BPAs normalmente so utilizados para apoiar o usurio de negcio nas etapas de
mapeamento e redesenho de processos. Dentro do BPA possvel representar toda a estrutura de processograma da
organizao, comeando pela cadeia de valor e descendo at os detalhes de cada processo, e chegando ento nas suas
atividades operacionais. Alm disso, os BPAs so importantes repositrios de processos que permitem que os processos
sejam organizados e armazenados dentro de um banco de dados, com controle de acesso e autenticao de usurio. Ao
definir um processo no BPA o analista pode definir e detalhar tambm os indicares que compe e que iro medir esse
processo, bem como identificar claramente os pontos do processo onde esses indicadores sero alimentados. De acordo com
o produto que est sendo utilizado possvel, inclusive, conectar os indicares definidos no BPA na base de dados gerada por
uma soluo de BPMS, permitindo assim, que seja atualizado dentro do BPA os dados reais do processo. Outros trs pontos
importantes de solues de BPA, que veremos agora em maiores detalhes, so os pontos de documentao, simulao e
publicao de processos.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 6

Em termos de documentao, possvel, no BPA, que a organizao identifique para cada tipo de elemento utilizado para
representar o processo, quais as informaes e atributos que devem ser preenchidos para se documentar esse elemento. Em
um processo em BPMN, por exemplo, possvel definir que informaes devem ser preenchidas quando o usurio estiver
documentando uma atividade humana. Alm disso, por ser um repositrio de processo, o BPA se torna o local onde so
armazenadas e consultadas, em termos organizacionais, todas as informaes a respeito de um processo de negcio. Essa
consulta pode ser realizada tanto atravs do acesso a ferramenta, como, tambm, atravs da gerao de documentao em
relatrios. Muitos BPAs possuem ambientes que permitem que se defina templetes de documentao que descrevem como
um documento de especificao de processos deve ser gerado. Assim, a qualquer momento, com esse template definido,
possvel com um clique de boto solicitar a gerao de um documento de especificao funcional automaticamente.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 7

Outro recurso importante dos BPAs a sua capacidade de realizar a simulao de processos. Na simulao o usurio
consegue modelar o seu processo e entrar com informaes que serviro de premissas para avaliar como o processo ir se
comportar na configurao em que ele foi modelado. Para realizar uma simulao, contudo, necessrio que o analista entre
com dados bastante detalhados sobre o processo, tais como o volume de instancias que se espera que esse processo seja
executado por dia, por hora ou minuto, a quantidade de recursos disponveis para a execuo de cada atividade, o tempo
dispendido por cada recurso para realizar uma determinada atividade e para cada gate incondicional a probabilidade do
processo seguir por um caminho A ou por um caminho B. A partir desses dados, possvel simular o comportamento do
processo, e avaliar se ele ir executar da forma esperada. Com recursos de simulao, conseguimos avaliar o comportamento
de um processo sem que ele tenha que ser colocado em produo, minimizando assim, os custos que a empresa teria se
realmente fosse utilizar aquele processo na prtica.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 8

Outra importante funcionalidade dos BPAs so os seus recursos de publicao. Atravs delas possvel realizarmos a
publicao dos processos de negcio para toda a organizao atravs de padres conhecidos como portais internos ou
pginas da web. Nesses portais possvel tambm criarmos mecanismos de controle de acesso de modo a definirmos quem
poder consultar cada processo. No momento de redesenho dos processos a equipe de analistas responsveis pelo
redesenho poderia utilizar esse recurso para publicar o processo e colher sugestes de melhorias com outros usurios da
empresa. Para isso, essas ferramentas possuem recursos de colaborao que permitem que os usurios, autorizados,
comentem o processo sem que este seja efetivamente alterado. Ao final dessa etapa de coleta de sugestes a equipe de
redesenho pode, ento, analisar cada item e avaliar quais sugestes ou criticas ir colher.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

SLIDE 9

De uma maneira geral, os BPAs so utilizados pelas reas de negcios, nas etapas de mapeamento e redesenho de processos
e, sempre que possvel, ele tambm pode ser utilizado pelo analista de sistemas nas etapas de modelagem para automao.
Via de regra, o envolvimento da rea de TI na aquisio de um BPA costuma ser de mdio a nulo, dependendo do quanto o
escritrio de processos da empresa tem autonomia para escolher a melhor soluo para si. Contudo, um grande problema
que costuma acontecer de forma muito frequente nas organizaes a rea de negcios escolher uma soluo de BPA que
incompatvel com a soluo de automao de processos escolhida pela rea de TI, gerando, em muitos casos, inmeras
situaes de retrabalho e de falta de compatibilidade. Um outro ponto importante que o modelo desenhado no BPA no
um modelo verificvel na vida real. Como a gente costuma dizer, o papel aceita tudo, e o BPA tambm, ou seja, no
possvel se ter a garantia que o processo desenhado no BPA realmente exequvel visto que o processo um mero
documento e que somente poder ser validado e colocado em prtica no momento da sua implantao.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

10

SLIDE 10

So exemplos de ferramentas de BPA o ARIS Business Architect, Oracle BPA, Websphere Modeler e o Corel e Graphics.
comum que algumas pessoas acharem que o Visio uma ferramenta de BPA. O Visio uma excelente ferramenta para a
representao de processos, mas no pode ser considerada como uma soluo de BPA, pois no tem as inmeras
funcionalidades esperadas por ele, tais como o conceito de repositrio de processos, dissimulao ou digesto de
indicadores.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

11

SLIDE 11

Entrando agora nos padres vamos comear falando do BPMN, o Business Process Model and Notation. O BPMN uma
notao grfica de representao de processos de negcios. Ao ser elaborada, os seus autores buscaram atender as
seguintes premissas: construir uma notao de fcil compreenso que se baseasse nas melhores prtica existentes at o
momento e que no exigisse grande esforo para o seu aprendizado. Buscaram tambm representar dentro da notao
todos os aspectos existentes nos processos de negcios organizacionais sejam esses processos internos, externos ou be to
be. E, por fim, eles buscarem desenvolver um modelo completo que tivesse um poder de expresso capaz de representar
todos os nveis de detalhes existentes ao longo do ciclo de gesto por processos. Dessa forma a mesma notao deveria
conseguir atender tanto s necessidades dos analistas de negcio que desejam representar os seus modelos as easy to be,
como as necessidades dos analistas de sistemas com seu modelo to do.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

12

SLIDE 12

O BPMN hoje amplamente utilizado em nvel mundial em grande parte das organizaes. Ele conseguiu se torna um
padro, de fato, principalmente a partir do momento em que a OMG, em 2006, o adotou como seu padro oficial para
modelagem de processos, ajudando muito na sua popularizao. Atualmente, ele adotado em grande parte das
ferramentas de BPM, sejam elas de negcios ou de implementao de processos. Dessa forma, a sua enorme aceitao tem
ajudado em muito, tanto a disseminao do conceito de processo de negcio, como tambm facilitado leitura e
entendimento dos processos entre diferentes organizaes.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

13

SLIDE 13

Nesse slide vemos um exemplo de um processo desenhado em BPMN. Vejam que o padro utiliza o conceito de piscinas para
representar o processo, e de raias para representar os atores do processo. Atores externos organizao so representados
por outras piscinas que aparecem paralelas piscina do processo. Os eventos de incio e de fim do processo so
representados por crculos, os pontos de deciso so representados por losangos e as atividades so representadas por
retngulo. Na parte superior direita de cada atividade existe um esteretipo, que identifica o tipo da atividade; atividades
humanas tem a figura de um busto, atividades automticas tem a figura de uma engrenagem, e subprocessos tem um sinal
de mais no centro da atividade.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

14

SLIDE 14

Um outro padro que ganho muita notoriedade no lanamento das primeiras ferramentas de BPMS foi o padro BPEL,
Business Process Execution Language. O BPEL um padro criado para permitir a implementao de processos de integrao
de sistemas. Muito utilizado em processos de SOA, o BPEL se utiliza do conceito de servios para realizar a orquestrao de
troca de informaes entre sistemas. Uma das suas principais caractersticas so os seus recursos de manipulao de dados e
de chamadas de servios, com diversas funcionalidades que facilitam que dados recebidos de um sistema sejam preparados
para serem utilizados na chamada de um prximo sistema. Alm disso, o BPEL tem um aspecto bastante tcnico conforma
podemos ver na figura ao lado de difcil compreenso por usurios de negcio.
Por ter se originado para realizar a orquestrao de servios, ele possui algumas caractersticas bastante limitantes para o
seu uso em processos de negcio, tais como a impossibilidade de se representar no seu fluxo uma condio que faa com
que exista uma transio para uma atividade anterior. Alm disso, o padro no possui nenhum elemento que represente,
ativamente, a atividade humana, dificultando, assim, ainda mais o seu uso para processos de negcios que no sejam de
integrao. Porm, mesmo no tendo sido criado para automao de processos de negcio, com caractersticas humanas, ele
acabou sendo adotado por inmeras ferramentas nas suas primeiras verses, h cinco anos. Contudo, com o tempo, grande
parte dos fabricantes acabou percebendo as dificuldades de uso desse padro para processos humanos, e foram adaptando
os seus produtos para que utilizassem a notao de BPMN para processos humanos, e a notao BPEL para processos de
integrao.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

15

SLIDE 15

Finalmente, ns temos os BPMS, que so uma sute de software que englobam um vasto conjunto de ferramentas que do
apoio a todo o ciclo de gesto por processos.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

16

SLIDE 16

Via de regra, um BPMS composto pelos seguintes elementos: no centro ns temos o motor do processo responsvel pela
interpretao e execuo do processo de negcio. Para representarmos o processo e sua posterior codificao, ns
utilizamos uma ferramenta de modelagem e desenvolvimento do processo. A partir de uma aplicao de lista de trabalho os
usurios podem interagir com as atividades humanas. Ao longo do processo, atividades automticas podem ser invocadas,
gerando a integrao do processo com sistemas internos e externos da organizao. Para permitir a gesto de regras de
negcios, que so utilizadas ao longo do processo, so utilizadas solues de BRM, ou Business Rules. E, finalmente, para
monitorarmos o andamento do processo e realizarmos o acompanhamento dos seus indicadores ns utilizamos solues de
BAM. Vamos a seguir ver detalhadamente cada um desses elementos.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

17

SLIDE 17

Um motor do processo o elemento central do BPMS. Ele quem d vida ao processo, ele o seu maestro. A sua principal
caracterstica a sua capacidade de interpretao, pois ele consegue seguir o processo conforme este foi desenhado e, para
cada tipo de atividade, ele consegue realizar a ao correspondente. Sempre que o motor encontra uma atividade humana,
ele busca identificar quem so os usurios que podem receber essa atividade; ele tambm monta as atividades que devem
ser enviadas para esse usurio; e encaminha essa atividade para os usurios habilitados. Nesse momento, o motor do
processo fica, ento, em stand by, aguardando que o usurio informe que terminou a atividade, momento esse que,
novamente, ele vai ser ento ativado e ir buscar a prxima atividade do processo. J quando encontra uma atividade
automtica o motor sabe como identificar o sistema que deve ser chamado e consegue, ento, estabelecer uma
comunicao desse sistema com o processo de modo a solicitar a execuo de uma rotina ou servio e no retorno tratar a
resposta recebida. J quando o processo encontra um gate, o motor sabe interpretar as condies existentes em cada
transio dirigindo, assim, o processo para a atividade correta. Alm disso, o motor mantm todas as informaes
pertinentes ao processo, registrando todo o seu histrico de execuo que servir mais tarde como uma valiosa base de
dados para a anlise de melhoria contnua do processo.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

18

SLIDE 18

A interface de interao do usurio com o processo ocorre atravs da lista de trabalho. A lista de trabalho funciona de forma
semelhante a uma caixa de e-mail, cada usurio possui a sua e para acess-la, ele deve fazer um login com a sua
identificao. Todas as atividades humanas que so enviadas para um determinado usurio aparecem na sua lista de
trabalho, como podemos ver na parte superior dessa imagem. Ao clicar na atividade o usurio consulta o contedo da
atividade, onde deve estar todas as informaes necessrias para a sua execuo. Para terminar a atividade, o usurio ir
respond-la, informando de que forma a atividade foi finalizada.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

19

SLIDE 19

Outro componente do BPMS, so os motores de regras de negcios, tambm conhecidos como business rules. O BRM uma
tecnologia que permite que o prprio usurio de negcios defina suas regras de forma declarativa, numa espcie de
algoritmo, em portugus, estruturado. Cada regra definida fica armazenada em um repositrio de regras, podendo ser
consultada e alterada sempre que a rea de negcios achar necessrio. A grande vantagem dos motores de regra est,
justamente, na liberdade que eles do para o usurio de negcios definir e dar manuteno em suas prprias regras. Essa
situao, normalmente, impossvel de acontecer quando essas regras esto codificadas dentro de telas de sistemas,
tornando o acesso e o processo de alterao dessas regras muito difcil. So exemplos de regra de negcios, regras que, por
exemplo, definam como realizar as aladas de uma aprovao, como fazer o clculo de preos, de impostos ou de um
desconto ao consumidor, ou que fazem a avaliao de escores de riscos ou de definio de prioridades.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

20

SLIDE 20

Nesse slide temos o exemplo de uma arquitetura utilizada por um motor de regra. O repositrio de regras armazena todas as
regras criadas, e fazem o controle de acesso as mesmas. Atravs da ferramenta de autoria, os analistas e gestores do negcio
podem criar novas regras e dar manuteno s regras existentes. As regras so definidas em portugus estruturado, e na sua
criao so definidas quais os valores de entrada e de sada so esperados para a sua execuo. No exemplo, para esta regra
ser executada, o sistema ter que enviar as informaes de valor e de tipo de mdia e a regra dar, como retorno, de que
forma a confirmao ser exigida. As regras armazenadas no repositrio so, ento, disponibilizadas para os sistemas e para
os processos atravs do mecanismo de servios, dessa forma, sempre que um processo precisar executar determinada regra,
ele ir chamar um servio disponibilizado pelo motor de regras, passando as informaes necessrias e recebendo o retorno
esperado.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

21

SLIDE 21

Dessa forma o uso de motores de regra traz para a organizao inmeros benefcios e entre eles podemos citar uma maior
flexibilidade para a rea de negcio para definir as suas regras, traz tambm uma grande independncia entre as regras de
negcio e a sua aplicao em sistemas e processos, tendo em vista que agora elas so definidas externamente a esses
sistemas. Os motores de regra tambm trazem uma maior transparncia sobre as regras que existem atualmente, uma vez
que essas regras so armazenadas em um repositrio, no ficam mais dentro de um cdigo, de um sistema legado. Outro
ponto importante a reduo no esforo na manuteno de sistemas, tendo em vista que muitas modificaes em regras de
negcio podero ser feitas diretamente no BRM, sem exigir uma nova codificao no sistema. E, como consequncia para
tudo isso, temos uma maior agilidade para a adaptao dos sistemas as suas novas regras de negcio, ganhando, ento,
assim, em toda a organizao em termos de custo e esforo.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

22

SLIDE 22

Uma outra tecnologia de grande importncia na gesto por processos o BAM, Business Activity Monitoring, ou
monitoramento de atividade de negcios. O BAM uma tecnologia que permite o acompanhamento de indicadores de
negcio em tempo real, mostrando o que est acontecendo com os processos nesse exato momento. Ao contrrio do BI, que
serve para a anlise do passado, o BAM uma ferramenta de tomada de deciso imediata, pois permite que o usurio de
negcio acompanhe a sua operao e tome aes que alterem os cenrios em andamento.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

23

SLIDE 23

Os indicadores, no BAM, so acompanhados pelos usurios, atravs do que chamamos de dashboards, que so painis
montados de acordo com as necessidades do negcio, onde so mostrados os diversos indicadores que precisam ser
monitorados. Para cada indicador possvel modelarmos regras que definem que na ocorrncia de uma determinada
situao como, por exemplo, um indicador que apresente um comportamento fora do previsto, sejam enviados alertas para
os usurios responsveis. Alm disso, na ocorrncia dessas situaes, ns tambm podemos definir que sejam executadas as
aes corretivas automticas como, por exemplo, o disparo de um novo processo ou uma chamada de uma rotina de um
sistema legado.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

24

SLIDE 24

Nesse slide vemos, ento, o exemplo de implementao de um dashboard. Vejam que esse dashboard est acompanhando
diversos indicadores que so importantes para o negcio, tais como o desempenho de SLA, e o controle de capacidade de um
posto de armazenamento. Caso um determinado SLA no seja comprido, uma alerta pode ser disparado, ou alguma ao
pode ser tomada automaticamente. No canto inferior esquerdo, temos uma caixa de entrada que mostra alguns alertas que
foram gerados dentro da prpria ferramenta.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

25

SLIDE 25

Vimos at aqui algumas das principais tecnologias que apiam as iniciativas de gesto por processo. Devido a sua
importncia e complexidade, deixamos para ver por ltimo, em um captulo a parte, um dos principais modelos utilizados por
solues de BPM, que o SOA ou Arquitetura Orientada a Servios, que visa facilitar, enormemente, a capacidade do
processo de se integrar com sistemas externos ou internos organizao.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

26

SLIDE 26

Ento, vamos comear falando sobre uma das realidades mais comuns que existem nas reas de TI das organizaes. Como
comentamos anteriormente, atualmente, a maior parte das organizaes conta com uma quantidade muito grande de
sistemas para dar apoio ao andamento do seu negcio. Via de regra, esses sistemas surgem com necessidades diferentes,
muitas vezes verticais, de determinadas reas de negcio e, por isso, acabam atendendo de uma forma muito particular
somente uma determinada rea. muito comum vermos sistemas que so utilizados somente por um departamento ou
centro de custos da empresa, pois esses sistemas foram concebidos ou adquiridos para atender aquele departamento.
Porm, chega uma hora que esses sistemas tm que se falar entre si, de modo a aumentar a produtividade da empresa,
neste momento comeam a surgir as integraes, que permitem a interao entre diferentes sistemas. Contudo, via de
regra, essas integraes vo sendo desenvolvidas sobre demanda medida que elas se fazem necessrias, de forma
desorganizada, que viabiliza a criao de um cenrio onde tudo catico.
Neste cenrio, cada integrao desenvolvida de forma distinta, com tecnologias diferentes. Alm disso, muito comum
uma mesma integrao acabar sendo redesenvolvida mais de uma vez, ou seja, toda vez que eu preciso integrar um sistema
A com um outro sistema, eu acabo redesenvolvendo essa integrao. Alm disso, quando um sistema A precisa se integrar
com um sistema B muito comum ela trazer para dentro do sistema B detalhes tcnicos da estrutura do sistema A. Isso faz
com que sempre que alguma coisa da estrutura de um sistema for alterado seja preciso repetir essa alterao em todos os
outros sistemas que fazem uma integrao com ele, isso o que chamamos de um alto nvel de acoplamento, ou seja,
quando o sistema conhece detalhes tcnicos de outro sistema para viabilizar uma integrao com ele. Para piorar a situao,
no raro, as empresas no tem uma estrutura organizada para documentar quais so as integraes que existem e como elas
funcionam. muito comum vermos reas de TI, onde s integraes entre sistemas so completamente desconhecidas, ou
quando elas so conhecidas, a documentao muito pobre e quase ningum mais sabe como elas funcionam. Todo esse
cenrio acaba por gerar o que chamamos de um espaguete de integraes, onde todo mundo se integra com todo mundo
de uma forma no organizada e documentada, conforme mostra a figura do slide.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

27

SLIDE 27

Como resultado, as reas de TI acabam passando por uma srie de dificuldades, resultantes dessa situao. Algumas das
maiores dificuldades geradas so, primeiro, a dificuldade na modificao de um sistema devido ao forte acoplamento com
outros sistemas. Se um sistema, por exemplo, se integra com outros cinco, possivelmente a mudana na estrutura interna
desse sistema exigir, tambm, a mudana na codificao dos outros cinco sistemas que se integram a ele. A mesma coisa
ocorre com as regras de negcio do sistema, se uma regra de negcio teve que ser reaplicada em vrios outros sistemas,
para viabilizar a integrao, quando essa regra de negcio mudar, a mudana ter que ser feita em todos esses cinco
sistemas. Esse forte acoplamento acaba trazendo um grande temor nas reas de TI no momento em que tem que ser feita
uma substituio ou mudana no sistema. muito comum, no momento em que uma rea de TI precisa mudar algo no
sistema, ela no saber, com convico, se todas as integraes com aquele sistema realmente esto documentadas. Dessa
forma, a melhoria de sistema acaba sendo retardada ou gerando um esforo muito maior do que o desejado. Em um cenrio
mais grave, muitas vezes a substituio integral de um sistema antigo por um mais novo torna-se invivel, dada
complexidade de adaptar essa mudana, e todos os outros sistemas legados da empresa, ou seja, como resultado ns temos
um cenrio de alto custo, longos prazos e enormes riscos operacionais.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

28

SLIDE 28

Para reforar esse cenrio temos um estudo do Gartner que traz que 35% do oramento anual gasto com manuteno de
sistemas dispendido na manuteno de integraes entre sistemas. E, aproximadamente, 30% dos investimentos com
implantao de ERPs se originam da necessidade de se integrar essas ERPs com sistemas legados da empresa. Ou seja, por
um lado a integrao entre sistemas hoje um grande complicador quando pensamos em agilidade e eficincia na mudana
dos nossos sistemas porm, essa mesma integrao um dos fatores mais importantes quando pensamos na automao de
processos, pois devido s caractersticas horizontais do negcio, normalmente um processo acaba integrando e passando por
diferentes sistemas da empresa.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

29

SLIDE 29

Para ajudar a organizar toda essa situao surgiu o conceito de servio. Um servio nada mais do que a exposio de uma
funcionalidade de um sistema para o mundo exterior. O servio trabalha sempre em nvel de negcio, ou seja, essa
funcionalidade que disponibilizada para outros sistemas deve ser entendida pela rea de negcio. Por exemplo, um sistema
de gesto oramentria poderia disponibilizar um servio para a consulta de um valor disponvel em oramento de um
determinado centro de custo, e poderia, tambm, disponibilizar um segundo servio que realizasse a reserva oramentria
de uma rubrica, para uma despesa que foi aprovada, mas ainda no foi paga. De forma similar, um sistema financeiro poderia
disponibilizar um servio que permitisse a emisso e o cadastro de uma nota fiscal nesse sistema, e um segundo servio que
trouxesse o quanto a empresa faturou em um determinado ms. Vejam que, nesses quatro exemplos, os servios
apresentados tm caractersticas claramente de negcios.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

30

SLIDE 30

Entre as principais caractersticas de um servio podemos trazer que um servio possui um conjunto de entradas e sadas
bem definidas, assim como premissas, restries e lgicas de negcio. Um servio de consulta oramentaria, por exemplo,
possivelmente tem como entrada a rubrica que se deseja consultar, o centro de custo da rubrica e o ms de competncia do
oramento, e tenha como sada o valor total do oramento previsto naquele ms, o quanto desse oramento j foi reservado
e o quanto desse oramento j foi gasto.
Outro ponto chave do conceito de servios est no baixo acoplamento. Quando um sistema disponibiliza uma funcionalidade
sua atravs de um servio, est ocultando do consumidor, todo e qualquer detalhe sobre a forma como o servio
implementado. Toda a estrutura interna e lgica utilizada para se processar as informaes enviadas pelo servio devem ser
transparentes para o consumidor, que ir sempre chamar o servio com informaes em nveis de negcio, e ir sempre
receber o retorno tambm com informaes em nveis de negcio. Para o processo de viagens, por exemplo,
completamente transparente a forma como o sistema oramentrio busca as informaes de oramento da rubrica de
viagens de um determinado centro de custo. Toda essa lgica est encapsulada dentro do servio, no visvel para quem
est fora dele. Dessa forma, os sistemas que se integram atravs do uso de servios possuem baixo acoplamento, pois prrequisito que as solicitaes e retornos com esse servio, ocorram sempre em nvel de negcio, independente da forma
como o sistema implementa aquela funcionalidade. Assim, mudanas internas nos sistemas que disponibilizam um servio,
no devem e no podem impactar no uso desse servio por outros sistemas. Finalmente, um servio algo reutilizvel, ou
seja, um mesmo servio disponibilizado por um sistema A pode ser utilizado por um ou mais outros sistemas distintos.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

31

SLIDE 31

Aqui ns vemos um desenho que mostra a estrutura de uma chamada de servio. O consumidor o ente externo que precisa
utilizar esse servio, como por exemplo, o processo de viagens que precisa consultar o oramento disponvel. O provedor o
sistema que est disponibilizando o servio para outros sistemas, como por exemplo, um sistema oramentrio que
disponibiliza um servio de consulta ao oramento.

A interface o ponto de ligao entre o provedor e o consumidor, ou seja, a forma como o servio ser chamado, qual a
sua identificao e o detalhamento das informaes de entrada e sada. Por fim, a implementao a forma como o sistema
provedor se organiza internamente. justamente a implementao que s vista pelo provedor, ou seja, o consumidor
desconhece completamente como funciona a implementao do provedor, ele conhece somente a interface do servio.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

32

SLIDE 32

Como exemplo, temos abaixo dois servios disponibilizados por um sistema de RH. No primeiro, um servio de registro de
ausncias, utilizado sempre que um sistema precisa cadastrar uma ausncia futura para um colaborador, nesse caso, temos
um servio de incluso de dados que disponibilizado por um sistema de RH para qualquer outro sistema, ou processo, que
tenha essa demanda.
No caso, essa necessidade j foi identificada no processo de viagens, quando o colaborador no for bater o ponto, por um
determinado perodo, por estar viajando pela empresa. E tambm foi identificado no processo de licena mdica, quando o
colaborador tiver que se ausentar do trabalho por problemas de sade. Um segundo servio no nosso exemplo tambm
disponibilizado pelo sistema de RH, que o servio de consulta salrios. Nesse caso, o sistema de folha de pagamento, que
externo ao sistema de RH, chama esse servio mensalmente sempre que precisa rodar o clculo da folha.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

33

SLIDE 33

A partir dos conceitos de servios surgiu o conceito de SOA, Service Oriented Architecture, ou Arquitetura Orientada a
Servios. Existem inmeras definies de SOA, mas, para ns, a que traz de forma mais concreta os seus conceitos essa
apresentada abaixo: SOA uma filosofia de TI que visa criar e disponibilizar solues modulares e fracamente acopladas,
baseadas no conceito de servios. Por que dizemos que SOA uma filosofia de TI? Porque ela uma forma de pensar na
integrao dos sistemas, de organizar essas integraes. E que forma essa? justamente atravs do uso de servios. Por
estarmos usando servios, estamos, necessariamente, dizendo que as solues so modulares, por exemplo, somente no
sistema oramentrio onde teremos um servio de consulta de oramento. Estamos tambm dizendo que elas so
fracamente acopladas, pois um dos conceitos do uso de servios que o consumidor no deve conhecer os detalhes de
implementao do provedor. Ento, conforme podemos ver na figura abaixo, uma arquitetura SOA tem um conjunto de
sistemas provedores que disponibilizam funcionalidades atravs da publicao dos seus servios numa camada de servios,
que podem ser chamadas por consumidores. interessante notar que em um determinado sistema ou processo, pode ser,
por algumas funcionalidades, provedor e, para outras funcionalidades, consumidor.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

34

SLIDE 34

SOA no uma tecnologia, mas sim, uma forma de organizar a integrao entre os sistemas. Muito menos um software.
Existem inmeras solues no mercado que facilitam enormemente a implantao de uma arquitetura orientada a servios,
mas a sua aquisio no obrigatria para que tenhamos uma arquitetura SOA. Dessa forma, SOA no algo que possa ser
comprado, ela a forma como pensamos, organizao, da integrao entre os nossos sistemas. E, finalmente, SOA no web
services, web services so uma forma de publicar um servio na web, e eles so bastante utilizados para implantao de
solues SOA, mas SOA muito mais amplo do que isso.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

35

SLIDE 35

A implementao de uma arquitetura orientada a servios tem o objetivo de solucionar uma srie de problemas existentes
nas formas convencionais de se implantar a integrao entre sistemas. Com o uso de servios a integrao entre sistemas
passa a ter um baixo acoplamento, ou seja, um sistema no conhece detalhes do funcionamento interno do outro, de modo
que, mudana do funcionamento interno de um sistema no devem alterar em nada a implementao de outros sistemas
que se integram a ele. Alm disso, uma vez disponibilizado um servio, esse servio poder ser reutilizado inmeras vezes
pela mesma ou por diferentes aplicaes. O servio de registro de ausncias, por exemplo, uma vez disponibilizado poderia
ser utilizado tanto pelo processo de viagens, como pelo processo de licena mdica, ou pelo processo de aprovao de frias,
ou pelo processo de aprovao de licena maternidade, sem que nada mais precise ser feito dentro do sistema de RH. Alm
disso, como o conceito de servios est a nvel de negcio, nada impede que posteriormente um sistema inteiro seja alterado
sem que haja qualquer tipo de impacto nos sistemas que se integram com ele. Para isso, contudo, preciso garantir que o
novo sistema conseguir implementar os mesmos servios do sistema anterior, com exatamente a mesma assinatura e
comportamento esperado. Dessa forma, ganha-se muito em agilidade e em reduo de custos.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

36

SLIDE 36

Na implantao de uma arquitetura orientada a servios, um dos fatores cruciais de sucesso, est na escolha de servios
adequados, que traga uma tima relao custo/benefcio. A escolha de servios que tenham, por exemplo, baixa
probabilidade de reuso, podem no justificar o esforo de transformar uma integrao, que j est funcionando, em um
servio. Dessa forma, existe uma srie de fatores que devem ser analisados sempre que identificarmos que uma integrao
poderia ser transformada em um servio. Esses fatores no so mutualmente exclusivos, pelo contrrio, eles formam uma
pontuao onde quanto mais uma determinada integrao se encaixar nesses critrios, maior ser o ganho de transform-la
em um servio. Vamos, ento analisar, cada um deles:
O primeiro critrio analisa o quanto uma determinada funcionalidade est implementada, de forma redundante, em
diferentes sistemas da organizao. Uma funcionalidade que existe em diversos sistemas sempre de difcil manuteno,
pois sempre que precisarmos alterar alguma coisa na sua regra de negcio teremos que fazer essa mudana em diferentes
sistemas. Alm disso, em quanto mais locais for preciso alterar, maior ser a probabilidade de gerarmos erros na codificao.
Finalmente, uma das expectativas e estratgia de implantao de SOA justamente que tenhamos solues modulares,
onde, sempre que possvel, uma determinada funcionalidade esteja sendo disponibilizada em um nico sistema. Dessa
forma, quanto mais sistemas uma funcionalidade estiver implementada, mais cresce o interesse em transformar essa
funcionalidade em um servio.
Outro ponto importante de avaliao est na quantidade de sistemas que tenha essa integrao implementada. Quanto mais
sistemas utilizarem uma determinada integrao, maior ser a sua reutilizao, dessa forma, ao transformarmos essa
integrao em um servio, estaremos reduzindo, consideravelmente, a quantidade de cdigo redundante, visto que todas
essas integraes sero transformadas em chamadas para um nico servio. Como consequncia, maior tambm ser a
economia no momento em que uma mudana nessa regra de negcio for necessria, visto que essa mudana precisar ser
feita em um s local, e no em cada um dos sistemas.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

37

O volume de alteraes esperadas em uma determinada funcionalidade tambm um ponto importante quando avaliamos a
atratividade de transformar uma integrao em um servio. Existem funcionalidades que, pela natureza do seu negcio,
esto em constante alterao. Funcionalidades que mudam frequentemente, mesmo que estejam integradas com poucos
sistemas, exigiro retrabalho constantes nesses sistemas, cada vez que for necessria uma alterao. Fazendo uma
comparao com o critrio anterior, digamos que uma funcionalidade esteja integrada com cinco sistemas e costuma exigir
duas alteraes por ano, dessa forma, ao longo de um ano, teremos duas alteraes em cinco sistemas, ou seja, a
necessidade de alterar dez pontos de integrao. Num outro cenrio, digamos que uma segunda funcionalidade esteja
integrada a dois sistemas somente, mas costuma sofrer, pelo menos, uma alterao por ms. Neste caso teremos doze
alteraes em dois sistemas ao longo de um ano, ou seja, a necessidade de alterarmos vinte e quatro pontos de integrao.
Vejam que, nesse caso, a frequncia das alteraes fez com que a transformao dessa funcionalidade em um servio fosse
mais vantajosa do que no primeiro caso.
No mesmo sentido, um outro fator importante est na agilidade que ser cobrada para que ocorra uma alterao e uma
integrao. Se a alterao na funcionalidade, ou regra de negcio, exigir uma velocidade muito rpida de execuo, ter essa
integrao j exposta como servio, tender a fazer com que a mudana na sua estrutura exija menos tempo para ser
implementada. E mesmo que essa funcionalidade, hoje, tenha poucos pontos de integrao com outros sistemas,
importante que se faa uma projeo de qual a tendncia para as prximas semanas ou meses. Talvez uma integrao que
hoje pouco acessada venha a ser muito requisitada em pouco tempo, de modo que a sua transformao em servio trar
ganho de curto ou mdio prazo quando essas novas implementaes forem necessrias.
E, finalmente, temos que avaliar a complexidade de transformar uma integrao em um servio. Aqui, a avaliao inversa a
que fizemos at o momento. Existem casos em que a integrao tem um nvel de complexidade muito elevado, so crticas
para a organizao e encontram-se, atualmente, funcionando bem, sem nenhum problema. Nestes casos importante
avaliarmos os riscos de este processo de transformao da integrao em servio trazer instabilidade e introduzir novos erros
e ento compararmos este risco com todos os possveis ganhos que apresentamos nos itens anteriores, de modo ento, a
realizarmos uma avaliao adequada de custos versus riscos versus benefcios.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

38

SLIDE 37

Dado esse cenrio qual o relacionamento existente entre BPM e SOA? Tanto o BPM quanto o SOA so modelos que surgiram
de forma independente com objetivos distintos. Por um lado, o BPM surgiu com a ideia de desenvolver a gesto por
processos apoiado por solues de tecnologia. J a SOA, surgiu para organizar a forma como so pensadas as integraes
entre os sistemas.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

39

SLIDE 38

Entre os dois modelos existe uma relao muito prxima de interao. Por um lado, os processos so consumidores natos de
servios, pois sempre que um processo precisa realizar uma operao ou consulta em um sistema ele precisar que esse
sistema disponibilize uma funcionalidade para que ele possa cham-la. Nesse sentido, a arquitetura orientada a servios vem
justamente com a ideia de ajudar os processos, a viabilizar a implementao dessas integraes.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

40

SLIDE 39

Dessa forma existe um circulo virtuoso entre BPM e SOA. Por um lado, a modelagem e anlise de processos uma forma
muito natural de se identificar a necessidade de servios. Por outro lado, para que a arquitetura SOA possa, realmente, trazer
retorno para a organizao importante que sejam identificados bons candidatos a servios, que tenham uma alta
probabilidade de serem reutilizados. E nesse sentido, a modelagem de processos justamente uma tima forma de
identificarmos bons servios, com alto nvel de reutilizao. E, uma vez que os servios so identificados e construdos,
justamente a arquitetura orientada a servios, viabiliza que, quando um segundo processo, ou uma nova aplicao precisem
utilizar novamente esse servio, nenhum esforo adicional seja mais necessrio, porque o servio j foi construdo,
disponibilizado e encontra-se pronto para reuso.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

41

SLIDE 40

Chegamos ao final dessa aula, antes de terminar, vamos, ento, repassar alguns dos conceitos apresentados.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

42

SLIDE 41

Ao longo da aula de hoje vimos inmeras iniciativas de TI que buscam viabilizar e implementar a gesto por processos. Temos
padres como o BPEL e BPMN, que busca uniformizar alguns conceitos. Temos inmeras tecnologias como o BPA, BPMS,
BRM e BAM, que facilitam o ciclo de gesto por processos. E temos, ento, a Arquitetura Orientada a Servios como uma
importante parceira para a implementao de processos com alto nvel de automatizao e integrao.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

43

SLIDE 42

Agradecemos a todos por ter nos acompanhado at aqui, espero vocs no nosso frum de discusso. At a prxima aula.

6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

44

ANOTAES DO ALUNO

________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

45

________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
6.1 Componentes de uma plataforma de BPMS

ELO Group 2011

46