Ata 09 · Integrações do ADMS e DMS com os Canais Digitais e o Atendimento Convencional: Ocorrência Técnica, Eventos, Consistência Transacional e Atualização Cadastral (15 e 16 de julho de 2026)

Ata unificada das duas sessões consecutivas realizadas em 15 e em 16 de julho de 2026, consolidada a partir das compilações técnicas de cada encontro e das transcrições integrais das duas gravações.

Datas	15 de julho de 2026 (quarta-feira) e 16 de julho de 2026 (quinta-feira)
Horários	Sessão 1: 10h39 às 11h27 · Sessão 2: 10h30 às 11h33
Duração	Aproximadamente 48 minutos na primeira sessão e 1h03 na segunda, totalizando cerca de 1h51 de levantamento
Plataforma	Microsoft Teams (reuniões remotas, com gravação e transcrição automática)
Tema	Integrações dos canais digitais e do atendimento convencional com o ADMS e o DMS, modelagem de eventos no Kafka, consistência transacional, atualização cadastral de clientes e instalações e limites de domínio
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Elaborado por	Syntropy Labs
Fontes	Compilações técnicas das duas sessões e transcrições integrais das gravações do Microsoft Teams

1.10.1. Identificação e contexto das sessões

1.10.1.1. Por que as duas sessões formam um registro único

As reuniões de 15 e de 16 de julho tratam do mesmo objeto: o caminho percorrido por uma ocorrência técnica desde a abertura no canal de atendimento até o despacho, a atualização dos sistemas e a comunicação ao cliente. A primeira sessão foi conduzida pela área de canais digitais e a segunda pela área de atendimento convencional, sobre a mesma arquitetura e a mesma cadeia de microserviços.

A divisão foi circunstancial. Na sessão de 15 de julho, a apresentação do atendimento convencional não pôde ser concluída porque a interlocutora tinha compromisso no horário seguinte, e a continuidade foi agendada para a manhã do dia seguinte. Na abertura da segunda sessão foi expressamente registrado que o fluxo é basicamente o mesmo apresentado no dia anterior, com uma única diferença de entrada, e que não haveria repetição do que já havia sido percorrido. Por essa razão, o conteúdo das duas sessões é registrado aqui como uma única ata, com os temas e os conceitos unificados.

1.10.1.2. Origem da demanda de revisão ponta a ponta

A iniciativa nasceu de uma recomendação feita por Érica de Andrade e Santos em reuniões anteriores: realizar uma revisão das integrações ponta a ponta do DMS. A necessidade se acentuou após as primeiras implantações do ADMS e do DMS, em especial após a implantação no Mato Grosso do Sul. A partir dessa recomendação, a Energisa decidiu buscar uma consultoria externa para obter um olhar independente, que não estivesse restrito à visão interna de cada área.

Foi esclarecido às áreas, no início da primeira sessão, que o escopo do trabalho não está restrito ao Kafka. O objetivo declarado é compreender a integração de forma ampla, incluindo os processos de negócio, as dores das áreas usuárias e as entregas já realizadas, antes de propor qualquer mudança.

1.10.1.3. Escopo declarado do levantamento

Foi solicitado às áreas que apresentassem os fluxos existentes, os sistemas envolvidos, as integrações já implementadas, as dificuldades conhecidas e os pontos que, na avaliação delas, deveriam ser revistos. O levantamento abrange:

• Canais digitais, atendimento convencional e sistemas de abertura de solicitações.
• Serviços de entrada, serviços de validação e microserviços de ocorrência técnica.
• Camada de eventos em Confluent Kafka, incluindo tópicos, partições e contratos.
• Integração com o ADMS e o DMS, síncrona e assíncrona.
• Integração com o WFM e o ciclo das ordens de serviço.
• Sistemas legados e mecanismos de captura de dados alterados.
• Bancos de dados relacionais e documentais que sustentam o estado das ocorrências.
• Observabilidade, consistência transacional, tratamento de falhas e escalabilidade.
• Governança dos eventos e limites entre domínios.

1.10.2. Participantes e áreas envolvidas

As duas sessões reuniram as áreas de canais digitais e de atendimento convencional da Energisa, com a coordenação do assessment e a participação da consultoria.

Norberto da Silva Prado	Energisa. Coordenação do assessment, articulação com as áreas, contextualização do ambiente legado e organização das agendas.	15 e 16/07
Lucas de Almeida Teixeira	Energisa, canais digitais. Apresentação do fluxo de ocorrência técnica, dos microserviços, dos tópicos e das dores de volumetria.	15 e 16/07
Izabooh Enmilay Carvalher Goncalves	Energisa, atendimento convencional. Apresentação dos fluxos documentados na Wiki, dos microserviços de comunicação e cadastro e dos problemas em tratamento.	15 e 16/07
Weislla Fernanda da Cruz Tomazeto	Energisa. Participação na sessão de 15 de julho, com áudio majoritariamente ininteligível na transcrição automática.	15/07
Valéria Martelloti da Silva	Energisa. Responsável atual pelo CRM legado do atendimento. Participação breve na sessão de 16 de julho.	16/07
João Carlos Franco Castellani	Syntropy Labs. Condução da análise arquitetural sobre eventos, idempotência, limites de domínio e adequação tecnológica.	15 e 16/07
Vladimir Morozowski de Sousa	Syntropy Labs. Condução, registro das sessões e busca da visão ponta a ponta do negócio.	15 e 16/07

Foram citadas ao longo das sessões, sem participação direta, as seguintes pessoas e equipes:

• Érica de Andrade e Santos, que propôs a revisão ponta a ponta das integrações.
• Victor Teixeira Pinheiro, indicado como detentor da imagem do diagrama de arquitetura apresentado na Wiki.
• Equipe responsável pelo Sigode, apontada como detentora do desenho de publicação e segregação dos tópicos de ocorrência.
• Equipe do WFM, incluindo o profissional dedicado à modernização em eForce, para sessão posterior.
• Equipes de OpenShift, de infraestrutura e de telecom, ainda a agendar, esta última necessária para validar a comunicação entre os data centers da Paraíba e de Minas Gerais.
• Felipe Rosa Aguiar, então em férias, com retorno previsto para o dia 31, cuja apresentação do fluxo geral de negócio foi assumida por Norberto.

1.10.3. Resumo executivo

As duas sessões permitiram reconstruir a cadeia completa de uma ocorrência técnica e identificar sete temas que concentram o risco arquitetural do conjunto. O ambiente já alcançou desacoplamento técnico relevante, com resposta rápida ao canal, absorção de picos e processamento paralelo. O que está em discussão não é a adoção de eventos, mas a forma como os eventos foram modelados, onde reside o estado autoritativo de cada entidade e como a consistência entre banco e barramento é assegurada.

Abertura da ocorrência técnica	Chamada ao serviço de entrada com validação leve, protocolo devolvido de imediato ao canal e processamento assíncrono via Kafka.	O canal não aguarda a conclusão das etapas internas, mas a validação efetiva ocorre adiante na cadeia.	Manter o padrão assíncrono e reforçar contrato, correlação e observabilidade do ciclo completo.
Modelagem por estado	Sete tópicos representam estados da mesma ocorrência, com estrutura de mensagem semelhante entre eles.	Não existe garantia natural de ordem entre estados e o número de tópicos cresce com o número de situações.	Tópico por agregado, com event type, chave de partição por ocorrência e filtro no consumidor.
Cancelamento no CRM	O status cancelado é terminal no CRM legado e impede transições posteriores.	Ocorrências permanecem congeladas com status incorreto perante o cliente.	Revisar a máquina de estados no microserviço de comunicação e admitir transições válidas ou compensatórias.
Consistência banco e evento	Gravação no banco e publicação no barramento ocorrem como operações independentes em diversos pontos.	Risco de dual write, de falha silenciosa e de perda de atualização entre sistemas.	Transactional Outbox ou captura de dados alterados sobre tabela de outbox, com consumidores idempotentes.
Volumetria dos eventos	A fila de clientes afetados opera com 60 partições e acumula vários gigabytes mesmo em períodos de baixa ocorrência.	Custo de infraestrutura, latência, reprocessamento longo e risco de atraso nos eventos relevantes.	Revisar granularidade e filtros na origem e avaliar leitura direta a partir do ADMS e do DMS.
Fonte da verdade	O Sigode mantém, em base MongoDB, uma cópia consolidada do estado produzido pelo ADMS e pelo DMS.	Divergência já materializada em cancelamento não propagado, resolvido com carga manual de dados.	Eleger o ADMS e o DMS como fonte principal da informação técnica e reduzir o número de cópias do mesmo estado.
Base do CRM legado	O CRM do atendimento não expõe serviços e é atualizado por gravação direta em sua base Oracle, por diversos sistemas.	A modernização do CRM fica acoplada a vários domínios simultaneamente.	Encapsular a base com serviços de dados e aplicar camada anticorrupção entre os domínios.

Síntese do assessment O ganho da arquitetura orientada a eventos está sendo parcialmente consumido por três características que se reforçam. Primeiro, parte dos tópicos representa rotas técnicas entre dois sistemas, e não fatos de domínio reutilizáveis, o que mantém acoplamento funcional mesmo com comunicação assíncrona. Segundo, o estado de uma mesma ocorrência está representado simultaneamente no ADMS e no DMS, no Sigode, em bases MongoDB e na base do CRM, sem que a fonte autoritativa esteja formalmente definida. Terceiro, a consistência entre o dado e o evento é garantida por controle em código, e não por um padrão transacional, o que deixa espaço para falhas silenciosas.

1.10.4. Visão consolidada do ecossistema de atendimento e ocorrência técnica

A consolidação das duas sessões permite descrever o ecossistema em camadas e reconstruir os fluxos principais na sequência em que foram apresentados.

1.10.4.1. Camadas e componentes identificados

Canais de entrada	Canais digitais, com site e aplicativo, e canais convencionais, com agências e call center apoiados no CRM legado CATT.	Registro da solicitação do cliente e acompanhamento do atendimento.
Serviço de entrada	Serviço de registro de ocorrência técnica, referido como WS HOT.	Recebe a chamada de abertura, executa validações leves, devolve o protocolo e publica no Kafka.
Microserviços de ocorrência	Microserviço de ocorrência técnica, microserviço de filtro de incidentes, microserviço de comunicação e microserviço de desligamento emergencial.	Complemento de dados, persistência, filtragem dos eventos publicados pelo Sigode e sincronização de status com o CRM.
Microserviços cadastrais	Monitor de instalação, microserviço de cliente, microserviço de cliente CSV e microserviço de atualização de potência.	Atualização de clientes, instalações e potências ativa e reativa no DMS.
Integração com o ADMS e o DMS	Serviço de integração com o sistema técnico, com transformação de payload e chamada síncrona ao DMS.	Criação e atualização do incidente e obtenção dos identificadores de retorno.
Camada de eventos	Confluent Kafka, com KSQLDB em uso e Apache Flink previsto para etapas futuras.	Desacoplamento, distribuição dos eventos e processamento em streaming.
Camada de consolidação	Sigode, sistema desenvolvido internamente na Energisa, com base MongoDB.	Consolidação e enriquecimento dos eventos recebidos do ADMS e do DMS e republicação por estado.
Força de trabalho	WFM e Sigode.	Formação, despacho e acompanhamento das ordens de serviço executadas em campo.
Persistência	Base Oracle do atendimento convencional e bases MongoDB dos canais digitais e do Sigode.	Estado das comunicações, das ocorrências e dos cadastros de cliente e instalação.

1.10.4.2. Abertura de ocorrência técnica pelos canais digitais

O fluxo apresentado na primeira sessão descreve a abertura de uma ocorrência técnica, como falta de energia, a partir dos canais de atendimento.

1. O canal digital ou convencional aciona o serviço de entrada com a solicitação de abertura da ocorrência técnica.

2. O serviço de entrada executa validações leves, verificando a integridade do request e se a ocorrência poderia ser aberta, sem realizar as validações de negócio completas.

3. A resposta é devolvida rapidamente ao canal, com o número de protocolo, enquanto o processamento prossegue de forma assíncrona.

4. O serviço de entrada publica a mensagem em uma fila do Kafka.

5. O microserviço de ocorrência técnica consome a mensagem, recupera e complementa os dados faltantes e grava a comunicação na base da Energisa.

6. O mesmo microserviço republica o conteúdo em uma segunda fila, de registro da ocorrência no sistema técnico.

