Comportamento empresarial baseado em eventos

As empresas existem para fornecer produtos ou serviços, ou ambos, aos clientes. Elas fazem isso ao realizar uma ampla variedade de operações empresariais manuais ou automatizadas (processos) que fornecem diretamente o produto ou serviço, ou suportam a entrega ou desempenho do mesmo. O acionador desses processos é um evento empresarial, no qual algum conjunto de condições foi preenchido, indicando que um processo empresarial específico deve ser realizado (consulte Resources para obter links para mais informações). Por exemplo, quando um cliente de celular quer comprar um telefone novo, ocorre um evento de compra pelo cliente, indicando que a empresa deve realizar uma série de operações para atender essa solicitação (como atualizar o inventário, providenciar o faturamento e prestar os serviços desejados), como a a Figura 1 . (Veja uma versão ampliada da Figura 1.)

Observe que esses eventos acionadores podem iniciar uma cascata de outros eventos empresariais para concluir o processo empresarial global. No evento precedente de compra pelo cliente, a prestação dos serviços pode exigir vários sistemas internos para receber atualizações (como um novo evento de serviço), ou até mesmo parceiros externos que devem responder a eventos empresariais acionadores com seus próprios comportamentos. Essa coreografia empresarial complexa deve ser realizada com sucesso centenas ou até milhares de vezes por dia para que a empresa seja bem-sucedida. Claramente, a capacidade de entender quais eventos empresariais ocorreram (e quando ocorreram) é importante para rastrear e administrar essas operações empresariais complexas.

Voltar para parte superior

Respondendo à ação do cliente

Além do foco nas operações, as empresas estão valorizando cada vez mais a ideia das relações pessoais com os clientes (consulte Resources para obter links para mais informações). Em vez de usar categorias amplas de comportamentos de clientes (ou seja, demografia) para indicar qual grupo de clientes prefere um produto ou serviço, as organizações estão analisando o comportamento individual do cliente para fazer um marketing dirigido. Por exemplo, muitas redes de supermercados têm programas de fidelização de clientes que oferecem descontos imediatos em troca da conquista do comportamento de compra do cliente. Posteriormente, essas informações são usadas para fornecer cupons dirigidos com base nos produtos comprados com frequência. A capacidade de rastrear ações iniciadas por clientes individuais (como uma série de eventos empresariais subsequentes) fornece um mecanismo poderoso para aumentar o valor do cliente por meio de oportunidades dirigidas de venda ascendente e venda cruzada sempre que um cliente interage com a empresa.

Além disso, a capacidade de acompanhar esses comportamentos ao longo do tempo fornece os dados necessários para ações preditivas de retenção de clientes. A maioria dos esforços de retenção tem o objetivo de reduzir o cancelamento de clientes, ou a probabilidade de que os clientes passem para um concorrente, mas é tipicamente reativa — ou seja, a ação de retenção só é realizada depois que o cliente indica insatisfação com a empresa. Entretanto, com frequência, há vários sinais críticos de advertência (comportamentos do cliente), que indicam que o cliente está insatisfeito, como telefonemas frequentes ao atendimento ao cliente ou a devolução de determinados produtos. Se uma empresa consegue capturar e acompanhar esses eventos no nível individual, é possível realizar etapas proativas para melhorar a experiência do cliente e a relação com a empresa antes que o dano seja irrecuperável.

Voltar para parte superior

Inteligência empresarial baseada em eventos

Há um grande valor no entendimento dos vários eventos empresariais que ocorrem durante operações empresariais normais (ou anormais). A captura e análise dos padrões de eventos empresariais (também conhecidas como processamento de eventos complexos) melhoram ou possibilitam várias decisões empresariais, inclusive a detecção de atividades fraudulentas, auditoria de motivadores financeiros e detecção de invasão na segurança. A criação de logs de aplicativos é um meio bem estabelecido de obter insight sobre o funcionamento interno de processos empresariais internos, e vem sendo usada há muitos anos para localizar e eliminar falhas no sistema. Nos últimos anos, os arquivos de log vêm sendo aplicados a outras áreas da inteligência empresarial para obter informações sobre os comportamentos dos clientes.

