6.2 Aula Transcrita

8/19/2019 6.2 Aula Transcrita

1/46

6.2 Componentes de umaplataforma de BPMS


2/46

6.1 Componentes de uma plataforma de BPMS © ELO Group 2011

2

RESUMO

Aula: 6.2 Componentes de uma plataforma de BPMS

Tutor: Eduardo Britto, MSc, PMP, OCEB, CDIA+

Número de slides: 42 Duração da Aula: 55 min

SLIDE 1


3/46


3

SLIDE 2

Boa noite. Sejam bem vindos à segunda aula do módulo 6 do nosso curso sobre tecnologia e BPM.

Nessa aula nós iremos aprofundar um pouco mais os conhecimentos a respeito dos componentes tecnológicos que

dão apoio ao ciclo da gestão por processos.

Iremos também falar um pouquinho sobre a arquitetura orientada a serviços ou SOA, e conhecer qual é a relação

que existe entre SOA e BPM.

Finalmente, iremos fechar a aula dando um overview dos conceitos-chaves que apresentamos hoje.


4/46


4

SLIDE 3

Então, vamos começar conhecendo os componentes tecnológicos e ferramentas que nos ajudam na gestão por processos.


5/46


5

SLIDE 4

Existem inúmeras ferramentas e tecnologias que apoiam o ciclo de gestão por processos, vamos separá-las em três grupos,

que serão vistos ao longo deste capítulo. O primeiro grupo é o de ferramentas de BPA, ou Business Process Analys, que

ajudam o usuário do negócio a mapear, desenvolver, modelar e documentar o seu processo de negócio. O segundo grupo

são os padrões utilizados na gestão por processos sendo que os dois mais difundidos são o padrão BPMN, para modelagem

de processos, e o padrão BPEL, para automação e integração de sistemas. O terceiro grupo é composto pelas ferramentas

que são utilizadas para automação e a melhoria continua dos processos onde podemos citar tecnologias como, BPMS, BRM,

BAM e SOA.


6/46


6

SLIDE 5

Vamos começar então pelos BPAs. Os BPAs normalmente são utilizados para apoiar o usuário de negócio nas etapas de

mapeamento e redesenho de processos. Dentro do BPA é possível representar toda a estrutura de processograma da

organização, começando pela cadeia de valor e descendo até os detalhes de cada processo, e chegando então nas suas

atividades operacionais. Além disso, os BPAs são importantes repositórios de processos que permitem que os processos

sejam organizados e armazenados dentro de um banco de dados, com controle de acesso e autenticação de usuário. Ao

definir um processo no BPA o analista pode definir e detalhar também os indicares que compõe e que irão medir esse

processo, bem como identificar claramente os pontos do processo onde esses indicadores serão alimentados. De acordo com

o produto que está sendo utilizado é possível, inclusive, conectar os indicares definidos no BPA na base de dados gerada por

uma solução de BPMS, permitindo assim, que seja atualizado dentro do BPA os dados reais do processo. Outros três pontos

importantes de soluções de BPA, que veremos agora em maiores detalhes, são os pontos de documentação, simulação e

publicação de processos.


7/46


7

SLIDE 6

Em termos de documentação, é possível, no BPA, que a organização identifique para cada tipo de elemento utilizado para

representar o processo, quais as informações e atributos que devem ser preenchidos para se documentar esse elemento. Em

um processo em BPMN, por exemplo, é possível definir que informações devem ser preenchidas quando o usuário estiver

documentando uma atividade humana. Além disso, por ser um repositório de processo, o BPA se torna o local onde são

armazenadas e consultadas, em termos organizacionais, todas as informações a respeito de um processo de negócio. Essa

consulta pode ser realizada tanto através do acesso a ferramenta, como, também, através da geração de documentação em

relatórios. Muitos BPAs possuem ambientes que permitem que se defina templetes de documentação que descrevem como

um documento de especificação de processos deve ser gerado. Assim, a qualquer momento, com esse template definido, é

possível com um clique de botão solicitar a geração de um documento de especificação funcional automaticamente.


8/46


8

SLIDE 7

Outro recurso importante dos BPAs é a sua capacidade de realizar a simulação de processos. Na simulação o usuário

consegue modelar o seu processo e entrar com informações que servirão de premissas para avaliar como o processo irá se

comportar na configuração em que ele foi modelado. Para realizar uma simulação, contudo, é necessário 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 disponíveis para a execução 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, é possível simular o comportamento do

processo, e avaliar se ele irá executar da forma esperada. Com recursos de simulação, conseguimos avaliar o comportamento

de um processo sem que ele tenha que ser colocado em produção, minimizando assim, os custos que a empresa teria se

realmente fosse utilizar aquele processo na prática.


