faculdade farias brito ciÊncia da...

FACULDADE FARIAS BRITO

CIÊNCIA DA COMPUTAÇÃO

Elizeu Rodrigues da Silva

Cenários de integração entre processos e serviços: a relação

SOA - BPM

Fortaleza, 2012

1

ELIZEU RODRIGUES DA SILVA

Cenários de integração entre processos e serviços: a relação SOA

– BPM

Monografia apresentada para obtenção dos

créditos da disciplina Trabalho de Conclusão do

Curso da Faculdade Farias Brito, como parte das

exigências para graduação no Curso de Ciência

da Computação.

Orientador: Prof. Dr. Paulo Benicio de Sousa.

Fortaleza, 2012

2

CENÁRIOS DE INTEGRAÇÃO ENTRE PROCESSOS E

SERVIÇOS: A RELAÇÃO SOA – BPM

Elizeu Rodrigues da Silva

PARECER __________________

NOTA: FINAL (0 – 10):_______

Data: ____/____/_________

BANCA EXAMINADORA:

___________________________________

Prof. Paulo Benicio de Sousa, Dr.

(Orientador)

___________________________________

Prof. Murilo Eduardo Ybanez Nascimento, MSc.

(Examinador)

__________________________________

Prof. Mateus Mosca Viana Dr.

(Examinador)

3

AGRADECIMENTOS

Aos meus pais, João e Júlia, por me ensinarem a conduzir a vida de forma digna e com

respeito ao próximo.

A todos os professores que contribuíram para minha formação social e cognitiva desde

o início dos meus estudos. Agradeço, especialmente, à Prof.ª Mailde pelo carinho e

perseverança ao me ensinar a ler e a escrever.

À Faculdade Farias Brito pelos valores transmitidos e pelo apoio prestado.

Ao Prof.º Paulo Benício pelas ideias, paciência e sensibilidade em todo o processo de

desenvolvimento deste trabalho.

4

“Quão melhor é adquirir a sabedoria

do que o ouro! E quão mais excelente é

adquirir a prudência do que a prata!”

Provérbios 16:16

5

RESUMO

O presente trabalho visa investigar a relação entre dois conceitos de grande importância para a

área de TI da atualidade: processos de negócio e arquiteturas de serviços. O primeiro trata da

forma como estratégias e funcionalidades são pensadas em uma organização; já o segundo

avalia a forma como implementá-las em uma visão de componentes. Considerando essas

particularidades, percebe-se que existe uma integração possível em que ambos os conceitos

são mutuamente reforçados. O objetivo aqui pretendido é o de investigar a relação entre estas

abordagens e buscar uma forma consistente de apresentar um modelo de maturidade para este

cenário.

6

SUMÁRIO

INTRODUÇÃO ................................................................................................................................................... 9

VISÃO GERAL DO TRABALHO .......................................................................................................................... 10

1 SERVIÇOS E PROCESSOS DE TI ............................................................................................................... 12

1.1 CONTEXTUALIZAÇÃO .............................................................................................................................. 12

1.1.1 Visão Geral .................................................................................................................................... 12

1.1.2 Conceitos Preliminares .................................................................................................................. 13

1.2 ARQUITETURA ORIENTADA A SERVIÇOS ................................................................................................. 14

1.2.1 Visão Geral de SOA ........................................................................................................................ 14

1.2.2 Camadas ........................................................................................................................................ 17

1.2.3 Principais soluções SOA ................................................................................................................. 19

1.3 GESTÃO DE PROCESSOS DE NEGÓCIO (BPM) .......................................................................................... 20

1.3.1 Visão Geral .................................................................................................................................... 20

1.3.2 Principais soluções BPM ................................................................................................................ 23

2 IMPORTÂNCIA DA INTEGRAÇÃO ENTRE SOA/BPM ................................................................................ 24

2.1 CONTRIBUIÇÕES DE SOA PARA BPM ....................................................................................................... 27

2.2 CONTRIBUIÇÕES DE BPM PARA SOA ....................................................................................................... 29

3 MODELO DE INTEGRAÇÃO .................................................................................................................... 30

3.1 PROPOSTA DE UM MODELO DE MATURIDADE ...................................................................................... 31

3.1.1 Proposta de um Modelo de Maturidade para Processos .............................................................. 32

3.1.2 Proposta de um Modelo de Maturidade para Serviços ................................................................. 34

3.1.3 Unindo os modelos ........................................................................................................................ 35

3.2 APRESENTAÇÃO DE CENÁRIOS ................................................................................................................ 38

3.2.1 Cenário 1: Maturidade .................................................................................................................. 38

3.2.2 Cenário 2: Imaturidade.................................................................................................................. 41

3.2.3 Proposta de um questionário de avaliação (checklist) .................................................................. 43

3.3 CRÍTICAS SOBRE OS CENÁRIOS DE MATURIDADE .................................................................................... 52

4 CONCLUSÃO .......................................................................................................................................... 54

5 BIBLIOGRAFIA ....................................................................................................................................... 56

7

XXX

LISTA DE FIGURAS

Figura 1 - Camadas da Arquitetura Orientada a Serviços. ....................................................... 18

Figura 2 - Quadrante mágico Gartner para SOA referente a 2011. .......................................... 20

Figura 3 - Elementos que compõem o ciclo de vida de BPM. ................................................. 22

Figura 4 - Quadrante mágico para suítes BPM em 2011. ........................................................ 24

Figura 5 - Alinhamento BPM x SOA. ...................................................................................... 25

Figura 6 - Níveis de maturidade CMMI. .................................................................................. 32

Figura 7 - Níveis de classificação para implementação das práticas de ITIL. ......................... 34

Figura 8 - Matriz de combinações entre níveis de maturidade SOA x BPM. .......................... 37

Figura 9 - Exemplo de um cenário definido para uma empresa madura em processos e

serviços (CEF). ......................................................................................................................... 41

LISTA DE TABELAS

Tabela 1 - Proposta Modelo Maturidade SOA x BPM. ........................................................... 36

8

LISTA DE ABREVIATURAS E SIGLAS

Sigla Significado

BPEL Business Process Execution Language

BPM Business Process Management

BPMS Business Process Management System

BPO Business Process Outsorcing

CMMI Capability Maturity Model Integration

COBIT Control Objectives for Information and related Technology

ESB Enterprise Service Bus

ITIL InformationTechnology Infrastructure Library.

MPS.BR Melhoria de Processos do Software Brasileiro

SOA Service Oriented Architecture

9

INTRODUÇÃO

O advento de tecnologias mudou drasticamente o cenário das comunicações

corporativas e a forma de relacionamento entre indivíduos e organizações. Segundo Junior

(2007) os desafios para evolução e sobrevivência das empresas têm sido crescentes, tanto no

âmbito do negócio como no âmbito de TI. Dentre eles destacam-se: concorrência, aquisições e

incorporações, menor tempo de vida de produtos e serviços, integração com clientes e

parceiros, regulamentos, novas tecnologias, custos, integração entre aplicações,

disponibilidade e qualidade dos serviços e produtos.

Neste cenário, novas tendências, como Arquitetura Orientada a Serviços (do inglês

SOA – Service Oriented Architecture), têm se tornado padrão de mercado. Mas por trás da

tecnologia ou da base ferramental, o que se tem presenciado é a alteração na forma como os

mesmos serviços são projetados e/ou desenhados e a visão estratégica de negócio que permeia

tais conceitos, normalmente adotando um padrão de Gerenciamento de Processos de Negócio

(do inglês BPM – Business Process Management).

É importante enfatizar que SOA não é apenas uma arquitetura que trata dos aspectos

tecnológicos, como bem pondera Junior (2007) ao afirmar que “na verdade, SOA contempla

um espectro muito mais amplo de processos de negócio”.

Ao falar sobre a importância de SOA, Behara (2006) afirma que “o principal ponto da

implementação de SOA é que ela fornece uma plataforma de integração flexível, o que

permite que as aplicações mudem e evoluam sem que o núcleo da integração seja afetado”.

A Arquitetura Orientada a Serviços surgiu para permitir que as empresas pudessem

planejar e organizar suas aplicações orientando-as ao fácil reuso, manutenção e suporte, como

uma maneira de compartilhar dados e recursos eficientemente e alcançar resultados coerentes

e consistentes (HURWITZ et al., 2009).

AMARAL (2007a) cita os que são, na sua visão, os principais benefícios de SOA,

sendo eles:

O fato de que mudanças na lógica de negócios (service providers) não afetam

aplicações existentes – facilidade de manutenção.

Novas aplicações (service consumers) podem reaproveitar mais facilmente as

funcionalidades existentes – reuso;

10

Service providers podem ser substituídos com menor impacto, o que permite

aumentar a flexibilidade do sistema.

Se, por um lado, SOA surgiu para que as organizações fossem pensadas em termos de

serviços, por outro lado, BPM surgiu para que as organizações fossem vistas a partir do seu

conjunto de processos de negócios, uma vez que provê “uma metodologia, bem como uma

coleção de ferramentas que permitem às empresas identificar, etapa por etapa, os processos de

negócio” (BEHARA, 2006, p. 1).

É exatamente na investigação desta ponte BPM-SOA que focaremos o presente

trabalho, com base nos conceitos hoje considerados críticos para as atividades de gestão e

visão estratégica das empresas.

VISÃO GERAL DO TRABALHO

O intuito final deste trabalho é o de realizar um estudo sobre cenários de integração

entre processos e serviços, sob a visão de duas grandes linhas que envolvem, respectivamente,

SOA e BPM. O projeto visa, ainda, analisar como os processos contribuem para a eficiência

dos serviços e vice-versa. Neste sentido, é necessária a compreensão dos conceitos

relacionados e como esta integração está sendo desenvolvida nas organizações.

Neste contexto, podem ser numerados alguns objetivos complementares deste estudo,

dentre os quais:

A apresentação das necessidades e soluções de integração entre processos e serviços.

A análise das diferentes visões de integração entre os dois conceitos.

O estudo dos aspectos importantes para este cenário, tais como requisitos a serem

atendidos e tecnologias associadas.

A identificação dos custos e benefícios da integração dos dois conceitos a partir do

estudo de caso e/ou revisão bibliográfica.

11

A apresentação de estudo de caso procurando soluções existentes de integração entre

processos e serviços e sua viabilidade.

A proposta de critérios para a classificação para níveis de maturidade organizacionais

que integrem os conceitos de processos e serviços (como, por exemplo, os níveis de

maturidade do CMMI (Capability Maturity Model Integration): Inicial, Repetível,

Definido, Gerenciado, Otimizado).

Finalmente, uma breve indicação das tecnologias que fomentam a integração SOA-

BPM.

Em resumo, este trabalho também visa mostrar quais as principais arquiteturas e

conceitos envolvidos, soluções existentes oferecidas por empresas, bem como as principais

características e benefícios dessa abordagem.

12

1 SERVIÇOS E PROCESSOS DE TI

1.1 CONTEXTUALIZAÇÃO

Neste primeiro capítulo será apresentada uma visão geral sobre a relevância de

processos e serviços e como estes estão inseridos no ambiente corporativo atual, os conceitos

preliminares e uma pesquisa bibliográfica envolvendo os dois temas.

1.1.1 Visão Geral

