BPO usando Savvion Modeler Parte 2

Na parte 1 desta série de artigos, vimos alguns detalhes sobre o que é e o que implica BPO dentro das organizações. Vimos a importância sobre conhecer e melhorar contínuamente os processos vitais de uma organização em pró da melhoría operacional ou estratégica destas. Nesta segunda parte, vamos dedicar o artigo aos detalhes sobre COMO realizar melhoría contínua de processos, conhecendo os detalhes por trás desta prática e aprendendo a como realizar as etapas de análise, modelagem e simulação de processos usando a ferramenta Savvion BPM Modeler. O entendimento desta série do artigo é de suma importância porque aqui veremos os detalhes de "dia a dia" de quem engaja em iniciativas de BPO, detalhes esses que normalmente não podem ser vistos em livros, documentações e palestras. Com isso, iremos neste artigo trabalhar com um processo simples para que os detalhes sejam fielmente compreendidos, tornando a leitura muito mais didática.

Na parte 3 desta série, iremos ver como os conceitos e práticas mostrados na parte 1 e parte 2 podem ser aplicados a um processo de negócio real, que contêm detalhes e complexidades muito parecidos com outros processos que potencialmente você irá enfrentar. Para exercitar o que será mostrado aqui, você deverá possuir a versão 7.5 SP2 do Savvion Modeler. Este software poderá ser baixado dos repositórios da Progress caso você tenha este acesso ou licença de uso. Mãos à obra!

Entendendo o cenário que será usado como exemplo

Para que possamos praticar os conceitos de BPO, temos que primeiro traçar um cenário de negócio. O cenário que iremos trabalhar será de uma aprovação de requisição de material de uma empresa de fornecimento de energia elétrica. A idéia é que possamos mapear a situação onde um empregado da empresa solicita algum material que será usado para seu trabalho, como por exemplo, cartões de visita, um grampeador para sua mesa, ou até mesmo um laptop para trabalho remoto do escritório. Este cenário deverá mapear o momento que a requisição é feita, aprovada ou reprovada e operacionalizada dentro da compahia.

Começando a trabalhar: Iterações de análise de processo

A primeira coisa a se fazer é realizar um ou mais trabalhos de análise sobre estes processos. Estas análises devem ser categorizadas em diferentes frentes que a maioria dos escritórios de BPO devem ter mapeados de ante-mão. Exemplos destes tipos de análises são:

• Análise de Viabilidade: O processo merece ser entendido e/ou melhorado?
• Análise de Riscos: O processo representa quantos % do negócio da organização?
• Análise de Custos: Quanto custa, em termos de esforço e financeiro, melhorar este processo?
• Análise de Impacto: Mudar ou melhorar este processo apresenta impactos em pessoas e TI?

Estas análise normalmente são feitas com reuniões curtas entre os envolvidos e interessados no processo cujo formato são sessões de argumentações das categorias citadas. O insumo a ser criado é uma lista de argumentações que devem posteriormente serem respondidas e endereçacas as pessoas correspondentes. No caso particular da análise de custos, é interessante perguntar: "Quanto custa parar os envolvidos nos processos para melhorar isso?", "Se tiver que alterar sistemas da TI, quanto que isso me custa de tempo e dinheiro?", "É necessário adquirir novos pacotes de software ou contratar pessoas para isso?", "Precisamos contratar uma consultoria do assunto do processo?"

Assim que estas análises forem feitas, um relatório de embasamento deverá ser criado e enviado ao patrocinador do projeto. Ele deverá conseguir ver claramente quais os benefícios e impactos que um potencial investimento naquele processo irá ter. Deve ser possível também visualizar que tipo de melhoría será conseguida com aquilo. Isso é muito importante para efeitos de mobilização: Se um processo melhorado não apresenta benefícios, para que melhorá-lo? Se um sistema mapeia corretamente um fluxo da empresa (mesmo que não da melhor forma) por que atualizá-lo?

Nos primeiros esforços de BPO numa empresa, é comum constatar que nenhum benefício direto será alcançado. Isso acontece porque normalmente os processos ainda não são corretamente compreendidos e com isso, a percepção sobre que benefícios se obtêm quando se melhora não são claros. Mas como dito anteriormente, investir algum tempo e dinheiro no entendimento dos processos internos além de ser a fundação para um bom BPO, é um investimento que trás grandes benefícios, um deles é a clara percepção que o negócio possa estar mal conduzido. Quando você para para analisar como você faz as coisas, você percebe o quanto pode estar certo ou o quanto pode estar errado. Um ponto positivo de se fazer BPO pela primeira vez é que você nem precisa de tanto esforço de análise para ver o que está errado: Revisando o processo pela primeira vez você já têm a clara percepção de direção. Quando você tenta melhorar um processo que você já compreende e entende, ai muitas das vezes é necessário investir algum tempo analisando diferentes cenários e possibilidades, muitas das vezes, até por pessoas de fora, ou seja, pessoas que não tenham os mesmos interesses que os seus e que tenha expertise no tipo do processo.

O que é na prática melhoría de processos?

Alterar um processo e perceber uma melhoría? Isso pode ser um passo bem desafiador se você nunca fez isso ou se você não têm conhecimentos sobre a organização. É comum observar pessoas argumentando sobre o que é na prática melhoría de processos, pois muitas pessoas efetivamente repetem a frase mas não entendem corretamente seu significado e influências. Conheço um bom punhado de "Analistas de BPM" que na prática não ajudam em absolutamente nada. Melhoría de processos têm a ver com duas palavrinhas simples: Eficácia e Eficiência. Você é eficaz quando você desprende um conjunto de recursos disponíveis ou indisponíveis para um objetivo correto. Se você desprende recursos para objetivos incertos ou inviáveis, você não é eficaz. Eficiência têm a ver com alocar o menor número possível de recursos e conseguir o mesmo bom resultado (ou resultado melhor) que você teria com um conjunto menor de recursos. Costumo falar que eficácia têm a ver com visão e eficiência têm a ver com experiência.

Se você faz parte ou analisa um processo qualquer e consegue perceber que um dado processo é ou não é correto ou viável, você está tendo uma boa visão e portanto está sendo eficaz. O processo de escolha de uma lista de processos que devem ser melhorados têm a ver com visão. Em termos práticos, não somente escolher o processo correto, mas escolher o objetivo correto também é sinal de visão e de eficácia. Muitas das vezes, vemos empresas que possuem métodos de trabalho muito bons e uma boa base e equipe técnica qualificada, ingredientes estes que por si só apresentam sinais de um possível sucesso. Mas muitas destas empresas possuem objetivos pobres ou errôneos de forma que mesmo que conduzam os processos corretamente, eles trilham caminhos que não darão bons resultados. É o caso de grandes empresas que vemos no dia a dia que num dado momento são candidatas a falência em seu negócio. Os recursos eram bons, mas os objetivos não estavam bem traçados ou corretos. Empresas que pedem para serem compradas ou entram em processo de falência são bons casos destes. Faltou eficácia. Logo percebemos que podemos categorizar as empresas do mundo todo em 2 segmentos: As empresas que vão bem e as empresas que vão mal. As empresas que vão mal são aquelas que não possuem eficácia a fatalmente serão fadadas ao fracasso ou desligamento, e as empresas que vão bem são aquelas que possuem eficácia, e ainda estão no mercado disputando o espaço com outras no mesmo segmento. Estas empresas que vão bem, são aquelas que devem procurar ter mais eficiência.

Se você possuem um negócio que está indo pro caminho certo, mas está com dificuldades de alavancar seu negócio perante o poder dos concorrentes, está na hora de revisar sua eficiência. Como dito antes, eficiência têm a ver com trazer melhores resultados com menores ou os mesmos recursos ou diferentes estratégias. Bons exemplos de melhores resultados com menores recursos é quando você é um fabricante de algum material e consegue aumentar sua fabricação diminuindo os recursos necessários ou alterando sua abordagem de produzir. Para conseguir isso, você precisa de uma estratégia. Vamos a um exemplo da vida real ...

