Plano de Trabalho — Assessment ADMS (Energisa)

Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS Equipe: Vlad e Castellani Versão: V3 (versão anterior: V2 de 13/07/2026) · migrado do HTML original para markdown em 03/08/2026 Data-base: 25/07/2026

Plano de trabalho para conclusão do Assessment de Arquitetura e Integrações ADMS e para o desenho da arquitetura To-Be. A V3 atualiza o plano após a conclusão das sessões com Manutenção, WFM/IQS, Canais Digitais/Atendimento e OpenShift/Confluent Kafka (Ata 10, de 20/07), consolidadas no documento v1.8. A sessão de OpenShift trouxe dois achados críticos novos, tráfego interno saindo do cluster e ausência de estratégia de DR do barramento, que passam a integrar o diagnóstico e o To-Be. O trabalho segue organizado em quatro fases: fechar o levantamento, consolidar o diagnóstico As-Is, validar com a Energisa e desenhar o To-Be com roadmap de transição.

Números de referência (em 25/07/2026)

• 10 sessões de levantamento realizadas e documentadas (Atas 01 a 10)
• 3 frentes técnicas ainda pendentes de entrevista dedicada
• go-live G1 (Paraíba e Sergipe) em 01/09 — marco que atravessa a fase de To-Be

Objetivo do plano

Concluir o assessment com rastreabilidade e evidências, produzir um diagnóstico As-Is validado com as áreas responsáveis e entregar um desenho To-Be com princípios arquiteturais, arquitetura alvo por domínio e roadmap de transição priorizado por risco, esforço e custo.

Ponto de decisão · calendário

O go-live do G1 em 01/09 cai no meio da fase de To-Be. É preciso decidir com Norberto se o diagnóstico preliminar antecipa um capítulo destacado de riscos e mitigações pré-go-live ainda em agosto. Sem essa antecipação, o assessment corre o risco de entregar recomendações sobre um cenário que já mudou.

Escopo de atuação

A Syntropy diagnostica, desenha e valida a arquitetura. A execução, configuração e testes de ambiente são conduzidos pela Energisa em janelas autorizadas, com planos de rollback.

As quatro fases

Fase	Quando	Descrição
Fase 1 · Fechar o levantamento	27 a 31/07	Entrevistas pendentes, retornos de validação e destravamento de acessos e artefatos.
Fase 2 · Diagnóstico As-Is	até 07/08	Matriz de achados e lacunas, matriz de riscos consolidada e mapa de evidências (ver 080-diagnostico/).
Fase 3 · Validação	semana 10/08	Norberto e Rômulo primeiro, depois rodada técnica com as áreas, incluindo Érica.
Fase 4 · Desenho do To-Be	17/08 a 04/09	Princípios, arquitetura alvo por domínio, roadmap de transição e entrega final (ver 100-to-be/).

Fase 1 · Fechar o levantamento (27 a 31/07)

Concentrar as três entrevistas pendentes e os quatro retornos de validação, e destravar em paralelo as pendências operacionais que comprometem a rastreabilidade do diagnóstico. A sessão dedicada de OpenShift foi realizada em 20/07 (Ata 10) e sai deste bloco, deixando como herança um retorno com o barramento e evidências a cobrar.

Roteiros das entrevistas pendentes (à época)

01 · Infraestrutura e contingência — crítico. Articulação: Norberto · Condução: Castellani, com apoio de Vlad. - Estratégia entre datacenters no cenário G1: ADMS ativo na Paraíba, corporativo e DR em Cataguases; - Failover, recuperação de desastre, replicação, RTO e RPO por sistema; - Runbooks, procedimentos manuais, dependências e pontos únicos de falha; - Testes de contingência já realizados e resultados; - Continuidade do barramento (Ata 10): objetivos de RTO e RPO dos eventos e escolha entre replicação de clusters, replicação de tópicos, recuperação via Event Store ou reconstrução a partir dos sistemas de origem. - Evidências a solicitar: diagramas, planos de contingência, resultados de testes, inventário de dependências e cobertura de replicação na licença Confluent. - Status em 03/08: realizada em 03/08 — ver 010-evidencias/150-dr-sistemas-corporativos.md.