Nos últimos anos, a competitividade dos mercados tem se acentuado como decorrência

da globalização. Nesse cenário, são constantes as mudanças de produtos e serviços que as

organizações precisam oferecer. Com isso, empresas têm que ser ágeis para se manterem

competitivas e, para isso, precisam constantemente melhorar seus processos, bem como

identificar aqueles ainda não mapeados.

Para atender à demanda gerada pelos processos, a organização deve garantir que os

serviços sejam eficientes, capazes de atender as novas necessidades resultantes dos processos

e que tenham um custo benefício que justifique sua existência. Junior (2007, p. 16) aponta as

iniciativas que são preocupações atuais das empresas e que podem ser diretamente apoiadas

por SOA/ BPM, sendo elas:

Melhorar os processos de negócio;

Garantir vantagem competitiva;

Fortalecer o conceito de BPO (Business Process Office), incluindo aspectos

que envolvem, por exemplo, a terceirização de processos de negócio;

Ter foco em controles internos.

Ao implantar iniciativas BPM para gerenciar seus processos, as organizações têm sido

beneficiadas com ganho em agilidade no mapeamento e melhoria contínua de seus processos

e, consequentemente, têm se tornado mais competitivas e otimizado a redução de gastos. Com

seus processos bem definidos e gerenciados, a implantação de uma Arquitetura Orientada a

Serviços para dar suporte aos processos tem se mostrado vantajosa para as organizações, pois

13

tal modelo fornece serviços testados, desacoplados, além de facilitar que sejam amplamente

reutilizados.

Como uma forma de garantir sua rápida resposta às mudanças dos cenários

econômico, geopolítico e legal que as circundam, as organizações têm se concentrado em

assegurar que as mudanças em seus processos sejam rapidamente refletidas em seus serviços.

Entender como deve ser feita a integração entre processos e serviços e em quais

cenários tal integração é viável é de grande importância para o desenvolvimento de

metodologias que fomentem uma implantação conjunta de processos e serviços em uma

organização, o que justifica o interesse com o tema não apenas no cenário atual, mas na visão

de médio prazo para as organizações envolvidas em serviços de TI.

1.1.2 Conceitos Preliminares

Antes de tudo, tem-se o conceito de serviços que, do ponto de vista de TI, são

programas com os quais é possível se comunicar através da troca de mensagens. Neste

sentido, considerando a analogia da arquitetura cliente servidor, tem-se respectivamente os

papéis de provedores e consumidores de serviços (service providers e service consumers). No

entanto, sob um prisma que envolve negócio, eles correspondem a funcionalidades que têm a

capacidade de atender necessidades específicas de negócio de uma organização, por exemplo,

um serviço de saque, um serviço de consulta de CEP, etc.

Do ponto de vista arquitetural, existem dois conceitos essenciais à definição de

serviços: a interoperabilidade, traduzindo-se como a capacidade de um componente e/ou

sistema se comunicar com outro sistema de forma transparente e o reuso, que trata do

reaproveitamento de componentes prontos. “O reuso é um dos pilares de SOA, pois é ele que

possibilita o ganho de velocidade na construção de novas aplicações, a redução dos custos e

aumento da qualidade” (JUNIOR, 2007, p. 9).

O que aqui chamamos de processos de negócio, por sua vez, podem ser definidos

como a codificação de regras e tarefas logicamente relacionadas, tendo como objetivo a

obtenção de um resultado bem definido, percebido pelo cliente ou por outros usuários.

Em termos de implementação, será adotado aqui o conceito de arquitetura de

software definida por (JUNIOR, 2007, p. 8) como sendo “a estrutura ou estruturas do

14

sistema, as quais compreendem elementos de software, as propriedades externamente visíveis

desses elementos, e o relacionamento entre eles”. Ou seja, arquitetura de software designa a

descrição dos componentes de um sistema de computador e a forma como eles se conectam e

interagem. Nos dias de hoje, a arquitetura é baseada na ideia de componentes, isto é,

unidades de software independentes, “que podem ser reutilizadas, pois foram desenvolvidas

com esta preocupação” (JUNIOR, 2007, p. 9).

Uma ideia importante a ser mencionada é que, no amplo cenário de implementação de

processos, existem duas abordagens arquiteturais distintas: a orquestração e a coreografia. O

conceito de orquestração é tratado pela literatura como sendo fundamental para SOA,

baseando-se em componentes providos pela infraestrutura que atuam no gerenciamento das

interações entre os serviços dentro de um processo de negócio (JUNIOR, 2007). Já segundo

Santos (2010) a coreografia trata de “regras e políticas que possibilitam que serviços

diferentes colaborem para atender um processo de negócio. Cada serviço envolvido enxerga e

contribui apenas como parte do processo”. Coreografia se distingue de orquestração por não

possuir um processo mestre, responsável por coordenar a composição e execução de serviços.

Consequentemente, na coreografia cada serviço deve interagir de forma ordenada e precisa ter

o conhecimento que faz parte de uma composição.

1.2 ARQUITETURA ORIENTADA A SERVIÇOS

A seguir serão apresentados os diferentes conceitos de Arquitetura Orientada a

Serviços, demonstrando quais são as suas vantagens e como sua adoção contribui para tornar

o ambiente de TI de uma organização mais alinhada aos interesses de negócio.

1.2.1 Visão Geral de SOA

Iniciativas de SOA (Service Oriented Architecture ou Arquitetura Orientada a

Serviços) vêm sendo amplamente adotadas em grandes organizações como uma eficiente

abordagem para o desenvolvimento de sistemas. Mas implementar SOA representa bem mais

que um consequente bom desempenho no desenvolvimento de sistemas. Sua influência e

ganhos transcendem a área de TI, e sua adoção representa uma mudança cultural nas

organizações. SOA destaca-se por liberar o negócio das restrições de tecnologia (JUNIOR,

15

2007) e por permitir organizar programas para fácil reuso, que assegurem resultados coerentes

em suas organizações (MICROSOFT, 2008).

O termo Arquitetura Orientada a Serviços possui diversas definições na literatura, a

seguir são apresentadas algumas delas:

Para Hurwitz (2009, p. 44) SOA é “uma arquitetura de software para criar

aplicações que implementam processos ou serviços de negócio usando um

conjunto de baixo acoplamento, componentes de caixa-preta orquestrados para

oferecer um nível bem definido de serviço”. Ainda segundo o autor, SOA é

“uma abordagem de tecnologia de negócio tanto quanto é uma abordagem de

metodologia tecnológica”, afirmação esta que nos fornece a ideia de uma

importante relação entre SOA e BPM.

Amaral (2007b) define SOA como sendo “uma filosofia de TI que visa criar e

disponibilizar soluções modulares e fracamente acopladas baseadas no

conceito de serviços”.

Já Microsoft (2008, p. 9) define SOA como sendo “uma arquiteturade de baixo

acoplamento projetada para atender as necessidades do negócio da

organização, sendo uma arquitetura que permite criar sistemas construídos a

partir de serviços autonômos”.

SOA destaca-se por prover flexibilidade e redução de custos à organização como é

relatado por Arruda (2009) o qual afirma que:

Optando pela implantação de SOA, a empresa passará a ser mais flexível,

compartilhando informações entre os departamentos, abandonando o

conceito de unidades de negócios independentes, possibilitando maiores

oportunidades para resolução de problemas. Além disso, as novas soluções

podem ser mais integradas aos sistemas legados, fazendo com que os custos

sejam reduzidos e com que a empresa exercite a sua flexibilidade para inovar

em busca de vantagem competitiva (ARRUDA, 2009, p. 11).

É importante observar que esses benefícios de SOA são consequência de mecanismos

tais como os conceitos de interoperabilidade, orquestração, coreografia e ESB (Enterprise

Service Bus).

16

Josuttis (2008) demonstra que SOA não deve ser vista como solução para qualquer

domínio de negócio ao afirmar que SOA “é a solução ideal para circunstâncias muito

especiais, tais como sistemas distribuídos heterogêneos”, bem como não deve ser vista como

uma especificação tecnológica.

Adicionalmente, a adoção de SOA implica obrigatoriamente na definição de um

modelo arquitetural baseado em camadas, o que implica em uma maior complexidade da

solução a ser adotada. Da mesma forma, não se pode assumir que as arquiteturas orientadas a

serviços são perfeitamente intercambiáveis, isto é, uma solução pode não ser facilmente

acoplada à outra sem algum esforço adicional.

Junior (2007) coloca sua visão sobre SOA, fazendo distinção do conceito quanto ao

ponto de vista de TI e quanto ao ponto de vista do negócio, sugerindo as seguintes definições:

SOA do ponto de vista do negócio: maneira de implementar os processos de

negócio da empresa na forma de funções bem definidas, chamadas de serviços.

SOA do ponto de vista de TI: é uma arquitetura que permite a automação dos

processos de negócio da empresa através da orquestração de diversos

componentes com funções bem definidas (serviços).

Considerando este último ponto, deve-se destacar que SOA se baseia em diversas

tecnologias, como WebServices, sendo apoiada pelo uso de BPM, priorizando características

como aderência a padrões, agilidade, flexibilidade, reutilização, interoperabilidade e

alinhamento ao negócio (JUNIOR, 2007). Este relacionamento consiste exatamente no objeto

de estudo do presente trabalho.

Segundo Amaral (2007a), SOA tem como objetivos o reuso de componentes, baixo

acoplamento, transparência da infraestrutura, eliminação de redundâncias e criação de

aplicações por composição de serviços.

Neto (2008) discorre sobre a filosofia SOA, apontando os seguintes objetivos como

sendo os principais:

Foco no cliente (serviços finais) e qualidade;

Agilidade, flexibilidade, produtividade e menores riscos;

Forte alinhamento às estratégias empresariais;

Ampla integração e interoperabilidade;

Amplo reuso e preservação de ativos;

17

Redução de custos, operação e manutenção simples.

São ainda apontados diversos ganhos e vantagens decorrentes da adoção de SOA.

Entretanto, antes disso, é preciso levar em conta que nem toda organização está apta a tirar

proveito desta abordagem. Neto (2008, p. 10) apresenta um conjunto de características das

organizações que devem adotar SOA, isto é, que têm maior potencial para tirar proveito ao

adotá-la:

Organizações que possuem elevada maturidade empresarial e dos seus sistemas

computacionais;

Empresas que perceberam e agem para explorar a importância estratégica de

TI;

Áreas de negócio com alto uso de TI: serviços financeiros, logística, e-

Business e afins;

Segmentos amplamente integrados: redes (serviços, revendas e varejo), cadeias

industriais;

Organizações com processos sedimentados e pouco adaptáveis como em

algumas esferas de Governo.

Em resumo, pode-se dizer que Arquitetura Orientada a Serviços é um paradigma

segundo o qual os sistemas devem ser constituídos a partir de serviços autônomos e

reutilizáveis, que implementam os processos da organização. Apesar das visões nem sempre

convergentes, existe pelo menos um ponto em que todos concordam: “SOA é um paradigma

que melhora a flexibilidade” (JOSUTTIS, 2008, p. 11).

1.2.2 Camadas

A Arquitetura Orientada a Serviços é composta de camadas, onde cada uma tem sua

função dentro de uma organização. A Figura 1, reproduzida de Junior (2007), apresenta as

camadas de abstração que compõem SOA.