Imagine que você é do ramo de Data Centers. Você possui sua cartela de clientes fixos, mais para aumentar sua cartela implica em aumentar seu custo operacional de telefonia ou de links dedicados. Seu concorrente faz a mesma coisa que você mas possuem a "vantagem" de também ser uma operadora de telefonia móvel e fixa que inclusive presta serviços pra você. Para que você faça seu negócio acontecer, você têm um custo de telefonia, para que seu concorrente faça o negócio dele acontecer, ele não possui um custo de telefonia e por isso, pode escalar mais. Posicionar portanto uma empresa sobre se ela é ou não mais competitiva é a questão de perguntar: Os recursos operacionais dela são mantidos por ela mesma (auto-suficiência) ou são mantidos por terceiros? A empresa do concorrente portanto é muito mais eficiente que a sua, porque ela detêm os recursos operacionais necessários para o negócio.

Produzir coisas têm a ver com aquisição de matéria prima ou insumos. Se você produz alguma coisa e quer ser mais competitivo significa que você deve reavaliar com adquire sua matéria prima ou como você pode reduzir o custo desta aquisição. Uma outra forma de garantir que sua produção possa ser mais eficiente é trocando a matéria prima ou os recursos utilizados ou utilizando o conceito de recursos compartilhados. Compartilhar recursos sempre é uma abordagem que traz bons resultados de eficiência, não importa o contexto. Para os técnicos de plantão que estão lendo este artigo, pense por exemplo nos EJB's do tipo session: Quem escala mais, os SLSB's ou os SFSB's? Sem dúvida será aquele que tiver menor número de recursos alocados e maior número de recursos compartilhados.

Acredito que depois desta explanação sobre eficácia e eficiência, melhoría de processos deva estar mais clara agora. Melhorar um processo implica primeiro e acima de tudo fazer com que o processo seja eficaz, e quando este for eficaz que ele seja mais eficiente. A busca constante por melhoría na prática é a busca constante pela eficiência, mas, somente se o processo estiver buscando os objetivos corretos. De nada adianta você construir um processo que seja demasiadamente eficiente se ele não refletir os objetivos e resultados corretos. E, antecipando um pouco do que veremos a seguir, conseguir ser eficiente é, ao contrário do que se pensa, muito mais simples do que conseguir ser eficaz. Como dito antes, eficácia têm a ver com visão, e eficiência têm a ver com experiência. Se você já passou por uma situação, você pode dar palpites sobre como melhorar algo. A experiência é algo que é concreto, que podemos vivenciar ao longo dos anos. Pode demorar, mas uma hora você adquire a experiência em algo para torná-lo mais eficiente. Ter visão é mais complicado, não é algo que você vivencia ou experimenta. É um dom!

Você deve ter a sorte de ser uma pessoa de visão para saber que tipos de objetivos perseguir. Fazendo um breve paralelo com a vida real, existem muitas pessoas estáveis e experientes que quando argumentadas sobre o que ela quer da vida ... não sabem responder. Isso porque lhes falta visão. E normalmente, as pessoas que não têm visão sobre a própria vida jamais irão ter visão sobre o seu negócio. Justamente por isso, algumas grandes empresas, consolidadas e até líderes no seu mercado, contratam o que chamamos de CEO: pessoas que vem para as empresas para tentar trazer a visão que falta para a equipe de diretoria e grupos acionistas. Não é surpresa, dito isso, que muitas grandes empresas possuem CEOs que na verdade não são os donos destas empresas, e, contextualizando no nosso país, não é surpresa que um presidente precise de tantos acessores para "ajudar" a conduzir o país. Os acessores são as pessoas de visão e portanto que trará a eficácia ;-)

Brincando com o Savvion BPM Modeler

Agora vamos dar uma olhada na ferramenta de modelagem da Progress conhecida como Savvion BPM Modeler. Esta é sem dúvida uma das melhores ferramentas (senão a melhor) de modelagem de processos de negócio usando a notação BPMN. De fato, o Savvion BPM Modeler é bem mais do que isso, é uma suíte completa de BPO onde você pode praticar análise e simulação de processos e promover efetivamente melhoría de processos. Além disso, a ferramenta de modelagem é parte integrante de uma suíte maior de BPMS conhecida como Savvion Business Manager. Com esta suíte, você pode além de modelar e simular processos, transformar estes processos em aplicações corporativas completas com o mínimo de esforço possível. Mas vamos deixar a suíte BPMS da Progress para um próximo post, neste, iremos focar efetivamente em melhoría de processos usando técnicas de BPO. Para começar, inicie a ferramenta Savvion BPM Modeler para entendermos um pouco de como ela funciona.

Continua ...

BPO usando Savvion Modeler Parte 1

Toda organização possui (ou deveria possuir) um conjunto de objetivos estratégicos e diretrizes onde todos na organização atuam. Estes objetivos e diretrizes tomam diferentes formas e diferentes níveis: visão, missão, planos e direção para os negócios, etc. Pessoas nestas organizações atuam colaborativamente e estão sujeitos as políticas e regulamentações, práticas e padrões relevantes e procedimentos estabelecidos para atingir estes objetivos. A entidade fundamental que reune todos estes elementos são os processos de negócio. Uma organização é em última análise, uma coleção de processos que determinam como a mesma opera, como ela gera seus rendimentos, como ela suporta seus clientes, etc. Como uma empresa se diferencia uma das outras têm a ver unicamente com seus processos de negócio. Neste caso, os processos de negócio de uma organização são ativos vitais e críticos que devem ser tratados como o bem mais valioso que existe. Sendo assim, eles devem ser gerenciados e mantidos apropriadamente. Para isso, os processos precisam ser reconhecidos, documentados, compreendidos e analisados antes que eles sejam automatizados e gerenciados. Este é o processo mais vital que fará com que os processos de negócio tenham a devida atenção que merecem. A automação destes somente fará com que a "roda possa girar" e fazer o dinheiro fluir, mas isso só acontecerá se os processos estiverem concisos.

Para estabelecer este ciclo, se faz necessário o uso de ferramentas visuais de simples utilização que possa gerar modelos e uma linguagem de notação padrão e que este possa ser controlado num sistema de repositórios centralizado de acesso controlado. Desta forma, as pessoas envolvidas nos processos podem criar modelos, atualizar existentes, promover discussões sobre os modelos já criados e garantir que os processos estejam sempre íntegros e atualizados. Mais ainda, estas ferramentas devem prover recursos de simulações destes processos, de forma que as pessoas possam "observar" as diferentes combinações criadas, e os diferentes caminhos e alocações de recursos que um dado processo possa gerar.

Uma vez que você tenha estabelecido este tipo de ferramenta em sua organização, em conjunto com os ciclos citados anteriormente, você poderá então oficialmente instituir um grupo responsável por BPO, sigla de "Business Process Optimization". Considerar um grupo de BPO dentro de qualquer organização de médio ou grande porte é sem dúvida uma forma de garantir sucesso de mercado e diferencial quanto aos concorrentes. Se você fizer isso e tiver uma pequena parcela de concorrentes que ainda não o façam (ou façam mas com pouca ou nenhuma seriedade) então você poderá colher os frutos de ser um líder no seu nicho de mercado. Em muitos casos, BPM é visto como algo extremamente dispendioso e dificil de justificar, principalmente quando se fala em alterações nas aplicações para acomodar a automação dos processos. Mas bem mais importante do que a fase de automação de processos é a fase de análise e melhoría destes. Instituir um grupo responsável por BPO numa empresa de médio ou grande porte é algo que de longe pode ser caro e pode (ou deve) ser tratado muito mais como um investimento do que como uma despesa.

Com níveis adequados de maturidade nos processos, é interessante fechar o ciclo do BPM e promover a automação dos processos junto a TI. A justificativa da mudança será simples e muito bem embasada. Boas estratégias de adoção de BPM devem incluir fases preliminares de observação e entendimento dos processos, seguido de propostas de melhoría e de melhorías em si, acordadas entre os interessados, aprovada pelos níveis de diretoria e fundamentada com dados estatísticos sobre redução de custos e recursos. Depois que estes primeiros passos forem dados, BPO poderá dar espaço a ciclos de automação e gerenciamento, fechando o que chamamos de ciclos de BPM. Dai o sentido da letra "M" do BPM.

A idéia deste artigo é mostrar, em termos conceituais e práticos, como operacionalizar análise, modelagem e melhoría de processos através de simulações de cenários. Nesta primeira parte iremos nos ater os quesitos conceituais sobre processos de negócio, e na segunda parte iremos ver como modelar, analisar e simular um processo de negócio na prática, usando para isso a ferramenta Savvion BPM Modeler da Progress.

A Necessidade de Análise e Modelagem de Processos de Negócio

Processos são os insumos básicos que governam qualquer tipo de negócio. Alguns destes processos estão embutidos em aplicações comerciais (ERP's, CRM's) que capturam algumas funcionalidades, atividades e segmentos de um processo. Mas muitos destes processos que governam o negócio envolvem várias aplicações, vários sistemas e várias pessoas, sejam elas funcionários, clientes, parceiros ou fornecedores. Estes processos também não são formalmente definidos e documentados. Cada departamento ou organização pode potencialmente definir seus próprios processos (ou segmentos destes processos) baseados em vários procedimentos, formulários, guidelines e outros documentos.

As coisas podem ficar muito piores quando você têm processos que são distribuídos em diferentes organizações, como nos casos onde o processo se inicia num fornecedor de serviços, passa por um fornecedor de produtos e termina nas fronteiras dos clientes. O conhecimento sobre estes processos distribuídos estão espalhados entre vários gerentes de negócio das organizações envolvidas. Não existe um único lugar ou pessoa onde se possa aprender sobre estes processos. Se algumas destas pessoas se desligar da sua organização, o processo terá uma lacuna de conhecimento. Mais ainda, nenhum processo de negócio é uma ilha isolada, todos os processos de negócio estão embutidos ou fazem parte de outros processos criando portanto camadas de processos dentro das organizações. Processos de camadas mais baixas normalmente são ditos processos operacionais quando que processos de camadas mais altas são ditos processos estratégicos.

Dado este grande número de problemas relacionados a processos, se faz necessário uma abordagem pragmática que mantenha os processos livre destes tipos de problemas. Primeiro, deve-se manter os processos em repositórios controlados nas organizações, ou, se trata-se de processos inter-organizacionais, em repositórios mantidos por pessoas (empresas) comuns para as organizações envolvidas. Segundo, os modelos não podem ser estáticos. A abordagem deve se basear na construção inicial dos processos e na evolução constante destes processos. Para isso, as ferramentas envolvidas deverão possibilitar a constante mudança nos artefatos dos processos de forma distribuída, ou seja, possibilitar que diferentes pessoas possam alterar os artefatos simultâneamente. Além disso, é necessário também que as ferramentas possam prover links entre os processos, de forma que se um processo é um processo interno de outro (um sub-processo), o processo maior possa, quando simulado ou executado, executar o processo interno e esperar que ele termine até que ele possa dar prosseguimento no processo maior. É necessário também que a ferramenta possa ter como atividades, diferentes tipos de "caixinhas" que possam variar de atividades humanas a atividades sistêmicas.

Deve ser possível por exemplo, que uma atividade seja operacionalizada por uma ação realizada por um dos sistemas da organização. Para isso, estas operações devem ser encapsuladas na forma de serviços e se tornarem disponíveis na forma de uma paleta de atividades: Todos os serviços da organização deverão estar registrados em algum sistema automatizado de registros de forma que possam aparecer na ferramenta de desenho de processos como uma paleta de possibilidades. Com isso, os donos dos processos podem pensar nas etapas dos processos em "caixinhas" que possuem um significado ou representação, sem se preocupar em como aquela caixinha quando executada, irá fazer seu trabalho. Há quem diga que um processo é uma coleção de caixinhas ligadas umas nas outras que formam um caminho a ser percorrido. Assim devem ser os processos construídos, simples ao ponto de poderem ser definidos desta forma.

Benefícios do Uso de Análise e Modelagem de Processos

Como mencionado anteriormente, organizações podem se beneficiar substancialmente realizando investimentos de análise, modelagem e melhoría nos seus processos de negócio. Estudos têm mostrado que mesmo que as organizações não tenham uma intenção formal de ter ciclos de BPM e de automatizar seus processos, apenas modelando e simulando os processos podem ajudar a melhorá-los consideravelmente. Mesmo que a melhoría não ocorra num primeiro momento, somente o esforço de modelar, documentar e entender os processos já é um ganho considerável. Muitas empresas não possuem entendimento dos seus processos e com isso, elas não podem evoluir e serem mais competitivas. Se você não entende corretamente o que você faz, como você pode saber se você está fazendo certo ou errado?