02 · Telecomunicações — crítico. Articulação: Norberto · Condução: Castellani, com apoio de Vlad. - Links MPLS entre Paraíba e Minas, redundância, rotas e qualidade dos circuitos; - Latência e disponibilidade medidas versus requisitos das integrações síncronas do ADMS; - Conectividade com unidades operacionais e contingência de comunicação; - Dependências do ADMS e do GIS sobre a WAN em operação normal e em contingência. - Evidências a solicitar: topologia de links, SLAs, histórico de indisponibilidade e testes de comutação. - Status em 03/08: realizada em 29/07 (Ata 13).

03 · Big Data, Databricks, CDC e Flink — alto. Articulação: Norberto e equipe de Big Data · Condução: Castellani, com apoio de Vlad. - Arquitetura de ingestão, transformação, sincronização e consumo, além do caso do dashboard; - Uso do Databricks para sincronização estrutural e alternativas mais econômicas; - Motivação e escopo da possível introdução do Flink; - Custos, volumes, latências e classificação dos casos de uso em real-time, near real-time, micro-batch e batch; - Encaminhamento da Ata 10: classificar os requisitos de ingestão de BI e da plataforma de dados e eliminar do barramento as cargas inadequadas. - Evidências a solicitar: arquitetura de dados, volumes, custos, jobs, métricas e fluxos CDC. - Status em 03/08: realizada em 31/07 (Ata 14).

04 · Retornos decorrentes da Ata 10 · barramento e consumidores — alto. Articulação: Norberto · Condução: Castellani, com apoio de Vlad. - Equipe do barramento Kafka e Confluent: topologia, componentes, versões, licenças, retenções e configuração dos conjuntos de conectores; - Desenvolvedores do ADMS e das aplicações consumidoras: inventário de URLs e rotas de acesso ao Kafka, políticas de reconexão, espera progressiva, idempotência e retomada automática do consumo. - Evidências a solicitar: inventário de URLs por workload (rota versus Service), configurações de cliente Kafka e métricas de latência e erro de conexão.

Pendências operacionais em paralelo

• Acessos · Citrix e DevOps — cobrança: Vlad. Validar o procedimento, disponibilizar ícone ou endereço interno, testar permissões com Vlad e Castellani e documentar o passo a passo.
• Artefatos · SharePoint — cobrança: Castellani, via Norberto. Apresentações, diagramas, atas, links de gravações, inventários e documentação técnica nas pastas hoje vazias ou incompletas.
• Transcrições brutas — cobrança: Castellani, junto a Roberto. Centralizar as transcrições na pasta oficial do assessment, organizadas por reunião, para a base de conhecimento.

Fase 2 · Consolidar o diagnóstico As-Is (até 07/08)

O consolidado v1.8 já funciona como dossiê de evidências. Falta o destilado: matriz de achados, matriz de riscos unificada e mapa de lacunas. O diagnóstico é progressivo e não espera todas as respostas para começar. Ver os três entregáveis já produzidos em 080-diagnostico/.

Fase 3 · Validação do diagnóstico (semana de 10/08)

Sequência acordada na conversa de equipe de 11/07: primeiro Norberto e Rômulo, depois a rodada técnica com as áreas entrevistadas. Só depois disso o diagnóstico vira base oficial do To-Be.

1. Norberto e Rômulo — apresentar achados, riscos, lacunas e prioridades. Validar entendimento e autorizar a rodada técnica.
2. Rodada técnica — retornar às áreas entrevistadas, incluindo Érica, para corrigir interpretações e registrar validações.
3. Diagnóstico validado — versão consolidada com pendências finais e registro das validações por área.