18

Figura 1 - Camadas da Arquitetura Orientada a Serviços.

a) Camada corporativa – É caracterizada por ser um modelo que descreve o

negócio da empresa. O modelo identifica os processos mais importantes para a

empresa, os quais são essenciais para a competitividade, bem como os processos

de suporte.

b) Camada de processos – É nesta camada que os processos do modelo de negócios

são identificados e caracterizados. Cada processo pode ser composto por vários

subprocesssos e é único para cada área funcional de negócio como bem enfatiza

Junior (2007, p. 11) ao afirmar que “processos são únicos, pois envolvem decisões,

fluxos e pessoas específicas para atender determinado processo de negócio”.

c) Camada de serviços – A camada de serviços é caracterizada por um número de

serviços que realizam funções básicas, técnicas e de negócio. Dentro da arquitetura

SOA, esta camada fornece uma ponte entre as camadas de alto (camada

corporativa e de processos) e baixo nível (camada de componentes e objetos).

Usualmente, é nesta camada que as funções críticas necessárias para o negócio são

identificadas, visto que é nessa camada onde usualmente são identificadas e

expostas as funções para suportar o negócio.

d) Camada de componentes – Na camada de componentes são identificados e

caracterizados os componentes que podem ser mapeados como serviços.

Normalmente através de técnicas bottom-up (análise das aplicações e identificação

de funções que podem ser serviços, por terem um potencial de reaproveitamento

em vários sistemas).

19

e) Camada de objetos – Na camada de objetos estão as classes, atributos e

relacionamentos de um objeto. É importante identificar que a classe não apenas é

pública, mas sim que ela é importante o suficiente para ser promovida a

componente/serviço, e assim poder ser chamada por mecanismos como os

WebServices (Junior, 2007).

A compreensão destas camadas é essencial para garantir que na visão de integração

entre os conceitos SOA / BPM, se possa evidenciar as interfaces adequadas deste cenário.

1.2.3 Principais soluções SOA

A Gartner, periodicamente, divulga relatórios de análise das principais tecnologias do

mundo através de um gráfico conhecido como “quadrante mágico”. O eixo X (horizontal)

demonstra a abrangência da visão da empresa em relação à tecnologia. O eixo Y (vertical)

mostra a capacidade da empresa de executar o que propõe para aquela tecnologia (Alves,

2010). Quanto mais à direita e acima no quadrante apresentado, melhor classificada está a

empresa quanto ao fomento e desenvolvimento de tecnologias referentes ao tema tratado no

quadrante.

A Figura 2, reproduzida de Gartner (2011a), apresenta o “quadrante mágico” da

Gartner referente a SOA. A figura demonstra quais são os principais fornecedores de

tecnologias SOA em 2011. Ao analisar a figura, observa-se que empresas como Software AG,

Oracle, Progress Software são os principais fornecedores de soluções em SOA, de acordo

com a pesquisa da Gartner.

Para um melhor entendimento do quadrante, destaca-se que as empresas que estão no

quadrante “líderes” são, de acordo com a classificação definida pela Gartner, empresas com

um bom nível de inovação em SOA e com boa capacidade de entregar o que prometem. As

empresas apontadas como “visionárias” seriam empresas que oferecem bastantes inovações,

mas que não possuem tanta capacidade para entregar o que prometem. As “desafiadoras”, por

outro lado, se caracterizam por possuírem boa capacidade de execução, mas que não agregam

tanto em inovação. E, por último, as empresas situadas no quadrante “nicho de mercado”

20

seriam aquelas que não possuem grande expressividade no mercado geral como um todo e

geralmente possuem produtos específicos.

Figura 2 - Quadrante mágico Gartner para SOA referente a 2011.

1.3 GESTÃO DE PROCESSOS DE NEGÓCIO (BPM)

A seguir serão apresentados os conceitos do Gerenciamento de Processos de Negócio

e como este tem contribuído para melhorar a maneira como os processos organizacionais são

gerenciados e implementados.

1.3.1 Visão Geral

BPM (Business Process Management ou Gerenciamento de Processos de Negócio)

vem sendo cada vez mais adotado nas organizações, pois seu conjunto de melhores práticas

de gerenciamento possibilita o mapeamento e contínuo aperfeiçoamento dos processos de

negócio de uma organização. Uma eficiente gestão dos processos de negócio é importante

para resolver problemas, como o relatado em Behara (2006), segundo o qual processos de

negócio estão espalhados em múltiplas aplicações, afetando todas elas, o que implica que

21

todas essas aplicações precisam ser modificadas para acomodar mudanças nos processos de

negócio.

Da mesma forma que apontado anteriormente para SOA, vale a pena destacar a visão

de alguns autores com relação ao gerenciamento de processos de negócio:

Para Hurwitz (2009, p. 78), “BPM é a abordagem moderna para desenvolver e

gerenciar processos de negócio”.

Outra definição de BPM é encontrada em Amaral (2007b, p. 17) segundo o qual

BPM é “o modelo de gerenciamento dos processos apoiado for ferramentas de

TI”.

Junior (2007, p. 13) demonstra a importância de BPM ao afirmar que:

Agora que BPM passou a ser usuário das tecnologias e diretrizes da SOA,

gradativamente são incorporados novos mecanismos, como integração de

aplicações, colaboração entre pessoas, ferramentas de desenvolvimento,

regras de negócios externalizadas, mostrando todo o potencial do BPM para

transformação do negócio.

Um dos importantes aspectos de BPM é que ele busca viabilizar o importante

alinhamento entre negócio e TI e ao unir os processos de negócio, pessoas, informações e

tecnologias de uma empresa, BPM cria uma visão integrada e em tempo real do negócio e dos

sistemas de TI (JUNIOR, 2007).

A adoção de BPM prepara a organização para alcançar seus objetivos estratégicos bem

como pontua Evangelista (2007), segundo o qual “BPM autoriza o analista de negócios a

alinhar os sistemas de TI com as metas estratégicas da organização, criando e definindo

processos empresariais, monitorando o desempenho deles e aperfeiçoando para maiores

eficiências operacionais”.

Para Junior (2007, p. 13), BPM “visa mapear e melhorar os processos de negócio da

empresa, através de uma abordagem baseada em um ciclo de vida de modelagem,

desenvolvimento, execução, monitoração, análise e otimização dos processos de negócio”.

Tal ciclo é demonstrado na Figura 3, reproduzida de Junior (2007):

22

Figura 3 - Elementos que compõem o ciclo de vida de BPM.

Com BPM, os processos são modelados explicitando a importância da relação entre

pessoas e aplicações, bem como analisa Junior (2007), segundo o qual a modelagem de

processos com BPM expressa os processos de negócio em termos de interações entre

aplicações e pessoas. O autor demonstra que a modelagem traz como resultado o fato de que

informações que antes estavam espalhadas em diversos sistemas sejam documentadas e

disponibilizadas para todos na organização. Segundo o autor, esse resultado implica em

melhoria dos processos e reutilização de processos.

Junior (2007, p. 14) apresenta um conjunto de benefícios que a implantação de BPM

pode trazer para uma organização, dentre os quais podemos destacar:

Documentar os processos e assim permitir sua visibilidade e validação;

Identificar e eliminar redundâncias e gargalos;

Reduzir o risco através do entendimento dos impactos do processo antes de sua

implantação;

Separar a lógica de integração de seu código de implementação;

Aumentar a portabilidade e diminuir o custo de manutenção por construir as

aplicações e implantá-las segundo padrões consagrados da indústria;

Automatizar a criação de processos através da automatização de tarefas manuais

de implantação;

23

Identificar possíveis melhorias no processo.

Amaral (2007b, p. 10) aponta os benefícios que a automação de processos traz para a

gestão de processos de uma organização, sendo eles:

Maior eficiência dos processos;

Maior agilidade operacional;

Consistência e integridade dos processos;

Melhor monitoramento e controle dos processos;

Melhoria contínua dos processos.

Outro grande benefício de BPM é apontado por Hurwitz (2009, p. 78) segundo o qual

“BPM, sozinho, contribui significativamente para liberar o negócio da tecnologia”.

Existe, contudo, um preço a pagar com a adoção de BPM: o primeiro é a necessidade

de formalização de processos, o que é incompatível com a grande maioria de empresas que

funcionam de maneira ad-hoc. Um segundo desafio envolve a necessidade de possuir enfoque

no cliente e no resultado, não apenas na maneira como a área de negócio projeta os seus

serviços. Este último ponto tem merecido destaque por parte das visões atuais de BPM para

deixar claro que o que interessa não é o quantitativo, mas a melhoria qualitativa do negócio.

Em resumo, pode-se dizer que uma eficiente implantação de BPM traz uma série de

ganhos para a organização, ao propiciar que a modelagem e melhoria dos processos sejam

realizadas com maior velocidade e eficácia.

1.3.2 Principais soluções BPM

Semelhantemente ao que foi feito para SOA, a seguir será apresentado o “quadrante

mágico” para BPM da Gartner, o qual é apresentado em Gartner (2011b). A Figura 4,

baseada em Gartner (2011b), apresenta quais foram, em 2011, os maiores fornecedores de

BPMS para BPM. Destacam-se Pegasystems, IBM (Lombardi), Software AG, Oracle,

Appian, Progress (Savvion), dentre outras. A interpretação do quadrante deve seguir à

orientação apresentada para o quadrante referente a SOA.

24

Figura 4 - Quadrante mágico para suítes BPM em 2011.

2 IMPORTÂNCIA DA INTEGRAÇÃO ENTRE SOA/BPM

A seguir serão abordados os motivos pelos quais, cada vez mais, é defendida a junção

de soluções SOA com iniciativas BPM, ressaltando os ganhos e vantagens obtidos pelas

organizações que obtiverem êxito na integração conjunta.

Amaral (2007a) apresenta uma visão clara dos campos de atuação de BPM e SOA

afirmando que “enquanto BPM é responsável por implementar a estratégia mediante os

processos, SOA define a forma como os sistemas de TI se articularão para apoiar os

processos”.

A Figura 5, baseada em Amaral (2007a), mostra o campo de atuação de cada conceito

e como estes estão alinhados, destacando o fato de que SOA se aproxima mais do nível

operacional de TI, enquanto BPM, por definição, fica contextualizado em um nível mais

elevado da gestão do negócio, ao passo que o nível mais elevado de abstração se encontra no

conceito da visão estratégica da empresa. Muito embora isso possa parecer uma diferença

25

pouco relevante, este quadro reforça uma visão típica top-down pela qual processos são

planejados, definidos e implementados, respectivamente nestes 3 (três) níveis.

Figura 5 - Alinhamento BPM x SOA.

Uma vez que os serviços fornecidos por SOA são idealmente uma implementação dos

processos modelados por BPM, podemos observar que há uma relação entre BPM e SOA,

encontrada não apenas na literatura, mas nas próprias visões de produtos e serviços

disponibilizados para o cenário de gestão corporativa.

Ao defender a importância que processos e serviços caminhem juntos nas

organizações, Junior (2007) afirma que atualmente só faz sentido implantar BPM sem

depender de SOA se seus processos não requererem automação (algo tipicamente visível em

serviços providos por um barramento ESB – do inglês Enterprise Service Bus ou Barramento

de Serviços Corporativo), nem os benefícios de uma monitoração em tempo real