9/46


9

SLIDE 8

Outra importante funcionalidade dos BPAs são os seus recursos de publicação. Através delas é possível realizarmos a

publicação dos processos de negócio para toda a organização através de padrões conhecidos como portais internos ou

páginas da web. Nesses portais é possível também 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 responsáveis pelo

redesenho poderia utilizar esse recurso para publicar o processo e colher sugestões de melhorias com outros usuários da

empresa. Para isso, essas ferramentas possuem recursos de colaboração que permitem que os usuários, autorizados,

comentem o processo sem que este seja efetivamente alterado. Ao final dessa etapa de coleta de sugestões a equipe de

redesenho pode, então, analisar cada item e avaliar quais sugestões ou criticas irá colher.


10/46


10

SLIDE 9

De uma maneira geral, os BPAs são utilizados pelas áreas de negócios, nas etapas de mapeamento e redesenho de processos

e, sempre que possível, ele também pode ser utilizado pelo analista de sistemas nas etapas de modelagem para automação.

Via de regra, o envolvimento da área de TI na aquisição de um BPA costuma ser de médio a nulo, dependendo do quanto o

escritório de processos da empresa tem autonomia para escolher a melhor solução para si. Contudo, um grande problema

que costuma acontecer de forma muito frequente nas organizações é a área de negócios escolher uma solução de BPA que é

incompatível com a solução de automação de processos escolhida pela área de TI, gerando, em muitos casos, inúmeras

situações de retrabalho e de falta de compatibilidade. Um outro ponto importante é que o modelo desenhado no BPA não é

um modelo verificável na vida real. Como a gente costuma dizer, o papel aceita tudo, e o BPA também, ou seja, não é

possível se ter a garantia que o processo desenhado no BPA é realmente exequível visto que o processo é um mero

documento e que somente poderá ser validado e colocado em prática no momento da sua implantação.


11/46


11

SLIDE 10

São 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

representação de processos, mas não pode ser considerada como uma solução de BPA, pois não tem as inúmeras

funcionalidades esperadas por ele, tais como o conceito de repositório de processos, dissimulação ou digestão de

indicadores.


12/46


12

SLIDE 11

Entrando agora nos padrões vamos começar falando do BPMN, o Business Process Model and Notation. O BPMN é uma

notação gráfica de representação de processos de negócios. Ao ser elaborada, os seus autores buscaram atender as

seguintes premissas: construir uma notação de fácil compreensão que se baseasse nas melhores prática existentes até o

momento e que não exigisse grande esforço para o seu aprendizado. Buscaram também representar dentro da notação

todos os aspectos existentes nos processos de negócios organizacionais sejam esses processos internos, externos ou be to

be. E, por fim, eles buscarem desenvolver um modelo completo que tivesse um poder de expressão capaz de representar

todos os níveis de detalhes existentes ao longo do ciclo de gestão por processos. Dessa forma a mesma notação deveria

conseguir atender tanto às necessidades dos analistas de negócio que desejam representar os seus modelos as easy to be,

como as necessidades dos analistas de sistemas com seu modelo to do.


13/46


13

SLIDE 12

O BPMN hoje é amplamente utilizado em nível mundial em grande parte das organizações. Ele conseguiu se torna um

padrão, de fato, principalmente a partir do momento em que a OMG, em 2006, o adotou como seu padrão oficial para

modelagem de processos, ajudando muito na sua popularização. Atualmente, ele é adotado em grande parte das

ferramentas de BPM, sejam elas de negócios ou de implementação de processos. Dessa forma, a sua enorme aceitação tem

ajudado em muito, tanto a disseminação do conceito de processo de negócio, como também facilitado à leitura e

entendimento dos processos entre diferentes organizações.


14/46


14

SLIDE 13

Nesse slide vemos um exemplo de um processo desenhado em BPMN. Vejam que o padrão utiliza o conceito de piscinas para

representar o processo, e de raias para representar os atores do processo. Atores externos à organização são representados

por outras piscinas que aparecem paralelas à piscina do processo. Os eventos de início e de fim do processo são

representados por círculos, os pontos de decisão são representados por losangos e as atividades são representadas por

retângulo. Na parte superior direita de cada atividade existe um estereótipo, que identifica o tipo da atividade; atividades

humanas tem a figura de um busto, atividades automáticas tem a figura de uma engrenagem, e subprocessos tem um sinal

de mais no centro da atividade.


15/46


15

SLIDE 14

Um outro padrão que ganho muita notoriedade no lançamento das primeiras ferramentas de BPMS foi o padrão BPEL,

Business Process Execution Language. O BPEL é um padrão criado para permitir a implementação de processos de integração

de sistemas. Muito utilizado em processos de SOA, o BPEL se utiliza do conceito de serviços para realizar a orquestração de

troca de informações entre sistemas. Uma das suas principais características são os seus recursos de manipulação de dados e

de chamadas de serviços, com diversas funcionalidades que facilitam que dados recebidos de um sistema sejam preparados

para serem utilizados na chamada de um próximo sistema. Além disso, o BPEL tem um aspecto bastante técnico conforma

podemos ver na figura ao lado de difícil compreensão por usuários de negócio.

Por ter se originado para realizar a orquestração de serviços, ele possui algumas características bastante limitantes para o

seu uso em processos de negócio, tais como a impossibilidade de se representar no seu fluxo uma condição que faça com

que exista uma transição para uma atividade anterior. Além disso, o padrão não possui nenhum elemento que represente,

ativamente, a atividade humana, dificultando, assim, ainda mais o seu uso para processos de negócios que não sejam de

integração. Porém, mesmo não tendo sido criado para automação de processos de negócio, com características humanas, ele

acabou sendo adotado por inúmeras ferramentas nas suas primeiras versões, há cinco anos. Contudo, com o tempo, grande

parte dos fabricantes acabou percebendo as dificuldades de uso desse padrão para processos humanos, e foram adaptando

os seus produtos para que utilizassem a notação de BPMN para processos humanos, e a notação BPEL para processos de

integração.


16/46


16

SLIDE 15

Finalmente, nós temos os BPMS, que são uma suíte de software que englobam um vasto conjunto de ferramentas que dão

apoio a todo o ciclo de gestão por processos.


17/46


17

SLIDE 16

Via de regra, um BPMS é composto pelos seguintes elementos: no centro nós temos o motor do processo responsável pela

interpretação e execução do processo de negócio. Para representarmos o processo e sua posterior codificação, nós

utilizamos uma ferramenta de modelagem e desenvolvimento do processo. A partir de uma aplicação de lista de trabalho os

usuários podem interagir com as atividades humanas. Ao longo do processo, atividades automáticas podem ser invocadas,

gerando a integração do processo com sistemas internos e externos da organização. Para permitir a gestão de regras de

negócios, que são utilizadas ao longo do processo, são utilizadas soluções de BRM, ou Business Rules. E, finalmente, para

monitorarmos o andamento do processo e realizarmos o acompanhamento dos seus indicadores nós utilizamos soluções de

BAM. Vamos a seguir ver detalhadamente cada um desses elementos.


18/46


18

SLIDE 17

Um motor do processo é o elemento central do BPMS. Ele é quem dá vida ao processo, ele é o seu maestro. A sua principal

característica é a sua capacidade de interpretação, pois ele consegue seguir o processo conforme este foi desenhado e, para

cada tipo de atividade, ele consegue realizar a ação correspondente. Sempre que o motor encontra uma atividade humana,

ele busca identificar quem são os usuários que podem receber essa atividade; ele também monta as atividades que devem

ser enviadas para esse usuário; e encaminha essa atividade para os usuários habilitados. Nesse momento, o motor do

processo fica, então, em stand by, aguardando que o usuário informe que terminou a atividade, momento esse que,

novamente, ele vai ser então ativado e irá buscar a próxima atividade do processo. Já quando encontra uma atividade

automática o motor sabe como identificar o sistema que deve ser chamado e consegue, então, estabelecer uma

comunicação desse sistema com o processo de modo a solicitar a execução de uma rotina ou serviço e no retorno tratar a

resposta recebida. Já quando o processo encontra um gate, o motor sabe interpretar as condições existentes em cada

transição dirigindo, assim, o processo para a atividade correta. Além disso, o motor mantém todas as informações

pertinentes ao processo, registrando todo o seu histórico de execução que servirá mais tarde como uma valiosa base de

dados para a análise de melhoria contínua do processo.


19/46


19

SLIDE 18

A interface de interação do usuário com o processo ocorre através da lista de trabalho. A lista de trabalho funciona de forma

semelhante a uma caixa de e-mail , cada usuário possui a sua e para acessá-la, ele deve fazer um login com a sua

identificação. Todas as atividades humanas que são enviadas para um determinado usuário aparecem na sua lista de

trabalho, como podemos ver na parte superior dessa imagem. Ao clicar na atividade o usuário consulta o conteúdo da

atividade, onde deve estar todas as informações necessárias para a sua execução. Para terminar a atividade, o usuário irá

respondê-la, informando de que forma a atividade foi finalizada.


20/46


20

SLIDE 19

Outro componente do BPMS, são os motores de regras de negócios, também conhecidos como business rules. O BRM é uma

tecnologia que permite que o próprio usuário de negócios defina suas regras de forma declarativa, numa espécie de