A sessão com Norberto e Rômulo também deve confirmar o enquadramento da Fase 4: profundidade esperada do desenho To-Be por domínio; inclusão ou não de estimativas de custo nas recomendações; inclusão ou não de plano de implementação (a execução permanece com a Energisa); responsáveis pela validação e aprovação final; e a decisão sobre o capítulo antecipado de riscos e mitigações pré-go-live G1.

Postura na condução: abordagem técnica, transparente, não acusatória, baseada em evidências e respeitosa em relação às decisões históricas. Atribuições corretas importam: os seis relatórios essenciais do COp, por exemplo, foram construídos pela equipe do Norberto na Energisa.

Fase 4 · Desenho do To-Be (17/08 a 04/09)

Quatro blocos: princípios arquiteturais, arquitetura alvo por domínio, roadmap de transição em três horizontes e ciclo de validação e entrega. O go-live G1 em 01/09 atravessa a fase e exige o tratamento antecipado dos riscos pré-go-live. Conteúdo ainda não desenvolvido — ver 100-to-be/ (placeholder).

Bloco 1 · Princípios arquiteturais (diretrizes que os achados já apontam)

• Consistência transacional por Transactional Outbox em vez de dual write;
• Idempotência e deduplicação nativas nos consumidores;
• Correlation ID ponta a ponta em todos os fluxos críticos;
• Eventos modelados por agregado, com contrato versionado no Schema Registry;
• Failover automatizado nas três camadas do CDC: endpoint, continuidade do job e integridade de LSN e offsets;
• Monitoramento de serviço, não apenas de infraestrutura;
• Requisitos classificados pelo SLA real de negócio (real-time, near real-time, micro-batch, batch), não por real-time como default;
• Custo total como critério de decisão, ao lado da aderência técnica.

Bloco 2 · Arquitetura alvo por domínio

Domínio	Direção do desenho To-Be	Achado que responde
ADMS / OMS	Camada de proteção e priorização na frente do ADMS: buffer, controle de vazão, priorização e deduplicação, avaliando reuso da mensageria existente antes de nova tecnologia.	Single-thread, contenção e crescimento de volume
WFM / Equipes	Evolução da carga full para integração incremental por API, em estratégia híbrida com critérios de viabilidade definidos na Ata 08.	Pontos de falha, timeout e ausência de confirmação
GIS / ADMS	Mecanismo de reconciliação para a janela de sincronização e tratamento de eventos tardios, com granularidade adequada de incidentes durante a janela.	Janela de 12 horas e inconsistências processuais
CRM / Incidentes	Fluxo ponta a ponta documentado de agrupamento, fechamento, reabertura e conciliação, com Outbox, idempotência e correlação nos serviços envolvidos.	Dual write, cancelamento não propagado, eventos tardios
F5 / Failover	Monitores ativos de serviço, automação do chaveamento entre datacenters, política corporativa de nomenclatura e higienização de VIPs.	Monitor de servidor, chaveamento manual, falta de padrão
API / Sensedia	Esteira CI/CD com testes de contrato, bloqueio de breaking changes, versionamento obrigatório e catálogo governado.	Quebra de compatibilidade tratada como manutenção normal
Dados / CDC	Simplificação da cadeia CDC, Databricks e Flink orientada por custo e SLA, com batch e micro-batch onde o processo tolera, e failover do CDC nas três camadas.	Custo do Databricks, real-time sem requisito, CDC preso ao endpoint primário
OpenShift / Plataforma	Correção do tráfego interno (Services e DNS do cluster no lugar de rotas externas, endpoints centralizados em configuração governada, Network Policies por namespace), planejamento formal de capacidade, estudo de segregação do barramento orientado a requisitos e custo total, escala orientada a demanda (direção KEDA), serviços stateless e observabilidade fim a fim.	Rota externa para tráfego interno, 120 cores dedicados ao barramento, limites de escala, risco multitenant
Barramento / Eventos e continuidade	Governança de eventos com catálogo corporativo, esquema canônico por domínio e revisão dos tópicos fragmentados; matriz de decisão entre streaming, CDC, API, batch e arquivo; Event Store com replay controlado; DR do barramento definida por RTO e RPO, com testes periódicos de failover e failback; consumidores resilientes com reconexão automática e health checks funcionais.	Duplicação de eventos, cargas inadequadas no barramento, DR ausente, consumidores frágeis

