Diagnóstico Preliminar As-Is — Recomendações Preliminares por Domínio
Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa)
Versão: v0.2 · rascunho de trabalho (v0.1 migrado de portal-adms-v4.html para markdown em 06/08/2026; revisado em 18/08/2026 — ver nota de revisão ao final)
Data-base: 03/08/2026
Cada achado do diagnóstico carrega uma recomendação preliminar de melhoria. Este documento reúne as 42 recomendações por domínio: é a agenda de evolução que o assessment propõe levar à rodada de validação com as áreas. Ver também a matriz de riscos consolidada e a matriz de achados e lacunas.
Por que preliminares
Pelo método do diagnóstico, recomendação preliminar é direção de melhoria sujeita a validação de viabilidade e prioridade com as áreas responsáveis. A priorização formal, por risco, esforço e custo, é o produto da Fase 4 do plano de trabalho: o desenho da arquitetura alvo com o roadmap de transição.
As cinco frentes transversais
As convergências CV1 a CV5, detalhadas na síntese executiva, atravessam os domínios abaixo. Tratadas como programas únicos, destravam melhorias em várias áreas de uma vez: continuidade da cadeia de dados, classes de serviço para cargas massivas, automação da contingência, requisitos de tempo formalizados e governança com donos definidos.
Recomendações por domínio
D1 · ADMS / OMS — núcleo e adaptadores
Levantar capacidade, backlog e projeção de volume (linha abaixo) é pré-requisito da camada de proteção e priorização, não uma linha paralela — sem a medição não é possível dimensionar a camada nem definir limiares (ajuste de 18/08/2026, revisão de Vlad).
| Recomendação preliminar |
Origem |
| Levantar capacidade, backlog e projeção de volume com Schneider e equipe ADMS. |
Ata 08, conv. 11/07 |
| Camada de proteção e priorização na frente do ADMS, dimensionada a partir da medição acima; engajamento formal da Schneider. |
Atas 01, 08 |
| Rever a solução de materialização, formalizar propriedade e avaliar contrato de dados com o fornecedor. |
Ata 12 |
| Acordo formal de mudanças com a Schneider, detecção de desvio de esquema e automação da recriação. |
Ata 12 |
D2 · GIS e integração GIS-ADMS
| Recomendação preliminar |
Origem |
| Tratar como questão arquitetural, sem conclusão antecipada; documentar a camada de transformação. |
Ata 06 |
| Mapear o fluxo ponta a ponta, definir mecanismo de reconciliação e tratamento de eventos tardios. |
Ata 06, conv. 11/07 |
| Resolver a divergência como questão de validação no retorno com GIS/ADMS, sem arbitrar silenciosamente. |
Atas 01, 06 |
D3 · CRM, incidentes e canais de atendimento
| Recomendação preliminar |
Origem |
| Adotar Outbox nos serviços críticos; idempotência e deduplicação nos consumidores. |
Ata 09 |
| Definir e propagar identificador de correlação em todos os fluxos críticos. |
Ata 09 |
| Documentar e validar com Érica o fluxo ponta a ponta: geração, agrupamento, fechamento, reabertura e conciliação. |
Ata 09, conv. 11/07 |
| Avaliar a notificação proativa do ADMS ao CRM: publicar o incidente detectado no barramento assim que identificado, para o CRM consultar antes de abrir chamado novo e anexar a ligação do cliente a um incidente já em andamento, em vez de abrir outro — confirmar antes com Érica se o CRM já tem algum mecanismo de consulta ao ADMS ou se o fluxo é hoje estritamente unidirecional. |
Ata 09, conv. 11/07 |
A linha acima depende da anterior: só faz sentido redesenhar a regra de geração de incidente depois de ter o fluxo atual documentado e validado com Érica. É também a única recomendação deste domínio que mexeria na direção do fluxo, não só na execução — as outras três melhoram o fluxo como ele é hoje; esta mudaria quem dispara a abertura de um incidente (ajuste de 18/08/2026, revisão de Vlad).
D4 · WFM e sincronização de equipes
| Recomendação preliminar |
Origem |
| Evoluir para integração incremental por API em estratégia híbrida, conforme critérios discutidos na Ata 08. |
Ata 08 |
| Confirmar volumetria e janelas com o especialista do WFM (sessão pendente, pós-férias). |
Ata 08 |
D5 · Barramento Kafka — eventos e governança
| Recomendação preliminar |
Origem |
| Event Store com replay controlado; DR definida por RTO e RPO com testes periódicos de failover e failback. |
Ata 10 |
| Catálogo corporativo de eventos, esquema canônico por domínio e revisão dos tópicos fragmentados. |
Ata 10 |
| Contrato versionado obrigatório e regras de compatibilidade na esteira. |
Atas 04, 09 |
| Reconexão automática, espera progressiva, health checks funcionais e escalonamento para drenagem de backlog. |
Atas 04, 10 |
| Matriz de decisão entre streaming, CDC, API, batch e arquivo, condicionando a aprovação de novos fluxos. |
Atas 10, 12 |
| Recomendação preliminar |
Origem |
| Substituir rotas por Services e DNS do cluster, centralizar endpoints em configuração governada e aplicar Network Policies. Maior retorno imediato apontado pela Ata 10. |
Ata 10 |
| Confirmar por inventário; planejamento formal de capacidade e estudo de segregação do barramento por requisitos e custo total. |
Ata 10 |
| Medir entrada e saída, validar StorageClass e hipótese de esquema de paridade. |
Ata 10 |
| Institucionalizar o ciclo de atualização com janelas, testes e critérios de rollback. |
Ata 10 |
D7 · F5 — balanceamento e chaveamento
| Recomendação preliminar |
Origem |
| Monitores ativos de aplicação: health endpoint, código e conteúdo de resposta, dependências e prontidão real. |
Ata 05, conv. 11/07 |
| Automatizar o chaveamento com health checks conscientes de papel (role-aware) e runbooks testados. |
Ata 05 |
| Política corporativa de nomenclatura e metadados; higienização do inventário. |
Ata 05, conv. 11/07 |
D8 · APIs e Sensedia
| Recomendação preliminar |
Origem |
| Testes de contrato no CI/CD, bloqueio de breaking changes, versionamento obrigatório e validação de consumidores críticos. |
Ata 05, conv. 11/07 |
| Aprofundar com desenvolvimento, API Management e DevOps no retorno de F5/Sensedia. |
Conv. 11/07 |
D9 · Captura de dados (CDC) — Oracle e SQL Server
| Recomendação preliminar |
Origem |
| Medir vazão por etapa, revisar particionamento e paralelismo, isolar as tabelas ofensoras. |
Ata 12 |
| Separar conectores e workloads por criticidade, com classes de serviço distintas. |
Ata 12 |
| Levantar comandos e versões envolvidos; submeter alterações de banco a procedimento controlado. |
Ata 12 |
| Health checks conscientes de papel ou AG Listener, mais procedimento de retomada do job com validação de offsets. |
Ata 05 |
| Matriz de consumidor, finalidade, criticidade e SLA, substituindo o termo "tempo real" por requisito mensurável. |
Ata 12 |
| Consolidar em solução única de integração, publicando produtos de dados reutilizáveis. |
Ata 12 |
D10 · Observabilidade e monitoração
| Recomendação preliminar |
Origem |
| Arquitetura de coleta segura na OT com correlação junto ao APM e à telemetria corporativa. |
Ata 11 |
| Roadmap de cobertura por criticidade e aceite de instrumentação como requisito de projeto. |
Ata 11 |
| Storage e recursos dedicados, planejamento de capacidade e arquitetura resiliente na reestruturação. |
Ata 11 |
| Contrato de logging, tópico por aplicação, quotas e rateio de custo. |
Ata 11 |
| Mascaramento e detecção de segredos antes da indexação; TLS fim a fim com gestão de certificados. |
Ata 11 |
| Incluir observabilidade como requisito de arquitetura e de aceite; consolidar a visão multifonte. |
Ata 11 |
| Automação de remediação para cenários recorrentes e retenção por classe de log. |
Ata 11 |
| Recomendação preliminar |
Origem |
| Evidenciar por testes a resiliência da WAN e o comportamento das integrações síncronas em degradação. |
Atas 01, 03, 05 |
| Desenhar o failover ponta a ponta, incluindo reapontamento das integrações, com teste periódico. |
Ata 12 |
| Sessão dedicada de infraestrutura e contingência, com a continuidade do barramento incorporada à pauta. |
Pendente |
D12 · Engenharia de dados e Data Lake
Domínio incorporado a este documento em 18/08/2026, a partir da Ata 14 (Engenharia de Dados/Data Lake) — já presente na matriz de achados e lacunas e na matriz de riscos consolidada (R37–R41) desde 04/08/2026, mas sem linha correspondente neste documento até esta revisão — apontado por Vladimir Morozowski De Sousa na revisão do v0.1. Nenhuma destas recomendações passou pela rodada de validação com as áreas.
| Recomendação preliminar |
Origem |
| Documentar e testar o caminho completo entre o ambiente próprio e a nuvem, com failover e retomada automática; avaliar conectividade dedicada com o provedor de nuvem — hoje ponto único de falha de toda a cadeia analítica e regulatória. |
Ata 14 |
| Qualidade de dados e retenção da landing são duas metades do mesmo risco, não achados independentes: sem regras de qualidade, um erro semântico entra sem alarme e é publicado nas APIs regulatórias (projeto Radar/PI Radar, ANEEL, defasagem máxima de 30 min) a cada ciclo; a detecção hoje é reativa, e quando o erro é finalmente percebido a janela de retenção de 7 dias da landing já expirou — sem dado para reprocessar (caso real de perda já ocorrido) e sem mecanismo de reenvio corrigido à ANEEL. Implantar regras mínimas de qualidade com quarentena e substituir a retenção uniforme por classes de retenção por criticidade, como uma só prioridade. |
Ata 14 |
| Estabelecer contrato arquitetural obrigatório para reprocessamento, deduplicação, chave de idempotência e captura incremental de estado nos consumidores do data lake — mesma lacuna já registrada de forma independente na Ata 09, do lado do CRM. |
Atas 09, 14 |
| Contratos de dados versionados, validação automatizada na esteira e alerta preventivo para mudanças incompatíveis de esquema na origem. |
Atas 12, 14 |
| Validar viabilidade técnica e contratual da extração incremental por marcador temporal antes de ampliar a dependência — alternativa em estudo ao upgrade de licenciamento Oracle para replicação de grande volume, estimado em cerca de R$ 6 milhões. |
Ata 14 |
| Formalizar propriedade, documentação e sustentação do serviço de gravação em Go — mesmo padrão de risco já registrado em D1 (materialização de views, Ata 12); tratar como política transversal, não caso a caso. |
Ata 14 |
Nota de revisão (18/08/2026): três ajustes a partir da revisão de Vladimir Morozowski De Sousa (com apoio do Fable) sobre o v0.1. Primeiro, incorporado o domínio D12 (Engenharia de Dados e Data Lake), já existente na matriz de achados e lacunas e na matriz de riscos consolidada (R37–R41) desde 04/08/2026, mas até aqui sem linha correspondente neste documento — a síntese que trata retenção uniforme e ausência de qualidade de dados como duas metades do mesmo risco, sugerida por Vlad, entra como uma recomendação combinada em vez de duas linhas independentes, o que reduziu 7 achados de origem para 6 linhas de recomendação. Segundo, invertida a ordem de D1.1/D1.2: o levantamento de capacidade com a Schneider passa a vir antes da camada de proteção, com a dependência explicitada no texto, não só na ordem — a linha de proteção também deixou de repetir "medição de capacidade e backlog", que agora só aparece na linha anterior. Terceiro, adicionada D3.4 (avaliar notificação proativa do ADMS ao CRM), com nota de dependência de D3.3 e de confirmação pendente com Érica. Nenhuma linha de D2, D4–D10 foi alterada.