7. O serviço de integração com o sistema técnico consome essa fila, aplica as transformações exigidas pelo modelo do DMS e envia a requisição.

8. A chamada ao DMS é síncrona nesse ponto, porque o serviço depende do retorno para prosseguir.

9. Com o retorno, é produzida uma mensagem de resposta contendo o identificador do incidente criado no DMS e os dados da reclamação, publicada novamente no Kafka.

10. O microserviço de ocorrência técnica mantém duas trilhas de consumo, uma para a chamada e outra para o retorno, e atualiza o registro com o incidente recebido.

Foi relatado que, em cerca de noventa e nove por cento dos casos, o DMS devolve o identificador do incidente na resposta. Nos casos residuais em que isso não ocorre, um serviço do atendimento convencional realiza a atualização posterior, localizando o registro pelo número da comunicação.

Coexistência com os sistemas técnicos anteriores O fluxo descrito vale para a integração com o DMS. Para os sistemas técnicos anteriores, ainda em operação em parte das empresas, o serviço de integração não existe e o registro segue caminho distinto, com gravação direta em tabela. Foi informado que esses sistemas deixarão de existir à medida que o ADMS e o DMS avancem nas demais empresas, o que torna o fluxo atual transitório em duas frentes ao mesmo tempo.

1.10.4.3. Entrada pelo atendimento convencional

A diferença apresentada na segunda sessão está exclusivamente no ponto de entrada. No atendimento convencional, a abertura da ocorrência parte do CRM legado, referido como CATT, utilizado pelo call center e pelas agências. Esse sistema invoca o mesmo serviço de entrada dos canais digitais e, a partir daí, todo o processamento segue o fluxo já descrito, incluindo publicação de eventos, atuação dos microserviços de ocorrência técnica e persistência em banco de dados. O encerramento da comunicação também é realizado por meio do mesmo serviço de entrada.

Foi esclarecida a divisão interna do atendimento: a frente digital compreende o site, o aplicativo e o atendimento remoto, enquanto a frente convencional compreende as agências e o call center, sustentados pelo sistema legado. Da perspectiva do atendimento convencional, o serviço de entrada é o ponto de integração visível, e as demais etapas são tratadas como responsabilidade da cadeia posterior.

1.10.4.4. Retorno do ADMS e do DMS: incidente, pontos de entrega e trouble tickets

Uma ocorrência técnica não é representada por um objeto único. O adaptador do lado do ADMS e do DMS devolve três mensagens distintas, correspondentes ao serviço ou incidente, aos pontos de entrega afetados e aos trouble tickets associados.

• Um único serviço pode ter vários pontos de entrega de energia afetados.
• O mesmo incidente pode ter vários trouble tickets, que correspondem às reclamações registradas.
• Nem todo ponto afetado possui reclamação: existem clientes sem energia que não realizaram contato.
• O trouble ticket corresponde à comunicação registrada no atendimento e o incidente corresponde à ocorrência técnica reconhecida pelo sistema de operação.

O exemplo conceitual utilizado na sessão descreve dois vizinhos que registram reclamações e um terceiro que está sem energia e não fez contato. O resultado é um único incidente com três pontos de entrega e dois trouble tickets. A separação em três mensagens foi adotada justamente porque o modelo anterior, com objeto único, tornava-se excessivamente grande em casos extremos, chegando a incidentes com dezenas de milhares de unidades consumidoras afetadas.

Evolução já realizada e limite remanescente A quebra do objeto único em três mensagens foi apresentada como uma melhoria já entregue, que reduziu de forma significativa um problema anterior de tamanho de payload. O limite remanescente é que o conteúdo continua sendo consolidado no Sigode: quando chega uma alteração, o microserviço precisa consultar a base do Sigode para reconstruir a lista de clientes afetados, o que mantém a dependência de uma representação intermediária do estado.

1.10.4.5. Camada do Sigode e republicação por estado

O Sigode é um sistema desenvolvido internamente na Energisa, com base MongoDB. Ao receber cada uma das mensagens produzidas pelo ADMS e pelo DMS, ele executa processamento, persiste o conteúdo em sua base, complementa as informações e gera uma mensagem correspondente no Kafka. As mensagens chegam em sequência: primeiro o incidente, depois os pontos afetados e depois os trouble tickets, cada uma gerando uma publicação própria.

Do lado da publicação, o Sigode mantém um tópico mais amplo de ordem de serviço, que carrega uma coluna de status indicando o estado de cada registro. A partir dele, o próprio Sigode agrega e republica o conteúdo em tópicos específicos, destinados ao consumo dos demais sistemas. Foram citados sete tópicos correspondentes a estados ou situações da ocorrência: criado, despachado, encerrado, cancelado, arquivado, chamada e afetado.

Dentro de cada tópico, a estrutura da mensagem é a mesma. O que distingue um tópico do outro é o estado que ele representa. Foi registrado que o Sigode também realiza composição de informações da qual alguns consumidores dependem, o que precisa ser considerado em qualquer proposta de simplificação do fluxo.

1.10.4.6. Encaminhamento ao WFM e ciclo das ordens de serviço

Após a formação dos eventos técnicos, as informações seguem para o WFM, responsável por consolidar os dados e criar as ordens de serviço para execução em campo. Foram mencionados diversos tipos de evento emitidos pelo WFM, entre eles serviço criado, ordem de serviço criada, serviço atualizado, ordem de serviço baixada, mudança de status, conclusão de atividade e cancelamento.

Um componente de integração consome eventos de várias filas do WFM e os transforma em dois tópicos consumidos tanto pelos canais digitais quanto pelo atendimento convencional: um de ordem de serviço e um de clientes afetados. Esse componente existe em grande medida para filtrar conteúdo: o evento de serviço criado do WFM traz muita informação irrelevante para o atendimento e dispara gatilhos em situações que não interessam aos canais, que precisam apenas do que se origina no ADMS e no DMS.

• A fila de clientes afetados é uma das de maior movimentação do conjunto, porque um único incidente é decomposto em uma mensagem por ponto de entrega, podendo gerar de poucas a dezenas ou centenas de mensagens.
• Para dar vazão a esse volume, o tópico correspondente opera com 60 partições.
• O WFM também recebe ordens de serviço de natureza comercial e originadas em sistemas legados. Nesses casos, é utilizada captura de dados alterados sobre a base legada e o evento chega ao mesmo tópico de ordem de serviço criada, distinguido por um campo de tipo de serviço.
• Não toda ordem de serviço é executada pelo Sigode ou pelo WFM. Troca de titularidade, alteração cadastral simples e mudança de dados de contato permanecem no domínio comercial. Tudo o que exige deslocamento físico a campo passa pelo WFM.
• Toda ordem de serviço nasce em uma etapa administrativa no atendimento, seja no call center, seja no atendimento remoto.

1.10.4.7. Comunicação ao cliente e sincronização de status

O microserviço de comunicação é o componente responsável por manter o ADMS e o CRM no mesmo estado lógico. O status registrado na ocorrência do lado técnico deve refletir-se no CRM, para que o atendimento e os canais digitais informem ao cliente a situação correta.

O microserviço de filtro de incidentes consome os sete tópicos publicados pelo Sigode e, conforme o conteúdo recebido, alimenta as filas de comunicação do CRM, de comunicação de desligamento emergencial e de ordem de serviço. Cada trouble ticket contido no incidente gera uma mensagem na fila de comunicação, e existe fluxo equivalente para clientes afetados, que carrega o ponto de entrega. Entre a chamada e o registro existe um processamento intermediário que já converte parte das informações para o formato esperado pelo DMS.

A qualidade dessa sincronização depende diretamente da semântica dos eventos, da ordem de processamento, das regras de transição de estado admitidas e do tratamento de duplicidades, temas tratados nos itens seguintes.

1.10.5. Modelagem de eventos, tópicos e estados

1.10.5.1. Desenho atual

O desenho vigente distribui os estados de uma mesma ocorrência em tópicos distintos. A identidade do estado é dada pelo tópico de origem, e não por um atributo da mensagem, uma vez que a estrutura do payload é semelhante entre eles. O consumidor atualiza o CRM conforme o evento que recebe, e existe algum controle de estado no próprio filtro, que evita, por exemplo, republicar a mensagem de criação quando a ocorrência já está cancelada.

1.10.5.2. Risco de ordenação e de regressão de estado

Ao distribuir estados correlacionados em tópicos diferentes, não há garantia natural de ordem global entre eles. Um consumidor pode receber um evento de arquivamento ou de cancelamento antes do evento de criação, em função de atrasos, distribuição por partições, novas tentativas ou reprocessamento. A resposta de que o CRM simplesmente atualiza conforme o evento recebido não elimina o risco de regressão de estado nem de transição inválida, porque o consumidor não possui uma referência de ordem própria da entidade.

1.10.5.3. Falha no status cancelado

A dor mais concreta registrada nas sessões está no tratamento do cancelamento. Diversas ocorrências aparecem como canceladas no CRM legado e não conseguem assumir outro status posteriormente, porque a regra vigente torna o cancelamento terminal. O time já havia identificado e registrado a falha e indicou que a correção deve ocorrer no microserviço de comunicação, e não no filtro de incidentes.

O cancelamento bloqueia transições posteriores da ocorrência.	Status incorreto ou congelado no CRM e informação divergente ao cliente.	Regra de estado terminal implementada no microserviço de comunicação.	Revisar a máquina de estados, admitir transições válidas ou eventos compensatórios e testar cenários de replay.

1.10.5.4. Proposta de organização por agregado

A alternativa discutida organiza os eventos por agregado ou entidade de domínio, e não por estado. Em lugar de um tópico para cada situação, existiria um tópico de ocorrência ou incidente, com o estado expresso como tipo de evento.

• Tópico por entidade: ocorrência ou incidente, em lugar de um tópico por estado.
• Tipo de evento indicando o fato ocorrido, como criação, despacho, cancelamento ou arquivamento.
• Chave de partição pelo identificador da ocorrência, garantindo ordenação por entidade dentro do tópico.
• Regra de consumo capaz de ignorar eventos obsoletos, duplicados ou incompatíveis com a máquina de estados.
• Resultado esperado: menor número de tópicos, maior coerência semântica e ordenação garantida por agregado.

Os participantes das duas áreas consideraram a reestruturação adequada ao cenário, ressalvando que a decisão não pertence a elas.

1.10.5.5. Dependência do time responsável pela publicação

A avaliação definitiva depende do time do Sigode, responsável pela publicação e pela segregação dos eventos. Foi acordada uma sessão específica com essa equipe para esclarecer por que o desenho foi implementado dessa forma, quais consumidores existem para cada tópico, quais requisitos históricos motivaram a decisão e quais restrições impedem ou permitem a reestruturação.

1.10.5.6. Tópicos de ponte e adequação tecnológica

Um segundo padrão observado é a existência de tópicos cujo nome descreve a rota técnica entre dois sistemas, e não um fato de domínio. O caso analisado foi o tópico de atualização de cliente entre o CRM e o ADMS, para o qual os participantes indicaram não haver outros assinantes além do componente de destino. Nessa configuração, o barramento cumpre apenas papel de desacoplamento técnico e de resiliência, protegendo o consumidor de sobrecarga e de indisponibilidade temporária, função que poderia ser atendida por uma fila mais simples.

Número de consumidores	Múltiplos e independentes	Um ou poucos consumidores	Um destino imediato
Retenção e replay	Requisito relevante	Possível, porém não é o objetivo principal	Não aplicável
Semântica	Fato de domínio reutilizável	Comando ou fila técnica	Operação de requisição e resposta
Comunicação ponto a ponto	Evitar tópicos que funcionem como ponte	Adequado	Adequado quando a criticidade é baixa
Custo operacional	Mais elevado	Menor ou moderado	Menor, porém com acoplamento temporal
Uso indicado na discussão	Eventos entre domínios distintos	Resiliência interna e comunicação específica	Chamadas simples com tempo limite e disjuntor

Foram citadas como alternativas para as filas puramente técnicas o RabbitMQ e o mecanismo de filas já disponível no ecossistema utilizado pelos times, sem decisão definitiva. A avaliação dependerá do inventário de tópicos, produtores e consumidores.

