faculdade farias brito ciÊncia da...
TRANSCRIPT
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?
Avaliação: Nível 2, pelo menos.
45
QS6: A sua infraestrutura de TI é de fácil operação e manutenção?
Avaliação: Nível 2, pelo menos.
Nível 3 - Definido
QS7: O ambiente de TI tem facilidade para reaproveitar as funcionalidades
existentes na implementação de sistemas?
Avaliação: Nível 3, pelo menos.
QS8: A lógica de integração dos sistemas é separada do código de
implementação?
Avaliação: Nível 3, pelo menos.
QS9: As aplicações são construídas e implantadas segundo padrões usados
na indústria?
Avaliação: Nível 3, pelo menos.
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?
Avaliação: Nível 4, pelo menos.
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):
Nível 0 - Inexistente
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?
Avaliação: Nível Inexistente.
QP3: Não há nenhum esforço para identificação, mapeamento e/ou
documentação dos processos da instituição?
Avaliação: Nível Inexistente.
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?
Avaliação: Definido, pelo menos.
QP11: Na sua concepção, o Negócio da sua empresa é independente de
restrições de tecnologia?
Avaliação: Definido, pelo menos.
Nível 3 - Gerenciado
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?
Avaliação: Gerenciado, pelo menos.
QP14: As mudanças na lógica de negócios são transparentes para os
processos?
Avaliação: Gerenciado, pelo menos.
QP15: As informações são compartilhadas entre os diversos
departamentos?
Avaliação: Gerenciado, pelo menos.
QP16: Há uma documentação ampla dos processos de negócio?
Avaliação: Gerenciado, pelo menos.
QP17: Na sua concepção, as mudanças no negócio de sua empresa, são
refletidas nos sistemas de TI rapidamente?
Avaliação: Gerenciado, pelo menos.
Nível 4 - Otimizado
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
Avaliação: Otimizado.
QP20: Há coleta de estatísticas quanto à eficiência dos processos de
negócio?
Avaliação: Otimizado.
C. Proposta conjunta de questões para a avaliação da maturidade da integração SOA x
BPM (QC):
Nível 0 - Inexistente
QC1: Os sistemas são desenvolvidos sem a visão de orientação a serviços,
dificultando o suporte aos processos?
Avaliação: Nível Inexistente.
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?
Avaliação: Nível Inexistente.
Nível 1 - Inicial
QC3: A integração de sistemas é feita diretamente pelo motor de
processos?
Avaliação: Inicial, no melhor caso.
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?
Avaliação: Inicial, no melhor caso.
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.
Nível 3 - Gerenciado
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?
Avaliação: Gerenciado, pelo menos.
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?
Avaliação: Gerenciado, pelo menos.
QC8: A documentação dos sistemas reflete de forma coerente o modelo de
processos da empresa?
Avaliação: Gerenciado, pelo menos.
QC9: Em sua concepção, os processos mapeados e implantados na sua
empresa o são de forma automatizada?
Avaliação: Gerenciado, pelo menos.
QC10: Se sua empresa faz o uso de softwares BPM, esses softwares já se
tornaram parte natural do ambiente de desenvolvimento de serviços?
Avaliação: Gerenciado, pelo menos.
Nível 4 - Otimizado
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?
Avaliação: Otimizado.
51
QC12: Seu ambiente de TI possui a flexibilidade necessária para responder
rapidamente às mudanças nos processos de negócio?
Avaliação: Otimizado.
QC13: Os processos são monitorados em tempo real e eventuais mudanças
têm suporte rápido por parte do ambiente de TI?
Avaliação: Otimizado.
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?
Avaliação: Otimizado.
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.
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.
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.