algoritmo, em português, estruturado. Cada regra definida fica armazenada em um repositório de regras, podendo ser

consultada e alterada sempre que a área de negócios achar necessário. A grande vantagem dos motores de regra está,

justamente, na liberdade que eles dão para o usuário de negócios definir e dar manutenção em suas próprias regras. Essa

situação, normalmente, é impossível de acontecer quando essas regras estão codificadas dentro de telas de sistemas,

tornando o acesso e o processo de alteração dessas regras muito difícil. São exemplos de regra de negócios, regras que, por

exemplo, definam como realizar as alçadas de uma aprovação, como fazer o cálculo de preços, de impostos ou de um

desconto ao consumidor, ou que fazem a avaliação de escores de riscos ou de definição de prioridades.


21/46


21

SLIDE 20

Nesse slide temos o exemplo de uma arquitetura utilizada por um motor de regra. O repositório de regras armazena todas as

regras criadas, e fazem o controle de acesso as mesmas. Através da ferramenta de autoria, os analistas e gestores do negócio

podem criar novas regras e dar manutenção às regras existentes. As regras são definidas em português estruturado, e na sua

criação são definidas quais os valores de entrada e de saída são esperados para a sua execução. No exemplo, para esta regra

ser executada, o sistema terá que enviar as informações de valor e de tipo de mídia e a regra dará, como retorno, de que

forma a confirmação será exigida. As regras armazenadas no repositório são, então, disponibilizadas para os sistemas e para

os processos através do mecanismo de serviços, dessa forma, sempre que um processo precisar executar determinada regra,

ele irá chamar um serviço disponibilizado pelo motor de regras, passando as informações necessárias e recebendo o retorno

esperado.


22/46


22

SLIDE 21

Dessa forma o uso de motores de regra traz para a organização inúmeros benefícios e entre eles podemos citar uma maior

flexibilidade para a área de negócio para definir as suas regras, traz também uma grande independência entre as regras de

negócio e a sua aplicação em sistemas e processos, tendo em vista que agora elas são definidas externamente a esses

sistemas. Os motores de regra também trazem uma maior transparência sobre as regras que existem atualmente, uma vez

que essas regras são armazenadas em um repositório, não ficam mais dentro de um código, de um sistema legado. Outro

ponto importante é a redução no esforço na manutenção de sistemas, tendo em vista que muitas modificações em regras de

negócio poderão ser feitas diretamente no BRM, sem exigir uma nova codificação no sistema. E, como consequência para

tudo isso, temos uma maior agilidade para a adaptação dos sistemas as suas novas regras de negócio, ganhando, então,

assim, em toda a organização em termos de custo e esforço.


23/46


23

SLIDE 22

Uma outra tecnologia de grande importância na gestão por processos é o BAM, Business Activity Monitoring, ou

monitoramento de atividade de negócios. O BAM é uma tecnologia que permite o acompanhamento de indicadores de

negócio em tempo real, mostrando o que está acontecendo com os processos nesse exato momento. Ao contrário do BI, que

serve para a análise do passado, o BAM é uma ferramenta de tomada de decisão imediata, pois permite que o usuário de

negócio acompanhe a sua operação e tome ações que alterem os cenários em andamento.


24/46


24

SLIDE 23

Os indicadores, no BAM, são acompanhados pelos usuários, através do que chamamos de dashboards, que são painéis

montados de acordo com as necessidades do negócio, onde são mostrados os diversos indicadores que precisam ser

monitorados. Para cada indicador é possível modelarmos regras que definem que na ocorrência de uma determinada

situação como, por exemplo, um indicador que apresente um comportamento fora do previsto, sejam enviados alertas para

os usuários responsáveis. Além disso, na ocorrência dessas situações, nós também podemos definir que sejam executadas as

ações corretivas automáticas como, por exemplo, o disparo de um novo processo ou uma chamada de uma rotina de um

sistema legado.


25/46


25

SLIDE 24

Nesse slide vemos, então, o exemplo de implementação de um dashboard . Vejam que esse dashboard está acompanhando

diversos indicadores que são importantes para o negócio, tais como o desempenho de SLA, e o controle de capacidade de um

posto de armazenamento. Caso um determinado SLA não seja comprido, uma alerta pode ser disparado, ou alguma ação

pode ser tomada automaticamente. No canto inferior esquerdo, temos uma caixa de entrada que mostra alguns alertas que

foram gerados dentro da própria ferramenta.


26/46


26

SLIDE 25

Vimos até aqui algumas das principais tecnologias que apóiam as iniciativas de gestão por processo. Devido a sua

importância e complexidade, deixamos para ver por último, em um capítulo a parte, um dos principais modelos utilizados por