Oportunidade identificada pelo próprio time Ao discutir o tópico de atualização de cliente, a área de canais digitais identificou uma oportunidade concreta: se existisse um tópico geral de cliente, com todos os tipos de atualização, os canais digitais poderiam consumi-lo diretamente para manter suas próprias bases atualizadas. Isso permitiria eliminar diversos serviços que hoje consultam periodicamente a base legada apenas para alimentar cópias locais destinadas a acelerar respostas. A troca de um tópico de rota por um fato de domínio reutilizável reduziria, ao mesmo tempo, o número de tópicos, o volume de consultas ao legado e a quantidade de componentes de cache a manter.

1.10.5.7. Contratos, esquemas e envelope de eventos

Sobre a governança dos contratos, foi informado que o Schema Registry é utilizado em parte dos casos. Em outros fluxos, o objeto já possui classe definida no código, mas não existe contrato formal gerenciado de forma centralizada. Foi registrado que, nesses casos, a geração do esquema seria um passo relativamente pequeno, dado que a estrutura já está tipada na aplicação.

A ausência de contrato formal em parte dos eventos cria risco de produtores e consumidores operando em versões diferentes, de alterações incompatíveis e de campos interpretados de maneira distinta entre times. Para padronizar, foi discutido o uso de um envelope canônico para todos os eventos críticos.

Identificador do evento	Identificar unicamente cada emissão	Deve permanecer o mesmo em novas tentativas do mesmo evento
Identificador do agregado	Identificar a ocorrência, o cliente ou a ordem de serviço	Utilizado como chave de partição e de correlação
Tipo do evento	Descrever o fato ocorrido	Substitui a prática de expressar o estado pelo nome do tópico
Momento do fato	Registrar quando o fato ocorreu	Distinto do momento de publicação e do momento de processamento
Identificador de correlação	Ligar todos os eventos de uma mesma jornada	Deve ser criado na entrada e propagado até o fim da cadeia
Identificador de causalidade	Relacionar o evento derivado ao evento que o originou	Permite reconstruir a árvore de eventos de um incidente
Versão do esquema	Controlar a evolução do contrato	Necessário para compatibilidade e migração de consumidores
Identificador da empresa	Distinguir a distribuidora de origem	Já trafega hoje no cabeçalho e no corpo da mensagem

1.10.6. Consistência transacional: dual write, Outbox e captura de dados alterados

1.10.6.1. Identificação do dual write

Ao percorrer o funcionamento do Sigode, foi identificado um padrão de dual write: o serviço atualiza sua base e, em seguida, publica um evento no Kafka como duas operações independentes. Como as duas tecnologias não compartilham, por padrão, uma única transação, a confirmação de uma não garante a confirmação da outra. Foi confirmado que esse mesmo risco já havia sido apontado anteriormente a outros times da Energisa, incluindo o time do WFM.

1.10.6.2. Cenários de falha

1. O banco confirma a gravação e a publicação no Kafka falha: a informação permanece registrada na origem, os consumidores não recebem a mudança e o estado fica inconsistente entre sistemas.

2. O evento é publicado e a gravação no banco falha: os consumidores processam uma informação que não existe na origem.

3. A nova tentativa gera duplicidade: o serviço não sabe com segurança se a publicação foi aceita, repete a operação e consumidores não idempotentes podem duplicar efeitos.

4. Os commits ocorrem em momentos diferentes: uma falha entre as duas operações não pode ser revertida por rollback distribuído simples.

1.10.6.3. Mitigação já aplicada em um dos serviços

No microserviço de ocorrência técnica dos canais digitais existe uma mitigação relevante: a comunicação é gravada no banco e enfileirada no Kafka, mas a confirmação no banco ocorre somente depois da confirmação do barramento. Essa inversão reduz a janela de inconsistência e o time relata não ter enfrentado o problema nesse ponto. A mitigação não elimina, porém, todos os cenários, porque a falha pode ocorrer entre a confirmação do Kafka e a confirmação do banco, e o padrão não está aplicado de forma uniforme nos demais serviços da cadeia.

1.10.6.4. Padrão Transactional Outbox

A alternativa discutida em detalhe foi o padrão Transactional Outbox. Em lugar de gravar no banco e publicar no barramento como operações independentes, o serviço grava, na mesma transação, o dado de negócio e um registro representando o evento a publicar.

1. O dado de negócio é gravado na coleção ou tabela da entidade, por exemplo o incidente.

2. O payload do evento é gravado em uma coleção ou tabela de outbox, no mesmo commit.

3. Após a confirmação da transação, um processo separado lê a outbox e publica o evento no Kafka.

4. O registro é marcado como enviado e, em caso de falha, é submetido a nova tentativa.

5. Após determinado número de tentativas, o evento é encaminhado para tratamento específico em fila de mensagens não processadas.

Foram discutidas as duas aplicações pertinentes ao ambiente. Em MongoDB, seriam mantidas uma coleção de incidentes e uma coleção de eventos a publicar, com atualização na mesma unidade transacional e, na sequência, leitura por polling ou por captura de dados alterados sobre a coleção de outbox. Em Oracle, seriam utilizadas a tabela da entidade e a tabela de outbox no mesmo commit, com a alternativa de empregar o mecanismo nativo de filas do próprio banco, desde que participe da mesma unidade transacional.

Consistência entre o dado e o evento na mesma unidade transacional	Identificador único por evento
Possibilidade de reprocessamento e de replay controlado	Consumidores idempotentes
Auditoria dos eventos produzidos e controle de tentativas	Política de novas tentativas e tratamento de mensagens problemáticas
Identificação objetiva de eventos pendentes de publicação	Retenção e expurgo da outbox
Redução de falhas silenciosas e separação entre persistência e publicação	Monitoramento de pendências e ordenação por entidade

Foi mencionado que um profissional da Energisa vinha avaliando uma biblioteca do ecossistema .NET que facilita a implantação do padrão, cujo nome deverá ser recuperado e registrado.

1.10.6.5. Captura de dados alterados e alternativas de streaming

A captura de dados alterados foi reconhecida como alternativa que reduz o risco de dual write, porque o evento passa a derivar de uma alteração já confirmada no banco. O mecanismo já é utilizado no ambiente para as ordens de serviço comerciais e originadas em sistemas legados, que chegam ao tópico de ordem de serviço criada por essa via.

• Foi esclarecido que o fluxo do ADMS e do DMS apresentado nas sessões não utiliza captura de dados sobre a base do Sigode: a publicação é feita pelo próprio serviço a partir do conteúdo recebido.
• Foram citadas ferramentas de captura sobre bases Oracle, entre elas o GoldenGate, como referência de mecanismo capaz de encaminhar alterações a um fluxo de eventos.
• O KSQLDB já é utilizado para processamento de streaming e há intenção declarada de adotar Apache Flink em etapa posterior, para junções de fluxos, agregações, janelas temporais, deduplicação e enriquecimento.
• A aplicação preferencial da captura de dados alterados, quando combinada ao padrão Outbox, é sobre a tabela de outbox, e não sobre a tabela de negócio.

1.10.6.6. Falhas silenciosas e replay

A discussão convergiu para a natureza do risco. O problema não é apenas a possibilidade de perda de uma atualização, mas o fato de que essa perda tende a ser silenciosa: não gera erro evidente ao usuário, não interrompe o processamento e só é percebida por uma consequência operacional posterior. Quando isso ocorre, a reconstrução dos fatos e o replay tornam-se mais difíceis, exatamente no momento em que o volume é maior.

Caso concreto registrado nas sessões Uma ocorrência foi cancelada no DMS e o cancelamento não chegou ao Sigode. Como consequência, o evento de cancelamento não foi produzido para os demais consumidores, os sistemas de atendimento não receberam a atualização e foi necessário executar carga manual de dados para restabelecer a consistência. Foi relatado que não é possível mapear todos os casos em que isso ocorreu. Este é o exemplo mais direto do encadeamento entre ausência de fonte única da verdade, dual write e falha silenciosa, e é o argumento central para a adoção do padrão transacional.

1.10.7. Idempotência, replay e deduplicação

1.10.7.1. Tratamento atual identificado

Ambas as áreas afirmaram tratar duplicidades, com abordagens complementares. A atualização em MongoDB é executada como operação de atualização ou inserção conforme a existência do registro, o que a torna naturalmente tolerante à repetição. Para o disparo de comunicação proativa ao cliente existe um controle adicional em código, que registra até que ponto a ocorrência avançou: se um evento de criação chega novamente, nenhum disparo é gerado; quando chega o evento de execução, a mensagem correspondente é enviada e o controle é atualizado.

• O controle abrange mais do que a mudança de status. Foram citadas condições como alteração da data prevista, mudança de status da equipe e alterações no incidente, cada uma podendo ou não gerar comunicação.
• Foi mencionado que um dos tópicos possui um código único de mensagem, mas o controle efetivamente aplicado pelo consumidor não se baseia nele.
• No lado do atendimento convencional, foi informado que existem tratativas em andamento para problemas identificados no CRM legado, cujo detalhamento ficou pendente de uma rodada adicional com os analistas responsáveis pelos microserviços.
• Não foi possível confirmar, nas sessões, se existe identificador único de evento no envelope, hash de payload, chave natural ou tabela de inbox como mecanismo formal de deduplicação.

1.10.7.2. Custo do mecanismo atual

Um ponto que começou como curiosidade técnica passou a integrar o diagnóstico: um controle que depende de consultar e gravar no banco a cada mensagem, inclusive quando ela é duplicada, consome um recurso caro. Sob alto volume, isso se traduz em operações de entrada e saída desnecessárias, contenção e custo de infraestrutura. A própria área de canais digitais associou esse efeito à percepção já relatada de que o ambiente processa muitas mensagens sem necessidade.

1.10.7.3. Mecanismo recomendado

• Adotar identificador único de evento no envelope, mantido inalterado em novas tentativas do mesmo fato.
• Registrar no consumidor os identificadores já processados, por tabela de inbox ou por chave de idempotência, evitando reprocessamento antes de qualquer gravação de negócio.
• Descartar duplicidades o mais cedo possível na cadeia, de preferência sem acesso ao banco de dados de negócio.
• Documentar, por consumidor crítico, qual é o mecanismo, qual é a chave utilizada e qual é a evidência de teste.
• Incluir cenários de replay e de reenvio nos testes, verificando ausência de efeito duplicado em comunicação ao cliente, criação de ordens e atualização de status.

1.10.8. Correlação e rastreabilidade ponta a ponta

Existe correlação, mas não existe um identificador único propagado de maneira uniforme por todas as etapas. Foi confirmado o uso de identificador de correlação em parte dos pontos, inclusive na publicação de mensagens de erro, que carregam a etapa em que o problema ocorreu, a identificação da comunicação, o tipo de tentativa e o motivo da falha.

O limite aparece na fronteira com o sistema técnico. O DMS gera seu próprio identificador de correlação e não devolve o mesmo identificador para o incidente e para o trouble ticket, ainda que as duas entidades estejam relacionadas. Na prática, a correlação é reconstruída por chaves de negócio.

• Número da comunicação, utilizado como referência principal do lado do atendimento.
• Identificador do trouble ticket, que corresponde à comunicação aberta no atendimento.
• Identificador do incidente no DMS, que corresponde à ocorrência técnica.
• Código do cliente e código do ponto de entrega, que identificam de forma única o local que recebe energia e existem tanto no DMS quanto nas bases do atendimento.
• Chaves internas das tabelas e dos documentos de cada sistema.

O modelo funciona, e o próprio time reconheceu que o desenho correto seria criar o identificador de correlação já na entrada da requisição, no serviço de abertura, e propagá-lo até o final da cadeia. A recomendação decorrente é estabelecer identificador de correlação global, identificador de causalidade para os eventos derivados e identificador único por evento, com propagação obrigatória, registro em log e consulta centralizada da trilha completa.

1.10.9. Volumetria, granularidade e mensagens desnecessárias

A principal dor apresentada pela área de canais digitais é a desproporção entre o volume de mensagens produzidas e o volume real de ocorrências, sobretudo no fluxo de desligamento emergencial. Foi relatado que, mesmo em períodos com poucos incidentes, determinados tópicos crescem rapidamente e acumulam vários gigabytes. Na data da sessão, o volume observado estava abaixo do usual porque o DMS encontrava-se em manutenção, o que reforça a necessidade de medir o comportamento em produção.

Republicação de objetos completos a cada alteração	Aumento do custo de infraestrutura e do armazenamento
Consolidação no Sigode e posterior separação por ponto de entrega	Maior latência e necessidade de mais consumidores
Eventos com granularidade muito fina e repetição de dados	Reprocessamento e replay mais demorados
Informação irrelevante trazida dos eventos do WFM e gatilhos disparados por alterações que não interessam ao atendimento	Dificuldade de monitoramento e de identificação do que é relevante
Ausência de filtro na origem e de distinção entre snapshot e evento de mudança	Risco de saturação de filas e de atraso nos eventos efetivamente críticos

