Fala Dataholics, tudo bem? Neste artigo, vou falar um pouco sobre BPM. Mas, antes de tudo, vamos começar do início: você sabe o que é um processo? Podemos dizer que um processo é uma atividade ou um conjunto de atividades realizadas em uma ordem sequencial para atingir um resultado desejado. A imagem abaixo ilustra de maneira geral um processo e sua estrutura. E ao se definir um processo buscamos 3 coisas: Eficácia: a medida em que as necessidades do cliente são atendidas. Eficiência: o grau de utilização dos recursos para alcançar os resultados desejados. Flexibilidade: a capacidade de adaptar os processos para atender às solicitações especiais dos clientes ou das partes interessadas. Agora que entendemos o que é um processo, o que é BPM? O Business Process Manager (BPM) ou Gestão de Processos de Negócio é uma disciplina de gerenciamento que busca compreender os processos internos de uma empresa, permitindo a medição desses processos e, consequentemente, possibilitando a gestão dos mesmos. Em outras palavras, o BPM permite que as empresas documentem, analisem, melhorem e automatizem seus processos de negócios. É importante lembrar que o BPM não é uma metodologia, mas sim uma prática ou disciplina de gestão. Ou seja, é um conjunto de conhecimentos sobre princípios e práticas de gestão de processos que engloba estratégias, objetivos, cultura, estruturas organizacionais, funções, políticas, métodos e tecnologia para analisar, projetar, implementar, gerenciar o desempenho, transformar e estabelecer a governança do processo. Qual é o objetivo do BPM? Fica claro que o objetivo do BPM é melhorar os processos, mas melhorar processos não significa apenas executá-los corretamente. Por exemplo, automatizar um processo não é o mesmo que otimizar o processo em si, mas sim a forma como ele é executado. O BPM vai além disso, envolvendo a melhoria contínua dos processos de negócios. A cultura de melhoria contínua é essencial para aprimorar os processos. Isso significa revisar processos melhorados regularmente para identificar oportunidades de aprimoramento, como a eliminação de etapas desnecessárias, remoção de gargalos, análise da necessidade de tarefas em sequência que poderiam ser executadas simultaneamente e verificar se as pessoas no fluxo estão realmente realizando as atividades. Agora vamos dar uma olhada nas etapas do BPM: Planejar e Identificar: Nesta etapa, os processos de negócios são identificados e documentados, incluindo seus objetivos, entradas e saídas, recursos necessários e partes envolvidas. Analisar: Os processos são analisados para identificar áreas de melhoria, incluindo gargalos, atividades desnecessárias ou ineficientes e pontos de falha. Desenhar: Com base na análise dos processos, são propostas soluções para melhorar a eficiência, eficácia e qualidade dos processos. Isso pode envolver a eliminação de etapas desnecessárias, a automatização de atividades ou a reorganização de tarefas. Implementar: As mudanças propostas são implementadas, incluindo a atualização da documentação dos processos, a comunicação com as partes envolvidas e a implementação de tecnologia para automatizar tarefas. Monitorar: Os processos são monitorados continuamente para garantir que estejam funcionando conforme o esperado e para identificar oportunidades adicionais de melhoria. Otimizar/Refinar: Com base no monitoramento contínuo, são propostas novas melhorias e refinamentos aos processos, permitindo que a melhoria contínua seja um processo cíclico e constante. A Modelagem de Processos Modelagem de processos de negócio é uma prática importante dentro do BPM para desenhar como os processos de uma empresa funcionam. É importante que ela seja bem detalhada para que se possa entender como o processo acontece do começo ao fim. Para isso, é necessário encontrar a melhor forma de detalhar o processo de acordo com a necessidade da empresa. Existem várias formas de representar modelos de processos, dependendo da finalidade e do público-alvo. Algumas das formas mais comuns são: ● Fluxograma: é uma representação gráfica dos processos em que são utilizados símbolos para representar atividades, decisões, fluxos, entre outros. É útil para descrever o fluxo do processo de forma simples e fácil de entender. ● Diagrama de processo: é uma representação gráfica do processo que mostra a sequência de atividades e os relacionamentos entre elas. É mais detalhado do que um fluxograma e é útil para identificar as atividades do processo e seus resultados. ● BPMN (Business Process Model and Notation): é uma notação gráfica padrão que permite a representação detalhada dos processos de negócios. O BPMN utiliza uma série de símbolos padronizados (ícones) para representar atividades, eventos, gateways, fluxos, entre outros. ● UML (Unified Modeling Language): é uma linguagem de modelagem padrão que permite a representação de processos e sistemas em geral. O UML é utilizado principalmente na modelagem de sistemas de software, mas também pode ser aplicado em processos de negócios. ● IDEF (Integrated Definition Language): é um conjunto de técnicas e notações para a modelagem de processos. O IDEF é utilizado principalmente em processos de engenharia e produção, mas também pode ser aplicado em processos de negócios. Entre elas a BPMN se tornou a mais utilizada para criar desenhos de processos mais elaborados e detalhados. Aqui estão os passos para modelar e mapear um processo: Identificar os objetivos do processo Identificar as saídas do processo Identificar os clientes do processo Identificar as entradas e componentes do processo Identificar os fornecedores do processo Determinar os limites do processo Documentar o processo atual Identificar melhorias necessárias ao processo Consenso sobre melhorias a serem aplicadas ao processo Documentar o processo revisado Em resumo, o BPM em conjunto com a modelagem dos processos pode trazer diversas vantagens, tais como a melhoria da eficiência, a padronização das tarefas, a redução de custos, o aumento da qualidade e a transparência dos processos.