soluções de BPM, que é o SOA ou Arquitetura Orientada a Serviços, que visa facilitar, enormemente, a capacidade do

processo de se integrar com sistemas externos ou internos à organização.


27/46


27

SLIDE 26

Então, vamos começar falando sobre uma das realidades mais comuns que existem nas áreas de TI das organizações. Como

comentamos anteriormente, atualmente, a maior parte das organizações conta com uma quantidade muito grande de

sistemas para dar apoio ao andamento do seu negócio. Via de regra, esses sistemas surgem com necessidades diferentes,

muitas vezes verticais, de determinadas áreas de negócio e, por isso, acabam atendendo de uma forma muito particular

somente uma determinada área. É muito comum vermos sistemas que são utilizados somente por um departamento ou

centro de custos da empresa, pois esses sistemas foram concebidos ou adquiridos para atender aquele departamento.

Porém, chega uma hora que esses sistemas têm que se falar entre si, de modo a aumentar a produtividade da empresa,

neste momento começam a surgir as integrações, que permitem a interação entre diferentes sistemas. Contudo, via de

regra, essas integrações vão sendo desenvolvidas sobre demanda à medida que elas se fazem necessárias, de forma

desorganizada, que viabiliza a criação de um cenário onde tudo é caótico.

Neste cenário, cada integração é desenvolvida de forma distinta, com tecnologias diferentes. Além disso, é muito comum

uma mesma integração 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 integração. Além disso, quando um sistema A precisa se integrar

com um sistema B é muito comum ela trazer para dentro do sistema B detalhes técnicos da estrutura do sistema A. Isso faz

com que sempre que alguma coisa da estrutura de um sistema for alterado seja preciso repetir essa alteração em todos os

outros sistemas que fazem uma integração com ele, isso é o que chamamos de um alto nível de acoplamento, ou seja,

quando o sistema conhece detalhes técnicos de outro sistema para viabilizar uma integração com ele. Para piorar a situação,

não raro, as empresas não tem uma estrutura organizada para documentar quais são as integrações que existem e como elas

funcionam. É muito comum vermos áreas de TI, onde às integrações entre sistemas são completamente desconhecidas, ou

quando elas são conhecidas, a documentação é muito pobre e quase ninguém mais sabe como elas funcionam. Todo essecenário acaba por gerar o que chamamos de um “espaguete” de integrações, onde todo mundo se integra com todo mundo

de uma forma não organizada e documentada, conforme mostra a figura do slide.


28/46


28

SLIDE 27

Como resultado, as áreas de TI acabam passando por uma série de dificuldades, resultantes dessa situação. Algumas das

maiores dificuldades geradas são, primeiro, a dificuldade na modificação de um sistema devido ao forte acoplamento com

outros sistemas. Se um sistema, por exemplo, se integra com outros cinco, possivelmente a mudança na estrutura interna

desse sistema exigirá, também, a mudança na codificação dos outros cinco sistemas que se integram a ele. A mesma coisa

ocorre com as regras de negócio do sistema, se uma regra de negócio teve que ser reaplicada em vários outros sistemas,

para viabilizar a integração, quando essa regra de negócio mudar, a mudança 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 substituição ou mudança no sistema. É muito comum, no momento em que uma área de TI precisa mudar algo no

sistema, ela não saber, com convicção, se todas as integrações com aquele sistema realmente estão documentadas. Dessa

forma, a melhoria de sistema acaba sendo retardada ou gerando um esforço muito maior do que o desejado. Em um cenário

mais grave, muitas vezes a substituição integral de um sistema antigo por um mais novo torna-se inviável, dada à

complexidade de adaptar essa mudança, e todos os outros sistemas legados da empresa, ou seja, como resultado nós temos

um cenário de alto custo, longos prazos e enormes riscos operacionais.


29/46


29

SLIDE 28

Para reforçar esse cenário temos um estudo do Gartner que traz que 35% do orçamento anual gasto com manutenção de

sistemas é dispendido na manutenção de integrações entre sistemas. E, aproximadamente, 30% dos investimentos com

implantação de ERPs se originam da necessidade de se integrar essas ERPs com sistemas legados da empresa. Ou seja, por

um lado a integração entre sistemas é hoje um grande complicador quando pensamos em agilidade e eficiência na mudança

dos nossos sistemas porém, essa mesma integração é um dos fatores mais importantes quando pensamos na automação de

processos, pois devido às características horizontais do negócio, normalmente um processo acaba integrando e passando por

diferentes sistemas da empresa.


30/46


30

SLIDE 29

Para ajudar a organizar toda essa situação surgiu o conceito de serviço. Um serviço nada mais é do que a exposição de uma

funcionalidade de um sistema para o mundo exterior. O serviço trabalha sempre em nível de negócio, ou seja, essa