A direção discutida pela própria área é simplificar o fluxo: passar a ler diretamente do ADMS e do DMS em lugar de depender da republicação pelo Sigode, reproduzindo em processamento de streaming as regras de composição hoje mantidas naquele componente. O ganho esperado é duplo: reduzir o volume de mensagens intermediárias e eliminar um ponto de falha da cadeia. A contrapartida, registrada na própria sessão, é que parte da composição realizada pelo Sigode é necessária aos consumidores e precisaria ser reimplementada sem perda funcional.

1.10.10. Arquitetura multiempresa e escalabilidade

A solução atende hoje três empresas com OMS implantado, com a quarta implantação em curso, e foi construída considerando o alcance de nove empresas. As mensagens trafegam por tópicos compartilhados, com a identificação da empresa presente tanto no cabeçalho quanto no corpo da mensagem, e o consumidor utiliza esse identificador para separar e processar os dados de cada distribuidora.

Do ponto de vista funcional, o modelo foi considerado preparado para a expansão. A preocupação declarada é de vazão: a passagem de três para seis ou nove empresas pode exigir redimensionamento dos consumidores e revisão da estratégia de partições. Os pontos a endereçar antes do crescimento são:

• Redimensionamento de consumidores e revisão do número de partições por tópico.
• Critério explícito para tópico compartilhado, tópico por empresa ou partição por empresa.
• Limites de consumo, prioridade e isolamento de falhas entre empresas.
• Monitoramento individualizado por empresa, e não apenas por tópico.
• Política de capacidade que acompanhe o cronograma de implantação das novas distribuidoras.

Padrão a revisar antes da expansão Foi apontado pela própria área de canais digitais que a arquitetura reúne, em determinado ponto, informações de várias empresas para depois separá-las novamente, quando o conteúdo já chega com o detalhe do ponto de entrega. A sugestão levantada é encaminhar os eventos diretamente aos tópicos de destino, eliminando a etapa de agregação e posterior separação. Trata-se de uma ineficiência que hoje é absorvida pela infraestrutura e que tende a ficar mais custosa com a entrada das próximas empresas.

1.10.11. Atualização cadastral de clientes e instalações no DMS

A segunda sessão detalhou a cadeia responsável por levar clientes e instalações ao DMS, reconhecida pela própria área como o ponto de partida de qualquer implantação em nova empresa.

1.10.11.1. Componentes envolvidos

• Monitor de instalação, responsável por identificar os registros de instalação pendentes de envio e publicar o evento de atualização.
• Microserviço de cliente, que consome a fila de atualização, participa do cálculo das potências e da atualização do cliente no DMS.
• Microserviço de cliente em formato CSV, que gera os arquivos destinados ao DMS.
• Microserviço de atualização de potência, dedicado à atualização das potências ativa e reativa.
• Serviço legado desenvolvido em PowerBuilder, responsável pela troca do indicador de transferência e pela efetivação da transmissão.

1.10.11.2. Modo incremental e indicador de transferência

1. Uma ordem de serviço altera dados da instalação ou do cliente.

2. O serviço legado em PowerBuilder altera o indicador de transferência para o DMS, marcando o registro como pendente.

3. O monitor de instalação consulta a base, obtém as instalações pendentes e processa a alteração.

4. O monitor publica o evento de atualização de cliente no tópico correspondente do Kafka.

5. O microserviço de cliente consome o evento e conduz a atualização no DMS.

Uma instalação pendente pode corresponder a naturezas bastante diferentes. Pode ser uma alteração cadastral simples, como nome, razão social ou endereço eletrônico, e pode ser uma alteração técnica que exija atividade de campo, como substituição de equipamento ou mudança de transformador. Foi registrado que nem toda ordem de serviço é executada pelo Sigode ou pelo WFM: parte permanece no domínio comercial e do atendimento.

1.10.11.3. Modo de carga completa

Além do modo incremental, existe a carga completa, utilizada normalmente na implantação do ADMS em uma nova empresa. Nesse modo, o conjunto de clientes e instalações é carregado integralmente, enquanto o modo incremental processa apenas os registros marcados como pendentes. A convivência dos dois modos é intencional e acompanha o calendário de implantação das distribuidoras.

1.10.11.4. Cálculo de potências e transferência por arquivo

O microserviço de cliente participa do cálculo das potências ativa e reativa, referidas como P e Q, e da atualização do cadastro no DMS. O fluxo inclui também a geração de arquivos em formato CSV, depositados em pasta de transferência de arquivos para envio ao DMS, além de persistência em MongoDB e de um serviço específico dedicado à atualização das potências. A coexistência de integração por evento e de transferência por arquivo no mesmo fluxo cadastral é um ponto a validar no mapeamento ponta a ponta.

1.10.11.5. Ciclo de status da ordem de serviço cadastral

Foram citados os status pelos quais a ordem de serviço cadastral transita: aberta, criticada, executada e transferida. A efetivação da transmissão pelo serviço legado é o que marca o registro como transferido, e o encerramento do ciclo devolve ao atendimento a informação de situação que será comunicada ao cliente.

1.10.11.6. Natureza do tópico de atualização de cliente

Ao ser questionado se o tópico de atualização de cliente possui outros assinantes, o time indicou que se trata, na percepção atual, de comunicação ponto a ponto entre dois componentes, cuja finalidade é desacoplamento técnico e resiliência. Essa constatação originou a discussão de adequação tecnológica registrada no item 1.10.5.6 e a oportunidade de transformá-lo em um tópico geral de cliente, com tipos de evento, capaz de alimentar outros domínios.

1.10.12. Desligamento emergencial e desligamento programado

O fluxo de desligamento emergencial foi identificado como dor na primeira sessão e detalhado na segunda.

1. O microserviço de filtro de incidentes consome as filas publicadas pelo Sigode.

2. O filtro publica no tópico de cliente afetado por desligamento emergencial.

3. O microserviço de desligamento emergencial consome esse tópico e atualiza o incidente.

4. A alteração de status é persistida e refletida na tela do CRM, para que o atendimento apresente a situação corrente ao cliente.

5. No lado dos canais digitais, a mesma atualização é gravada em MongoDB em lugar da base Oracle, e pode acionar o envio de comunicação proativa ao cliente.

Foi reforçado que o controle associado ao disparo de comunicação considera mais do que a mudança de status, incluindo alteração da data prevista, mudança de status da equipe e alterações no incidente. Esse é o mesmo controle descrito no item 1.10.7.1 e o ponto em que idempotência e regra de negócio se sobrepõem.

O fluxo de desligamento programado não foi detalhado. Foi informado que ele existe, é mais simples que o emergencial, tem ponto de entrada distinto e converge para a mesma cadeia a partir dos microserviços de ocorrência. As duas áreas acordaram apresentá-lo em conjunto em sessão posterior, juntamente com os fluxos ainda não percorridos.

1.10.13. Domínios, linguagem ubíqua e camada anticorrupção

1.10.13.1. Fronteiras de domínio observadas

A discussão buscou distinguir o domínio de relacionamento com o cliente do domínio de instalação, ordem de serviço, manutenção e execução de campo. O caso analisado foi o monitor de instalação: seu nome e parte de seu comportamento sugerem um componente técnico, mas ele parte de uma alteração de dados do cliente e devolve ao atendimento a informação de status. Os participantes o posicionaram no domínio de relacionamento com o cliente, justamente porque a origem do fluxo é cadastral. A sobreposição indica fronteiras pouco explícitas, e não necessariamente um posicionamento incorreto.

1.10.13.2. Requisição de serviço, caso e ordem de serviço

O conjunto foi comparado a um fluxo de requisição de serviço: o atendimento registra uma solicitação, encaminha às áreas executoras, acompanha o status e devolve a informação ao cliente. No CRM, esse objeto corresponderia a um caso de atendimento; no domínio operacional, a uma ordem de serviço. Tratar os dois como o mesmo objeto, ou propagar diretamente a linguagem da ordem de serviço para o CRM, cria acoplamento semântico entre domínios que possuem vocabulários e ciclos de vida distintos.

1.10.13.3. Acoplamento funcional apesar do barramento

Foi explicitado o limite do desacoplamento obtido pelo Kafka. O barramento desacopla disponibilidade e desempenho: o produtor continua publicando mesmo quando o consumidor está indisponível, e o acúmulo é processado depois, o que aumenta a resiliência do ambiente. Entretanto, se o payload carrega o modelo, os jargões e as regras internas de outro domínio, o acoplamento funcional permanece. Mudanças no produtor continuam propagando impacto aos consumidores, ainda que a comunicação seja assíncrona, e a substituição de um componente volta a ser um problema de várias equipes.

1.10.13.4. Camada anticorrupção

A recomendação decorrente é introduzir camada anticorrupção nos limites entre domínios. Ela consome o evento do domínio produtor, traduz os conceitos e entrega ao domínio consumidor um modelo próprio.

• Mapear entidade e vocabulário de origem para entidade e vocabulário de destino.
• Isolar códigos de produto, status legados e estruturas de banco em adaptadores dedicados.
• Manter o modelo interno do domínio consumidor independente do contrato externo.
• Versionar e testar as transformações de contrato como parte da integração.
• Concentrar no adaptador a absorção de mudanças na linguagem do produtor, preservando os componentes de domínio.

Os limites candidatos identificados nas sessões são três: entre o atendimento e o CRM e o domínio de ordem de serviço; entre cliente e instalação e a operação de campo; e entre o ecossistema do ADMS e do DMS e os sistemas de atendimento.

1.10.14. Legado, CRM proprietário e acoplamento de bases

1.10.14.1. Natureza do CRM do atendimento

O CRM utilizado pelo call center e pelas agências é um sistema interno, desenvolvido pela própria Energisa em PowerBuilder. Foi confirmado que ele não disponibiliza serviços ou interfaces de integração. Em consequência, os microserviços do atendimento atualizam diretamente a base de dados desse sistema, cuja versão de Oracle foi informada como 19. Foi registrado também que outros microserviços e outros sistemas persistem diretamente nessa mesma base.

A modernização do CRM não está no escopo do projeto ADMS. Ela pertence à frente dos canais convencionais e é conduzida por outra equipe, com a responsável atual pelo sistema presente na segunda sessão.

1.10.14.2. Dimensão do acoplamento no ambiente

Foi estimado que cerca de noventa por cento do ambiente permanece legado. As bases Oracle desses sistemas estão fortemente acopladas entre si, com uso histórico de ligações diretas entre bancos e de visões que atravessam fronteiras de sistema, prática que era considerada adequada quando as integrações foram construídas. Foi citado como referência o caso do WFM em modernização: criou-se uma base apartada e uma estrutura nova de microserviços, mas ainda é necessário replicar dados para tabelas legadas, porque atendimento, faturamento e outros sistemas utilizavam as mesmas tabelas.

A estratégia declarada para lidar com esse cenário é o estrangulamento progressivo do legado, com substituição gradual das funcionalidades e manutenção temporária das estruturas compartilhadas.

1.10.14.3. Consequência para a modernização

A consequência arquitetural é direta. Se vários sistemas de domínios distintos permanecem conectados diretamente à base do CRM, todos passam a fazer parte de qualquer projeto de substituição desse CRM. Encapsular a base com serviços de dados ou com microserviços funcionais permitiria que os demais domínios deixassem de depender do modelo físico e da forma como as estruturas foram criadas internamente. Nesse arranjo, a troca do sistema manteria os serviços como fachada, e a substituição dos serviços poderia ocorrer depois, de forma incremental.

Impacto no escopo do assessment O acoplamento entre bases é uma restrição que condiciona as recomendações desta ata. Propostas como evento por domínio, camada anticorrupção, redução de tópicos e leitura direta a partir do ADMS e do DMS pressupõem que produtores e consumidores possam evoluir de forma independente. Enquanto parte relevante deles continuar lendo e gravando em bases legadas compartilhadas, o ganho de qualquer uma dessas medidas será parcial. O sequenciamento entre modernização das bases e reestruturação dos eventos precisa, portanto, ser tratado como decisão de arquitetura, e não como consequência de projetos independentes.

1.10.15. Observabilidade e tratamento de falhas