Infelizmente, a criação de logs baseada em arquivos é insuficiente para esse fim, por várias razões. Primeiro, as entradas de log se baseiam em eventos únicos no nível do sistema e, normalmente, não estão ligadas aos motivadores empresariais de alto nível. Em segundo lugar, os desenvolvedores de aplicativos são os principais beneficiários dos esforços de criação de logs. Assim sendo, as entradas de log variam em termos de sintaxe e conteúdo e frequentemente são difíceis de interpretar, como estes dois exemplos mostram:

Exemplo 1 (do aplicativo Java):
08:50:49,664 FATAL LogClass:33 – Log Attempt Failed (btrack@metatelecommunications)

Exemplo 2 (do servidor da Web):
April 3, 2010 (23:04:05) 45:T50 Log attempt failure – 772, 81gAt

As informações de log são necessárias em diversos níveis operacionais (negócios, serviço, aplicativo, banco de dados, infraestrutura, rede) e para fins diferentes (inteligência empresarial, suporte operacional, segurança, auditoria). Como as entradas de log são geradas somente dentro de um ambiente de sistema específico (com um banco de dados, dispositivo de rede ou aplicativo), as transações empresariais de longa duração — as mais interessantes para a empresa — são difíceis de rastrear por meio de diversos sistemas. Normalmente, não há um mecanismo comum para identificar quais entradas de log estão ligadas entre si dentro de uma transação empresarial.

Há vários problemas em muitos mecanismos atuais de criação de logs no nível do aplicativo:

• Aplicativos, armazenamentos de dados, servidores e elementos de rede tratam a criação de logs de formas diferentes, usando sintaxes, mecanismos e níveis de rastreamento diferentes (por exemplo, erro fatal, informação, aviso).
• É difícil, para não dizer impossível, ligar vários níveis de geração de eventos (aplicativo empresarial, armazenamento de dados ou rede) para determinar a causalidade entre os eventos (em outras palavras, o evento empresarial 1 causou os eventos de aplicativo A, B, C e D).
• As informações de log, que são mais impulsionadas pelas necessidades operacionais ou de desenvolvimento do que pelas necessidades empresariais, podem não incluir informações críticas para a interpretação adequada.
• Não existe o conceito de taxonomia de eventos (ou seja, um conjunto bem definido de termos de descrição de eventos) para organizar eventos de sistema de níveis alto e baixo.
• Um processamento adicional significativo é necessário para converter logs baseados em arquivo para um armazenamento de dados inteligível, no qual é possível fazer buscas.
• As interações entre diversos sistemas de cooperação, como as necessárias para transações complexas, como a prestação de um serviço, não são fáceis de rastrear nem de conectar devido à característica assíncrona dessas operações.
• Não há fornecimento de reconhecimento de padrões de eventos complexos, principalmente para a reação em tempo real a situações importantes, como eventos iniciados por clientes, tentativas de fraude ou invasões na segurança.

Voltar para parte superior

O framework de gerenciamento de eventos corporativos

O propósito do enterprise event management framework (EEMF) é fornecer um mecanismo leve para aplicativos novos e legados dentro de uma organização, para gerar eventos e poder responder a eventos que outros sistemas geram. Em muitos aspectos, o EEMF é semelhante a uma arquitetura orientada a serviços, mas, em vez de definir uma interface em um conjunto de serviços de sistema, o EEMF permite que os aplicativos e serviços já existentes registrem eventos em um local comumente acessível. Além disso, outros sistemas que se registram para a notificação de eventos (como um mecanismo de regras de processador de eventos ou a analítica de eventos empresariais quase em tempo real) podem ter a garantia da notificação de todos os eventos de interesse.

O EEMF tem cinco componentes críticos:

• A taxonomia de eventos é um vocabulário controlado de eventos empresariais que identifica sem ambiguidade cada evento e as relações com outros eventos abaixo e acima deles em uma hierarquia bem definida.
• Identificação de eventos é a identificação globalmente exclusiva de um evento em relação a todos os outros eventos, inclusive eventos subordinados e subordinantes em uma árvore de eventos.
• Estrutura dos eventos é formada pelas informações descritivas principais sobre um evento, inclusive a origem do mesmo (informações do sistema e do usuário), e pelos dados específicos do evento usados no processo empresarial acionado.
• Transporte de eventos é o mecanismo pelo qual o evento é gerado e obtém a resposta por meio de uma entrega formal garantida.
• Persistência de eventos é o armazenamento de longo prazo das informações do evento para fins de auditoria e inteligência empresarial.