Aplicando corretamente BPO numa organização, possibilita que você usufrua dos seguintes benefícios:

• Analistas do negócio, gerentes funcionais e diretores se tornam responsáveis pelos processos. Com essa autonomia, a decisão se torna mais simples e mais coesa;
  
• Processos internos e inter-organizacionais serão melhor controlados e não mais irão existir somente quando as pessoas existirem: Na substituição da pessoa (recurso) o processo continua existindo e funcionando;
  
• Previsão de funcionamento sem que a TI tenha que mostrar como se faz. Processos poderão ser analisados mesmo que não sejam automatizados pela TI. Isso possibilita maior agilidade na tomada de decisão, uma vez que toda a ciência, autonomia e responsabilidade está agora na área de negócios. Interações com a TI serão reduzidas a pedidos de automação concretos;
• Suporte a iniciativas de compliance tais como Six Sigma, ISO 9000, Sarbanes Oxley, etc;
• Investimentos melhores justificados. Ao requisitar para a TI a automação de um processo que foi comprovadamente dito como "de sucesso", os fundos para isso serão providenciados rapidamente, isto é, se houver fundo disponível e aprovado para o item "Melhoría de Processos";

Boas Melhorías :-)

Monitoramento de SLA's com JBoss ESB

Suponha que você possui um ou mais serviços implementados no seu barramento e que deverão ser utilizados pelos seus clientes e parceiros. Para que você possa oferecer um serviço com um mínimo de segurança, você deve criar contratos de SLA (Service Level Agreement) com estes clientes e parceiros. Estes contratos normalmente regem condutas mínimas de utilização como percentual de disponibilidade do serviço, tempo de resposta mínimo, tempo de indisponibilidade do serviço e o tempo de recuperação deste caso haja falhas na operação. Isso se dá porque ou o cliente ou o parceiro possui um contrato de utilização do serviço (ou do negócio que está sendo prestado) com você, e estas regras de utilização são protegidas por multas que costumam ser bem desafiadoras do ponto de vista contratual. Para que você esteja preparado para acomodar este tipo de situação, você deve ter ferramentas e tecnologias que possam lhe ajudar a mensurar estes itens quanto a viabilidade, e também controlar e monitorar estes eventos de indisponibilidade ou utilização de forma reativa ou preferencialmente, de forma pró-ativa.

O objetivo deste artigo é mostrar como, através do conjunto de tecnologias e plataformas da JBoss, podemos oferecer este tipo "garantia" para os clientes e parceiros, caso você esteja engajado neste tipo de negócio, que, em algumas verticais de negócio como no ramo financeiro e principalmente o ramo das telecomunicações, se torna cada vez mais comum. Dezenas de operadoras brasileiras já possuem pelo menos um destes contratos com outras empresas fornecedores de conteúdo digital e afins. Para a vertical de governo, não é dificil imaginar este tipo de situação: Porventura, uma empresa que possui um serviço de nota fiscal eletrônica possa querer fazer outsourcing não da aplicação, mas do serviço de processamento de notas fiscais para órgãos do governo e assim, acarretar em um ou mais contratos de SLA.

Para implementar este tipo de cenário em suas instalações, você precisará essencialmente do JBoss ESB versão 4.7 ou superior e a plataforma de gerenciamento e monitoramento da JBoss conhecida como JOPR, versão 2.3.1 ou superior. Se você deseja possuir estas tecnologias a plataformas com o suporte e respaldo técnico da Red Hat [novamente a questão de SLA ;-)] você deve adquirir as subscrições do SOA Platform 5.0 que contêm o ESB e do JBoss Operations Network versão 2.3.1.

Entendendo o cenário, os SLA's e a arquitetura da solução de demonstração

Tenho uma solução baseada no JBoss ESB que processa pedidos de contratos de seguros. Suscintamente falando, a solução recebe estes pedidos de diferentes canais de transporte e de diferentes formatos de dados que vão desde documentos XML até mensagens baseadas em CSV lidas de um banco de dados relacional. A idéia é que estes pedidos sejam convertidos em um formato comum para o ESB, ou seja, o padrão Canonical Data Model e que uma vez que a mensagem esteja neste formato padrão, ela seja enriquecida com um punhado de regras de negócios que são disparadas a partir do software JBoss BRMS (Business Rules Management System). Estas regras vão destes regras sobre cálculo de riscos da aplicação da proposta, quanto a regras de aprovação da mesma e descontos promocianais criados pela equipe de marketing da empresa. Uma vez que a proposta esteja corretamente processada e seja aprovada, ela é transformada numa cotação e é enviada a diferentes canais de transporte para fins de notificação e finalização da transação do processo de negócio, canais estes que vão desde filas JMS até tabelas de bancos de dados. A figura abaixo sintetiza este cenário do ponto de vista do barramento de serviços:

Este processo de negócio supostamente foi contratado por um cliente da seguradora que deseja que alguns SLA's sejam definidos e resguardados contratualmente entre a seguradora e o tal cliente. Os SLA's definidos para este processo de negócio foram:

SLA_1: Através do canal SOAP, o número de mensagens não processadas não deverá ser superior à 5.
SLA_2: Através do canal FILE, o tempo de processamento não deverá extrapolar 5 segundos.
SLA_3: Independente do canal de transporte (SMS, SOAP, SMTP ou FILE), a cada 10 pedidos de seguro processados, um gerente de vendas do cliente deverá ser notificado via e-mail.

Repare que para cada SLA demos um apelido para que possamos referenciá-los futuramente no artigo. Grave estes apelidos para futura conferência do seu significado. A idéia é que possamos usufruir da excelente integração entre o JBoss ESB e o JBoss Operations Network para acomodar estes SLA's. As estratégias de configuração aqui apresentadas poderão ser personalizadas para outros cenários de negócio e não se restringe somente a este cenário apresentado, uma vez que as métricas, alertas e eventos do JBoss ESB são tratados pelo JBoss ON de forma genérica.

Atendendo o "SLA_1" usando o JBoss Operations Network

Para atender o SLA_1, temos que primeiramente configurar o JBoss ON para que ele gerencie automaticamente o uso médio da métrica "Overall Bytes Failed" que determina a quantidade de bytes que falharam na hora do processamento de uma mensagem. Isso é importante porque além da notificação sobre quanto o SLA é comprometido, devemos poder proativamente observar o andamento deste tipo de cenário nas plataformas de execução.

Para isso, acesse o serviço do JBoss ESB que será monitorado, e clique na métrica "Overall Bytes Failed" existente na guia "monitor" do JBoss ON.

Ao clicar na métrica, você será encaminhado para a visualização do gráfico de utilização da métrica. utilizando a barra de rolagem do seu navegador, desça até o final da página onde você verá uma seção chamada "Metric Baseline & Expected Range". Nesta seção, você pode verificar e calcular qual é a taxa de utilização média da métrica. Clique no link "Change Value" para solicitar a computação da métrica e na sequência, clique em "Save Value".

Agora que temos nosso baseline definido e marcado para 0 bytes, podemos criar um alerta que monitore as mensagens com erros de processamento. Para isso, irei criar um alerta para o serviço cujo endpoint é baseado em SOAP. Basta clicar na guia "Alert" e definir um novo alerta usando as configurações da interface. Crie um alerta baseado na métrica "Overall Bytes Failed" e diga que você quer "tolerar" apenas 5% do baseline, ou seja, a primeira mensagem com falha já irá alertar sobre mal funcionamento do processo de negócio e do SLA_1.

Atendendo o "SLA_2" usando o JBoss Operations Network

O SLA_2 é um pouco mais exigente e por isso, merece uma configuração um tanto quanto diferente. Como trata-se de um SLA relacionado a performance, temos que configurar além do JBoss ON, o nosso barramento de serviços. O JBoss ESB a partir da versão 4.7 possui um recurso super interessante relacionado a monitoramento de serviços. Em suma, você pode definir tanto em nível de serviço quanto em níve de ação do pipeline dois tipos de verificações: Tempo de processamento e tamanho da mensagem.