Existem mecanismos de log e de acompanhamento, incluindo a publicação de mensagens de erro. Nos casos de falha, são produzidas informações contendo a etapa em que o problema ocorreu, a identificação da comunicação, o tipo de tentativa e o motivo da falha, o que permite diagnóstico pontual.

As lacunas identificadas são de uniformidade e de alcance funcional, mais do que de instrumentação:

• A observabilidade não é uniforme entre os microserviços da cadeia.
• Não foi evidenciada trilha única capaz de acompanhar uma ocorrência do canal até a comunicação ao cliente.
• Falhas silenciosas não geram alerta e são percebidas por consequência operacional.
• Não foram evidenciadas, nas sessões, política formal de novas tentativas nem uso de fila de mensagens não processadas nos fluxos apresentados.
• Não há medição consolidada de volumetria, de tamanho de payload e de duplicidade por tópico.

O modelo mínimo recomendado correlaciona logs, métricas e rastreamento por identificador de correlação, com visão por jornada de negócio, e não apenas por componente. Isso inclui painéis por tópico e por consumidor com atraso de consumo, taxa de erro e reprocessamento; alerta para pendências de publicação quando o padrão Outbox for adotado; e indicadores funcionais, como divergência de status entre o sistema técnico e o CRM.

1.10.16. Achados consolidados

Tópico por estado da ocorrência	Sete tópicos representam estados da mesma entidade, com estrutura de mensagem equivalente.	Ausência de ordem entre estados e proliferação de tópicos.	Alta	Consolidar por agregado, com tipo de evento e chave de partição.
Cancelamento terminal no CRM	Ocorrências canceladas não assumem novo status no sistema legado.	Status incorreto perante o cliente e necessidade de correção manual.	Alta	Corrigir a máquina de estados no microserviço de comunicação e testar replay.
Dual write entre banco e barramento	Serviços gravam na base e publicam no Kafka como operações independentes.	Perda de atualização, duplicidade e falha silenciosa.	Alta	Aplicar Transactional Outbox ou captura de dados alterados sobre outbox.
Ausência de fonte única da verdade	Caso de cancelamento não propagado do DMS ao Sigode, com carga manual de dados.	Divergência entre sistemas sem detecção automática.	Alta	Definir sistema de registro por entidade e reduzir cópias do mesmo estado.
Idempotência pouco explícita	Controle descrito em código e por atualização em MongoDB, sem envelope confirmado.	Duplicidade de efeitos, custo de banco e disparos repetidos ao cliente.	Alta	Identificador de evento, inbox e testes de replay por consumidor crítico.
Volumetria desproporcional	Acúmulo de gigabytes em tópicos com poucos incidentes reais e fila com 60 partições.	Custo, latência e reprocessamento longo.	Alta	Medir volumetria, revisar granularidade e filtrar na origem.
Tópicos que funcionam como ponte	Tópico de atualização de cliente sem outros assinantes, usado para resiliência técnica.	Uso do barramento como fila técnica, com custo desnecessário.	Média	Classificar cada integração e avaliar fila tradicional ou chamada síncrona.
Acoplamento de linguagem entre domínios	Ordem de serviço, caso de atendimento, cliente e instalação atravessam fronteiras de domínio.	Mudanças no produtor propagam impacto funcional aos consumidores.	Alta	Criar camada anticorrupção e modelo canônico por domínio.
Contratos de evento parciais	Schema Registry em parte dos casos e classes definidas apenas em código nos demais.	Divergência de versões e alterações incompatíveis.	Média	Padronizar envelope e registrar contratos com teste de compatibilidade.
Gravação direta na base do CRM legado	Ausência de serviços no CRM e persistência direta por vários sistemas.	Modernização do CRM acoplada a múltiplos domínios.	Alta	Encapsular a base com serviços e mapear dependências.
Conhecimento distribuído entre times	Os apresentadores não detêm o desenho de publicação dos tópicos, mantido por outra equipe.	Decisões de arquitetura tomadas sem visão completa de produtores e consumidores.	Alta	Workshop com o time do Sigode e inventário de consumidores.
Visão de negócio ponta a ponta incompleta	Detalhamento técnico avançado sem a jornada completa do atendimento à comunicação.	Diagnóstico local sem dimensionamento do impacto de negócio.	Média	Sessão de fechamento com a jornada completa validada.

1.10.17. Decisões, entendimentos e encaminhamentos

1. A revisão abrange toda a integração ponta a ponta, e não apenas a camada de mensageria.

2. Os fluxos dos canais digitais e do atendimento convencional compartilham a maior parte dos componentes, sendo o CRM legado a única diferença relevante de entrada.

3. As sessões especializadas serão concluídas antes do fechamento da visão ponta a ponta de negócio, que será conduzida em encontro específico.

4. Será realizada sessão com o time responsável pelo Sigode para explicar o desenho atual de publicação e segregação dos tópicos, os consumidores existentes e as restrições de mudança.

5. A correção da regra que impede transição após o cancelamento será feita no microserviço de comunicação.

6. Idempotência e consumo duplicado passam a integrar formalmente o escopo do assessment, com atenção ao custo de operações em banco de dados.

7. O padrão Transactional Outbox foi reconhecido como estratégia adequada para os pontos de dual write, com investigação da biblioteca .NET mencionada.

8. A definição de fonte única da verdade é necessária, com o ADMS e o DMS como candidatos naturais para a informação técnica.

9. A avaliação de fila tradicional para comunicações puramente técnicas e ponto a ponto foi acolhida, sem decisão definitiva.

10. A camada anticorrupção entre domínios será considerada nas recomendações de arquitetura.

11. O fluxo de desligamento programado, os exemplos de payload e os esquemas dos eventos ficam para uma rodada adicional com os analistas responsáveis.

12. Serão agendadas sessões com o time do WFM, incluindo o profissional dedicado à modernização em eForce, e com as equipes de OpenShift, de infraestrutura e de telecom.

1.10.18. Recomendações técnicas consolidadas

1.10.18.1. Curto prazo: estabilização e visibilidade

• Corrigir e testar a regra de cancelamento, cobrindo transição posterior, compensação e replay.
• Inventariar tópicos, produtores, consumidores, chaves de partição, retenção, esquema e volume.
• Documentar a máquina de estados da ocorrência e da ordem de serviço, com as transições válidas.
• Confirmar e registrar o mecanismo de idempotência de cada consumidor crítico.
• Medir volumetria real por tópico, incluindo mensagens por incidente, tamanho médio e máximo de payload e atraso de consumo.
• Realizar o workshop com o time do Sigode e com os responsáveis pelos microserviços de comunicação.

1.10.18.2. Médio prazo: modelagem de eventos e contratos

• Definir envelope canônico de eventos, com identificador de evento, de agregado, tipo, momento do fato, origem, correlação, causalidade e versão de esquema.
• Consolidar tópicos de estado em tópicos de agregado, quando tecnicamente viável e sem quebra de compatibilidade.
• Padronizar os contratos no Schema Registry e automatizar testes de compatibilidade.
• Classificar cada fluxo como fato de domínio, comando, integração técnica ou sincronização de dados.
• Comparar barramento, fila tradicional e chamada síncrona por critérios objetivos de retenção, replay, número de consumidores, acordo de nível de serviço e custo.

1.10.18.3. Médio prazo: consistência e rastreabilidade

• Implantar Transactional Outbox nos pontos de dual write e inbox nos consumidores críticos.
• Criar identificador de correlação na entrada da requisição e propagá-lo por toda a cadeia, com registro em log.
• Implantar observabilidade ponta a ponta por jornada de negócio, com indicadores funcionais de divergência de status.
• Estabelecer política de replay, definindo o que pode ser reprocessado, como evitar duplicidade e como validar o resultado.
• Definir e documentar o sistema de registro de cada entidade: incidente, ponto afetado, reclamação, comunicação, cliente, instalação, ordem de serviço e cancelamento.

1.10.18.4. Médio e longo prazo: simplificação e desacoplamento

• Avaliar a leitura direta a partir do ADMS e do DMS, com processamento em streaming, reproduzindo sem perda as composições hoje realizadas pelo Sigode.
• Substituir tópicos de rota por fatos de domínio reutilizáveis, começando pela atualização de cliente.
• Reduzir os serviços que consultam periodicamente bases legadas para alimentar cópias locais.
• Encapsular a base do CRM legado com serviços de dados, como pré-condição da sua modernização.
• Introduzir camada anticorrupção nos limites entre atendimento, cliente e instalação e operação de campo.
• Construir o roadmap de estrangulamento das integrações baseadas em ligação direta entre bancos e visões compartilhadas.
• Preparar capacidade, partições e isolamento para o cenário multiempresa completo.

1.10.19. Plano de ação priorizado

1	Validar a nomenclatura oficial de sistemas, serviços e tópicos citados nas sessões	Canais digitais e atendimento convencional	Curto	Glossário validado, com nomes confirmados na documentação e no código
2	Corrigir a regra que impede transição após o cancelamento	Time do microserviço de comunicação	Curto	Correção entregue, com transições válidas testadas e sem regressão
3	Mapear os sete tópicos de ocorrência e a máquina de estados	Time do Sigode com apoio da integração	Curto	Mapa de eventos e transições, com estados, chaves e consumidores documentados
4	Auditar o mecanismo de idempotência por consumidor	Arquitetura e desenvolvimento	Curto	Matriz por consumidor, com mecanismo, chave e evidência de teste
5	Inventariar os tópicos do Kafka utilizados pelo atendimento	Plataforma de mensageria e times de sistema	Curto	Catálogo com produtor, consumidor, volume, retenção e criticidade
6	Medir volumetria, tamanho de payload e duplicidade em produção	Canais digitais e plataforma de mensageria	Curto	Relatório de volumetria por tópico, por incidente e por empresa
7	Classificar a adequação tecnológica de cada fluxo	Arquitetura	Médio, após o inventário	Matriz de decisão por fluxo entre barramento, fila e chamada síncrona
8	Especificar o envelope canônico e registrar os contratos	Arquitetura e times produtores	Médio	Envelope publicado e contratos registrados com teste de compatibilidade
9	Desenhar o mapa de domínios e as camadas anticorrupção	Arquitetura com as áreas de negócio	Médio	Mapa de contextos e contratos de tradução aprovados
10	Avaliar e prototipar o padrão Outbox nos pontos de dual write	Times de desenvolvimento com arquitetura	Médio	Prova de conceito em um fluxo, com métrica de pendências e replay validado
11	Detalhar o fluxo de desligamento programado e os fluxos remanescentes	Atendimento convencional e canais digitais	Próxima sessão	Diagrama e narrativa completos, com erros e tempos de resposta documentados
12	Consolidar a jornada de negócio ponta a ponta	Coordenação do assessment com as equipes	Após as sessões técnicas	Fluxo de negócio validado, do atendimento e da detecção de falha até a comunicação ao cliente

1.10.20. Questões em aberto para aprofundamento

1.10.20.1. Nomenclatura, artefatos e evidências

• Confirmar os nomes oficiais de todos os sistemas, serviços, microserviços e filas apresentados nos diagramas.
• Receber os desenhos de arquitetura utilizados nas duas sessões, incluindo a imagem do diagrama que não pôde ser exibida.
• Obter acesso à documentação da Wiki utilizada na apresentação do atendimento convencional.
• Identificar os tópicos do Kafka envolvidos em cada fluxo e obter exemplos de payload.
• Verificar quais eventos utilizam Schema Registry e quais possuem apenas classe definida em código.

1.10.20.2. Modelagem, contratos e consistência

• Quais são exatamente os sete tópicos de ocorrência e quais estados e transições cada um representa.
• Qual garantia de ordenação existe hoje entre estados publicados em tópicos diferentes.
• Qual é a máquina de estados oficial da ocorrência e quais transições são válidas após o cancelamento.
• Como o Sigode cria, segrega e publica os eventos, e quais requisitos motivaram o desenho atual.
• Quais consumidores existem para cada tópico e quais dependem de retenção histórica ou de replay.
• Como a idempotência é implementada em cada consumidor: identificador de evento, hash de payload, chave natural, controle em código ou tabela de inbox.
• Onde exatamente ocorre dual write na cadeia e se algum fluxo já utiliza o padrão Outbox.
• Qual biblioteca do ecossistema .NET foi avaliada para implantação do padrão Outbox.
• Se o processo de publicação a partir da base utiliza polling ou publicação direta pelo serviço.
• Quais fluxos utilizam captura de dados alterados e sobre quais bases.
• Como o mecanismo de correlação atual se comporta em cenários de reprocessamento.
• Se existe identificador de rastreamento ponta a ponta e onde ele é registrado.