(notadamente presente em mecanismos de gerenciamento via orquestração ou coreografia de

serviços).

Importante ressaltar que, na visão de alguns autores, é possível a implementação ser

realizada conjuntamente como bem salienta Vollmer apud Junior (2007) ao afirmar que “não

há a necessidade de implementar SOA antes de BPM, pois ambos podem ser feitos

simultaneamente”. Isso, contudo, traz implicações na forma como serviços podem ser

construídos, o que, ainda de acordo com a Figura 5, implicaria em um planejamento prévio

no nível de processos de negócio.

26

Também favorável a uma implementação conjunta, Junior (2007) reforça a viabilidade

do casamento SOA/BPM e lembra que “a geração atual de produtos BPM se baseia em

fundamentos SOA e são capazes de suportar todo o leque de funcionalidades da SOA”, algo

que ainda de acordo com a Figura 5, justificaria uma contribuição de SOA para BPM num

modelo bottom-up.

A visão de um conceito facilita a implantação do outro bem como relata Amaral

(2007b, p. 35) segundo o qual “a visão dos processos facilita a implantação de SOA, tanto no

aspecto técnico quanto na justificativa do investimento. A visão de SOA facilita a

implantação de BPM, reduzindo custos e prazos”.

Um outro benefício da junção SOA/BPM é relatada em Azevedo (2011, p. 27)

segundo o qual “a combinação de BPM e SOA fecha a lacuna existente entre modelos de

processos e os diagramas de TI”.

A importância da integração dos conceitos abordados também é reforçada por Hurwitz

(2009, p. 78) segundo o qual “enquanto BPM foca no desenvolvimento efetivo dos processos

de negócio, SOA é uma arquitetura que convenientemente permite que a TI se alinhe com os

processos de negócio”, deixando clara mais uma contribuição de SOA para BPM.

Com os dois conceitos juntos, tem-se o cenário em que os serviços são providos por

SOA e são consumidos por processos – criados por BPM (BEHARA, 2006).

Em um mundo globalizado, caracterizado por alta competitividade, as empresas que

unirem BPM e SOA tendem a serem mais competitivas, como explica Junior (2007), segundo

o qual, se uma empresa conseguir responder rapidamente às mudanças em seus processos de

negócio, ela possui grande vantagem competitiva no mercado, mas para isso seu ambiente de

TI deve ser flexível, sendo que esta é uma proposta de SOA.

Ao defender a integração Hurwitz (2009, p. 78) enfatiza o quanto os dois conceitos

devem ser pensados de forma conjunta ao afirmar que:

É simplesmente natural – embora muito importante – para o sucesso da

implementação de SOA, que SOA e BPM tenham convergido, com

ferramentas de software BPM se tornando uma parte natural de um ambiente

de desenvolvimento de SOA. Junto com SOA, BPM é duplamente poderoso.

Para reforçar a necessidade da combinação dos dois conceitos Junior (2007, p. 20)

também afirma que “SOA e BPM não devem mais ser tratados como iniciativas isoladas, mas

27

sim como uma solução integrada para alinhar Negócio à TI, e assim viabilizar melhores

resultados para a empresa”.

Segundo Behara (2006) SOA e BPM, combinados, automaticamente criam serviços

que podem ser reusados de diversas maneiras na empresa, e múltiplos processos que podem

ser continuamente melhorados. O autor reforça que BPM sozinha é poderosa para construir

aplicações, mas dificulta o crescimento da empresa, enquanto que SOA sozinha é poderosa

para criar consistentes e reusáveis serviços, mas sozinha não tem capacidade para, a partir

desses serviços, transformar a empresa em uma ágil e competitiva organização. Ainda para o

autor, SOA atua minimizando a distância entre a análise do negócio e o trabalho de

desenvolvimento realizado pela TI.

Outra razão para a integração SOA x BPM é apontada por Amaral (2007a) segundo o

qual um dos maiores desafios para a implantação de SOA é, sem dúvida, a definição

adequada do portfólio de serviços da empresa, desafio que, segundo o autor, pode ser

superado se os processos da empresa forem conhecidos, ou seja, se estiverem bem definidos.

Da mesma forma que acontecia nos cenários independentes de SOA e BPM, um

grande desafio ao se pensar na adoção de ambos reside na complexidade que tal atividade

exige. Aliado a isso, é necessário conjugar corretamente as visões de negócio (BPM) com a

estratégia tecnológica de implementação (SOA), o que se traduz com a operacionalização da

visão estratégica da empresa.

2.1 CONTRIBUIÇÕES DE SOA PARA BPM

É possível encontrar na literatura os indícios do forte relacionamento que os conceitos

SOA e BPM possuem: um contribui para o outro em diversos aspectos, fortalecendo a

importância e os resultados dos dois para as organizações. A seguir serão apresentados os

principais pontos em que SOA tem contribuído para uma maior eficiência da implantação de

BPM.

Amaral (2007b) relata que a forma tradicional de desenvolvimento de sistemas com

BPM traz problemas como o fato de a integração de sistemas ser feita diretamente pelo motor

de processos (fortemente acoplado). Desta forma, a ferramenta BPM é totalmente dependente

de qualquer modificação nos sistemas, sendo que a integração representa geralmente de 20 a

60% dos custos de um projeto BPM. O autor enfatiza que em uma solução que adote SOA e

28

BPM, a responsabilidade de integração fica com o ESB e, consequentemente, as ferramentas

BPM ficam independentes da infraestrutura de sistemas e mudanças na lógica de negócios são

transparentes para o processo. Observa-se que com a junção BPM/SOA há uma redução do

custo da implantação de BPM.

Outra vantagem do casamento SOA/BPM apontada por Amaral (2007b) é que “o

BPMS pode reutilizar serviços já disponibilizados pela plataforma SOA (BPMS como

consumidor de serviços)”. Os BPMS (do inglês Business Process Management System) são

sistemas que realizam a execução, o controle e a monitoração dos processos de negócio. Com

o reuso dos serviços, o autor enfatiza que há “redução de custo para a automação do processo,

maior agilidade no desenvolvimento e evolução dos processos e minimização da

complexidade e dos riscos dos projetos BPM”.

Segundo Junior (2007), a implementação de BPM mudou substancialmente como

consequência da influência de conceitos e tecnologias associadas a SOA. Os grandes

fornecedores de produtos BPM estão reconstruindo seus produtos para serem baseados em

SOA. O autor cita como exemplos de componentes BPM afetados por SOA a BPEL cujo

novo padrão é baseado no conceito de chamadas a serviços e de interfaces bem definidas, e a

integração entre aplicações, que agora é fortemente baseada em conceitos de tecnologias e

serviços.

Com SOA, há uma maior flexibilidade na contratação de serviços. Segundo Amaral

(2007b, p. 33) “como o processo está fracamente acoplado à infraestrutura de sistemas, é

possível substituir os sistemas-base com muito maior facilidade”. O autor enfatiza que isto

tem como consequência o estímulo a outsourcing flexível e inteligente e a possibilidade de

ativação simultânea de vários fornecedores.

Behara (2006) afirma que a camada de serviços fornece uma plataforma ideal para os

processos de negócio. As mudanças nos processos podem ser implementadas mais

rapidamente na camada empresarial, porque SOA desacopla os processos da implementação,

e a comunicação entre processo e aplicação ocorre somente através da integração SOA.

Segundo Garcia (2008) SOA atua como um paradigma que visa facilitar a

compreensão e a manutenção de processos de negócio que abrangem sistemas grandes. Já

para Camacho (2007) SOA atua na melhoria da flexibilidade das aplicações de negócio para

suporte às mudanças dos processos de negócio.

29

2.2 CONTRIBUIÇÕES DE BPM PARA SOA

Para atender a constante evolução no negócio das organizações, a Gestão de Processos

de Negócio objetiva permitir que a organização modele e altere seus processos de forma

estratégica e eficiente. Desta forma, soluções BPM contribuem para que uma organização

tenha o seu conjunto de processos bem definido, o qual representa as necessidades de negócio

da organização. Com esse conjunto bem definido, podemos supor que a transformação desses

processos em serviços por soluções SOA possa ocorrer de forma mais eficiente. A seguir

serão apresentados os aspectos em que BPM apoia a implantação e otimização de SOA dentro

de uma organização.

Segundo Junior (2007) quando SOA evoluiu de uma arquitetura tecnológica para uma

arquitetura de negócio, os conceitos e técnicas do BPM se encaixaram perfeitamente,

passando a integrar a camada de processos da arquitetura SOA.

Já Evangelista (2007) demonstra como BPM contribui para a implantação de SOA ao

salientar que “a adoção de um bom projeto BPM pode e deve ter a capacidade de aprender a

identificar os serviços e a granularidade dos serviços, a inserção futura de um ESB entre a

camada de negócios e a de serviços e a criação de um lugar único para registrar e descobrir

serviços”.

Behara (2006) apresenta alguns pontos em que BPM influencia SOA, destacando-se:

Ao usar BPM, SOA é ligada à composição do fluxo de negócios;

BPM fornece poder adicional em tempo de execução à combinação de serviços

que dão suporte ao negócio;

BPM aproveita e estende o poder de SOA com a adição de uma solução flexível,

uma ágil camada em tempo de execução para os serviços providos por SOA.

Amaral (2007a) elenca pontos em que iniciativas BPM podem cooperar para a

implementação de SOA, sendo eles:

Contribui para a definição dos serviços que compõem o conjunto de serviços

que dão suporte aos objetivos do negócio da empresa. O autor afirma que “uma

empresa conhecedora de seus processos, ou seja, que já tem uma iniciativa de

BPM – estará em melhores condições para fazer uma adequada definição do seu

portfólio de serviços”.

30

Apoia a justificativa do investimento em SOA. O autor demonstra a dificuldade

de a TI justificar para a área de negócio investir na implementação de SOA,

enfatizando que “segundo o Gartner Group, o principal motivador de insucesso

das iniciativas de SOA é a dificuldade em justificar o investimento para as áreas

de negócio”. Nesse cenário, a melhor abordagem é combinar o projeto SOA com

um projeto BPM. A utilização de BPM trará como benefícios maior agilidade do

processo, mais transparência, melhor controle, garantia da integridade do

processo, entre outros, e esses resultados são mais facilmente compreendidos

pela área de negócio, o que facilita a aprovação dos projetos (AMARAL,

2007a).

Prepara o ambiente organizacional para a implantação de SOA. O autor aponta a

definição adequada dos diversos processos do negócio como fator fundamental

para o êxito da implantação de SOA. Não havendo conhecimento dos processos

de negócio “a iniciativa SOA tende ao caos e ao descontrole, podendo ser

rapidamente descontinuada” (AMARAL, 2007a).

Segundo Evangelista (2007, p. 1) “com BPM os processos de negócio serão expressos

por um conjunto de serviços que são unidos (orquestrados) para compor o processo do

negócio”. Desta forma, para o autor, BPM alinhada a SOA fornece mecanismos para medir o

desempenho geral e o desempenho comparado a indicadores que são essenciais para o

negócio da organização.

3 MODELO DE INTEGRAÇÃO

Esta seção investiga a forma pela qual os conceitos de estratégias de negócio e

plataformas de serviço podem ser integrados na busca por um modelo que permita o