O que é um Message broker? Um "broker" é um intermediário de comunicação entre diferentes aplicativos, sistemas e serviços. Ele age como um tradutor de mensagens, permitindo que serviços interdependentes "conversem" diretamente, mesmo que tenham sido escritos em diferentes linguagens de programação ou implementados em diferentes plataformas. Esses intermediários são chamados de "message brokers" e fazem parte de um conjunto de ferramentas chamado "middleware", que ajuda os desenvolvedores a lidar com o fluxo de dados entre diferentes partes de um aplicativo, permitindo que eles se concentrem na lógica principal do programa. Esse tipo de ferramenta pode ser usado para ajudar aplicativos que funcionam em plataformas diferentes a se comunicarem uns com os outros. Os message brokers podem validar, armazenar, encaminhar e entregar mensagens aos destinos apropriados. Eles são como intermediários entre diferentes aplicativos, permitindo que remetentes emitam mensagens sem saber onde estão os destinatários, se eles estão ativos ou quantos são. Isso facilita a comunicação entre diferentes partes do sistema. Para garantir que as mensagens sejam armazenadas e entregues de maneira confiável, os message brokers geralmente dependem de uma estrutura ou componente chamado "message queue", que armazena e organiza as mensagens até que os aplicativos possam processá-las. As mensagens são armazenadas na ordem exata em que foram enviadas e permanecem na fila até que a confirmação de recebimento seja feita. Como os message brokers funcionam? Producer - a aplicação responsável pelo envio de mensagens. Está conectado ao intermediário de mensagens. No padrão de publicação/assinatura (vamos chegar lá), são chamados de publicadores. Consumer - o ponto final que consome mensagens que estão aguardando no intermediário de mensagens. No padrão de publicação/assinatura, são chamados de assinantes. Queue/topic - uma pasta em um sistema de arquivos. O intermediário de mensagens os usa para armazenar mensagens. Os message brokers oferecem dois padrões básicos de distribuição de mensagens ou estilos de comunicação: Point-to-point messaging: Este é o padrão de distribuição utilizado em filas de mensagens, com uma relação de um-para-um entre o remetente e o destinatário da mensagem. Cada mensagem na fila é enviada para apenas um destinatário e é consumida apenas uma vez. A comunicação ponto a ponto é chamada quando uma mensagem deve ser agida apenas uma vez. Exemplos de casos de uso adequados para este estilo de comunicação incluem processamento de folha de pagamento e transações financeiras. Nestes sistemas, tanto remetentes quanto destinatários precisam de garantia de que cada pagamento será enviado uma única vez. Publish/subscribe: Neste padrão de distribuição de mensagens, frequentemente chamado de "pub/sub", o produtor de cada mensagem a publica em um tópico e vários consumidores de mensagens se inscrevem em tópicos dos quais desejam receber mensagens. Todas as mensagens publicadas em um tópico são distribuídas para todas as aplicações inscritas nele. Este é um método de distribuição de estilo de transmissão, no qual há uma relação de um-para-muitos entre o publicador da mensagem e seus consumidores. Se, por exemplo, uma companhia aérea quiser divulgar atualizações sobre os horários de chegada ou o status de atraso de seus voos, várias partes poderiam utilizar a informação: equipes em solo realizando manutenção e reabastecimento da aeronave, manipuladores de bagagens, comissários de bordo e pilotos preparando-se para a próxima viagem do avião e operadores de displays visuais notificando o público. Usar um message broker oferece diversas vantagens, tais como: Possibilita a comunicação entre serviços que não estão em execução simultânea. O produtor pode enviar mensagens independentemente de o consumidor estar ativo ou não, desde que o message broker esteja em execução. Melhora o desempenho do sistema por meio da introdução de processamento assíncrono. Tarefas de alta intensidade podem ser distribuídas para processos separados, acelerando a aplicação e melhorando a experiência do usuário. Aumenta a confiabilidade do sistema garantindo a transmissão de mensagens. Os message brokers oferecem um mecanismo de reenvio que pode enviar a mensagem imediatamente ou em um tempo determinado em caso de falha do consumidor. Além disso, há suporte para o roteamento de mensagens não entregues por meio do mecanismo de "dead-letter". Agora que você tem uma melhor compreensão do que é um message broker e sua importância. 😎