1.10.20.3. Volumetria, capacidade e operação

• Medir o volume real de mensagens por minuto, por incidente e por empresa, em dias normais e em dias críticos.
• Medir o tamanho médio e máximo dos payloads e identificar duplicidades.
• Validar o número e a natureza das instâncias ou funções de processamento utilizadas para dar vazão ao fluxo do WFM.
• Verificar a estratégia de retenção e a política de replay por tópico.
• Avaliar a necessidade de segmentação por empresa e os critérios de quota, prioridade e isolamento.
• Identificar o volume de mensagens descartadas ou sem utilidade para os consumidores.
• Analisar a observabilidade atual e a existência de fila de mensagens não processadas.

1.10.20.4. Fluxos e domínios a completar

• Detalhar o fluxo de desligamento programado e o fluxo de cliente afetado correspondente.
• Concluir o detalhamento dos microserviços do atendimento convencional.
• Analisar o fluxo de cancelamento em todas as suas origens.
• Definir quais objetos pertencem aos domínios de cliente, instalação, atendimento, ordem de serviço e operação de campo.
• Identificar todos os sistemas que persistem diretamente na base do CRM legado.
• Mapear as integrações que utilizam ligação direta entre bancos e visões compartilhadas.
• Compreender como o fluxo de comunicação proativa se relaciona com as regras de negócio de cada canal.

1.10.21. Matriz de riscos

Perda silenciosa de atualização entre banco e barramento	Alta	Alto	Crítico	Transactional Outbox, monitoramento de pendências e conciliação periódica entre sistema técnico e CRM
Ocorrência congelada em status cancelado no CRM	Alta	Alto	Crítico	Correção da máquina de estados, testes de transição e verificação do passivo já existente
Regressão de estado por ausência de ordenação entre tópicos	Média	Alto	Alto	Tópico por agregado com chave de partição e descarte de eventos obsoletos no consumidor
Duplicidade de comunicação ao cliente por falta de idempotência formal	Média	Alto	Alto	Identificador de evento no envelope, inbox e testes de replay
Saturação de filas e consumidores com a entrada de novas empresas	Média	Alto	Alto	Medição de volumetria, revisão de partições, escala elástica de consumidores e política de capacidade
Custo crescente de infraestrutura por volume desnecessário de mensagens	Alta	Médio	Alto	Revisão de granularidade, filtro na origem e eliminação da consolidação seguida de separação
Bloqueio da modernização do CRM pelo acoplamento de bases	Alta	Alto	Crítico	Encapsulamento da base com serviços, mapa de dependências e roadmap de estrangulamento
Decisão de reestruturação de tópicos sem inventário de consumidores	Média	Alto	Alto	Inventário completo antes de qualquer mudança e transição com compatibilidade retroativa
Divergência de contrato entre produtores e consumidores	Média	Médio	Médio	Envelope canônico, Schema Registry e teste automatizado de compatibilidade

1.10.22. Conclusão do assessment destas sessões

As duas sessões cumpriram o objetivo de reconstruir a cadeia completa de uma ocorrência técnica e, mais do que isso, transformaram detalhes de implementação em hipóteses arquiteturais verificáveis. O ambiente apresentado possui desacoplamento técnico real, usa o barramento para absorver picos e permitir processamento paralelo e já incorporou melhorias relevantes, como a quebra do objeto único de incidente em três mensagens e a inversão da ordem de confirmação entre banco e barramento em um dos serviços.

Os três temas que concentram o risco são independentes da tecnologia adotada. O primeiro é a ausência de definição formal de fonte da verdade, que já produziu divergência corrigida manualmente. O segundo é a consistência entre o dado e o evento, hoje garantida por controle em código e sujeita a falhas silenciosas. O terceiro é a modelagem dos eventos, na qual tópicos representam estados e rotas técnicas em lugar de fatos de domínio, o que mantém acoplamento funcional e amplia o número de artefatos a governar.

Nenhuma dessas recomendações deve ser aplicada de forma genérica. A consolidação de tópicos depende de inventário de consumidores, de compatibilidade e de transição segura. A escolha entre barramento, fila tradicional e chamada síncrona depende de fatos verificáveis, como número de consumidores, necessidade de retenção e replay, volume, criticidade e propriedade do fluxo. O sequenciamento em relação à modernização das bases legadas é, por si, uma decisão de arquitetura, dado o acoplamento relatado.

O passo seguinte definido nas próprias sessões é duplo: aprofundar com o time responsável pela publicação dos eventos, para compreender a origem do desenho atual, e fechar a visão de negócio ponta a ponta, ligando atendimento, operação, força de trabalho e comunicação ao cliente. Com esses dois elementos, o assessment passa a poder propor a arquitetura de referência sem depender de inferência sobre requisitos históricos.

Anexo A · Registro cronológico revisado da sessão de 15 de julho de 2026

Registro cronológico revisado do conteúdo inteligível da sessão, com a marcação de tempo da gravação. A sequência temporal, as perguntas, respostas, hipóteses e conclusões foram preservadas. Saudações, repetições, problemas de conexão e de compartilhamento de tela, conversas paralelas e trechos corrompidos pelo reconhecimento automático de voz foram condensados ou omitidos. Termos técnicos capturados de forma imprecisa foram normalizados quando o contexto permitiu identificação segura.

00:00:06 Norberto: Contextualiza a origem da iniciativa: em reuniões anteriores, Érica recomendou uma revisão das integrações ponta a ponta do DMS, e a partir disso a Energisa buscou uma consultoria externa para obter um olhar independente. Registra que o interesse é compreender as integrações que envolvem o atendimento, conhecer as dores das áreas e receber propostas de solução.

00:01:18 Norberto: Apresenta os interlocutores: a área de canais digitais e a área de atendimento convencional, esta última com integrações legadas relevantes.

00:01:45 Lucas: Compartilha o desenho de arquitetura da abertura de ocorrência técnica e se compromete a enviar o material posteriormente.

00:02:06 Lucas: Informa que tanto os canais digitais quanto os convencionais utilizam o mesmo sistema para a abertura no sistema técnico.

00:02:25 Izabooh: Confirma que o fluxo apresentado engloba o do atendimento convencional, com diferença apenas nas etapas posteriores.

00:02:50 Lucas: Descreve o serviço de registro de ocorrência técnica, que recebe a chamada de abertura e publica no Kafka.

00:03:11 Norberto: Esclarece que o escopo do trabalho é a integração ponta a ponta, e não apenas a camada de mensageria.

00:03:18 Lucas: Explica que o serviço de entrada precisa responder rápido, faz apenas validações leves e devolve o protocolo ao canal, enquanto a validação efetiva ocorre no microserviço de ocorrência técnica.

00:04:25 Lucas: Descreve a gravação da comunicação na base da Energisa e a republicação em uma segunda fila, de registro da ocorrência no sistema técnico.

00:05:04 Lucas: Registra que o fluxo apresentado é o do DMS e que os sistemas técnicos anteriores seguem caminho distinto, com gravação em tabela, e deixarão de existir.

00:05:40 Lucas: Explica que o serviço de integração aplica as transformações exigidas pelo modelo do DMS, realiza chamada síncrona e produz mensagem de retorno com o incidente e a reclamação.

00:06:30 Lucas: Detalha as duas trilhas de consumo do microserviço de ocorrência técnica, uma para a chamada e outra para o retorno, e informa que em cerca de noventa e nove por cento dos casos o identificador do incidente é devolvido pelo DMS. Nos casos residuais, um serviço do atendimento convencional atualiza o registro pelo número da comunicação.

00:07:38 Norberto: Observa que parte do tráfego corresponde apenas a atualização da reclamação.

00:07:39 Izabooh: Menciona o microserviço de filtro de incidentes, utilizado para filtrar os eventos e obter o retorno.

00:08:44 Lucas: Explica que o adaptador envia três mensagens, referentes ao serviço, aos pontos de entrega afetados e aos trouble tickets, e usa o exemplo de dois vizinhos que reclamam e um terceiro afetado que não fez contato.

00:10:30 Lucas: Descreve a formação das ordens de serviço no WFM e a existência de várias filas de evento, lidas pelo filtro, que publica nas filas de ordem de serviço e de clientes afetados consumidas pelos dois canais.

00:11:37 Lucas: Registra que a fila de clientes afetados é uma das de maior movimentação, porque o incidente é decomposto por ponto de entrega.

00:11:45 Lucas: Informa que o tópico opera com 60 partições para dar vazão ao volume.

00:12:33 Norberto: Contextualiza que há três empresas com OMS implantado, a quarta em curso, e que o desenho considera o alcance de nove empresas.

00:13:08 Lucas: Explica que todas as empresas trafegam nas mesmas filas e que a identificação da empresa vem tanto no cabeçalho quanto no corpo da mensagem.

00:13:32 Lucas: Aponta a vazão como a principal preocupação para a expansão, considerando a passagem de três para um número maior de empresas.

00:13:47 Norberto: Questiona a observabilidade do conjunto e a viabilidade de redimensionamento entre empresas.

00:13:58 Lucas: Aponta o padrão de juntar o incidente para depois separá-lo novamente e manifesta a intenção de separar no próprio barramento, lendo a informação diretamente do DMS.

00:14:46 Norberto: Questiona a dependência da composição realizada pelo Sigode.

00:14:57 Lucas: Confirma que parte da composição é necessária em alguns pontos e avalia que ela poderia ser feita no processamento de streaming, com ganho de tempo.

00:15:12 Norberto: Informa que o KSQLDB já é utilizado e que há visão de adotar o Apache Flink para o processamento de streaming.

00:15:29 Castellani: Pergunta se existem esquemas formais dos eventos publicados e se o Schema Registry é utilizado.

00:15:44 Lucas: Informa uso parcial: alguns tópicos possuem esquema registrado e, nos demais, o objeto já possui classe definida, restando gerar o registro do esquema.

00:16:24 Castellani: Pergunta como o evento está organizado, se existe identificador de correlação e como é feita a observabilidade do ciclo de vida do evento.

00:16:52 Lucas: Confirma a existência de identificador de correlação em parte dos pontos e descreve a publicação de mensagens de erro contendo a etapa, o tipo de tentativa e o motivo da falha.

00:18:13 Lucas: Reconhece que o desenho correto seria criar o identificador de correlação na entrada da requisição e propagá-lo até o fim da cadeia.

00:18:45 Lucas: Informa que o DMS gera identificador de correlação próprio e não devolve o mesmo identificador para o incidente e para o trouble ticket, ainda que estejam relacionados.

00:19:28 Castellani: Pergunta como a correlação é efetivamente reconhecida entre os registros.

00:19:43 Lucas: Explica que a correlação é feita pela chave do trouble ticket, que corresponde à comunicação aberta no atendimento.

00:20:02 Lucas: Explica que o código do ponto de entrega é o identificador único do local que recebe energia e existe tanto no DMS quanto nas bases do atendimento, o que permite reconhecer o mesmo local nos dois lados.

00:20:51 Norberto: Solicita que as áreas apresentem suas dores e os pontos que consideram passíveis de revisão.

00:21:05 Lucas: Aponta como principal dor o volume de mensagens no fluxo de desligamento emergencial, desproporcional ao que efetivamente chega.

00:21:20 Lucas: Relata acúmulo de vários gigabytes com poucos incidentes e observa que o volume estava momentaneamente menor porque o DMS estava em manutenção.

00:21:55 Lucas: Propõe passar a ler diretamente do DMS em lugar do Sigode, ressalvando a necessidade de reproduzir as regras de negócio hoje aplicadas naquele componente.

00:22:19 Norberto: Sintetiza a proposta como simplificação do fluxo com processamento em streaming.

00:22:43 Lucas: Relata o caso concreto em que uma ocorrência cancelada no DMS não chegou cancelada ao Sigode, o evento de cancelamento não foi gerado, foi necessária carga manual de dados e conclui que o ideal seria ter uma única fonte da verdade.

00:23:21 Izabooh: Confirma que o problema persiste e que não é possível mapear todos os casos em que ele ocorreu, reforçando a necessidade de fonte única da verdade.

00:23:42 Castellani: Retoma o desenho para confirmar que o ADMS gera três eventos por meio do adaptador, consolidados no Sigode e reenviados aos consumidores.