funcionalidade que é disponibilizada para outros sistemas deve ser entendida pela área de negócio. Por exemplo, um sistema

de gestão orçamentária poderia disponibilizar um serviço para a consulta de um valor disponível em orçamento de um

determinado centro de custo, e poderia, também, disponibilizar um segundo serviço que realizasse a reserva orçamentária

de uma rubrica, para uma despesa que foi aprovada, mas ainda não foi paga. De forma similar, um sistema financeiro poderia

disponibilizar um serviço que permitisse a emissão e o cadastro de uma nota fiscal nesse sistema, e um segundo serviço que

trouxesse o quanto a empresa faturou em um determinado mês. Vejam que, nesses quatro exemplos, os serviços

apresentados têm características claramente de negócios.


31/46


31

SLIDE 30

Entre as principais características de um serviço podemos trazer que um serviço possui um conjunto de entradas e saídas

bem definidas, assim como premissas, restrições e lógicas de negócio. Um serviço de consulta orçamentaria, por exemplo,

possivelmente tem como entrada a rubrica que se deseja consultar, o centro de custo da rubrica e o mês de competência do

orçamento, e tenha como saída o valor total do orçamento previsto naquele mês, o quanto desse orçamento já foi reservado

e o quanto desse orçamento já foi gasto.

Outro ponto chave do conceito de serviços está no baixo acoplamento. Quando um sistema disponibiliza uma funcionalidade

sua através de um serviço, está ocultando do consumidor, todo e qualquer detalhe sobre a forma como o serviço é

implementado. Toda a estrutura interna e lógica utilizada para se processar as informações enviadas pelo serviço devem ser

transparentes para o consumidor, que irá sempre chamar o serviço com informações em níveis de negócio, e irá sempre

receber o retorno também com informações em níveis de negócio. Para o processo de viagens, por exemplo, é

completamente transparente a forma como o sistema orçamentário busca as informações de orçamento da rubrica de

viagens de um determinado centro de custo. Toda essa lógica está encapsulada dentro do serviço, não é visível para quem

está fora dele. Dessa forma, os sistemas que se integram através do uso de serviços possuem baixo acoplamento, pois é pré-

requisito que as solicitações e retornos com esse serviço, ocorram sempre em nível de negócio, independente da forma

como o sistema implementa aquela funcionalidade. Assim, mudanças internas nos sistemas que disponibilizam um serviço,

não devem e não podem impactar no uso desse serviço por outros sistemas. Finalmente, um serviço é algo reutilizável, ou

seja, um mesmo serviço disponibilizado por um sistema A pode ser utilizado por um ou mais outros sistemas distintos.


32/46


32

SLIDE 31

Aqui nós vemos um desenho que mostra a estrutura de uma chamada de serviço. O consumidor é o ente externo que precisa

utilizar esse serviço, como por exemplo, o processo de viagens que precisa consultar o orçamento disponível. O provedor é o

sistema que está disponibilizando o serviço para outros sistemas, como por exemplo, um sistema orçamentário que

disponibiliza um serviço de consulta ao orçamento.

A interface é o ponto de ligação entre o provedor e o consumidor, ou seja, é a forma como o serviço será chamado, qual a

sua identificação e o detalhamento das informações de entrada e saída. Por fim, a implementação é a forma como o sistema

provedor se organiza internamente. É justamente a implementação que é só vista pelo provedor, ou seja, o consumidor

desconhece completamente como funciona a implementação do provedor, ele conhece somente a interface do serviço.


33/46


33

SLIDE 32

Como exemplo, temos abaixo dois serviços disponibilizados por um sistema de RH. No primeiro, um serviço de registro de

ausências, é utilizado sempre que um sistema precisa cadastrar uma ausência futura para um colaborador, nesse caso, temos

um serviço de inclusão 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 não for bater o ponto, por um

determinado período, por estar viajando pela empresa. E também foi identificado no processo de licença médica, quando o

colaborador tiver que se ausentar do trabalho por problemas de saúde. Um segundo serviço no nosso exemplo também é

disponibilizado pelo sistema de RH, que é o serviço de consulta salários. Nesse caso, o sistema de folha de pagamento, que é

externo ao sistema de RH, chama esse serviço mensalmente sempre que precisa rodar o cálculo da folha.


34/46


34

SLIDE 33

A partir dos conceitos de serviços surgiu o conceito de SOA, Service Oriented Architecture, ou Arquitetura Orientada a

Serviços. Existem inúmeras definições de SOA, mas, para nós, a que traz de forma mais concreta os seus conceitos é essa

apresentada abaixo: SOA é uma filosofia de TI que visa criar e disponibilizar soluções modulares e fracamente acopladas,

baseadas no conceito de serviços. Por que dizemos que SOA é uma filosofia de TI? Porque ela é uma forma de pensar na

integração dos sistemas, de organizar essas integrações. E que forma é essa? É justamente através do uso de serviços. Por

estarmos usando serviços, estamos, necessariamente, dizendo que as soluções são modulares, por exemplo, somente no

sistema orçamentário é onde teremos um serviço de consulta de orçamento. Estamos também dizendo que elas são

fracamente acopladas, pois um dos conceitos do uso de serviços é que o consumidor não deve conhecer os detalhes de

implementação do provedor. Então, conforme podemos ver na figura abaixo, uma arquitetura SOA tem um conjunto de

sistemas provedores que disponibilizam funcionalidades através da publicação dos seus serviços numa camada de serviços,

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.


35/46


35

SLIDE 34

SOA não é uma tecnologia, mas sim, uma forma de organizar a integração entre os sistemas. Muito menos é um software.

Existem inúmeras soluções no mercado que facilitam enormemente a implantação de uma arquitetura orientada a serviços,

mas a sua aquisição não é obrigatória para que tenhamos uma arquitetura SOA. Dessa forma, SOA não é algo que possa ser

comprado, ela é a forma como pensamos, organização, da integração entre os nossos sistemas. E, finalmente, SOA não é web

services, web services são uma forma de publicar um serviço na web, e eles são bastante utilizados para implantação de

soluções SOA, mas SOA é muito mais amplo do que isso.


36/46


36

SLIDE 35

A implementação de uma arquitetura orientada a serviços tem o objetivo de solucionar uma série de problemas existentes

nas formas convencionais de se implantar a integração entre sistemas. Com o uso de serviços a integração entre sistemas

passa a ter um baixo acoplamento, ou seja, um sistema não conhece detalhes do funcionamento interno do outro, de modo

que, mudança do funcionamento interno de um sistema não devem alterar em nada a implementação de outros sistemas

que se integram a ele. Além disso, uma vez disponibilizado um serviço, esse serviço poderá ser reutilizado inúmeras vezes

pela mesma ou por diferentes aplicações. O serviço de registro de ausências, por exemplo, uma vez disponibilizado poderia

ser utilizado tanto pelo processo de viagens, como pelo processo de licença médica, ou pelo processo de aprovação de férias,

ou pelo processo de aprovação de licença maternidade, sem que nada mais precise ser feito dentro do sistema de RH. Além

disso, como o conceito de serviços está a nível de negócio, 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 serviços do sistema anterior, com exatamente a mesma assinatura e

comportamento esperado. Dessa forma, ganha-se muito em agilidade e em redução de custos.


37/46


37

SLIDE 36

Na implantação de uma arquitetura orientada a serviços, um dos fatores cruciais de sucesso, está na escolha de serviços

adequados, que traga uma ótima relação custo/benefício. A escolha de serviços que tenham, por exemplo, baixa

probabilidade de reuso, podem não justificar o esforço de transformar uma integração, que já está funcionando, em um

serviço. Dessa forma, existe uma série de fatores que devem ser analisados sempre que identificarmos que uma integração

poderia ser transformada em um serviço. Esses fatores não são mutualmente exclusivos, pelo contrário, eles formam uma

pontuação onde quanto mais uma determinada integração se encaixar nesses critérios, maior será o ganho de transformá-la

em um serviço. Vamos, então analisar, cada um deles:

O primeiro critério analisa o quanto uma determinada funcionalidade está implementada, de forma redundante, em

diferentes sistemas da organização. Uma funcionalidade que existe em diversos sistemas é sempre de difícil manutenção,

pois sempre que precisarmos alterar alguma coisa na sua regra de negócio teremos que fazer essa mudança em diferentes

sistemas. Além disso, em quanto mais locais for preciso alterar, maior será a probabilidade de gerarmos erros na codificação.

Finalmente, uma das expectativas e estratégia de implantação de SOA é justamente que tenhamos soluções modulares,

onde, sempre que possível, 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 serviço.

Outro ponto importante de avaliação está na quantidade de sistemas que tenha essa integração implementada. Quanto mais

sistemas utilizarem uma determinada integração, maior será a sua reutilização, dessa forma, ao transformarmos essa

integração em um serviço, estaremos reduzindo, consideravelmente, a quantidade de código redundante, visto que todas

essas integrações serão transformadas em chamadas para um único serviço. Como consequência, maior também será a

economia no momento em que uma mudança nessa regra de negócio for necessária, visto que essa mudança precisará ser

feita em um só local, e não em cada um dos sistemas.


38/46


38

O volume de alterações esperadas em uma determinada funcionalidade também é um ponto importante quando avaliamos a