Observabilidade é um conceito que se concentra em interpretar os dados recebidos de um sistema externo para detectar qualquer falha ou erro mínimo nos dados. O objetivo de uma plataforma de observabilidade é encontrar o ponto de desempenho normal de um sistema e, em seguida, melhorá-lo. Embora este cenário perfeito possa não ser alcançado, a observabilidade permite eliminar possibilidades de erro. Para alcançar este objetivo, é necessária a relação de três pilares: métricas, logs e traces. Métricas são dados numéricos fáceis de obter de um determinado programa que está sendo observado. Esses dados são normalmente reunidos em gráficos para facilitar a leitura. Existem dois tipos de métricas: as métricas de trabalho, que fornecem informações sobre o sistema, como o throughput, e as métricas de recursos, que fornecem informações sobre os recursos do sistema, como a porcentagem de utilização de CPU. Os eventos são outro parâmetro importante da observabilidade, mas normalmente estão incluídos nas métricas. Eles são um acontecimento que ocorreu em um determinado momento, ao contrário das métricas que são recolhidas por intervalos de tempo. Um exemplo de evento é o acionamento de um alarme. Os logs são coleções de dados semiestruturados ou apenas strings que detalham erros ou anomalias presentes no sistema, ao contrário das métricas. Eles são usados para ter uma percepção do que aconteceu em caso de erro, a fim de encontrar uma solução mais rápida. Traces são dados semiestruturados, como os logs, mas contêm informações sobre o caminho de rede que se comunica com o programa para obter essa informação. É criado um documento semelhante a um log para mostrar detalhadamente um erro. Os principais parâmetros dos tracers incluem a função do sistema em que ocorreu o erro, sua duração, entre outros. No caso de micro serviços, que é uma arquitetura dividida em vários módulos que se comunicam entre si, os traces ganham importância adicional. Esses tracers mostram o caminho entre os vários módulos, o tempo que eles demoraram e os eventos que encontraram pelo caminho. Esses tracers são chamados de tracers distribuídos e são diferentes dos tracers normais. Eles utilizam cabeçalhos de pacote adicionais HTTP para se propagar entre os vários componentes do serviço. Qual é a diferença entre monitoramento e observabilidade? A observabilidade é realmente o monitoramento por outro nome? Em resumo, não. Embora a observabilidade e o monitoramento estejam relacionados e possam se complementar, são conceitos diferentes. Em um cenário de monitoramento, você geralmente configura painéis que são destinados a alertá-lo sobre problemas de desempenho que você espera ver mais tarde. No entanto, esses painéis dependem da suposição fundamental de que você é capaz de prever que tipos de problemas encontrará antes que ocorram. Ambientes nativos da nuvem não se prestam bem a esse tipo de monitoramento porque são dinâmicos e complexos, o que significa que você não tem como saber com antecedência que tipos de problemas podem surgir. Em um cenário de observabilidade, em que um ambiente foi totalmente instrumentado para fornecer dados completos de observabilidade, você pode explorar de forma flexível o que está acontecendo e rapidamente descobrir a causa raiz de problemas que pode não ter sido capaz de antecipar. Por que a observabilidade é importante? A observabilidade é importante porque oferece maior controle sobre sistemas complexos. Sistemas simples têm menos componentes móveis, o que os torna mais fáceis de gerenciar. Monitorar a CPU, a memória, os bancos de dados e as condições de rede geralmente é suficiente para entender esses sistemas e aplicar a correção apropriada a um problema. Os sistemas distribuídos têm um número muito maior de peças interconectadas, o que significa que o número e os tipos de falhas que podem ocorrer são também maiores. Além disso, os sistemas distribuídos são constantemente atualizados e cada mudança pode criar um novo tipo de falha. Em um ambiente distribuído, compreender um problema atual é um enorme desafio, principalmente porque ele produz mais "unknown unknowns" (problemas não são conhecidos nem monitorados) do que sistemas mais simples. Como o monitoramento requer "known unknowns" (problemas já identificados e monitorados), pode ser que a abordagem de monitoramento não seja suficiente para lidar adequadamente com os problemas que surgem em ambientes complexos. A observabilidade é mais adequada para a imprevisibilidade de sistemas distribuídos, principalmente porque permite fazer perguntas sobre o comportamento do sistema à medida que surgem problemas. "Por que X está quebrado?" ou "O que está causando a latência agora?" são algumas das perguntas que a observabilidade pode responder.