00:24:08 Castellani: Questiona se o reenvio é realizado por captura de dados alterados.

00:24:11 Lucas: Explica que o evento de criação carrega o incidente, os pontos de entrega e os trouble tickets.

00:24:39 Lucas: Relata que, em casos extremos com dezenas de milhares de unidades afetadas, o objeto único tornava-se excessivamente grande, problema mitigado pela separação em mensagens distintas.

00:25:38 Lucas: Explica que, quando chega uma alteração, o microserviço consulta a base do Sigode para recompor os clientes afetados.

00:26:00 Lucas: Aponta que o evento de serviço criado do WFM traz informação irrelevante para o atendimento e dispara gatilhos indesejados, o que justifica a existência do filtro, componente que poderia ser eliminado com o redesenho.

00:26:56 Castellani: Retoma a explicação para validar o entendimento sobre o papel do Sigode na cadeia.

00:27:19 Castellani: Confirma que o Sigode é um sistema desenvolvido internamente na Energisa e que persiste os eventos em base MongoDB.

00:27:37 Lucas: Confirma que cada mensagem recebida gera uma publicação própria e que as informações são complementadas ao longo do processo.

00:28:26 Castellani: Pergunta se a publicação decorre de captura de dados alterados sobre a base ou se são dois processos independentes.

00:28:48 Lucas: Informa que a publicação é realizada pelo próprio serviço, a partir do conteúdo recebido, e não por captura de dados sobre a base.

00:29:22 Norberto: Explica que ordens de serviço comerciais e originadas em sistemas legados chegam ao mesmo tópico de ordem de serviço criada por captura de dados alterados, distinguidas por um campo de tipo de serviço.

00:29:51 Castellani: Caracteriza o padrão identificado como dual write, dado que o serviço grava no banco e depois publica no barramento.

00:29:58 Norberto: Confirma que o problema já havia sido apontado às equipes anteriormente e que não sabe qual tratamento foi adotado desde então.

00:30:46 Norberto: Questiona como seria realizado o rollback do processamento em caso de falha entre as duas operações.

00:31:05 Lucas: Descreve o mesmo padrão no microserviço de ocorrência técnica e informa que a confirmação no banco ocorre somente depois da confirmação do barramento.

00:31:46 Castellani: Explica o padrão Transactional Outbox, com gravação do dado de negócio e do payload do evento na mesma unidade transacional.

00:32:29 Castellani: Descreve as duas formas de publicação a partir da outbox, por polling ou por captura de dados alterados sobre a coleção específica, com marcação de envio bem-sucedido.

00:33:10 Castellani: Descreve a aplicação em Oracle, com a tabela da entidade e a tabela de outbox atualizadas no mesmo commit.

00:33:54 Castellani: Descreve o tratamento de falhas, com reprocessamento ou encaminhamento para fila de mensagens não processadas.

00:34:05 Castellani: Menciona a possibilidade de utilizar o mecanismo nativo de filas do Oracle, por participar da mesma unidade transacional.

00:34:48 Norberto: Confirma a descrição do padrão apresentada.

00:34:58 Norberto: Informa que um colega vinha testando uma biblioteca do ecossistema .NET que facilita a implantação do padrão e que buscará a referência.

00:35:14 Norberto: Registra que a mesma orientação havia sido passada ao time do WFM e que não sabia que a necessidade também existia nesta frente.

00:35:26 Norberto: Associa os casos de inconsistência e de perda de dados ao padrão de gravação dupla.

00:35:34 Castellani: Caracteriza a falha silenciosa como o cenário mais sensível, porque não é percebida de imediato e torna o replay e a reconstrução dos fatos mais difíceis.

00:36:30 Izabooh: Informa que os microserviços do atendimento convencional ainda precisam ser apresentados.

00:36:50 Norberto: Informa que precisa sair para outra reunião e autoriza a continuidade da sessão com a consultoria.

00:37:00 Izabooh: Propõe agendar nova sessão para a apresentação dos seus fluxos, por ter compromisso no horário seguinte.

00:37:24 Norberto: Agenda a continuidade para a manhã do dia seguinte e se compromete a verificar as agendas.

00:38:07 Castellani: Solicita a visualização de um exemplo de estrutura de evento, ainda que sem o esquema formal.

00:40:10 Lucas: Apresenta exemplos obtidos em ambiente de homologação e explica que existe processamento entre a chamada e o registro, no qual parte das informações já é convertida para o formato esperado pelo DMS.

00:41:52 Lucas: Explica que cada trouble ticket contido no incidente gera uma mensagem na fila de comunicação do CRM.

00:42:08 Lucas: Registra a existência do fluxo equivalente de clientes afetados, que carrega o ponto de entrega.

00:42:30 Lucas: Menciona o fluxo de cliente afetado por desligamento programado, mais simples e ainda não apresentado.

00:42:45 Izabooh: Propõe apresentar esse fluxo em conjunto com os seus na sessão seguinte, dado o volume de conteúdo remanescente.

00:43:06 Lucas: Apresenta a visão consolidada do que é enviado e recebido e observa que parte dos fluxos existentes no CRM não é utilizada com o DMS.

00:43:54 Lucas: Encerra a apresentação e confirma o aprofundamento dos detalhes na sessão seguinte.

Anexo B · Registro cronológico revisado da sessão de 16 de julho de 2026

Registro cronológico revisado da segunda sessão, no mesmo padrão do anexo anterior. A sessão iniciou com dificuldade técnica na estação de trabalho da apresentadora, que impediu a exibição de um dos diagramas, e prosseguiu com a apresentação dos fluxos documentados na Wiki da área.

00:00:18 Izabooh: Inicia a apresentação pelo fluxo de ocorrência técnica documentado na Wiki da área.

00:00:46 Izabooh: Informa que a máquina não permite expandir o diagrama e que buscará a imagem com o profissional que a possui para enviá-la à consultoria.

00:01:02 Izabooh: Registra que, diferentemente dos canais digitais, a abertura da ocorrência no atendimento convencional parte do CRM legado, que invoca o serviço de entrada, e que a partir daí o processo segue todo o fluxo apresentado na sessão anterior.

00:01:53 Izabooh: Confirma que o único ponto adicional é o sistema legado de atendimento e que o restante do fluxo é idêntico ao já explicado.

00:02:14 Izabooh: Informa que o encerramento da comunicação também utiliza o mesmo serviço de entrada.

00:02:17 Izabooh: Apresenta os serviços envolvidos na geração de comunicação: o microserviço de filtro de incidentes e o microserviço de comunicação.

00:04:40 Izabooh: Descreve o CRM legado como o sistema pelo qual o call center dá entrada no atendimento ao cliente, com invocação do serviço de entrada dos canais digitais e persistência em banco de dados na sequência.

00:05:47 Izabooh: Retoma os serviços envolvidos na geração da comunicação.

00:06:06 Izabooh: Explica que o microserviço de filtro consome o que é processado pelo Sigode e sugere a participação daquele time nas próximas sessões.

00:07:25 Norberto: Informa que o time do Sigode participou da sessão anterior e que pode ser convocado novamente para um aprofundamento neste ponto específico.

00:07:44 Lucas: Relaciona o ponto aos tópicos de ordem de serviço mencionados na sessão anterior, ainda não detalhados individualmente.

00:08:16 Izabooh: Enumera os sete tópicos consumidos pelo microserviço: criado, despachado, encerrado, cancelado, arquivado, chamada e afetado, e informa que, conforme o conteúdo recebido, o serviço publica nas filas de comunicação do CRM, de comunicação de desligamento emergencial e de ordem de serviço.

00:08:41 Castellani: Pergunta se os sete tópicos são independentes ou se se relacionam, e se existe orquestração, máquina de estados ou controle de histórico no processamento.

00:09:04 Izabooh: Indica que o time do Sigode tem melhor propriedade para explicar o que determina a publicação em cada tópico.

00:09:21 Lucas: Informa que, dentro dos tópicos, a estrutura da mensagem é a mesma, e o que muda é o estado representado.

00:09:41 Izabooh: Explica que o microserviço de comunicação é o responsável por manter o ADMS e o CRM no mesmo status, refletindo no atendimento a situação registrada na ocorrência.

00:10:31 Castellani: Confirma o entendimento de que cada tópico corresponde a um estado da ocorrência.

00:10:48 Castellani: Questiona a consequência da ausência de ordenação, dado que um evento de arquivamento pode ser recebido antes do evento de criação.

00:11:02 Izabooh: Informa que a atualização ocorre conforme o evento recebido e introduz o problema existente no tratamento do cancelamento.

00:11:18 Izabooh: Relata que diversas ocorrências aparecem canceladas no CRM e não conseguem mais trocar de status, dor que exigirá alteração de regra.

00:11:42 Lucas: Informa que existe algum controle de estado no filtro, que evita, por exemplo, republicar a mensagem de criação quando a ocorrência já está cancelada.

00:12:12 Izabooh: Esclarece que a alteração da regra será feita no microserviço de comunicação, e não no filtro de incidentes.

00:12:47 Castellani: Apresenta a alternativa de organizar o tópico por agregado ou entidade, com o estado expresso como tipo de evento.

00:13:03 Castellani: Detalha o ganho: filtro por tipo de evento no consumidor, chave de partição por ocorrência, ordenação garantida e possibilidade de ignorar eventos incompatíveis com o estado corrente, com redução do número de tópicos.

00:13:53 Castellani: Pergunta se a reestruturação faria sentido no cenário da área.

00:14:05 Norberto: Informa que o Sigode possui um tópico amplo de ordem de serviço, com coluna de status, e que a própria equipe agrega e republica o conteúdo em tópicos específicos para consumo dos demais sistemas.

00:14:29 Lucas: Considera que a mudança seria viável do lado dos canais, mas que é necessário entender com o time do Sigode a razão do desenho atual.

00:14:37 Izabooh: Concorda que a reestruturação seria ideal e reforça a necessidade de tratar o tema com a equipe responsável.

00:15:00 Castellani: Questiona o tratamento de idempotência, considerando replay e envio de evento duplicado.

00:15:18 Lucas: Confirma que existe tratamento do lado dos canais digitais.

00:15:25 Izabooh: Confirma que existe tratamento e registra que há tratativas em andamento para problemas identificados no CRM legado.

00:16:44 Castellani: Descreve o mecanismo recomendado: identificador único de evento no envelope, mantido em novas emissões, com registro dos identificadores já processados pelo consumidor.

00:17:41 Lucas: Informa que um dos tópicos possui código único de mensagem, mas que o controle efetivamente aplicado não se baseia nesse código.

00:18:01 Lucas: Descreve o controle existente: a atualização em MongoDB é refeita, e para o disparo de comunicação existe controle separado que registra até que estágio a ocorrência avançou, evitando disparo repetido.

00:18:42 Castellani: Confirma que a atualização em MongoDB se comporta como operação de atualização ou inserção conforme a existência do registro.

00:19:12 Lucas: Informa que o controle se aplica ao disparo de comunicação proativa ao cliente e é implementado no próprio código.

00:19:20 Castellani: Aponta que o controle baseado em consulta e gravação em banco implica esforço desnecessário e custo mensurável.

00:19:30 Lucas: Associa esse custo ao excesso de mensagens já relatado na sessão anterior.

00:19:43 Castellani: Registra que o tema deixou de ser curiosidade e passou a ser item relevante do diagnóstico, dado que operações de escrita em banco são recurso caro sob alto volume.

00:20:22 Izabooh: Propõe nova rodada com maior profundidade, com acesso aos códigos dos microserviços.

00:21:44 Izabooh: Apresenta os microserviços de atualização de cliente: monitor de instalação, cliente, cliente em formato CSV e atualização de potência, e observa que a implantação em nova empresa começa por essa cadeia.

00:22:37 Izabooh: Descreve os dois modos de operação do monitor de instalação e explica que, a cada ordem de serviço que altera a instalação do cliente, o indicador de transferência para o DMS é alterado.

00:23:35 Izabooh: Identifica o serviço legado desenvolvido em PowerBuilder como responsável pela troca do indicador e pelo envio.

00:23:50 Izabooh: Descreve a publicação no tópico de atualização de cliente e o consumo pelo microserviço de cliente.

00:24:34 Izabooh: Informa que o microserviço de cliente participa do cálculo das potências ativa e reativa e da atualização do cliente no DMS, ressalvando que a responsabilidade é compartilhada com o serviço de arquivos.