relacionamento dos conceitos e a proposta de um modelo de maturidade, similar ao existente

em outras áreas de gestão. O grande objetivo, portanto, não é apenas propor mecanismos de

relacionamento entre as frentes de negócio e serviços, mas fornecer indicadores sobre a

maturidade do processo.

31

A adoção de modelos de maturidade permite avaliar e caracterizar as políticas e

práticas correntes. Um modelo de maturidade que abranja a adoção, capacidade de uso e

otimização de processos e serviços dentro de uma organização irá permitir a identificação dos

pontos fortes, fracos, dos ganhos e das possibilidades de otimização tanto no âmbito de

serviços quanto no âmbito de processos.

Entre os diversos usos e benefícios advindos com um modelo de maturidade,

SIQUIRA (2005, p. 7) destaca os seguintes:

Localizar as causas de desempenhos insatisfatórios;

Estimar os benefícios potenciais da melhoria da gestão de processos;

Determinar a capacidade do processo na execução de seus propósitos;

Prover as bases o orientações para melhorias contínuas;

Mediante avaliações sucessivas, monitorar e avaliar os progressos na melhoria

da gestão de processos.

Apesar dos benefícios da implementação de um modelo de maturidade é importante

enfatizarmos que a implantação de um modelo requer investimentos que, em um primeiro

momento, podem não ser facilmente justificáveis para a área de negócio e requer, também,

mudanças comportamentais das pessoas que compõem a organização. Diante disso, é

importante que as etapas descritas por Magalhães (2007, p. 39) sejam aceitas e realizadas

pelos envolvidos:

Reconhecer a necessidade de mudança;

Conhecer a “visão da mudança”;

Reconhecer as condições limitantes;

Selecionar o método a ser utilizado na mudança;

Implementem e avaliem o método utilizado para introduzir a mudança.

3.1 PROPOSTA DE UM MODELO DE MATURIDADE

A seguir será apresentada, através de uma abordagem por analogia com modelos

consagrados no mercado, uma proposta de modelo de maturidade que reflita qual o estágio de

maturidade para integração entre processos e serviços de uma organização.

32

3.1.1 Proposta de um Modelo de Maturidade para Processos

Primeiramente será apresentada uma proposta de modelo de maturidade para

processos. Para construir o modelo que será apresentado a partir de agora, foi tomado como

referência o CMMI, pelos seguintes motivos:

Pelo fato de o CMMI ser uma referência aceita e usada universalmente como

modelo de boas práticas para processos de software eficazes;

Como o CMMI define uma escala dos níveis de maturidade para software, é

possível vislumbrar uma analogia natural para a definição de uma maturidade

que contemple e permita uma visualização segmentada da junção de processos

com serviços. A segmentação pode ser útil, no caso de um modelo para

processos e serviços, para facilitar uma comparação pormenorizada dos dois

conceitos em cada um dos níveis.

Note-se que na busca por um modelo que represente o grau de maturidade dos

processos de uma organização, a comparação com os níveis do CMMI foi natural. Tal modelo

apresenta as características estruturais e semânticas para os objetivos e grau de qualidade do

desenvolvimento de software. De fato, o CMMI define 5 (cinco) escalas para definir a

maturidade, como podemos ver na Figura 6, reproduzida de VOLPE et.al. (2003):

Figura 6 - Níveis de maturidade CMMI.

33

É importante enfatizar que, apesar do uso do CMMI como referência neste trabalho,

no Brasil foi desenvolvido, e está sendo cada vez mais adotado por empresas, outro modelo

de maturidade de processos, o MPS.Br (Melhoria de Processos do Software Brasileiro). O

MPS.Br é compatível com o CMMI, mas foi criado justamente como uma alternativa ao custo

e esforço necessários na adoção do modelo internacional, tendo como propósito permitir às

pequenas e médias empresas brasileiras alcançar um padrão de qualidade de processos de

software respeitado pelo mercado nacional.

Segundo Oliveira (2008), apesar do enfoque interno, o MPS.Br é complementar ao

CMMI e, uma vez adotado, qualifica a empresa para a implementação do modelo

internacional.

Tendo apresentado o cenário de maturidade adotado pelo CMMI, faremos aqui uma

analogia com os processos de negocio. O objetivo é permitir um mapeamento mais direto com

o nível de maturidade esperado neste cenário corporativo:

Inexistente: Neste nível, os objetivos do negócio não são conhecidos ou

apenas começaram a ser definidos;

Inicial: Aqui, começam a ser modelados os processos, pressupondo-se

conhecimento dos objetivos do negócio. No entanto, sua existência não é nem

assegurada nem controlada;

Definido: Apresenta a ideia de processos consistentes. Neste cenário, a maioria

dos processos necessários ao negócio é conhecida, de maneira que se encontra

modelada;

Gerenciado: Nesta situação, os processos já são controlados e monitorados. O

conceito de estar gerenciado implica no fato de que existe uma visão ampla dos

processos em todos os níveis da organização, o que representa um nível de

cobrança institucional para os processos;

Otimizado: Finalmente, os processos não são apenas definidos, mas são

continuamente aperfeiçoados, refletindo as constantes mudanças no negócio da

34

organização. O objetivo é uma revisão contínua do processo, pelo qual existe

uma maneira de rever e melhorar o processo.

Importante enfatizar que para os níveis 4 (Gerenciado) e 5 (Otimizado) no CMMI é

necessário uma análise estatística apoiada por informações históricas. Tal característica não

foi abordada na proposta aqui apresentada, mas considera-se importante que possa estar

presente em futuros melhoramentos desse trabalho.

3.1.2 Proposta de um Modelo de Maturidade para Serviços

Tendo feita uma comparação entre os processos de negócio e o CMMI, nesta seção é

proposta uma escala de níveis para representar o grau de maturidade alcançado pela

implantação de serviços dentro de uma organização. Neste caso, foi elaborada a partir de

analogia com o CMMI e com um modelo de classificação para implementação das práticas de

ITIL (do inglês Information Technology Infrastructure Library) apresentado na Figura 7,

baseada em Bauer (2010):

Figura 7 - Níveis de classificação para implementação das práticas de ITIL.

Importante ressaltar que na literatura são encontrados diversos modelos de

classificação para a implementação de ITIL. Um outro interessante modelo e similar ao

encontrado em Bauer (2010) é apresentado em MAGALHÃES (2007, p. 35) o qual demonstra

35

o caminho desde um nível “caótico” até o nível “valor”, no qual torna-se perceptível para a

organização o quanto é importante o alinhamento do negócio com a TI.

Adaptando o modelo apresentado na Figura 7 para termos uma escala de maturidade

para a implantação de serviços em uma organização, tem-se o seguinte esquema:

Nível 1: Tem por objetivo substituir a infraestrutura de gerência por qualquer

tipo de processo. A arquitetura do sistema não reconhece serviços, somente

funcionalidades fechadas, acopladas.

Nível 2: Neste cenário, existem serviços, mas de maneira não padronizada.

Neste sentido, pode-se perceber a existência de componentes lógicos para

representar funções do sistema.

Nível 3: Já existem padrões sobre os serviços, bem como ferramentas, mas não

existe uma maneira de gerenciá-los, seja via orquestração ou coreografia.

Nível 4: É possível fazer orquestrações, sincronização dos serviços. Aqui,

surgem componentes como o ESB que funcionam como mediadores na

composição dos serviços.

Nível 5: Finalmente, pode-se pensar em otimizações nas comunicações e

serviços do ESB ou de quaisquer mecanismos de integração.

3.1.3 Unindo os modelos

O grande desafio deste trabalho não consiste em avaliar isoladamente propostas de

maturidade para serviços e processos, mas sugerir a sintetização das duas propostas de

classificação anteriormente apresentadas. Obviamente, a simples combinação entre as

variáveis torna-se impraticável por dois motivos principais:

A combinação de níveis entre os dois mundos leva a uma quantidade

considerável de possibilidades que poderia, em princípio, tornar

desnecessariamente complexa uma classificação;

Pode-se perceber que nem todas as situações são possíveis. Por exemplo, em

que o nível de maturidade de processos é o mais elementar, enquanto a visão

de serviços está num padrão otimizado. Neste cenário anômalo,

36

paradoxalmente seria possível uma completa gestão tecnológica sem sequer

possuir fundamentos conceituais estratégicos.

Neste sentido, é proposta a simplificação de uma proposta integrada para a avaliação

de maturidade entre SOA e BPM. Importante ressaltar que o autor, no desenvolvimento da

pesquisa bibliográfica, não se deparou com qualquer proposta de maturidade que englobasse

processos e serviços. O que se propõe aqui deve ser visto como a versão inicial de um modelo

que, semelhantemente ao que ocorreu para modelos consagrados no mercado como o CMMI,

precisará passar por críticas, melhoramentos e avaliações de caráter experimental da sua

aplicabilidade, tanto no âmbito acadêmico, como no corporativo, até que venha a ser tratado

como um modelo consistente e de uso recomendado em cenários reais. É preciso avaliar,

também, quais são os critérios consensuais que devem ser considerados para a definição da

maturidade em cenários de trabalho corporativos.

NÍVEL DESCRIÇÃO

Inexistente

Os objetivos do negócio ainda não são conhecidos, havendo apenas

uma visão míope das atividades. Não há esforço por modelagem de

processos. A arquitetura do sistema não reconhece serviços, somente

funcionalidades fechadas.

Inicial

Começam a ser modelados os processos, pressupondo-se conhecimento

dos objetivos do negócio. Existência de serviços sem padronização,

mas com a clara ideia de que funcionalidades monolíticas são

insuficientes: existem componentes lógicos.

Definido

Processos consistentes, de maneira que a maioria dos processos

necessários ao negócio é conhecida e encontra-se modelada. Estes

mesmos processos permitem definir padrões sobre os serviços, existem

ferramentas, mas ainda não existem mecanismos poderosos para

integração.

Gerenciado

Processos são controlados, permitindo um monitoramento. Por outro

lado, existe uma possibilidade de integração baseada em alto reuso dos

serviços, com o uso de coreografia e orquestração.

Otimizado

Os processos são aperfeiçoados, refletindo as constantes mudanças no

negócio que são igualmente refletidas na otimização das comunicações

e serviços entre os mais diferentes sistemas. Tanto a TI quanto a alta

gestão caminham no mesmo ritmo e sob o mesmo objetivo comum de

excelência na organização.

Tabela 1 - Proposta Modelo Maturidade SOA x BPM.

37

Uma observação importante é que, em termos de combinação dos diferentes níveis de

maturidade, poder-se-ia pensar em uma matriz 5x5. No entanto, as razões práticas podem

demonstrar que tal espectro de combinações não é em si mesmo possível: a razão é de que, ao

ascender em um nível um dos dois parâmetros (serviços ou processos), automaticamente

algum valor agregado é trazido pela outra variável. Por exemplo, um nível de excelência de

processos, automaticamente implica em uma gestão minimamente organizada de serviços e

vice-versa, conforme ilustrativamente mostrado na Figura 8, logo abaixo. Isso implica que as

combinações entre serviços e processos não podem ser arbitrariamente criadas, havendo

regiões (região A da figura) consideradas inviáveis para as diversas combinações entre os

níveis de maturidade de processos e serviços. Por outro lado, o que sempre é almejado é

alcançar um nível próximo da excelência (regiões B) em que a maturidade esteja num nível

otimizado.

.

Figura 8 - Matriz de combinações entre níveis de maturidade SOA x BPM.

Uma outra importante observação é que, dado ao caráter pioneiro da proposta de

maturidade aqui apresentada, um estudo bem mais profundo, inclusive com um viés empírico,

deve derivar de todo o processo.

38

3.2 APRESENTAÇÃO DE CENÁRIOS

A fim de dar vazão a uma melhor compreensão dos cenários de maturidade, esta seção

apresenta alguns exemplos típicos que podem ser considerados, adequando os níveis de

maturidade previamente apresentados.

3.2.1 Cenário 1: Maturidade

Neste cenário, considera-se o exemplo de uma grande empresa que possui sistemas

desenvolvidos em diferentes plataformas, desde sistemas baseados em mainframe, web a

aplicações cliente-servidor. Como modelo, foi estudado pelo autor um conjunto de

documentações desenvolvidas internamente pelo SERPRO (Serviço Nacional de

Processamento de Dados do Ministério da Fazenda) e disponíveis na Internet, com destaque

para os seguintes: uma proposta de arquitetura referencial para Governo, conforme Franzosi

(et. al., 2009) e a descrição da governança de processos na referida instituição, conforme

SERPRO (2011).

Algumas características observadas em tais documentações são pontuadas

sucintamente em um cenário como se segue:

CEN1.1 – Todos os serviços estratégicos e essenciais ao negócio são

conhecidos;

CEN1.2 – Novos sistemas são desenvolvidos sobre o paradigma da orientação

a serviços;

CEN1.3 – Os serviços são classificados em duas categorias: os que são

responsáveis por suportar as atividades da empresa, ou seja, da área afim,

(cadastro de fornecedores, por exemplo) e os serviços que controlam os

serviços finalísticos (autenticação, aferição de qualidade, por exemplo);

CEN1.4 – Os processos da empresa são conhecidos e são modelados com uma

ferramenta BPEL;

39

CEN1.5 – O conhecimento das regras de negócio estão disponíveis para

pessoas dos diversos departamentos;

CEN1.6 – O negócio é expressado em termos das relações entre pessoas e

processos;

CEN1.7 – Existe um escritório de processos responsável por diversas ações,

dentre elas:

Promover a padronização e integração dos processos corporativos;

Prestar suporte ao uso de ferramentas de modelagem e ao portfólio de

processos corporativos;

Monitorar o desempenho dos processos;

Promover a visibilidade interdepartamental dos processos corporativos;

Promover a capacitação adequada aos colaboradores para que tenham

conhecimento dos procedimentos de interação com os processos;

Benchmarking;

Eventos.

CEN1.8 – A alta gestão utiliza um software de gestão das informações

resultantes dos serviços;

CEN1.9 – Existe um Catálogo de Serviços (repositório para a troca e

descoberta de serviços com seus respectivos procedimentos de habilitação);

CEN1.10 – As regras de negócio estão localizadas em um repositório de regras

de negócio;

CEN1.11 – Há um criterioso mapeamento dos metadados utilizados na

execução dos serviços;

CEN1.12 – Foi criado um Catálogo de Padrões de Dados (um repositório onde

são registrados todos os padrões de dados reconhecidos e utilizados pelos

sistemas da empresa);

CEN1.13 – Para apresentar as informações resultantes dos serviços aos

Gerentes de negócio são utilizadas ferramentas de data mart – sub-conjunto de

dados em data warehouse, geralmente referentes a um assunto em especial – e

gerência de conteúdo dos portais;

40

CEN1.14 – A infraestrutura provê o uso de uma barramento SOA, o ESB, que

se responsabiliza por:

Rotear as mensagens entre os serviços;

Converter os protocolos entre a aplicação requisitante o serviço;

Transformar o conteúdo da mensagem entre o requisitante e o serviço;

Controlar os eventos de negócio disparados;

Integrações com aplicações legadas e bases legadas;

CEN1.15 – Os impactos de um processo novo são cuidadosamente analisados

antes de sua implementação;

CEN1.16 – É utilizado um componente de gerenciamento de processos que

provê componentes de análise/documentação dos processos, logs e metadados.

CEN1.17 – A execução e acompanhamento é feita através de um Portal de

Processos;

CEN1.18 – As medidas de desempenho dos processos têm permitido mensurar

o retorno do investimento, o que facilita justificar novos investimentos na

infraestrutura de TI que suporta os processos;

CEN1.19 – Os recursos (tecnológicos e humanos) são alocados de acordo com

as necessidades dos processos de negócio;

CEN1.20 – Atualmente a estrutura da empresa envolvendo os sistemas

legados, serviços desenvolvidos, processos de negócio e os portais de conteúdo

é coordenada pela infraestrutura SOA e BPM.

Considerando o cenário 1 apresentado, pode-se inferir com relativa facilidade que a

empresa em questão já possui um nível de maturidade bem definido na definição de processos

e serviços para toda a instituição. Isso significa que está além dos níveis 1 e 2. Além disso,

conforme mencionado no item CEN1.18, existe uma coleta de métricas que permite uma

avaliação contínua do desempenho, uma informação importante para viabilizar o nível

otimizado (5), muito embora não seja garantido que a empresa já se encontre neste patamar de

otimização. Com base nessas e em outras informações, um nível 4 (Gerenciado) pode ser,

seguramente, atribuído à mesma.

41

O item CEN1.7 destaca que os colaboradores que interagem com os processos devem

ter capacitação adequada, sendo que esse é um ponto que pode ser considerado como um fator

de grande importância para uma consistente maturidade dos processos organizacionais.

É importante notar que os critérios para a definição de maturidade não são absolutos,

podendo depender de uma avaliação subjetiva por parte do leitor e que, sob certos critérios,

um nível ou outro pode ser alcançado. A qualificação final da instituição pode depender tanto

da maior quantidade de inferências feitas (por exemplo, uma maior quantidade de indícios

recai sobre um determinado nível), quanto pela possível valoração de pesos de maior ou

menor importância a cada um destes critérios.

Além do cenário supracitado (SERPRO), pode-se avaliar que instituições diversas já

possuem um grande interesse em garantir um relacionamento entre processos e serviços. Por

exemplo, conforme pode ser observado em Silva (2008), a CEF apresenta um nível de

maturidade, pelo menos Definido (nível 3) para vários de seus núcleos (cliente bancário,

participação social ou atendimento ao governo), conforme indicado na Figura 9, reproduzida

de Silva (2008).

Figura 9 - Exemplo de um cenário definido para uma empresa madura em processos e serviços (CEF).

3.2.2 Cenário 2: Imaturidade

42

A seguir, considera-se um cenário comum a tantas empresas de TI que trabalham de

maneira não organizada (ad-hoc). Note-se que o panorama é consideravelmente diferente em

relação ao cenário anterior. O objetivo é constatar que algumas das práticas hoje vigentes

contrastam com uma visão recomendada de maturidade em processos e serviços. Neste

sentido, algumas características dos cenários podem ser pensadas:

CEN2.1 – Novos sistemas são desenvolvidos sob visão da orientação a

serviços;

CEN2.2 – Os processos mais importantes da empresa ainda encontram-se em

fase de identificação. Com isso, o esforço de documentação dos mesmos

encontra-se em fase incipiente. Os processos de um departamento são

desconhecidos pelos demais departamentos. Como consequência de ainda não

se conhecer os processos mais importantes, ainda não foi possível definir, a

nível corporativo, quais serão e qual o escopo de cada um dos serviços que a

infraestrutura de TI terá que implementar;

CEN2.3 – A empresa possui em sua base um grande conjunto de informações,

no entanto, não consegue fazer uso dessa informação de forma estratégica, uma

vez que não possui mineração dos dados. Além disso, não possui eficientes

mecanismos de avaliação de desempenho dos seus processos e, por não possuir

uma mensuração de desempenho, a alta gestão é cautelosa diante da

necessidade de investimentos volumosos na área de TI;

CEN2.4 – A integração de sistemas tem sido dispendiosa e, por muitas vezes,

demandado alterações no núcleo da integração.

CEN2.5 – Não é raro analistas de negócio se depararem com processos que

realizam tarefas similares ou até iguais as realizadas por outros processos

existentes;

CEN2.6 – Observa-se que dados e recursos da empresa poderiam ser melhor

compartilhados. Existem demandas no ciclo produtivo da empresa que são

sazonais, o que resulta em períodos em que os recursos, tanto humanos como

tecnológicos, ficam ociosos. Mas por não possuir estatísticas confiáveis e uma

43

infraestrutura flexível, ainda não foi possível fazer um uso mais inteligente dos

recursos, adotando outsourcing, por exemplo;

CEN2.7 – Uma vez por outra são encontradas discrepâncias entre o modelo de

processos e os diagramas de TI;

CEN2.8 – Gerenciar as interações entre os diversos serviços tem sido uma

grande dificuldade para dar suporte aos processos da empresa, uma vez que

diversas atividades de gerenciamento são feitas de forma manual;

CEN2.9 – O ambiente de TI, complexo e heterogêneo, tem sido um

dificultador na hora de implementar as mudanças necessárias;

CEN2.10 – As soluções de negócio, em sua maioria, ainda são dependentes

das restrições tecnológicas.

Considerando o cenário 2 apresentado, é possível afirmar que a empresa hipotética

retratada estaria, no máximo, no nível 2 (Inicial) na escala de maturidade de processos e

serviços. Os itens CEN2.1 e CEN2.2 permitem encaixar a empresa no nível 2, no entanto, os

itens a partir do 2.2 rebaixariam a classificação da maturidade da mesma para o nível 1.

Novamente, como afirmado anteriormente, uma qualificação definitiva da maturidade de

determinado cenário depende da quantidade de informações analisadas na inferência, bem

como de uma possível valoração dos pesos para os critérios analisados.

Estes cenários hipotéticos não pretendem ser, de forma alguma, exaustivos, mas visam

fornecer pistas para a avaliação dos critérios de maturidade aqui apresentados. A seguir, serão

considerados alguns pontos considerados relevantes acerca da metodologia adotada.

3.2.3 Proposta de um questionário de avaliação (checklist)

Como alternativa para uma melhor investigação de como qualificar empresas ou

instituições com relação à maturidade de processos e serviços, esta seção apresenta um

conjunto de questões definidas pelo autor que podem ser utilizadas para servir de insumo no

processo de avaliação dos cenários corporativos. As questões foram elaboradas com base na

44

pesquisa bibliográfica. Para cada questão, para fim de exemplificação, foi considerado em

qual nível estaria a qualificação da maturidade, levando-se em conta que a mesma foi

respondida como SIM.

A. Exemplo de uma lista para avaliação da maturidade de serviços (QS):

Nível 1 - Inexistente

QS1: Mudanças na lógica de negócios resultam, necessariamente, em

grandes alterações nos sistemas?

Avaliação: A resposta SIM colocaria a maturidade de serviços no nível 1,

no melhor caso.

QS2: Os sistemas existentes são fortemente acoplados e impedem o reuso e

dificultam manutenções?

Avaliação. Nível 1.

Nível 2 - Inicial

QS3: O esforço para a integração de um novo sistema afeta o núcleo da