Para atender o SLA_2, eu defini no meu módulo de configuração do ESB (jboss-esb.xml) a propriedade "AlertTimeThreshold" definindo seu valor para 5 segundos. Com isso, toda vez que aquele serviço receber uma mensagem não importando o canal de entrada (SOAP, JMS, File, FTP) ele irá cronometrar o tempo de processamento da mensagem, ou seja, o tempo entre a data e hora de entrada da mensagem no barramento e o final da execução de todo o pipeline definido para o serviço, isto é, sua cadeia de ações. Uma estratégia também muito interessante é que isso pode ser feito em nível de ação. Você pode por exemplo, cronometrar o tempo que uma transformação de SOAP para JAVA leva, o que impacta diretamente no tempo de processamento total do serviço.

As configurações de threshold funcionam da seguinte forma: Quando o JBoss ESB verifica que o "SLA" definido foi quebrado, ele cria uma entrada no MBean "MessageAlerts" que está disponivel dentro do JBoss ESB. Além disso, ele cria uma entrada no log de eventos do servidor usando a configuração padrão do Log4J. Com isso, o JBoss ON através do seu plugin de integração, pode interceptar estes eventos e gerar eventos específicos do JBoss ON, possibilitando assim, a criação e geração de alertas de SLA. Para que o JBoss ON possa interceptar os eventos gerados pelo JBoss ESB, você deve habilitar a leitura de eventos no JBoss ON. Para isso, clique no servidor e acesse a guia "Connection" disponivel no link "Inventory":

Uma vez que você tenha definido a configuração dos eventos, você pode criar um alerta baseado no evento usando a mesma estratégia usada anteriormente: Clicar na guia "Alert" e definir um novo alerta. Repare que para a definição do alerta é necessário definir que o filtro de expressão deve ser igual ou semelhante a "MessageAlert", nome do MBean que será escrito no log do servidor. A cada vez que uma nova entrada no log for escrita, o agente do JBoss ON irá notificar sobre um evento do JBoss ESB, que será avaliado na expressão do alerta. Caso esta expressão seja avaliada como verdadeira, então um evento do JBoss ON será gerado e o alerta será executado. No caso especial do SLA_2, eu configurei meu alerta para notificar um administrador de sistema que poderá realizar alguns diagnosticos no JBoss ESB e na sua estrutura geral de hardware e software, tudo isso, usando somente o JBoss ON.

Atendendo o "SLA_3" usando o JBoss Operations Network

Para atender o SLA_3 é muito simples: Basta criar um alerta no JBoss ON que depois de executar deverá zerar o contador da métrica "Message Count". O gerente de vendas deverá estar configurado no JBoss ON como um usuário de credenciais limitadas e que somente receberá notificações:

OK, tecnicamente estou convencido, mas e qual o diferencial?

Muitos leitores do blog e amigos em geral porventura me questionam sobre qual a vantagem de se estabelecer uma arquitetura orientada a serviços baseadas em tecnologias JBoss. Bem, costumo começar a responder falando sobre a questão de custo: Se você não optar por contratar as subscrições da Red Hat para ter facilidades como garantia de continuidade da tecnologia e o suporte técnico, o custo é literalmente zero, ou melhor, alguns centavos referentes ao custo do download do software a partir dos repositórios do JBoss.ORG.

Mesmo que você opte por contratar a Red Hat para ter suporte e todos os beneficios da subscrição, o custo ainda sim é super mais barato que as demais soluções. Acima de tudo, o custo indireto baseado em subscrições Red Hat é infinitamente mais vantajoso do que as demais soluções baseadas em software licençiado, uma vez que você não têm CAPEX, apenas OPEX, ou seja, você paga e recupera o valor pago a medida que usa o suporte ou atualiza o produto a partir da Red Hat.

Outro ponto importante é a liberdade de escolha: Toda tecnologia JBoss é baseada em padrões abertos (JCP, OASIS, W3C, WS-I) e totalmente open-source baseado em LGPL, dando você a garantia de que não ocorrerá vendor Lock-In, nem mesmo impossibilidade de troca do fornecedor do software. Se você quiser mudar de tecnologia e arquitetura por qualquer motivo, sinta-se a vontade para fazê-lo que seu investimento não será perdido.

Dito isso, outras soluções do mercado como Oracle Service Bus e webMethods ESB fazem tecnicamente a mesma coisa que as soluções JBoss, mas, se você deseja menor custo e garantia de portabilidade do investimento, pergunte-se: Por quê não JBoss?

Bons SLA's!