00:24:55 Izabooh: Descreve a geração dos arquivos em formato CSV, a pasta de transferência utilizada para envio ao DMS, a persistência em MongoDB e o serviço específico de atualização das potências.

00:25:12 Castellani: Pergunta se o tópico de atualização de cliente possui outros assinantes ou se funciona como comunicação ponto a ponto.

00:25:45 Izabooh: Indica que, na sua avaliação, trata-se de comunicação ponto a ponto.

00:26:05 Castellani: Confirma que, nesse caso, a finalidade do barramento é desacoplamento técnico e resiliência, função que poderia ser cumprida por chamada síncrona.

00:26:28 Lucas: Informa que os canais digitais não consomem esse tópico.

00:26:53 Castellani: Questiona a qual domínio pertence o monitor de instalação, dado que o componente parece mais técnico do que de relacionamento com o cliente.

00:27:18 Izabooh: Explica que o monitor parte de uma alteração de dados do cliente ou da instalação, que gera ordem de serviço e, na sequência, a troca do indicador de transferência.

00:28:00 Izabooh: Distingue o modo individual incremental, acionado por ordem de serviço, do modo de carga completa, utilizado na implantação do ADMS em nova empresa.

00:28:30 Castellani: Confirma que uma instalação pendente pode corresponder a uma alteração cadastral simples ou a um equipamento a ser instalado no ambiente do cliente.

00:29:14 Izabooh: Relaciona os status pelos quais a ordem de serviço transita e explica que a efetivação da transmissão pelo serviço legado marca o registro como transferido e executado.

00:30:15 Castellani: Questiona qual sistema gerencia efetivamente essas ordens de serviço.

00:30:27 Lucas: Informa que não é sempre o Sigode, citando a troca de titularidade como caso que permanece no domínio comercial.

00:30:39 Izabooh: Enumera exemplos de alteração cadastral, transferência e mudança de transformador, e observa que existem muitas ordens de serviço que não passam pelo Sigode.

00:31:13 Norberto: Sintetiza que tudo o que exige deslocamento físico a campo passa pelo WFM.

00:31:24 Norberto: Registra que sempre existe uma etapa administrativa no atendimento, no call center ou no atendimento remoto.

00:31:37 Castellani: Compara o conjunto a um fluxo de requisição de serviço, no qual o atendimento gerencia a solicitação, aciona as áreas executoras e devolve o status ao cliente.

00:32:35 Castellani: Levanta a questão do acoplamento de linguagem: a ordem de serviço do domínio operacional corresponde a um caso no CRM, e propagar diretamente o vocabulário de um domínio ao outro cria dependência funcional.

00:33:22 Castellani: Observa que não identifica no desenho uma camada anticorrupção explícita, salvo se o próprio microserviço estiver cumprindo esse papel.

00:34:12 Castellani: Exemplifica o risco de propagar a linguagem de um domínio ou os jargões do produto para outro domínio, o que produz acoplamento ainda que a comunicação seja assíncrona.

00:35:07 Castellani: Descreve a função da camada anticorrupção: consumir o evento, traduzir para a linguagem do domínio consumidor e concentrar nela o impacto de mudanças.

00:35:56 Lucas: Questiona qual seria exatamente a mudança pretendida na modelagem da ordem de serviço, observando que existem ordens que não vão a campo.

00:36:19 Norberto: Registra que acoplamento é a característica dominante do ambiente, porque praticamente todas as integrações são legadas.

00:36:38 Norberto: Relata o uso histórico de ligação direta entre bancos e de visões compartilhadas e informa que a preocupação com a camada anticorrupção existe nas frentes de modernização, restando muito a revisar.

00:36:56 Castellani: Observa que o barramento é oneroso quando utilizado apenas para prover resiliência em uma conexão ponto a ponto.

00:37:17 Castellani: Sugere fila mais leve para esse caso e caracteriza o tópico analisado como rota técnica entre dois sistemas, e não como fato de domínio.

00:38:20 Lucas: Propõe a criação de um tópico geral de atualização de cliente, que poderia ser consumido também pelos canais digitais para manter suas informações atualizadas.

00:38:54 Lucas: Relata que hoje existem vários serviços que consultam periodicamente a base legada para alimentar cópias locais destinadas a acelerar respostas, e que poderiam ser eliminados com o novo desenho.

00:39:11 Castellani: Confirma a proposta: em lugar de um tópico de rota, um tópico de cliente com tipos de evento, consumido por vários domínios, com redução do número total de tópicos.

00:39:56 Castellani: Explica que as perguntas visam construir entendimento suficiente para evitar proposta enviesada.

00:40:11 Izabooh: Concorda com a necessidade de revisar parte das filas e considera o tema merecedor de aprofundamento.

00:41:00 Castellani: Distingue eventos que atravessam domínios, que justificam o barramento, de eventos internos ao próprio domínio, que podem ser resolvidos por interação direta.

00:41:42 Castellani: Indica fila mais leve com disjuntor para a comunicação interna e propõe, em uma reestruturação, mapear os fluxos e criar os fatos de domínio, reduzindo a quantidade de tópicos e protegendo os domínios por camada anticorrupção.

00:43:10 Valéria: Participa brevemente para cumprimentar a consultoria, com quem já havia trabalhado anteriormente.

00:45:27 Izabooh: Inicia o fluxo de desligamento emergencial, informando que o microserviço de filtro de incidentes filtra as filas do Sigode e publica no tópico de cliente afetado por desligamento emergencial.

00:45:44 Izabooh: Descreve o microserviço de desligamento emergencial, que atualiza o status do incidente e reflete a informação na tela do CRM, com persistência em banco.

00:46:26 Lucas: Informa que nos canais digitais a mesma atualização é gravada em MongoDB em lugar da base Oracle e que o fluxo pode gerar comunicação proativa ao cliente.

00:46:58 Lucas: Detalha que o controle abrange condições adicionais, como alteração da data prevista, mudança de status da equipe e alterações no incidente, e não apenas a mudança de status.

00:47:25 Castellani: Pergunta se o CRM é produto de mercado ou desenvolvimento interno.

00:47:33 Izabooh: Informa que o CRM é interno, desenvolvido pela própria Energisa em PowerBuilder.

00:47:48 Castellani: Confirma que a ausência de serviços disponíveis no produto explica a atualização direta em sua base de dados.

00:48:17 Izabooh: Informa que a modernização do CRM está sob outra frente, a dos canais convencionais, e não faz parte do escopo do ADMS.

00:48:57 Izabooh: Explica a divisão do atendimento entre a frente digital, com site e aplicativo, e a frente convencional, com agências e call center apoiados no sistema legado.

00:49:30 Castellani: Confirma que os microserviços apresentados pertencem ao domínio do CRM e pergunta se outros sistemas também acessam diretamente a base do atendimento.

00:49:45 Izabooh: Confirma que outros serviços persistem diretamente nessa base e informa que a intenção é modernizar o conjunto e sair do legado.

00:50:25 Norberto: Informa que a versão do Oracle utilizada é a 19.

00:50:44 Castellani: Explica que proteger a base com microserviços ou serviços de dados permitiria substituir o CRM mantendo os serviços como fachada, com troca posterior e incremental dos próprios serviços.

00:51:52 Castellani: Observa que, havendo vários sistemas de outros domínios conectados diretamente à base, todos passam a integrar o projeto de modernização, o que aumenta a complexidade.

00:52:06 Norberto: Estima que cerca de noventa por cento do ambiente permanece legado.

00:52:21 Norberto: Relata que as bases Oracle desses sistemas estão fortemente acopladas, com ligações diretas entre bancos.

00:52:36 Norberto: Descreve a modernização do WFM, com base apartada, estrutura nova de microserviços e migração progressiva, mantendo replicação para tabelas legadas porque atendimento, faturamento e outros sistemas utilizavam as mesmas estruturas.

00:53:01 Norberto: Reforça a dimensão do acoplamento existente no ambiente.

00:53:21 Norberto: Menciona o uso da estratégia de estrangulamento do legado.

00:53:25 Castellani: Propõe nova agenda, por limite de tempo, para concluir os temas remanescentes.

00:54:40 Norberto: Propõe uma nova sessão com o time do WFM, incluindo o profissional mais envolvido no desenvolvimento e na modernização em eForce, além do serviço específico de integração com o ADMS.

Anexo C · Glossário e termos que exigem validação

As duas sessões foram registradas por transcrição automática, que capturou de forma imprecisa parte dos nomes de sistemas, serviços e filas. Nesta ata, os componentes foram descritos preferencialmente por sua função no fluxo, e as grafias abaixo são registradas para confirmação na documentação oficial e no catálogo de serviços.

ADMS e DMS	Plataforma de gestão avançada da distribuição e gestão da rede.	Sistema de destino das ocorrências e dos cadastros de cliente e instalação.
OMS	Gestão das ocorrências e dos clientes afetados.	Origem dos estados de ocorrência utilizados pelo atendimento.
WFM	Gestão da força de trabalho.	Formação, despacho e acompanhamento das ordens de serviço de campo.
CRM legado	Sistema de atendimento do call center e das agências, grafado na transcrição como CATT ou CTT.	Desenvolvido internamente em PowerBuilder, com base Oracle. Grafia a confirmar.
Serviço de entrada	Serviço de registro de ocorrência técnica, grafado como WS HOT ou variações.	Ponto de entrada comum aos canais digitais e convencionais. Grafia a confirmar.
Sigode	Componente que consolida os eventos do ADMS e do DMS e republica por estado.	Grafia oscilante na transcrição. Desenvolvido internamente, com base MongoDB.
Microserviços de ocorrência	Filtro de incidentes, comunicação, ocorrência técnica e desligamento emergencial.	Prefixos grafados de formas distintas na transcrição. Nomes oficiais a confirmar.
Serviço legado de transferência	Serviço em PowerBuilder que altera o indicador de transferência para o DMS.	Grafado na transcrição de mais de uma forma. Nome a confirmar.
Potências P e Q	Potências ativa e reativa calculadas no fluxo cadastral.	Calculadas e atualizadas por microserviços específicos.
Camada anticorrupção	Camada de tradução entre modelos e vocabulários de domínios distintos.	Recomendação de arquitetura discutida nas duas sessões.
Tipo de evento	Atributo que identifica o fato ocorrido dentro de um tópico por agregado.	Alternativa proposta ao desenho de um tópico por estado.
Transactional Outbox	Padrão de publicação confiável a partir da mesma transação do dado de negócio.	Estratégia acolhida para os pontos de dual write.

Além das grafias, os seguintes dados quantitativos e afirmações foram registrados como informados e devem ser confirmados antes de compor conclusões do assessment:

• As 60 partições atribuídas ao tópico de clientes afetados e a distribuição de partições dos demais tópicos.
• O número aproximado de instâncias ou funções de processamento utilizadas para dar vazão ao fluxo do WFM, citado na ordem de algumas centenas.
• A ordem de grandeza de dezenas de milhares de unidades consumidoras afetadas em incidentes extremos.
• O percentual aproximado de noventa por cento atribuído à participação do legado no ambiente.
• A versão 19 do Oracle informada para a base do atendimento.
• A proporção de cerca de noventa e nove por cento de retornos do DMS contendo o identificador do incidente.
• A identificação exata dos sete tópicos de estado e das filas de destino do microserviço de comunicação.
• A referência da biblioteca do ecossistema .NET avaliada para implantação do padrão Outbox.
• O ponto de entrada distinto atribuído ao fluxo de desligamento programado.

1.10.23. Observações finais

Esta ata foi consolidada a partir de quatro documentos referentes às duas sessões: a compilação técnica de cada encontro e a transcrição integral de cada gravação. Os temas foram unificados por assunto, e não por data, de modo que o leitor encontre em um único ponto o tratamento completo de cada questão arquitetural. Os registros cronológicos dos Anexos A e B preservam a sequência de cada sessão isoladamente, com condensação de trechos sem conteúdo técnico e normalização dos termos corrompidos pelo reconhecimento automático de voz.

O conteúdo da segunda sessão avança além do ponto em que a compilação preliminar daquele encontro se encerrava, incorporando o fluxo completo de desligamento emergencial, a natureza do CRM legado e a discussão sobre acoplamento de bases e estratégia de modernização. As classificações de severidade, as prioridades do plano de ação e as estimativas de prazo têm caráter indicativo e serão refinadas com o inventário de tópicos, os esquemas dos eventos e as sessões complementares já acordadas.