atratividade de transformar uma integração em um serviço. Existem funcionalidades que, pela natureza do seu negócio,

estão em constante alteração. Funcionalidades que mudam frequentemente, mesmo que estejam integradas com poucos

sistemas, exigirão retrabalho constantes nesses sistemas, cada vez que for necessária uma alteração. Fazendo uma

comparação com o critério anterior, digamos que uma funcionalidade esteja integrada com cinco sistemas e costuma exigir

duas alterações por ano, dessa forma, ao longo de um ano, teremos duas alterações em cinco sistemas, ou seja, a

necessidade de alterar dez pontos de integração. Num outro cenário, digamos que uma segunda funcionalidade estejaintegrada a dois sistemas somente, mas costuma sofrer, pelo menos, uma alteração por mês. Neste caso teremos doze

alterações em dois sistemas ao longo de um ano, ou seja, a necessidade de alterarmos vinte e quatro pontos de integração.

Vejam que, nesse caso, a frequência das alterações fez com que a transformação dessa funcionalidade em um serviço 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 alteração e uma

integração. Se a alteração na funcionalidade, ou regra de negócio, exigir uma velocidade muito rápida de execução, ter essa

integração já exposta como serviço, tenderá a fazer com que a mudança na sua estrutura exija menos tempo para ser

implementada. E mesmo que essa funcionalidade, hoje, tenha poucos pontos de integração com outros sistemas, é

importante que se faça uma projeção de qual a tendência para as próximas semanas ou meses. Talvez uma integração que é

hoje pouco acessada venha a ser muito requisitada em pouco tempo, de modo que a sua transformação em serviço trará

ganho de curto ou médio prazo quando essas novas implementações forem necessárias.

E, finalmente, temos que avaliar a complexidade de transformar uma integração em um serviço. Aqui, a avaliação é inversa a

que fizemos até o momento. Existem casos em que a integração tem um nível de complexidade muito elevado, são críticas

para a organização e encontram-se, atualmente, funcionando bem, sem nenhum problema. Nestes casos é importante

avaliarmos os riscos de este processo de transformação da integração em serviço trazer instabilidade e introduzir novos erros

e então compararmos este risco com todos os possíveis ganhos que apresentamos nos itens anteriores, de modo então, a

realizarmos uma avaliação adequada de custos versus riscos versus benefícios.


39/46


39

SLIDE 37

Dado esse cenário qual o relacionamento existente entre BPM e SOA? Tanto o BPM quanto o SOA são modelos que surgiram

de forma independente com objetivos distintos. Por um lado, o BPM surgiu com a ideia de desenvolver a gestão por

processos apoiado por soluções de tecnologia. Já a SOA, surgiu para organizar a forma como são pensadas as integrações

entre os sistemas.


40/46


40

SLIDE 38

Entre os dois modelos existe uma relação muito próxima de interação. Por um lado, os processos são consumidores natos de

serviços, pois sempre que um processo precisa realizar uma operação 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 serviços vem

justamente com a ideia de ajudar os processos, a viabilizar a implementação dessas integrações.


41/46


41

SLIDE 39

Dessa forma existe um circulo virtuoso entre BPM e SOA. Por um lado, a modelagem e análise de processos é uma forma

muito natural de se identificar a necessidade de serviços. Por outro lado, para que a arquitetura SOA possa, realmente, trazer

retorno para a organização é importante que sejam identificados bons candidatos a serviços, que tenham uma alta

probabilidade de serem reutilizados. E nesse sentido, a modelagem de processos é justamente uma ótima forma de

identificarmos bons serviços, com alto nível de reutilização. E, uma vez que os serviços são identificados e construídos,

justamente a arquitetura orientada a serviços, viabiliza que, quando um segundo processo, ou uma nova aplicação precisem

utilizar novamente esse serviço, nenhum esforço adicional seja mais necessário, porque o serviço já foi construído,

disponibilizado e encontra-se pronto para reuso.


42/46


42

SLIDE 40

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


43/46


43

SLIDE 41

Ao longo da aula de hoje vimos inúmeras iniciativas de TI que buscam viabilizar e implementar a gestão por processos. Temos

padrões como o BPEL e BPMN, que busca uniformizar alguns conceitos. Temos inúmeras tecnologias como o BPA, BPMS,

BRM e BAM, que facilitam o ciclo de gestão por processos. E temos, então, a Arquitetura Orientada a Serviços como uma

importante parceira para a implementação de processos com alto nível de automatização e integração.


44/46


44

SLIDE 42

Agradecemos a todos por ter nos acompanhado até aqui, espero vocês no nosso fórum de discussão. Até a próxima aula.


45/46


45

ANOTAÇÕES DO ALUNO

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________


46/46

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

Documents

6.2 Aula Transcrita