Bloco 3 · Roadmap de transição

• Horizonte 1 · pré-go-live G1 — o que reduz risco antes de 01/09: monitores ativos no F5 para o fluxo crítico, observabilidade mínima ponta a ponta, procedimento de contingência documentado e testado, e teste de carga inicial das integrações do G1.
• Horizonte 2 · 30 a 90 dias — correção do tráfego interno ao cluster, apontada na Ata 10 como o item de maior retorno imediato e menor ambiguidade técnica; definição da estratégia de DR do barramento por RTO e RPO; Outbox e idempotência nos serviços críticos, correlation ID, governança de VIPs, testes de contrato na esteira de APIs e automação do failover do CDC.
• Horizonte 3 · 90 a 180 dias ou mais — camada de proteção do ADMS, integração incremental de equipes, reconciliação GIS-ADMS, remodelagem de eventos por agregado com catálogo e governança, Event Store com replay, estudo de segregação do barramento e simplificação da arquitetura de dados.

Cada item do roadmap com risco endereçado, esforço, dependências e dono na Energisa. A execução é da Energisa, em janelas autorizadas com rollback.

Bloco 4 · Validação e entrega final

1. Revisão interna — ciclo de revisão entre Vlad e Castellani antes de qualquer apresentação ao cliente.
2. Validação técnica — apresentação a Norberto, Rômulo e Érica, com ajustes e registro de validações.
3. Versão executiva — síntese para Felipe Rosa, relevante também para a agenda de novos contratos.

Cronograma e sequência

Semana	Fase	Marcos
27 a 31/07	Fase 1 · Fechar o levantamento	Entrevistas infra/contingência (com continuidade do barramento), telecom e Big Data; retornos Érica, GIS/ADMS, F5/Sensedia e barramento Kafka/Confluent; acessos e artefatos destravados.
03 a 07/08	Fase 2 · Diagnóstico As-Is	Matriz de achados e lacunas, matriz de riscos consolidada e mapa de evidências pendentes.
10 a 14/08	Fase 3 · Validação	Apresentação a Norberto e Rômulo; início da rodada técnica; escopo do To-Be confirmado.
17 a 21/08	Fase 4 · To-Be, parte 1	Princípios arquiteturais e capítulo de riscos e mitigações pré-go-live G1 entregue de forma antecipada.
24 a 28/08	Fase 4 · To-Be, parte 2	Arquitetura alvo por domínio e roadmap de transição em três horizontes.
31/08 a 04/09	Fase 4 · Entrega	Validação técnica final, versão executiva para Felipe Rosa e encerramento. Go-live G1 em 01/09.

Datas-chave

• 28/07 — cobrança de agenda e interlocutores concluída com Norberto
• 07/08 — diagnóstico As-Is consolidado para apresentação
• 01/09 — go-live G1 · capítulo pré-go-live entregue antes deste marco

Premissas do cronograma

• As quatro entrevistas pendentes acontecem na semana de 27 a 31/07; cada semana de atraso desloca o diagnóstico e comprime o To-Be contra o go-live;
• O diagnóstico é progressivo: achados confirmados entram no To-Be sem esperar as lacunas restantes;
• Sergipe em homologação desde julho e G1 em 01/09 são as âncoras externas do plano;
• Revisão de versão com Castellani antes de qualquer entrega ao cliente.

Ver também: Status das sessões e Cobranças à Energisa.

Nota da migração (03/08/2026): este documento reflete o planejamento tal como estava em 25/07 (V3). Datas e status de entrevistas foram anotados com "Status em 03/08" onde a situação mudou; o restante (fases 2–4, cronograma) não foi replanejado nesta migração — é decisão da equipe atualizar para uma V4 com base no calendário real.