a Figura 2 ilustra esses componentes.

A taxonomia de eventos

A taxonomia de eventos fornece um meio de identificar de forma exclusiva cada tipo de evento de forma cada vez mais detalhada (o que é importante durante a discussão sobre a estrutura da carga útil de dados do evento). Cada termo é definido de forma exclusiva pelo ID de taxonomia de evento com base na característica da própria árvore. Por exemplo, como a A figura 3 mostra, Client é o ID de taxonomia A, Purchase é o ID de taxonomia A1, New Item é o ID A13, e assim sucessivamente. Essa abordagem do uso de uma posição de caractere no identificador por nível de hierarquia permite a inserção de termos novos na árvore sem precisar renumerar nenhum outro identificador de termo.

Identificação de eventos

Além da taxonomia de eventos, é necessário identificar de forma exclusiva cada evento gerado, por duas razões: primeiro, para permitir que eventos gerados fora da sequência sejam colocados na ordem correta (por exemplo, indicação de data e hora) e segundo, para permitir a captura da causalidade do evento, ou seja, a capacidade de saber qual evento fez com que outro evento acontecesse. Essa cadeia liga cada evento ao seu pai e a todos os eventos filho. Ao conhecer qualquer evento na árvore, é possível reconstruir toda a árvore usando esses identificadores exclusivos (veja a A figura 4).

Para ajudar a rastrear as relações entre pais e filhos, a arquitetura EEMF introduz o conceito de propagating composite identifier (PCI), que se origina na parte superior da árvore de eventos e passa para todos os eventos subsequentes. Como mostrado na Listagem 1, o PCI é criado a partir de um conjunto de GUIDs (globally unique identifiers) que são passados adiante para cada evento subsequente e têm o GUID do evento anexado a eles para a criação do identificador composto. Em termos práticos, isso significa que o GUID do evento se torna um parâmetro obrigatório em todas as chamadas de logs de eventos realizadas pelos aplicativos ou elementos de rede que participam da árvore de eventos. No caso dos sistemas legados, isso pode exigir o encapsulamento das chamadas da application programming interface (API), de forma a capturar o evento antes de continuar a chamada de método.

	
Event #1: 
	Customer.Purchase.Change Composite Event ID =
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}
Event #1.1: 
	Customer.Purchase.Change.Mobile_Number Composite Event ID =	
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}::
				{83dfd56a-e973-4f74-9cf9-ae2a901f80d2}
Event #1.2: 
	Customer.Purchase.Download.Equipment Composite Event ID =	
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}::
				{c5eb0984-fce4-45c7-8aa5-809da165ca15}
Event #1.2.1: 
	Customer.Purchase.Download.Equipment.Mobile Composite Event ID =
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}::
				{c5eb0984-fce4-45c7-8aa5-809da165ca15}::
				{aed0dd16-6a1b-4bbd-90a4-a30f0c939bca}

Quando uma árvore de eventos é concluída, pode ser reconstruída facilmente a partir de qualquer evento na árvore, através da inspeção da chave composta para se obter a chave pai e, em seguida, usando a chave pai de raiz (sempre a primeira chave do composto) para obter todos os nós relacionados.

Para capturar a estrutura das transações empresariais (que inicia cada árvore de eventos), o cabeçalho de evento da carga útil contém um atributo referente ao ID da transação. Entretanto, o aplicativo que inicia é responsável pela inclusão desse valor na geração do evento pai. Os eventos que estão mais abaixo na cadeia não têm onde usar esse valor e não são obrigados a mantê-lo ou passá-lo para outros eventos.

Estrutura dos eventos

