FACULDADEFARIASBRITO 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 ARQUITETURAORIENTADAASERVIÇ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ÃODEPROCESSOSDENEGÓ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ÇÕESDESOAPARABPM ... 27
2.2 CONTRIBUIÇÕESDEBPMPARASOA ... 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ÇÃODECENÁ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ÍTICASSOBREOSCENÁRIOSDEMATURIDADE ... 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 ARQUITETURAORIENTADAASERVIÇ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ÃODEPROCESSOSDENEGÓ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ÇÕESDESOAPARABPM
É 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ÇÕESDEBPMPARASOA
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ÇÃODECENÁ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
