Blueprint de Componentes de Software — Integração ADMS (Energisa)¶
Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa)
Versão: v0.4 · rascunho para validação
Data-base: 05/08/2026
Fonte: Artefatos de arquitetura já produzidos no assessment (pasta 030-artefatos/), consolidando Atas 01–14, sessões sem Ata correspondente (Engenharia de Dados, DR, Sustentação, evidências de produção Confluent), o catálogo corporativo Tech Stack.pdf e o diagrama GEAR-222139-Frente Relatório ADMS - v3-V03.drawio.png
Elaborado por: Consultoria Syntropy
Nota metodológica¶
Este blueprint consolida, num inventário único, todos os componentes de software citados nos artefatos de arquitetura do assessment — tanto sistemas de negócio (aplicações que um usuário final reconhece, como ADMS, GIS, WFM) quanto componentes técnicos da camada de integração, dados e infraestrutura (Kafka, OpenShift, Debezium, Databricks etc.). Cada componente traz sua categoria, papel funcional e as dependências mais relevantes ("roda sobre" / "conecta com"), permitindo ler o ecossistema de cima para baixo (negócio → integração → dados → infraestrutura) ou rastrear uma dependência específica.
Nomes marcados com (?) são identificações incertas — normalmente por erro de reconhecimento automático de voz (ASR) nas transcrições-fonte (ex.: "Insight"/"Minsight" prováveis leituras erradas de "Minsait") — e devem ser confirmados antes de uso em qualquer decisão de arquitetura ou comunicação formal com fornecedores. Este blueprint cobre apenas componentes confirmados como existentes hoje — ideias e recomendações discutidas nas sessões (ex.: RPA Adapter, Event Store, health check automatizado no F5) foram deliberadamente deixadas de fora; elas já estão registradas no questionário de mitigação de lacunas e nos artefatos de origem.
A. Camada de negócio — sistemas e módulos¶
A.1 ADMS e seus módulos internos¶
| Componente | Papel | Fornecedor / Tecnologia | Depende de / roda sobre |
|---|---|---|---|
| ADMS | Advanced Distribution Management System — plataforma integrada de operação e gestão da distribuição de energia. Produto 3.1 do domínio "Operação de Redes" no framework corporativo. | Schneider Electric | SQL Server (dados operacionais), ambiente OT segregado |
| EMS | Módulo do ADMS: loadflow, estimador de estados, localização de faltas, manobras de restabelecimento, IVVO, modelo de rede. | Módulo interno do ADMS | ADMS |
| SCADA | Aquisição de dados, monitoração, controle supervisório, alarmes, gestão de TAGs — pré-existente, aprimorado pelo ADMS. Sem integração direta documentada com o GIS. | Módulo interno do ADMS | Telemetria de remotas/IEDs de campo |
| DMS | UBLF, localização de faltas, manobras, FLISR, IVVO, monitoração DER, modelo de rede, simulador, historiador. | Módulo interno do ADMS | ADMS; recebe cadastro do GIS via GIS Adapter |
| OMS | Outage Management System — previsão e gestão de interrupções, ETRs, gestão de equipes de campo, análise de confiabilidade. | Módulo interno do ADMS | ADMS; integra com WFM, SGM, CRM-Service |
| OTS | Operator Training Simulator — ambiente de treinamento comum aos módulos. | Módulo interno do ADMS | ADMS |
A.2 Sistemas corporativos integrados diretamente ao ADMS¶
| Componente | Papel | Fornecedor / Tecnologia | Integração com o ADMS |
|---|---|---|---|
| GIS (Smallworld) | Cadastro georreferenciado e mestre dos ativos de rede (postes, cabos, transformadores). Domínio 1 (Planejamento e Engenharia). | GE Electric Office | Unidirecional, assíncrona, via GIS Adapter + SFTP (batch noturno) |
| WFM / SIGOD | Workforce Management — despacho e execução de trabalho de campo. Domínio 4 (Construção e Serviço de Campo). | Sigode (legado) | Carga full via SOAP/SFTP; sem endpoint de equipe única hoje |
| SGM (EAM) | Sistema de Gestão de Manutenção (SOMA/VERA/mNTCS) — gera notas de serviço consumidas pelo OMS. Domínio 2 (Gestão de Ativos). | — | 3 microsserviços dedicados (consulta/envio/notificação) via Kafka + Sensedia |
| CRM-Service (SIATE/SIATT) | Atendimento ao cliente e base comercial; origina reclamações de falta de energia. Domínio 6 (Experiência do Cliente). | — | Rede de microsserviços MsAtt* via Kafka; ver seção B.5 |
| CIS / Billing (SIFAR) | Customer Information System e Billing and Revenue Management. Domínio 5 (Proteção à Receita). | — | Integração não detalhada nas fontes atuais (SICCO/SIFAR) |
| AMI / MDM | Medidores inteligentes. | — | Não implementada — avaliação para fase 2 (risco de falso positivo) |
| DSS (NetClima) | Sistema irmão do ADMS no mesmo domínio (produto 3.2) — não é integração a absorver pelo ADMS. | — | Fora de escopo do projeto ADMS |
| BPM Qualidade Técnica (SICDE/SICNT) | Gestão da qualidade técnica, produto 3.3 do domínio "Operação de Redes". | — | Não detalhado nas sessões do assessment |
A.3 Demais domínios do landscape corporativo (contexto, fora do escopo direto do assessment)¶
| Domínio | Sistemas/Produtos principais |
|---|---|
| 7. Comercial | CRM, DCE |
| 8. Compra e Trade de Energia | ETRM |
| 9. Regulatório | Sem sistema/responsável mapeado no framework corporativo oficial (gap reconhecido). Na prática, o gap é preenchido pelo Data Pipeline regulatório e pelas APIs regulatórias (Projeto Radar/PI Radar — ver seção C), que hoje funcionam como o sistema de fato deste domínio, sem essa associação estar formalizada em nenhum documento corporativo. |
| 10. Cadeia de Suprimentos | ERP-Supply Chain, Procurement, WMS, TMS |
| 11. Planejamento e Controle Orçamentário | Enterprise Performance Management |
| 12. Suporte Corporativo | Treasury, Tax, HCM, Legal e mais 13 produtos |
B. Camada de integração — conectores, mensageria e API management¶
B.1 Adapters ponto-a-ponto¶
| Componente | Papel | Depende de |
|---|---|---|
| GIS Adapter | Extrai e transforma o modelo GE (Smallworld) para o modelo Schneider, calcula atributos derivados, entrega XML por grupo/empresa via SFTP. Customizado pela Minsait (?). | GIS, SFTP |
| SFTP / Staging (GIS) | Canal de entrega dos extratos XML; não segmentado por empresa individual dentro do mesmo grupo. | GIS Adapter |
| ADMS Staging + Motor de validação (4 etapas) | Importa e valida os extratos do GIS; rejeita o extrato completo do circuito em caso de erro (não item a item). | SFTP, DMS/OMS |
| Adapter WFM do ADMS (SOAP) | Descompacta e processa pacote GZIP de carga full de equipes; só aceita carga completa ou mudança de status via tela — sem endpoint de equipe única. | Sensedia, ADMS |
B.2 Barramento de eventos — Confluent Kafka no OpenShift¶
| Componente | Papel | Observações |
|---|---|---|
| Kafka brokers | Armazenamento e distribuição de eventos do barramento corporativo. 3 clusters em produção, ~2,5TB cada. | Nodes dedicados (Machine Config Pool), StorageClass CSI (RAID 6 suspeito) |
| KRaft controllers | Consenso e metadados do Kafka, sem dependência de ZooKeeper. | 3 pods em produção |
| Schema Registry | Governança e versionamento de schemas Avro das mensagens. | 2 pods em produção; adoção incompleta confirmada por inventário real — 78,7% dos 930 tópicos de produção têm schema (732/930), mas a cobertura é desigual entre domínios: 0% em WFM (0/40) e 21% em CRM (3/14). Fonte: evidencias-producao-confluent-kafka.md, seção A.1 |
| ksqlDB | Processamento de streams via SQL; usado na consolidação multiempresa (9 bancos → 1 tópico unificado). | Número real de produção: 322 streams + 263 queries persistentes (585 estruturas, não ~1000 como estimado na sessão de 09/07) e 0 tables materializadas. Candidato a migrar para Apache Flink (sugestão do fornecedor, sem decisão). Fonte: evidencias-producao-confluent-kafka.md, seção A.7 |
| Kafka Connect | Framework de conectores de origem (CDC) e destino; hoje compartilha os mesmos pods entre cargas operacionais e de BI. | 5 pods em produção; separação operacional/BI em teste (POC). Inventário real confirma 75 conectores (38 JDBC + 34 Debezium/XStream + 3 SQL Server), todos rodando com uma única task, sem exceção — ver seção D |
| Control Center | Console de operação do Confluent. | 1 pod em produção |
Nota (05/08/2026): o diagrama de arquitetura do cliente (
ambientes-barramento-integracao-confluent.png) identifica a equipe Best2Bee como responsável pela implantação, gestão e suporte da plataforma Confluent Kafka/Debezium — ator não documentado em nenhuma Ata até 04/08/2026, acessando via Citrix/Citrix VDA. Verevidencias-producao-confluent-kafka.md, seção B.1.Nota (05/08/2026) — Apache Kafka open source, cluster distinto: confirmado diretamente por Norberto (Energisa) que existe um cluster Apache Kafka open source real na Energisa — mas dedicado especificamente à stack de telemetria/ELK, não ao barramento corporativo nem ao CDC do ADMS documentado nesta seção. O catálogo corporativo
Tech Stack.pdflista "Apache Kafka" como item próprio, com ícone de status Legado, distinto de "Confluent Kafka" (ícone Referência, o cluster documentado nesta seção B). Ver seção E (linha ELK) para o detalhe, e seção G para a hipótese de um segundo broker Kafka dedicado ao CDC do ADMS — descartada; tratava-se de um cluster diferente deste aqui confirmado.
B.3 Captura de dados alterados (CDC)¶
| Componente | Papel | Observações |
|---|---|---|
| XStream | Mecanismo de captura de mudanças do Oracle (usa tecnologia GoldenGate, somente extração), adotado após POC. | Redo logs → fila interna Oracle → Kafka Connect |
| Debezium | Conectores Kafka Connect para captura de mudanças em Oracle e SQL Server. | Publica em tópico específico por tabela; já quebrou 2x por DDL não suportado. Inventário real: todos os conectores de captura rodam com task única, inclusive o mais extremo (oracle-source-xst-com-mgr) capturando 47 tabelas numa única task — causa raiz proposta para o atraso de captura já registrado em D9/R05. O conector sqlserver-source-adms-cpy (captura da réplica "ADMS Replica Realtime" na DMZ, 9 tabelas dms.*) foi confirmado como parte deste mesmo cluster Confluent — corresponde exatamente ao fluxo "Debezium Kafka Connect Source" do diagrama GEAR-222139. Ver evidencias-producao-confluent-kafka.md, seção A.3 |
| Captura nativa CDC (SQL Server) | Recurso nativo do SQL Server, habilitado tabela a tabela — não opera sobre views. | Base para o Debezium no lado SQL Server |
| Procedimento de materialização de views | Job customizado da Energisa (5–10 min) que faz merge por chave em tabela materializada, única alternativa para capturar dados de views proprietárias do ADMS (que invocam DLLs/funções internas). | Criado sob pressão de prazo (MS, set/2025), replicado em 3 implantações, sem equipe formalmente responsável |
| Oracle Data Guard (Far Sync) | Replicação do banco Oracle entre datacenters MG↔PB. Modalidade (leitura no secundário) e modo de proteção (síncrono/assíncrono) não confirmados. | Bancos Oracle corporativos — diagrama GEAR-222139 confirma os alvos exatos: IQOS, GIS, FAR, ATD, PDA |
B.4 API Management e balanceamento¶
| Componente | Papel | Observações |
|---|---|---|
| Sensedia | API Gateway/Manager — proxy, autenticação Client ID/Secret, rate limit, catálogo de APIs. Opera como gateway, não como orquestrador front-to-back. | Sem suporte a lint/contract testing automatizado no pipeline |
| F5 / BIG-IP | Entrega de aplicações: VIPs, pools, balanceamento entre datacenters. Health monitor verifica apenas porta 443, não papel lógico ativo nem conteúdo da resposta. | Site switch hoje é processo manual (aviso entre equipes) |
B.5 Microsserviços de atendimento (ADMS × Canais/CRM)¶
| Microsserviço | Papel | Tecnologia |
|---|---|---|
| WSROT | Serviço de entrada: valida, gera protocolo, publica no Kafka. | API .NET |
| MsAttOcorrenciaTecnica | Registra e atualiza a comunicação no banco ATD. | MS .NET |
| MsCrmMiddleware | Interface síncrona com ADMS (POST /TroubleTickets/). |
MS .NET |
| MsAttFiltroIncidentes | Consome os 7 tópicos wfm_ordem_servico_*, publica para CRM. |
Worker Service |
| MsAttComunicacao | Mantém a cadeia de atendimento no banco ATD. | Worker Service |
| MsAttDesligamentoEmergencial | Mantém a tabela DESLIGAMENTO_EMGCL_OCORC_TECNC. |
Worker Service |
| MsAttMonitoraInstalacao | Detecta instalações pendentes (CronJob 5 min). | Worker Service |
| MsAttCliente | Agrega 3 bancos Oracle, persiste no MongoDB. | Worker Service |
| MsAttClienteCsv | Gera CSV para SFTP (cliente, flexible load, load profile). | Worker Service |
| MsAtualizaPotenciaCliente | Recalcula potência (P/Q) — CronJob diário 02h00. | Worker Service |
| MsAttDesligamentoProgramado | Lê CSV do ADMS via SFTP (CronJob 2 min), publica clientes afetados. | Worker Service |
| SAC Proativo | Único consumidor confirmado do tópico de desligamento programado; 100% em canais digitais. | Canais digitais |
C. Camada de dados e nuvem¶
C.0 Bancos de dados core¶
| Componente | Papel | Fornecedor / Versão | Depende de / conecta com |
|---|---|---|---|
| SQL Server (ADMS/DMS) | Banco operacional do ADMS/DMS — hospeda as views proprietárias do produto (invocam DLLs/funções internas, algumas leem SCADA em memória). Origem da réplica "ADMS Replica Realtime" na DMZ. Captura nativa de CDC habilitada tabela a tabela — não opera sobre views. | Microsoft SQL Server — conflito não resolvido entre duas fontes do próprio cliente (atualizado 05/08/2026): o diagrama de arquitetura (ambientes-barramento-integracao-confluent.png e GEAR-222139-Frente Relatório ADMS) rotula a instância como 2019; Norberto (Energisa), em resposta direta e por escrito a este assessment, informou 2022. As duas fontes são do próprio cliente e se contradizem diretamente — não é mais a hipótese de memória do consultor (já descartada como origem do "2022"), e sim um conflito entre o diagrama e a resposta do arquiteto da Energisa. A pergunta complementar — se a instância atende exclusivamente ao ADMS ou também a outros sistemas — não foi respondida. Tratar como divergência aberta, não resolvida silenciosamente, até a Energisa confirmar qual das duas está correta (ou se são instâncias diferentes). Ver evidencias-producao-confluent-kafka.md, seção B.2 |
ADMS/DMS; alimenta Debezium (CDC nativo) e o procedimento de materialização de views |
| Oracle (bancos corporativos) | Bancos corporativos IQOS, GIS, FAR, ATD, PDA, além de uma instância por empresa (9 bancos, 1 por empresa) na consolidação multiempresa via ksqlDB. Fonte primária de dados operacionais capturados via XStream/CDC. | Oracle Database — 19c | Replicados via Oracle Data Guard Far Sync entre MG↔PB; capturados por XStream → Kafka Connect |
| MongoDB (SIGOD/Atendimento) | Persistência dos microsserviços de atendimento — coleções de ordem de serviço, cliente_adms, unidade consumidora, entre outras. | MongoDB — versão não confirmada | MsAttCliente, MsAttFiltroIncidentes, MsAttClienteCsv, Sigode |
C.1 Pipeline de dados e nuvem¶
| Componente | Papel | Observações |
|---|---|---|
| Azure Runtime Integrator | Roda no ambiente próprio da Energisa, conecta às bases Oracle corporativas e envia dados para a nuvem. | Cluster de 2–3 máquinas; topologia de failover não confirmada — apontado como ponto único de falha da cadeia analítica e regulatória. Diagrama GEAR-222139 confirma: 1 VM DEV/HMG + 1 VM PRD |
| Kafka Connect Sink (Go) | Serviço proprietário, desenvolvido internamente sob pressão de prazo regulatório, como stopgap até a contratação do Confluent Kafka Connect Sink oficial. | Consome o barramento Kafka, grava em Avro na Landing; sem propriedade formal — mesmo padrão de risco da materialização de views. Rotulado no diagrama GEAR-222139 como "Kafka Connect Sink Azure DataLake", com a mesma ressalva textual no próprio diagrama do cliente: "Confluent Kafka Connect Sink em processo de contratação" |
| Data Factory | Orquestração de ingestão de tabelas a partir de bases relacionais, na nuvem. | Azure |
| Landing | Área de aterrissagem do Data Lake (Azure Data Lake Storage) — retenção uniforme de 7 dias para todos os dados, independente de criticidade. Já causou perda irrecuperável de dado em reprocessamento tardio. | Recebe do Kafka Connect Sink e do Azure Runtime Integrator, ambos via internet pública (sem enlace dedicado) |
| Databricks (Bronze/Silver/Gold) | Pipeline único: processa carga bruta, harmoniza, agrega. Orquestração dos clusters efêmeros via Databricks Workflows nativo — citado na sessão como comparável a um Airflow ("como se fosse ali um Airflow da vida"), mas não é Apache Airflow real. | Consome Landing; sem framework de qualidade de dados/quarentena implementado |
| Unity Catalog | Governança, catalogação e controle dos objetos de dados do Databricks. | Databricks |
| Power BI (Microsoft Fabric) | Consumo analítico — ~8 mil relatórios, ~500 sob responsabilidade direta de TI. | Delta sharing / SQL Warehouse a partir do Databricks |
| APIs regulatórias (Projeto Radar / PI Radar) | 3 APIs consumidas pela ANEEL; indicadores em micro-batch de 20 min, tolerância de defasagem de 30 min. Sem mecanismo de correção/reenvio pós-publicação de dado incorreto. Junto com o pipeline Databricks que as alimenta, constitui hoje o sistema de fato do Domínio 9 "Regulatório" — ver seção A.3. | Databricks (camada Gold) |
D. Camada de infraestrutura e plataforma¶
| Componente | Papel | Observações |
|---|---|---|
| OpenShift | Plataforma Kubernetes empresarial que hospeda o barramento e os serviços de integração. Confirmados 3 clusters distintos por ambiente — ocpd1 (DEV), ocph1 (HML), ocpp1 (PRD) — cada um cluster próprio, não namespace compartilhado; o diagrama do cliente detalha a stack Confluent completa (Kafka/ksqlDB/Connect/Schema Registry/Control Center) apenas para ocpd1, com a produção real confirmada independentemente pelos cabeçalhos dos 3 relatórios (Ambiente: PRODUCAO, URLs *.apps.ocpp1.energisa.corp). |
Segregado por Machine Config Pool (barramento vs. pool geral ~26 nodes / ~3000 pods). Fonte dos 3 clusters: evidencias-producao-confluent-kafka.md, seção B.4 |
| StorageClass CSI (VMware) | Driver de armazenamento persistente para Kafka/Connect. | Suspeita de configuração RAID 6 (perda de performance), a confirmar |
| VxRail / VMware 8.0.3.330 | Hiperconvergência Dell — mesmo ambiente hospeda outros workloads além do barramento. | Datastore do StorageClass |
| Link corporativo MG–PB | Enlace L2L nominal de 3 Gbps, limitado a 1 Gbps pela interface do firewall OT. RPO de replicação: 4–6h (não instantâneo). | Achado não presente na matriz de riscos até a auditoria deste assessment |
| Data Center Interconnect (DCI) [em contratação] | Projeto de infraestrutura dedicada entre datacenters — contrato em assinatura, infraestrutura prevista para 2026, migrações até março/2027. | Não elimina a latência de ~60–70ms (fator dominante é distância física, ~3000km) |
| VPN Gateway (Azure) | Dois túneis VPN GW2 conectam o datacenter corporativo à subscription Azure Cloud Energisa — usados para os fluxos de captura de dados em batch (Azure Runtime Integrator) e de registro de arquivos Avro em streaming (Kafka Connect Sink). Detalhe de conectividade não documentado em nenhuma Ata; confirmado pelo diagrama GEAR-222139. | Internet pública não é usada para esses dois fluxos específicos — diverge da leitura anterior em C.1/Landing, que apontava internet pública sem enlace dedicado. Possível leitura (05/08/2026, não confirmada): resposta de Norberto trouxe o fragmento "O vpc gtw -e via internet", recebido de forma incompleta/pouco clara — interpretação provisória é que os túneis VPN GW2 usam a internet pública como meio de transporte (o que seria consistente com, não contraditório a, a leitura anterior de "internet pública" em C.1: haveria um enlace lógico dedicado — VPN — sobre a internet física, não uma linha dedicada separada). Esta é uma interpretação de um fragmento de texto ambíguo, não uma confirmação — deve ser validada diretamente com a Energisa antes de ser tratada como fato fechado |
| Firewall de borda (ADMS) | Não dedicado ao ADMS — atende também outros fluxos. | MG e PB |
| LDAP corporativo | Autenticação. Mitigado com 3 servidores nomeados antes do fallback genérico. | Kafka brokers e demais componentes |
| Citrix (VDI) | Infraestrutura de desktop virtual (Virtual Desktop Infrastructure) usada pelo operador do COI para acessar as instâncias do ADMS. Confirmado como VDI pelo próprio inventário do Zabbix (usuários conectados, VDIs, recursos de VDI, performance de login). Também usado pela equipe Best2Bee para acesso operacional ao Confluent — ver seção B.2. | MPLS / GPRS-Satélite |
| OpenShift DR (João Pessoa) | Não é ativo-ativo — operador e componentes hoje com volumes vazios, sem replicação definida para o barramento. | Kafka |
E. Observabilidade e DevOps¶
| Componente | Papel | Observações |
|---|---|---|
| Zabbix | Monitoração de infraestrutura — instâncias segregadas para OT e TI. | Rede, banco, servidores |
| Datadog | APM/observabilidade de aplicações (SaaS). Cobertura: 3 de 9 unidades de negócio, ~85% das APIs nessas 3. Nunca viabilizado no ambiente OT. | Instrumentação do Kafka em homologação |
| ELK / Elastic (LK) | Telemetria e logs — legado, anterior ao OpenShift, fora do cluster. Storage compartilhado; backup suspenso após incidente de rebalanceamento; em reestruturação total. 151 aplicações publicam no mesmo tópico de telemetria. | Confirmado por Norberto (05/08/2026): o "Kafka dedicado à telemetria" citado aqui é um cluster Apache Kafka open source real, distinto do Confluent Kafka do barramento corporativo (seção B.2) — dedicado especificamente à stack ELK, não ao CDC do ADMS. Corrobora o catálogo Tech Stack.pdf, que lista "Apache Kafka" como item próprio com ícone de status Legado (distinto de "Confluent Kafka", com ícone Referência) — consistente com a leitura de ELK como stack legada em reestruturação. Isto não é o mesmo achado da hipótese de segundo broker Kafka para o CDC do ADMS, investigada e descartada em B.3/G — são clusters diferentes, para propósitos diferentes |
| Prometheus + Grafana | Métricas nativas do OpenShift — cobre o cluster e o Confluent Kafka. | Nativo do OpenShift |
| PRTG | Monitoração de rede corporativa — legado em migração gradual. | — |
| Oracle Enterprise Manager | Monitoração complementar de bancos Oracle. | — |
| Azure DevOps Server | Instância própria on-premises (não o serviço SaaS) — Azure DevOps Server 2020 Update 1.1 (build 18.181.31527.1), 3 VMs de aplicação (MGDVPSEAPLP1 Windows Server 2016; MGDVPSEAPLP2/MGDVPA2APLP1 Windows Server 2019) + 1 VM de Search (MGDVPSESCHP1), URLs devops.energisa.com.br e hmgdevops.energisa.corp. Usado para documentação/wiki de projetos e pipelines de CI/CD — confirmado nas sessões apenas para o deploy dos componentes do barramento (Kafka/Connect). |
Confirmar com o cliente o escopo completo de uso (quais times/projetos usam Wiki e Boards, além do CI/CD do barramento) |
| JFrog Artifactory + X-Ray | Repositório de artefatos e segurança de dependências. | Fornece para o Azure DevOps |
Achado (05/08/2026) — segunda instância de Azure DevOps, distinta da acima: o diagrama GEAR-222139 (Frente Relatório ADMS, pipeline de Engenharia de Dados) mostra uma subscription separada, "Azure Energisa [Azure - GEAR Subscription]", com Azure DevOps Service (SaaS — não o Server on-premises) hospedando
Repos [Azure Repos]eCI/CD [Azure Pipelines], com um pool de 5 Microsoft Hosted Agents (3× Ubuntu 22.04.4 LTS + 2× Windows Server 2022) e um pool de Self-Hosted Agents (RHEL 8) que aciona SAST (SonarQube) e SCA (JFrog XRay) antes do deploy. Isto não é a mesma instância usada para o deploy do Kafka/Connect (linha acima) — são dois Azure DevOps distintos, um Server on-premises e um Service em nuvem, cada um servindo uma frente diferente do projeto (barramento vs. pipeline de dados). Nenhuma Ata documentou essa segunda instância até aqui.Confirmado por Norberto e por Castellani (05/08/2026), RESOLVIDO: as duas instâncias existem por decisão deliberada, não duplicação acidental — a instância SaaS é dedicada à EDP (Energisa Data Platform), usada pelo time de Dados. A sigla é interna da Energisa e não se refere à empresa EDP - Energias de Portugal. Consistente com a subscription "Azure - GEAR Subscription" e o pipeline de Engenharia de Dados já documentados na seção F (Purview, Key Vault, Entra ID, SonarQube, JFrog XRay, Qualys) — mesma frente de Dados. Adicionalmente, o catálogo
Tech Stack.pdfmarca "Azure DevOps Service" com ícone de status Experimental (contra Referência do "Azure DevOps Server" on-premises) — possível leitura é que "Experimental" reflita o estágio de adoção como padrão corporativo (ainda não é o padrão da maioria dos times), e não a ausência de uso real, já que o time de Dados já o usa em produção; esta leitura segue como hipótese, não confirmada com a área responsável pelo catálogo.
F. Identidade, segurança e DevSecOps do pipeline de dados — confirmado pelo diagrama GEAR-222139¶
Segão nova, adicionada em 05/08/2026 a partir da leitura do diagrama
GEAR-222139-Frente Relatório ADMS - v3-V03.drawio.png, fornecido pelo cliente, e cruzada com o catálogo corporativoTech Stack.pdf. Diferente do restante deste blueprint, estes componentes não vieram de nenhuma Ata — são achados de leitura direta de diagrama, sem confirmação verbal nas sessões. Tratar como achado de evidência documentária, não como achado validado com a área responsável.
| Componente | Papel | Observações |
|---|---|---|
| Microsoft Purview | Governança e políticas de segurança de dados — conecta ao Eng. de Dados e à camada de governança do Data Lake/Databricks. | Ambiente PRD; não mencionado em nenhuma Ata até 04/08/2026, apesar de aparecer com posição central no diagrama do cliente |
| Azure Key Vault | Cofre de segredos do ambiente de publicação DevOps (DEV/HMG/PRD) do pipeline de dados. | Escopo exato (quais credenciais/segredos) não detalhado no diagrama |
| Entra ID Energisa | Identidade e SSO+MFA (SAML 2.0) para acesso de analistas de dados ao Power BI. | Distinto do AD Energisa ADMS (linha abaixo) e do LDAP corporativo (seção D, autentica os brokers Kafka) — são três provedores de identidade diferentes, sem relacionamento documentado entre eles até aqui |
| AD Energisa ADMS (On-Prem AD) | Active Directory on-premises específico, faz SSO para os Adapters do ADMS (SMN/FUI/GNT). | Separado do Entra ID (cloud) — autênticação do lado OT/DMZ do ADMS é local, não federada com a nuvem |
| Qualys | Executa DAST (Dynamic Application Security Testing) sobre os componentes do pipeline de dados. | SaaS — acionado a partir do ambiente de publicação DevOps |
| SonarQube | Análise estática de código (SAST) no pipeline CI/CD do Azure DevOps Service (subscription GEAR). | Não aparece em nenhum outro artefato do assessment antes desta leitura |
| JFrog XRay | Análise de composição de software (SCA) sobre os artefatos do JFrog Artifactory, no mesmo pipeline CI/CD. | Complementa a entrada "JFrog Artifactory + X-Ray" já existente na seção E — aqui confirmado com o detalhe de fluxo (RHEL 8 self-hosted agents → Artifactory → XRay) |
G. Itens do Tech Stack corporativo revisados e não incorporados a este blueprint¶
O catálogo
Tech Stack.pdfcobre a plataforma de desenvolvimento inteira da Energisa — a maior parte do conteúdo (IDEs, linguagens, frameworks de frontend, ferramentas de design, storage não estruturado multi-cloud, FinOps etc.) não tem ligação confirmada com a integração ADMS e foi deliberadamente deixado de fora, pelo mesmo critério de escopo já usado neste documento (nota metodológica, no topo). Os itens abaixo são os que tinham alguma proximidade temática com o que já documentamos, mas foram revisados e não incluídos — registrados aqui para que a decisão de escopo fique explícita, não silenciosa.
| Item do Tech Stack | Por que foi considerado | Por que não foi incluído |
|---|---|---|
| Istio / Red Hat OpenShift Service Mesh | Relacionar-se-ia diretamente ao achado D6 (tráfego interno do Kafka saindo por rota externa via F5/API Gateway em vez de roteamento interno do cluster) — se existisse aplicado ao barramento, mudaria a leitura desse achado. | Resolvido (05/08/2026): confirmado por Norberto que Istio/Red Hat OpenShift Service Mesh é "intenção de uso futuro" — não está em uso hoje. Consistente com o ícone de status do catálogo (Tech Stack.pdf), agora lido com a legenda confirmada: ambos os itens têm ícone Experimental. Conclusão: o achado D6 (tráfego interno do Kafka saindo por rota externa via F5/API Gateway) não é mitigado hoje por Service Mesh — mantém-se válido como está registrado na matriz de riscos, sem necessidade de revisão. |
| Redis | Apareceria como banco in-memory não documentado em C.0. | Nenhuma evidência (Ata, diagrama ou relatório real) liga Redis a qualquer componente do fluxo ADMS documentado até aqui. Nota (05/08/2026): o catálogo marca Redis com ícone Referência (em uso confirmado em algum lugar da Energisa) — mas isso não constitui evidência de uso no fluxo ADMS especificamente; mantido fora do escopo deste blueprint pela mesma razão. |
| PostgreSQL | Apareceria como banco relacional não documentado em C.0. | Mesma razão do Redis — sem ligação confirmada ao ADMS. Catálogo marca PostgreSQL com ícone Purpose-Driven (uso pontual, não padrão geral) — reforça a leitura de que não é um componente central do ecossistema de dados corporativo. |
| RabbitMQ / Apache Kafka (item separado do Confluent Kafka no catálogo) | Motivou a investigação de uma hipótese de segundo broker Kafka para o CDC do ADMS, levantada a partir do rótulo "Apache Kafka" no diagrama GEAR-222139. | Hipótese do segundo broker para o CDC do ADMS investigada a fundo e descartada: o conector sqlserver-source-adms-cpy do diagrama bate tabela a tabela com o mesmo conector já catalogado no cluster Confluent de produção real (ver B.3). A única menção real a "Kafka open source" nas transcrições (Ata 10, 100-openshift-confluent-kafka.vtt) é uma sugestão do próprio consultor para ambientes de dev/teste, nunca confirmada como implementada, sem relação com o fluxo de CDC do ADMS. Não formalizado como achado — mantido apenas em registro de discussão com o cliente, fora deste documento. Distinto disto: um cluster Apache Kafka open source real existe, confirmado por Norberto — mas dedicado à stack ELK/telemetria, não ao CDC do ADMS; ver seção E, linha ELK, para o achado formalizado. RabbitMQ segue sem qualquer evidência de uso ligado ao ADMS. |
Legenda de ícones do Tech Stack.pdf confirmada por Norberto (05/08/2026): pino teal = Referência (em uso ativo); seta circular vermelha = Legado; chevron azul
<>= Experimental; anel roxo = Purpose-Driven (uso pontual/específico, não padrão geral). Com a legenda em mãos, uma releitura do catálogo revela divergências entre o status declarado no catálogo corporativo e o uso confirmado por este assessment em produção: Azure Key Vault, Azure Purview, Entra ID, RHSSO, Databricks, Delta Lake e Azure Data Lake aparecem com ícone Experimental no catálogo, apesar de todos aparecerem em uso ativo e confirmado no diagrama GEAR-222139 e/ou nas seções C e F deste blueprint. O mesmo vale para F5 Networks (Experimental no catálogo, porém documentado como infraestrutura core de produção desde a sessão de rede/telecom) e Azure Data Factory (Experimental no catálogo, porém em uso confirmado no pipeline de dados, seção C.1). Adicionalmente, o item "Azure Data Lake" aparece no PDF com o texto visualmente riscado (strikethrough) — possível indicação de descontinuação/renomeação no catálogo, não confirmada. Não se está resolvendo esta divergência silenciosamente: uma hipótese plausível é que "Experimental" no catálogo reflita o estágio de adoção como padrão corporativo (ainda não obrigatório/generalizado), não a ausência de uso real por times específicos — mas isto é uma interpretação nossa, a confirmar com a área responsável peloTech Stack.pdfantes de ser tratada como fato. Importante (05/08/2026): esta observação ganhou mais peso após o próprio cliente informar que oTech Stack.pdfestá desatualizado (ver planilha de inventário completo gerada para revisão do cliente) — as divergências acima podem, portanto, refletir simplesmente defasagem do catálogo em relação ao uso real, e não um critério de "Experimental" diferente do que se presumia.
Como ler este blueprint¶
As camadas acima refletem a ordem de dependência típica de uma chamada ou evento real no ecossistema: um sistema de negócio (A) publica ou consome via um adapter ou o barramento (B), que eventualmente alimenta a camada de dados/nuvem (C); tudo isso roda sobre a infraestrutura (D) e é observado pela camada E. A camada F cobre identidade/segurança especificamente do pipeline de dados, lida direto de um diagrama do cliente — tratamento à parte por ter maturidade de evidência diferente do resto do documento. Este blueprint documenta apenas o que existe hoje — recomendações e ideias discutidas nas sessões (RPA Adapter, health check automatizado no F5, Event Store) foram deixadas de fora deliberadamente; elas continuam registradas nos artefatos de origem e no questionário de mitigação de lacunas, mas não compõem este inventário.
Vários componentes desta lista já aparecem na matriz de riscos e no questionário de mitigação de lacunas produzidos anteriormente neste assessment — em especial os marcados sem "equipe formalmente responsável" (materialização de views, Kafka Connect Sink em Go) e os de topologia/failover não confirmados (Azure Runtime Integrator, Data Guard, OpenShift DR).
Nota de revisão (05/08/2026, v0.2 → v0.3): incorporados os achados do catálogo corporativo
Tech Stack.pdfe do diagramaGEAR-222139-Frente Relatório ADMS. Adicionada a seção F (identidade/segurança/DevSecOps do pipeline de dados) e a seção G (itens revisados e conscientemente não incluídos, com justificativa). Identificada uma segunda instância de Azure DevOps (Service/SaaS, subscription GEAR) distinta do Azure DevOps Server on-premises já documentado — nota adicionada à seção E. Adicionada linha de VPN Gateway em D, com divergência sinalizada (não resolvida) contra a leitura anterior de C.1 sobre uso de internet pública. Confirmado, via cruzamento com relatório real de produção, que o conectorsqlserver-source-adms-cpydo diagrama GEAR é o mesmo já catalogado no cluster Confluent (B.3) — descartada a hipótese de um segundo broker Kafka open source para o CDC do ADMS. Nenhuma linha de A–E teve seu conteúdo anterior removido.Nota de revisão (05/08/2026, v0.3 → v0.4): incorporadas 5 respostas diretas de Norberto (Energisa) a perguntas em aberto deste assessment. (1) Confirmado cluster Apache Kafka open source real, dedicado à stack ELK/telemetria — distinto do Confluent Kafka do barramento e da hipótese de segundo broker para o CDC do ADMS (já descartada) — achado formalizado na seção E, linha ELK. (2) Versão do SQL Server: Norberto respondeu 2022, o que contradiz diretamente o rótulo 2019 do diagrama GEAR — registrado como divergência aberta entre duas fontes do próprio cliente em C.0, não resolvido silenciosamente. (3) Istio/Red Hat OpenShift Service Mesh confirmado como não utilizado hoje (intenção futura) — seção G atualizada, achado D6 mantido sem mitigação por Service Mesh. (4) Legenda de ícones do
Tech Stack.pdfconfirmada (Referência/Legado/Experimental/Purpose-Driven) — releitura do catálogo identificou divergências entre o status "Experimental" de vários itens (Key Vault, Purview, Entra ID, RHSSO, Databricks, Delta Lake, Azure Data Lake, F5 Networks, Data Factory) e seu uso confirmado em produção por este assessment; registrado como observação em aberto na seção G, não como erro do catálogo. (5) Confirmadas como deliberadas as duas instâncias de Azure DevOps — a instância SaaS é dedicada à EDP (Energisa Data Platform), usada pelo time de Dados; sigla resolvida por Castellani em complemento a esta mesma rodada (05/08/2026) — não é a empresa EDP - Energias de Portugal. Adicionalmente, um fragmento de resposta pouco claro ("O vpc gtw -e via internet") foi registrado em D como interpretação provisória (não confirmada) da divergência VPN GW2 vs. internet pública. O cliente também informou que o próprioTech Stack.pdfestá desatualizado — nota adicionada à seção G; foi gerada uma planilha à parte com o inventário completo do catálogo para o cliente revisar e atualizar os status. Nenhuma linha de A–F teve seu conteúdo anterior removido.