Cada evento contém um conjunto de informações que é global para todos os eventos (como o nome, GUID e chave do evento) e específico para aquele evento em particular. A estrutura básica de uma mensagem de evento é mostrada como um documento XML na Figura 5, e Figura 6.. O operador<event> representa o elemento raiz do documento XML e contém informações globais para todos os eventos, inclusive o <event-context>. O contexto do evento permite que cada evento indique onde ele foi gerado e quem o gerou e forneça detalhes no ambiente de execução no momento da geração. O contexto do evento também contém informações que podem ser usadas em auditorias de segurança (como o ID do usuário), como mostra a Figura 5,.

O restante da mensagem do evento é dedicada à "carga útil" do evento (A Figura 6). A carga útil do evento contém informações específicas para cada tipo de evento, normalmente capturadas como atributos XML para cada nível na árvore de taxonomia de eventos. Por exemplo, o comando <customer> contém informações específicas para o cliente, como nome, sobrenome e outros dados de identificação. Cada tag adicional fornece informações ao evento geral, para proporcionar um quadro completo de toda a árvore de eventos.

Observe também que os dados fornecidos em cada nível não necessariamente se sobrepõem à medida que o evento se propaga de um sistema para outro. Por exemplo, o aplicativo que inicia (ou seja, o aplicativo de atendimento ao cliente) pode conhecer as informações de nível superior sobre o cliente e a compra, mas não ter informações sobre os eventos de nível mais baixo, como o número do diretório — MIN/MDN — ou o número do equipamento — MEID — que é designado. Os eventos subsequentes podem gerar informações que podem ser capturadas nesse nível, anexando tags adicionais a partir da taxonomia e deixando as tags de nível mais alto vazias.

Transporte de eventos

Para usar a taxonomia de eventos, a identificação e a estrutura que foram definidas, é necessário fornecer um mecanismo aos desenvolvedores de aplicativos para que eles criem e postem mensagens de eventos com facilidade. No ambiente do EEMF, esse mecanismo é fornecido por meio de um enterprise service bus (ESB) e um enterprise messaging service (EMS). O ESB fornece um conjunto de serviços que permite que geradores de eventos e assinantes interajam com a fila de eventos de mensagem e os tópicos. Um resumo do transporte de evento é ilustrado na figura 7. (Veja uma versão ampliada da figura 7.)

Os serviços de evento são fornecidos para permitir que o aplicativo gerador do evento use o método GetEventGUID() como o identificador composto do evento. Também são fornecidos serviços para ValidateEvent() com relação à hierarquia de eventos e PostEvent() para processamento. Finalmente, as partes podem usar RegisterEventSubscriber() e DeregisterEventSubscriber() para registrar interesse em eventos específicos e para remover o registro.

Os eventos postados na fila de mensagens de eventos são processados imediatamente pelo roteador de mensagens normalizadas para que a mensagem do evento seja postada em um tópico de evento específico. Os tópicos de eventos são organizados com base na taxonomia de eventos. Por exemplo, o primeiro tópico é o tópico de eventos Customer. Usando os mecanismos padrão de tratamento de mensagens, os eventos enviados por meio do ESB para o EMS são configurados para ter uma entrega garantida. A qualidade de dados referente aos eventos é gerenciada usando o serviço ValidateEvent() para garantir que todas as mensagens de evento sejam bem formadas. Entretanto, os dados reais contidos na carga útil não são validados nesse momento. A filtragem das mensagens é tratada no nível do tópico do assinante. Os eventos que não passam na validação são rejeitados e voltam como erro ao gerador do evento que chama, e a condição de erro gera um evento de exceção que detalha a origem do evento errôneo e das validações nas quais houve falha.

Persistência de eventos

Os eventos que são gerados para o ESB/EMS devem ser armazenados para análise de longo prazo e auditoria. O repositório de data mart de eventos tem uma janela de retenção definida que determina a duração da retenção dos eventos. A janela de retenção de eventos é definida pelas necessidades expressas referentes às mensagens de evento retidas, mas deve ser de pelo menos 60 dias (para proporcionar tempo para a análise e revisão empresarial). O período em que os eventos ficam armazenados depende principalmente do número de eventos gerados e da quantidade de espaço de armazenamento disponível. Pode ser um meio-termo razoável entre os dados on demand e os custos de armazenamento utilizar do armazenamento de primeiro nível durante os primeiros 60 dias e, em seguida, mover os dados para um meio de armazenamento de custo mais baixo, de segundo ou terceiro nível.