integração?

Avaliação: Considerando a resposta SIM, estaria em um nível 2, no

máximo.

QS4: Os sistemas são implementados sob a filosofia de serem aplicações

fracamente acopladas e divididas em serviços?

Avaliação: Nível 2, pelo menos.

QS5: Sua infraestrutura de sistemas faz uso de WebServices?


45

QS6: A sua infraestrutura de TI é de fácil operação e manutenção?


Nível 3 - Definido

QS7: O ambiente de TI tem facilidade para reaproveitar as funcionalidades

existentes na implementação de sistemas?


QS8: A lógica de integração dos sistemas é separada do código de

implementação?


QS9: As aplicações são construídas e implantadas segundo padrões usados

na indústria?


Nível 4 - Gerenciado

QS10: Quando surge um novo sistema, a integração com os sistemas

existentes é rápida e eficiente?

Avaliação: Considerando uma resposta SIM, a maturidade estaria, pelo

menos, no nível 4, pois sugere a ideia do uso de um ESB.

QS11: Os dados e recursos da empresa são compartilhados eficientemente?

Avaliação: A resposta SIM colocaria a maturidade em um nível 4, pelo

menos.

QS12: Os sistemas têm capacidade de comunicar-se com os outros de

forma eficiente?


46

Nível 5 - Otimizado

QS13: Existe algum repositório para armazenamento e descoberta dos

serviços?

Avaliação: Nível 5.

QS14: Existe algum mecanismo provido pela infraestrutura de TI

encarregado de coordenar as interações dos serviços?

Avaliação: Nível 5.

B. Proposta de questões para a avaliação da maturidade dos processos (QP):


QP1: As regras de negócio estão fixas no código dos sistemas?

Avaliação: Nível Inexistente.

QP2: Existem processos que realizam tarefas inexistentes às realizadas por

outros processos?


QP3: Não há nenhum esforço para identificação, mapeamento e/ou

documentação dos processos da instituição?


Nível 1 - Inicial

QP4: Os processos mais importantes da empresa estão identificados?

Avaliação: Nível Inicial, pelo menos.

47

QP5: É possível perceber uma lacuna entre os modelos de processos e os

diagramas de TI?

Avaliação: Inicial.

QP6: Quando um processo de negócio é alterado isso implica na alteração

de várias aplicações?

Avaliação: Inicial, no melhor caso.

Nível 2 - Definido

QP7: Na sua empresa há o uso de alguma ferramenta para a identificação

de processos de negócio?

Avaliação: Definido, pelo menos.

QP8: Tarefas manuais de implantação de processos estão e/ou foram

automatizadas?

Avaliação: Nível Definido, pelo menos.

QP9: Os processos são devidamente caracterizados e documentados?

Avaliação: Nível Definido, pelo menos.

QP10: O conjunto de processos tem facilitado a colaboração entre pessoas?


QP11: Na sua concepção, o Negócio da sua empresa é independente de

restrições de tecnologia?



48

QP12: O gerenciamento de negócios tem sido apoiado por ferramentas de

TI?

Avaliação: Gerenciado, pelo menos.

QP13: As regras de negócio são externalizadas, isto é, compartilhada entre

os diversos departamentos da empresa?


QP14: As mudanças na lógica de negócios são transparentes para os

processos?


QP15: As informações são compartilhadas entre os diversos

departamentos?


QP16: Há uma documentação ampla dos processos de negócio?


QP17: Na sua concepção, as mudanças no negócio de sua empresa, são

refletidas nos sistemas de TI rapidamente?



QP18: Existem mecanismos para identificar e evitar gargalos e

redundâncias no ambiente de sistemas?

Avaliação: Otimizado.

QP19: Os impactos do processo são cuidadosamente analisados antes de

sua implantação?

49


QP20: Há coleta de estatísticas quanto à eficiência dos processos de

negócio?


C. Proposta conjunta de questões para a avaliação da maturidade da integração SOA x

BPM (QC):


QC1: Os sistemas são desenvolvidos sem a visão de orientação a serviços,

dificultando o suporte aos processos?


QC2: Os processos da empresa são tratados sem padronização de forma

que a identificação de novos processos é lenta e gradual e, quando

identificados, não existem sistemas já devidamente testados e desacoplados

que possam dar suporte a esses processos?


Nível 1 - Inicial

QC3: A integração de sistemas é feita diretamente pelo motor de

processos?


QC4: Já há um esforço por modelagem dos processos mas, no entanto, não

há avaliações sobre o desempenho do mesmos e ainda não existem

ferramentas para acompanhar a execução desses processos?


50

Nível 2 - Definido

QC5: Todos os processos são conhecidos, mas, no entanto, ainda não há

mecanismos eficientes para realizar as integrações e interações com os

serviços?

Avaliação: Definido, no melhor caso.


QC6: Existe algum(ns) mecanismo(s) que atua(m) no gerenciamento das

interações entre os serviços que dão suporte a um processo de negócio?


QC7: Os serviços que dão suporte a um processo de negócio estão

submetidos a um processo mestre que coordena suas interações?


QC8: A documentação dos sistemas reflete de forma coerente o modelo de

processos da empresa?


QC9: Em sua concepção, os processos mapeados e implantados na sua

empresa o são de forma automatizada?


QC10: Se sua empresa faz o uso de softwares BPM, esses softwares já se

tornaram parte natural do ambiente de desenvolvimento de serviços?



QC11: Os sistemas de TI da sua empresa têm auxiliado a empresa a tomar

decisões estratégicas que a fazem se manter competitiva no mercado?


51

QC12: Seu ambiente de TI possui a flexibilidade necessária para responder

rapidamente às mudanças nos processos de negócio?


QC13: Os processos são monitorados em tempo real e eventuais mudanças

têm suporte rápido por parte do ambiente de TI?


QC14: A visão dos processos tem sido úteis no momento de justificar os

investimentos na infraestrutura de TI que dá suporte a esses processos?


Deve-se ressaltar que quando uma questão foi qualificada como “Inicial, pelo menos”

significa que, considerando aquela questão individualmente é possível enquadrar a

maturidade da empresa como Inicial, nesse caso, mas que, ao responder a outras questões, a

maturidade pode caminhar para níveis acima (Definido, Gerenciado, Otimizado).

Uma alternativa ao checklist seria o desenvolvimento de um método de avaliação

baseado em entrevistas e análise de informações históricas e qualitativas da instituição.

Estritamente falando, muitas outras questões podem ser propostas para ampliar a

cobertura na visão de processos e serviços, bem como pode ser pensada uma priorização das

questões consideradas mais relevantes em relação a pontos menos significativos.

Ainda como proposta de melhoria futura do checklist, poderia ser utilizado o método

de classificação nebulosa GOM para gerar 5 dimensões para as respostas, ao invés de apenas

SIM ou NÃO. Ou seja, ao utilizar GOM poder-se-ia pensar em algo como cinco

possibilidades para as respostas, tais como: Discordo parcialmente, Discordo totalmente,

Concordo parcialmente, Concordo totalmente, Não se aplica. Essa abordagem permitiria um

maior detalhamento, o que pode, certamente, contribuir para uma melhor avaliação da

maturidade da instituição. Complementarmente, para uma definição mais consistente das

metas de medição e avaliação da maturidade pode-se utilizar algum método baseado na

abordagem GQM (Goal-Question-Metric).

52

3.3 CRÍTICAS SOBRE OS CENÁRIOS DE MATURIDADE

Sobre os critérios de maturidade anteriormente descritos, algumas críticas podem

ser feitas a fim de avaliar corretamente os pressupostos assumidos na classificação pensada e

na integração considerada.

A. As opções de processos e serviços:

O primeiro questionamento que pode ser feito diz respeito à vinculação feita no

texto entre serviços e a arquitetura SOA e processos e o modelo BPM. Deve ficar claro que a

primeira componente (serviços / processos) não é de forma nenhuma exaurida pelas

características da segunda (SOA / BPM), mas, por outro lado, estas últimas representam não

apenas as grandes realidades na configuração e implementação de serviços e processos, como

também colaboram para amadurecer tais cenários. Estritamente falando, no entanto, um

estudo de serviços independente de SOA e processos independente de BPM pode ser

desenvolvido.

B. Necessidade de Integração:

Outro questionamento que pode ser feito diz respeito aos pontos chaves da

integração entre processos e serviços. Muito embora no texto tenha sido desenvolvida a ideia

de que a parceria entre SOA e BPM seja extremamente recomendada, não existe na literatura

uma relação obrigatória entre os mundos. Isso implica que um cenário de maturidade voltado

para apenas uma das componentes (serviços ou processos) pode ser realmente pensada.

C. Objetividade dos critérios:

O aspecto de um checklist subjetivo anteriormente proposto também representa

uma limitação do estudo: em especial, em cenários reais, onde existem definições de negócio

53

e arquiteturas de serviços, pode ser difícil precisar o nível de maturidade da organização. A

avaliação de itens do questionário pode ser um processo ambíguo de diagnóstico e, portanto,

sujeito a interpretações.

Uma alternativa seria a formalização de critérios e o ajuste de parâmetros que

possam aumentar a precisão e a confiabilidade no diagnóstico fornecido. Para tanto, a

utilização de sistemas especialistas pode ser recomendada como uma alternativa eficaz na

elaboração de um parecer final sobre a maturidade organizacional.

Além disso, a ausência de outros critérios além daqueles mencionados no

checklist, pode ser considerada uma imperfeição no método. Da mesma forma, pontos aqui

apresentados podem ser considerados inadequados na avaliação de certos cenários. Em

especial, considerando que cada organização tem o seu modo de operação (processos e

serviços), podem surgir pontos adicionais que irão adequando os itens de avaliação à

realidade bem mais rica e ampla das empresas, o que está além deste estudo acadêmico

inicial.

54

4 CONCLUSÃO

Um dos objetivos deste estudo consistiu em avaliar que tipo de organização é apta a

realizar a integração, bem como quais são os impactos/mudanças na estrutura organizacional e

na maneira como processos são gerenciados e os serviços são oferecidos.

O objetivo maior era o de propor um critério de maturidade para organizações que

enveredam pelo desafio da integração de processos (BPM) e serviços (SOA), à semelhança de

critérios de maturidade apregoados pelo CMMI e pelo COBIT (Control Objectives for

Information and Related Technology). O modelo permitirá ao leitor avaliar o nível de

maturidade de processos e serviços de uma organização.

A análise bibliográfica comprovou a importância do relacionamento dos conceitos de

SOA e BPM dentro de um cenário organizacional, com base na pesquisa bibliográfica. A

análise bibliográfica mostra, também, que adotar BPM e SOA em um ambiente

organizacional requer planejamento, consciência de que o retorno não será imediato e de que

é essencial romper com paradigmas: com a integração entre processos e serviços faz-se

necessário que sistemas sejam desenvolvidos com foco no reuso e que a empresa seja vista

como sendo a composição de pessoas e de como estas interagem sobre os processos de

negócio. Os exemplos permitiram avaliar as necessidades, etapas, dificuldades e benefícios

encontrados na realização de tal integração nas organizações.

Como trabalhos futuros, podem ser sugeridos:

Aprofundamentos no mecanismo de avaliação da maturidade de processos e

serviços, a avaliação de restrições impostas pelos cenários de tecnologias SOA e

BPM.

Também pode-se contemplar a possibilidade de utilização de sistemas

especialistas para a automação de um processo de classificação de maturidade em

ambiente corporativo.

55

Levando-se em conta o critério qualitativo do questionário apresentado, pode-se

elaborar um checklist que abranja também aspectos quantitativos referentes à

maturidade.

Adicionalmente, tomando como base cenários reais, pode-se mensurar em quais

critérios uma abordagem SOA/BPM tem desempenho superior e/ou inferior a uma

abordagem individual em médio e longo prazo.

Finalmente, é importante destacar que a utilização de processos e serviços, em maior

ou menor grau são hoje exigências fundamentais para a garantia de continuidade das

instituições: a correta utilização de tecnologias e de uma gestão eficiente, muito além do uso

de modelos teóricos, representa uma vantagem competitiva para as organizações. Pode ser

que no futuro, tal como ocorreu com a revolução tecnológica, nos perguntemos, como

pudemos viver tanto tempo sem o uso dessas alternativas.

56

5 BIBLIOGRAFIA

ALVES, Ronald. Como Analisar o “Quadrante Mágico” do Gartner para o Brasil. 2010.

Disponível em: http://tecnologiadenegocios.wordpress.com/2010/05/31/como-

analisar-o-quadrante-magico-do-gartner-para-o-brasil/. Acesso em: 27/11/2011.

AMARAL, V a; VIERO, D. BPM e SOA: um é bom, dois é melhor. 2007. Disponível em:

http://www.iprocess.com.br/artigos/conteudo/iprocess_bpm_soa.pdf. Acesso em

15/11/2011.

AMARAL, Vinícius b. Automação de Processos com BPM e SOA. 2007. Disponível em:

http://www.businessprocessday.com.br/palestras/Vinicius_Amaral.pdf. Acesso em:

19/11/2011.

ARRUDA, Silvana de Carvalho. A Importância do Uso de Arquitetura Orientada a Serviços

(SOA) para a Área de Negócios das Empresas. 2009. 44 f. Dissertação. (Centro

Tecnológico da Zona Leste) – Faculdade de Tecnologia da Zona Leste, São Paulo.

2009. Disponível em: http://www.fateczl.edu.br/TCC/2009-1/tcc-45.pdf. Acesso em:

20/11/2011.

AZEVEDO, Leonardo Guerreiro. Arquitetura Orientada a Serviços e Gestão de Processos de

Negócio. 2011. Disponível em: http://www.slideshare.net/fbotafog/aerio-2011-bpm-e-

soa-leonardo-azevedo. Acesso em: 20/11/2011.

BAUER, Per. Introducing a Capability Management Maturity Model. 2010. Disponível em:

http://www.teamquest.com/pdfs/whitepaper/maturity-model.pdf. Acesso em:

18/05/2012.

BEHARA, Gopala Krishna. BPM and SOA: A Strategic Alliance. 2006. Disponível em:

http://www.bptrends.com/publicationfiles/05-06-wp-bpm-soa-behara.pdf. Acesso em:

20/11/2011.

CAMACHO, José. Open BPM – EA, SOA. 2007. Disponível em: http://www.inst-

informatica.pt/servicos/informacao-e-documentacao/dossiers-tematicos/dossier-

tematico-no-6-bpm-business-process/08-NCS.pdf. Acesso em: 19/11/2011.

http://tecnologiadenegocios.wordpress.com/2010/05/31/como-analisar-o-quadrante-magico-do-gartner-para-o-brasil/

http://tecnologiadenegocios.wordpress.com/2010/05/31/como-analisar-o-quadrante-magico-do-gartner-para-o-brasil/

http://www.iprocess.com.br/artigos/conteudo/iprocess_bpm_soa.pdf

http://www.businessprocessday.com.br/palestras/Vinicius_Amaral.pdf

http://www.fateczl.edu.br/TCC/2009-1/tcc-45.pdf

http://www.slideshare.net/fbotafog/aerio-2011-bpm-e-soa-leonardo-azevedo

http://www.slideshare.net/fbotafog/aerio-2011-bpm-e-soa-leonardo-azevedo

http://www.teamquest.com/pdfs/whitepaper/maturity-model.pdf

http://www.bptrends.com/publicationfiles/05-06-wp-bpm-soa-behara.pdf

http://www.inst-informatica.pt/servicos/informacao-e-documentacao/dossiers-tematicos/dossier-tematico-no-6-bpm-business-process/08-NCS.pdf



57

EVANGELISTA, Carlos. Usar BPM ou SOA ou BPM e SOA. 2007. Disponível em:

http://www.igpinformatica.com.br/docs/BPMSOA.pdf. Acesso em: 15/11/2011.

FRANZOSI, Ednylton Maria. GARCIA, Ana. RODEIGUES, Sérgio Assis. BLASCHEK,

José Roberto. SOUZA, Jano Moreira de. Uma Proposta de Arquitetura Referencial

SOA para Desenvolvimento de Sistemas para o Governo. 2009. Disponível em:

http://www.lbd.dcc.ufmg.br/colecoes/wcge/2009/004.pdf. Acesso em: 25/05/2012.

GARCIA, Tiago R; GARCIA, Leonardo A; MATIAS, Thiago F. M. Implementando SOA

através de BPM, WebServices e ESB. 2008. Disponível em: http://cco910-12630-

12642-12643.googlecode.com/svn-history/r56/trunk/minicurso/minicurso.pdf. Acesso

em: 19/11/2011.

GARTNER. Magic Quadrant for SOA Governance Technologies. EUA, 2011. Disponível

em: http://process-modelling-city.blogspot.com/2010/12/gartners-bpm-magic-

quadrant-2010.html. Acesso em: 04/12/2011.

GARTNER. Magic Quadrant for Business Process Management Suites. EUA, 2011.

Disponível em: http://www.infoq.com/news/2010/12/gartner-systematic-soa-report.

Acesso em: 04/12/2011.

HURWITZ, Judith. Arquitetura Orientada a Serviços – SOA para Leigos. 2. ed. Rio de

Janeiro: Alta Books, 2009. 379 p.

JOSUTTIS, Nicolai M. SOA na Prática. Rio de Janeiro: Alta Books, 2009. 280 p.

JUNIOR, Antonio Carlos Benedete. Roteiro para a definição de uma arquitetura SOA

utilizando BPM. 2007. 56 f. Dissertação de MBA (Programa de Educação

Continuada em Engenharia) – Escola Politécnica da Universidade de São Paulo.

Disponível em: http://www.bmainformatica.com.br/pdfs/MBA-MONO-

AntonioCarlosJr.pdf. Acesso em: 12/11/2011.

MAGALHÃES, Ivan Luizio; WALFRIDO, Brito Pinheiro. Gerenciamento de Serviços de TI

na prática: uma Abordagem com Base na ITIL. 2007. Disponível em:

http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/235588.pdf.

Acesso em: 27/04/2012.

http://www.igpinformatica.com.br/docs/BPMSOA.pdf

http://www.lbd.dcc.ufmg.br/colecoes/wcge/2009/004.pdf

http://cco910-12630-12642-12643.googlecode.com/svn-history/r56/trunk/minicurso/minicurso.pdf

http://cco910-12630-12642-12643.googlecode.com/svn-history/r56/trunk/minicurso/minicurso.pdf

http://process-modelling-city.blogspot.com/2010/12/gartners-bpm-magic-quadrant-2010.html

http://process-modelling-city.blogspot.com/2010/12/gartners-bpm-magic-quadrant-2010.html

http://www.infoq.com/news/2010/12/gartner-systematic-soa-report

http://www.bmainformatica.com.br/pdfs/MBA-MONO-AntonioCarlosJr.pdf

http://www.bmainformatica.com.br/pdfs/MBA-MONO-AntonioCarlosJr.pdf

http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/235588.pdf

58

MICROSOFT. Service Oriented Architecture (SOA) in the Real World. EUA, 2008.

Disponível em

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16187.

Acesso em: 12/08/2011.

NETO, João C. SOA: Filosofia, Práticas e Recursos. 2008. Disponível em:

http://www.ctgi.com.br/REP/Pratica_e_Tendencias_em_SOA.pdf. Acesso em:

19/11/2011.

OLIVEIRA, Camila da. Comparando CMMI e MPS.BR: As Vantagens e Desvantagens dos

Modelos de Qualidade no Brasil. 2008. Disponível em:

http://www.camilaoliveira.net/Arquivos/Comparando%20CMMi%20x%20MPS.pdf.

Acesso em: 16/05/2012.

SANTOS, Rildo. Como Fazer a Integração entre BPM e SOA. 2010. Disponível em:

http://www.slideshare.net/Ridlo/como-fazer-a-integrao-entre-bpm-e-soa. Acesso em:

21/11/2011.

SERPRO. Governança de Processos no SERPRO. 2011. Disponível em:

http://plataformadeprocessos.serpro.gov.br/artefatos/Apresentacao%20EGOP.pdf/vie

w. Acesso em: 20/05/2012.

SILVA, Álvaro Augusto Parente. Automação de Processos na CAIXA. 2008. Disponível em:

http://www.aneel.gov.br/aplicacoes/intercambio/arquivos/dia 25/CAIXA - ALVARO

AUGUSTO.pps. Acesso em: 24/05/2012.

SIQUEIRA, Jairo. O Modelo de Maturidade de Processos: como maximizar o retorno dos

investimentos em melhoria da qualidade e produtividade. 2005. Disponível em:

http://www.ibqn.com.br/htm_artigos_links/Jairo_Siqueira_Modelo_de_Maturidade_

de_Processos.pdf. Acesso em: 27/04/2012.

VOLPE, Renato Luiz Della; JOMORI, Sergio Massao; ZABEU, Ana Cecília Peixoto. CMM

– CMMI: Principais Conceitos, Diferenças e Correlações. 2003. Disponível em:

http://www.asrconsultoria.com.br/downloads/pdf/SPIN_BH_CMMI.pdf. Acesso em:

18/05/2012.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16187

http://www.ctgi.com.br/REP/Pratica_e_Tendencias_em_SOA.pdf

http://www.camilaoliveira.net/Arquivos/Comparando%20CMMi%20x%20MPS.pdf

http://www.slideshare.net/Ridlo/como-fazer-a-integrao-entre-bpm-e-soa

http://plataformadeprocessos.serpro.gov.br/artefatos/Apresentacao%20EGOP.pdf/view

http://plataformadeprocessos.serpro.gov.br/artefatos/Apresentacao%20EGOP.pdf/view

http://www.aneel.gov.br/aplicacoes/intercambio/arquivos/dia%2025/CAIXA%20-%20ALVARO%20AUGUSTO.pps

http://www.aneel.gov.br/aplicacoes/intercambio/arquivos/dia%2025/CAIXA%20-%20ALVARO%20AUGUSTO.pps

http://www.ibqn.com.br/htm_artigos_links/Jairo_Siqueira_Modelo_de_Maturidade_de_Processos.pdf

http://www.ibqn.com.br/htm_artigos_links/Jairo_Siqueira_Modelo_de_Maturidade_de_Processos.pdf

http://www.asrconsultoria.com.br/downloads/pdf/SPIN_BH_CMMI.pdf

faculdade farias brito ciÊncia da...

Documents