Com base na definição de carga útil de eventos que foi fornecida, as estimativas de requisitos de armazenamento de dados são mostradas na Tabela 1.

Voltar para parte superior

Conclusão

Os eventos empresariais representam uma grande quantidade de informações, não somente sobre o desempenho da empresa, mas também como uma forma de obter insight sobre os comportamentos dos clientes e parceiros de negócios. Usando uma taxonomia de eventos e uma estrutura bem definida com um mecanismo global para relacionar vários eventos entre si e um mecanismo de transporte disponível em todo o empreendimento, agora é possível capturar e analisar todos os eventos empresariais relevantes. No próximo artigo desta série, será desenvolvido o protótipo de um sistema de gerenciamento de eventos corporativos para mostrar como esses conceitos funcionam na prática.

Recursos

Aprender

• Confira o livro de David Luckham, The Power of Events (Addison-Wesley, 2002), para uma boa introdução ao valor empresarial do gerenciamento de eventos e do processamento de eventos complexos.
  
  
• Para os interessados em entender o valor e a prática do desenvolvimento de relações empresariais com os clientes, leia Managing Customer Relationships de Don Peppers e Martha Rogers (John Wiley and Sons, 2004).
  
  
• Consulte a tese de doutorado de Marcus Wübben's, Analytical CRM pela Universidade Técnica de München (2008), para uma boa visão geral do gerenciamento de relações com clientes.
  
  
• Para ver uma revisão do poder da resposta em tempo real às necessidades dos clientes, leia o capítulo de Kamakurq Wagner, "Cross-Selling — Offering the Right Product to the Right Customer at the Right Time", em Profit Maximization Through Customer Relationship Marketing (L. Aksoy, T. Keiningham, D. Bejou, eds.; Haworth Press, 2008).
  
  
• Segmentos de mercado no IBM developerWorks: Obtenha todos os recursos técnicos específicos do segmento de negócio mais recentes para desenvolvedores.
  
  
• Biblioteca de segmentos de mercado: Consulte a biblioteca de segmentos de mercado do developerWorks e obtenha artigos técnicos e dicas, tutoriais, padrões e IBM Redbooks.
  
  
• developerWorks: Mantenha-se atualizado em relação à tecnologia nessas sessões.
  
  
• developerWorks no Twitter: Inscreva-se hoje para seguir os tweets do developerWorks.
  
  
• Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
  
  

Obter produtos e tecnologias

• Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste online no IBM SOA Sandbox e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®eWebSphere®.
  
  

Discutir

• Blogs do developerWorks: Confira esses blogs e participe.
  
  

Sobre o autor

Ben Lieberman trabalha como arquiteto principal da BioLogic Software Consulting. É especializado em consultoria e treinamento em diversos tópicos de desenvolvimento de software, como arquitetura de software, análise de requisitos, análise e design de software, gerenciamento de configuração e melhoria dos processos de desenvolvimento. Lieberman tem mais de dez anos de experiência em arquitetura de software e TI em diversos campos, como telecomunicações, viagens em linhas aéreas, e-commerce, governo, serviços financeiros e ciências biológicas. Seus serviços de consultoria se baseiam nas boas práticas de desenvolvimento de software, com especialização em arquiteturas orientadas a objeto e computação distribuída — especificamente, sistemas baseados em Java™e desenvolvimento distribuído de Web sites (J2EE), XML/XSLT, Perl e sistemas de cliente/servidor baseados em C++. Lieberman prestou serviços de arquitetura para organizações corporativas, como a EchoStar, Jones Cyber Solutions, Blueprint Technologies, Trip Network Inc. e Galileo International, instituições educacionais, como a Universidade de Duke e a Universidade do Colorado, e agências governamentais, como a Mine Safety and Health Administration. Ele também é escritor profissional bem-sucedido, autor de um livro e vários artigos relacionados a software. Lieberman tem doutorado em biofísica e genética pela Universidade do Colorado, Centro de Ciências de Saúde.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Comportamento empresarial baseado em eventos
• Respondendo à ação do cliente
• Inteligência empresarial baseada em eventos
• O framework de gerenciamento de eventos corporativos
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais