Ata 14 · Engenharia de Dados: Ingestão por Captura de Mudanças, Data Lake em Camadas, Processamento no Databricks, Qualidade de Dados, Consumo Regulatório e Resiliência da Integração com a Nuvem (31 de julho de 2026)

Ata consolidada a partir do relatório técnico produzido sobre a sessão e da transcrição integral da gravação, com unificação dos temas e preservação dos pontos que dependem de validação no áudio original.

Data	31 de julho de 2026 (sexta-feira)
Horário	15h03 às 16h21, horário de Brasília
Duração	1h17min53s
Plataforma	Microsoft Teams (reunião remota, com gravação e transcrição automática)
Natureza	Sessão técnica de levantamento com a equipe de engenharia de dados
Tema	Cadeia de dados do ADMS até o consumo analítico e regulatório: mecanismos de ingestão, landing, camadas do data lake, orquestração no Databricks, qualidade de dados, APIs regulatórias e resiliência da integração entre o ambiente próprio e a nuvem
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Elaborado por	Syntropy Labs
Fontes	Relatório técnico consolidado da sessão e transcrição integral da gravação do Microsoft Teams

1.15.1. Identificação e contexto da sessão

1.15.1.1. Posicionamento no assessment

A sessão foi aberta com a contextualização do trabalho: a consultoria conduz uma avaliação ponta a ponta das integrações que envolvem o ADMS, e não apenas dos relatórios, e o levantamento já havia envolvido cerca de treze a catorze equipes. Foi explicitado que o propósito é capturar as informações de cada frente, formar a visão da situação atual e, na sequência, propor soluções para as questões identificadas.

Como nas sessões anteriores, as equipes foram convidadas a apresentar primeiro o fluxo de trabalho e, em seguida, as dores percebidas. A coordenação registrou que algumas dores já eram conhecidas de conversas anteriores, mas pediu que fossem repetidas, além de eventuais questões adicionais.

1.15.1.2. Contexto organizacional da equipe

Um elemento relevante de contexto foi apresentado na abertura: a equipe de engenharia de dados foi recentemente incorporada à estrutura de arquitetura, movimento já registrado na Ata 12 como consequência da assunção da frente de relatórios pela arquitetura em conjunto com DevOps. Foi registrado que os profissionais estavam há aproximadamente três semanas nessa configuração, o que explica algumas remissões entre os participantes durante a sessão.

Foi também descrita a trajetória anterior da área: antes da constituição da equipe de dados, a operação funcionava como um BI tradicional, no qual a mesma equipe realizava a transformação, a limpeza e a construção dos relatórios. O modelo de atuação era mais próximo do ambiente próprio, apoiado em ferramenta de extração e carga, e a criação da plataforma de dados corporativa foi apresentada como um dos principais desafios assumidos, uma vez que existiam apenas repositórios parciais, sem estrutura consolidada.

1.15.1.3. Limites da sessão

A identificação automática de falantes não permite associar com segurança as vozes aos nomes citados, de modo que o registro cronológico do Anexo A atribui as falas por papel funcional. Diversos termos técnicos, nomes de produtos e números foram capturados de forma foneticamente imprecisa e estão relacionados no Anexo B. Não foram apresentadas, na sessão, medições consolidadas de latência ponta a ponta, inventário de fluxos por classe de atualização nem documentação da topologia do componente de integração com a nuvem.

1.15.2. Participantes e áreas envolvidas

Norberto da Silva Prado	Energisa, arquitetura e integração. Contextualização do assessment, apresentação das equipes, descrição do fluxo de captura e articulação das agendas subsequentes.
Luan	Energisa, arquitetura. Oriundo da equipe de dados, responde temporariamente pela liderança da frente de engenharia de dados do ADMS. Conduziu a explicação sobre o Databricks, as camadas do lake, a orquestração, os custos e as dores percebidas.
Douglas	Energisa, engenharia de dados. Atuação integrada à arquitetura na frente do ADMS.
Victor	Energisa, engenharia de dados. Responsável por ingestão e transformação, com apoio à construção dos relatórios. Detalhou o funcionamento das APIs regulatórias.
Priscila	Energisa, engenharia de dados. Apoio temporário à equipe de arquitetura no projeto do ADMS, com atuação em engenharia e visualização. Detalhou os tratamentos aplicados na camada intermediária.
João Carlos Franco Castellani	Syntropy Labs. Condução da análise arquitetural sobre ingestão, checkpoint, reprocessamento, qualidade de dados, criticidade e resiliência.
Vladimir Morozowski de Sousa	Syntropy Labs. Condução, gestão e acompanhamento do assessment e registro da sessão.

Foram citados, sem participação direta na sessão:

• Felipe Rosa Aguiar, com retorno de férias previsto para o dia seguinte à sessão.
• Equipe de DevOps, que apoiou o desenvolvimento do serviço de ingestão e que deverá ser ouvida em sessão específica.
• Equipe de barramento e conectores, responsável pela configuração dos conectores de captura.
• Equipe de administração de banco de dados, a ser consultada sobre a alternativa de extração incremental no Oracle.
• Área responsável pelo levantamento dos requisitos regulatórios, que traduz as exigências do órgão regulador para linguagem técnica.
• Desenvolvedor sênior da frente de força de trabalho, cuja sessão estava pendente de agendamento em razão de férias.

1.15.3. Resumo executivo

A sessão mapeou a cadeia completa que conecta as bases do ADMS e dos sistemas corporativos ao data lake e, a partir dele, aos relatórios operacionais e às entregas regulatórias. O desenho combina tecnologias modernas e capacidade de escala, mas a criticidade operacional e regulatória do conteúdo exige elevar o nível de engenharia em quatro eixos: resiliência da integração, capacidade de reprocessamento, qualidade de dados e observabilidade.

Resiliência da integração	A ligação entre o ambiente próprio e a nuvem depende de um componente intermediário de execução, em cluster com contingência, com tráfego pela internet pública.	Uma falha nesse elo interrompe ingestão, processamento, qualidade e disponibilização simultaneamente.	Documentar e testar o caminho completo, com failover e retomada, e avaliar conectividade dedicada.
Retenção da área de aterrissagem	Regra uniforme de expurgo em sete dias para os eventos recebidos.	Incidentes descobertos tardiamente não podem ser reprocessados.	Substituir a regra única por classes de retenção conforme criticidade e obrigação regulatória.
Qualidade de dados	Existem harmonização, padronização e conversão de tipos, mas não há framework formal de regras, quarentena e reconciliação.	Um pipeline pode concluir com sucesso enquanto os valores publicados estão semanticamente incorretos.	Implantar regras mínimas de completude, validade e consistência, com quarentena e indicadores.
Evolução de esquema	Alterações de tipo, remoção de campos ou mudança de regra na origem quebram pipelines. A prevenção é incipiente.	Interrupção do fluxo percebida frequentemente após a reclamação do consumidor.	Contratos de dados versionados, validação automatizada e alerta preventivo.
Consumo regulatório	O projeto de indicadores regulatórios opera em micro-batch, com defasagem máxima aceita de 30 minutos e três APIs de exposição.	Atraso ou dado incorreto em ambiente altamente regulado implica penalidade.	Definir objetivos de atualidade e disponibilidade por fluxo e mecanismo de reenvio corrigido.
Reprocessamento e idempotência	Os conectores estão ativos apenas para o fluxo corrente. Não há mecanismo de reconstrução para além da janela de sete dias, e a idempotência dos consumidores não está implementada.	Recarga histórica indisponível e risco de duplicidade em caso de reenvio.	Testar captura incremental de estado nos conectores e exigir idempotência como requisito de arquitetura.
Custo de processamento	O custo do ambiente de processamento ficou acima do planejado e foi objeto de otimização nos dois meses anteriores.	Pressão orçamentária sobre a expansão da plataforma.	Medir custo por pipeline e comparar as modalidades de execução conforme o prazo real exigido.
Alternativa ao licenciamento de replicação	O upgrade da ferramenta de replicação para a capacidade voltada a grandes volumes foi estimado em valor considerado inviável para um único projeto.	Alguns fluxos precisam reler janelas históricas extensas no banco de origem.	Persistir os eventos capturados em tabela paralela e extrair de forma incremental.

Síntese do assessment A dor declarada pela própria equipe não está no processamento, e sim na camada de integração entre o ambiente próprio e a nuvem. O argumento apresentado é preciso: preocupações com processamento e com qualidade de dados dizem respeito ao que já chegou ao destino, mas se o elo intermediário falha, não há processamento, não há qualidade e não há dado. Esse diagnóstico converge com o que foi levantado na Ata 13, na qual se registrou que o tráfego para a nuvem ocorre pela internet pública, sem enlace dedicado, e que a avaliação de alternativas está em curso. Trata-se, portanto, do mesmo ponto visto de duas perspectivas: a de quem opera a rede e a de quem depende dela para entregar dado regulatório.

1.15.4. Visão geral da arquitetura de dados

A cadeia discutida pode ser consolidada no seguinte encadeamento lógico, das fontes ao consumo.

Fontes	SQL Server do ADMS localizado na DMZ, bancos Oracle corporativos e demais bases.	Sistemas transacionais e operacionais que originam os dados e os eventos.
Captura	Captura de dados alterados no SQL Server, conector do barramento com plugin de leitura, conector para bases Oracle e XStream sobre a ferramenta de replicação.	Registrar inserções, atualizações e exclusões, evitando releituras históricas completas.
Integração	Serviço próprio desenvolvido em Go, componente de execução de integração instalado no ambiente próprio e serviço de orquestração de dados na nuvem.	Mover os dados entre o ambiente próprio, a DMZ e a nuvem.
Área de aterrissagem	Armazenamento de objetos na nuvem, com os eventos gravados em formato de serialização com esquema.	Persistência inicial dos eventos e base para o controle de posição e o reprocessamento.
Processamento	Databricks, com fluxos orquestrados, clusters efêmeros de trabalho e clusters contínuos.	Executar transformação, harmonização, enriquecimento e agregação.
Governança	Catálogo unificado da plataforma de processamento.	Catalogação, controle e governança dos objetos de dados.
Compartilhamento	Mecanismo de compartilhamento de tabelas e camada de consulta SQL.	Exposição e virtualização dos dados para consumo.
Visualização	Power BI, atualmente sob a plataforma unificada da Microsoft.	Modelos semânticos, cache e relatórios com atualização agendada.
Consumo regulatório	APIs do projeto de indicadores regulatórios.	Disponibilização de indicadores e fotografias operacionais ao órgão regulador em ciclos de até 30 minutos.

1.15.5. Mecanismos de ingestão

1.15.5.1. Captura a partir do SQL Server do ADMS

Foi descrita a captura de dados alterados configurada no banco SQL Server do ADMS, localizado na DMZ. O fluxo utiliza um conector de origem, com o plugin de leitura das mudanças, publica no barramento e, do outro lado, um componente de destino grava o conteúdo na área de aterrissagem do data lake.

Foi confirmado na sessão o formato dos eventos: o conteúdo registra as mudanças de estado, identificando a operação realizada e trazendo a representação do registro antes e depois da alteração, além dos casos de inserção e de exclusão. O formato foi descrito como espelho do esquema de eventos, o que preserva o histórico de mudanças.

1.15.5.2. Serviço próprio de gravação

Origem do serviço em Go O componente que consome do barramento e grava na área de aterrissagem não é o conector comercial esperado. Foi relatado que a solução original demandaria a aquisição do conector do fabricante da plataforma de streaming, mas a aquisição não se concretizou no prazo necessário, e o projeto tinha um compromisso de natureza regulatória com data definida. Diante disso, a equipe interna, com apoio de DevOps, desenvolveu um serviço em Go que desempenha essa função. É o segundo componente crítico criado sob pressão de prazo identificado no assessment, ao lado do procedimento de materialização das views registrado na Ata 12, e merece o mesmo tratamento de propriedade formal, documentação e sustentação.

1.15.5.3. Demais mecanismos

• Componente de execução de integração instalado no ambiente próprio, que se conecta às bases Oracle e captura informações para a nuvem.
• Conector adicional que realiza captura de mudanças sobre determinados bancos Oracle, citado como em uso em uma das frentes.
• Serviço de orquestração de dados na nuvem, utilizado na ingestão de tabelas a partir das bases relacionais.
• Uso do barramento sobretudo para evitar releituras volumosas por janela de data, e não necessariamente por exigência de streaming ponta a ponta.

Essa última observação é relevante para o diagnóstico consolidado: ela confirma, pela perspectiva de quem consome, o achado registrado na Ata 10 de que parte das cargas encaminhadas ao barramento tem natureza de movimentação de dados, e não de evento operacional em tempo real.

1.15.6. Área de aterrissagem, controle de posição e retenção

1.15.6.1. Mecânica de consumo

O ambiente de processamento consome os dados da área de aterrissagem, que reside em armazenamento de objetos. O mecanismo de controle de posição registra, por diretório, até onde o fluxo já processou, de modo que cada execução retoma a partir do último evento consumido, sem reprocessar automaticamente o que já foi tratado.

1. Os eventos são gravados na área de aterrissagem à medida que chegam.

2. Na execução seguinte, o processo consulta o registro de posição correspondente àquele diretório.

3. São processados todos os eventos existentes a partir daquele ponto.

4. O registro de posição é atualizado ao final do processamento bem-sucedido.

5. Na execução seguinte, o ciclo recomeça a partir da nova posição registrada.

Foi esclarecido que o controle de posição é mantido por diretório, e que as partições correspondem a estruturas de pastas, de modo que cada pasta possui o seu próprio registro. Existe particionamento na área de aterrissagem, mas os participantes não souberam confirmar a estratégia exata configurada, o que integra as evidências solicitadas.

1.15.6.2. Retenção e janela de reprocessamento

Retenção atual	Regra de limpeza dos eventos da área de aterrissagem em sete dias, aplicada de forma uniforme.
Reprocessamento dentro da janela	É possível reposicionar o registro de posição e reprocessar os eventos ainda presentes, com a equipe dispondo de sete dias para identificar e corrigir o problema.
Reprocessamento fora da janela	Torna-se inviável, porque os eventos já foram expurgados. A lacuna foi reconhecida explicitamente na sessão.

Caso concreto relatado Foi registrado um caso em que houve necessidade de capturar novamente os dados para reprocessamento e a janela de sete dias já havia sido ultrapassada, de modo que o conteúdo estava expurgado e não foi possível recuperá-lo. A pergunta feita na ocasião, sobre como recuperar o que já havia sido perdido, é exatamente a que o mecanismo de persistência histórica de eventos discutido na Ata 10 endereça. A convergência entre as duas sessões reforça a recomendação: sem repositório histórico durável, a retenção do barramento e da área de aterrissagem tende a ser ampliada por precaução, o que eleva o custo sem resolver o problema de fundo.

1.15.7. Processamento e camadas do data lake

A cadeia segue o padrão de camadas sucessivas de refinamento. Foi esclarecido que um mesmo fluxo pode executar todas as etapas em uma única execução orquestrada: o cluster sobe, processa a área de aterrissagem, grava na camada bruta, aplica os tratamentos na camada intermediária, realiza a agregação na camada final e é encerrado.

Bruta	Representação próxima da fonte, descrita como uma réplica do conteúdo original, mantendo inclusive a separação por empresa existente nos bancos comerciais.	Conversão dos tipos da fonte para os tipos suportados na plataforma. Não há agrupamento nem regra de negócio nessa camada.
Intermediária	Dado tratado, harmonizado e enriquecido para uso corporativo.	Limpeza, agrupamento por empresa, inclusão dos identificadores, códigos e siglas das empresas, ajuste de nomenclatura de colunas e regras simples de negócio.
Final	Dado preparado para consumo analítico.	Agregações, organização em dimensões e fatos, tabelas amplas e métricas prontas para publicação.

Foi esclarecido que a tipagem é aplicada no momento em que o dado é persistido em formato estruturado, uma vez que a tipagem da origem difere da adotada na plataforma. Para as ingestões realizadas pelo serviço de orquestração de dados, foi descrita uma etapa intermediária que consulta os tipos da tabela de origem e aplica um mapeamento de correspondência previamente construído, de modo que o dado permanece fortemente tipado no destino, com conversão controlada.

1.15.8. Orquestração, clusters, latência e custos

Micro-batch	O projeto de indicadores regulatórios executa em micro-batch a cada 20 minutos.
Streaming	Foram citados sete fluxos com cluster ligado continuamente, descritos como o cenário mais próximo de tempo real existente hoje. Ao mesmo tempo, foi registrado que ainda não existe caso consolidado de tempo real ponta a ponta até a visualização.
Cluster efêmero	Tempo típico de inicialização entre três e cinco minutos.
Execução sem servidor	Inicialização praticamente imediata, com custo superior ao da modalidade efêmera.
Orquestração	Realizada pelos fluxos de trabalho da própria plataforma, executando o pipeline completo do início ao fim.
Dependências	Fluxos transversais, agendados por tempo, coordenam conjuntos de tabelas provenientes de múltiplas fontes, inclusive combinando cargas contínuas e em lote.
Ociosidade	Não foram relatados casos relevantes de cluster iniciado sem conteúdo a processar, porque as tabelas encaminhadas ao lake possuem alta movimentação.
Custos	O custo ficou acima do planejado e foi objeto de trabalho de redução nos dois meses anteriores à sessão, com resultado descrito como contornado.

A latência total percebida pelo consumidor resulta da soma de captura, transporte, espera do agendamento, inicialização do cluster e tempo de transformação. Não foi apresentada medição consolidada dessa cadeia, especialmente no trecho entre o ambiente próprio e a nuvem, o que integra as evidências solicitadas.

1.15.8.1. Dependências entre fontes e completude

Foi discutido o cenário em que uma métrica depende de tabelas provenientes de sistemas heterogêneos, que chegam em momentos distintos. A pergunta colocada foi como se assegura que o dado publicado esteja completo, e não parcialmente formado.

• Para fluxos isolados, sem dependência externa, o pipeline pode ser executado integralmente na chegada do lote.
• Para fluxos dependentes, existem processos transversais, acionados por tempo, que atualizam os conjuntos de tabelas em sequência, contornando o problema de ordem de chegada.
• O projeto de indicadores regulatórios foi citado como caso concreto de dependência entre dados do ADMS e de outros sistemas corporativos.
• A identificação dessas dependências exige estudo prévio e alinhamento com a área de negócio para definir a completude mínima antes da publicação.
• Foi citado também o caso em que uma tabela é consumida em fluxo contínuo e outra em lote, o que exige gestão específica.

1.15.9. Camada de visualização e consumo analítico

O consumo analítico ocorre principalmente entre as camadas intermediária e final, preferencialmente na final. A ferramenta de visualização monta um modelo semântico próprio e trabalha por importação, com carga para o seu próprio cache, e os usuários acessam as informações a partir desse cache. Não foi identificada conexão direta e contínua à base.

• A opção pela importação foi justificada também por custo: o modelo semântico é montado do lado da camada de visualização para aproveitar o ambiente já contratado, evitando concentrar todo o consumo na plataforma de processamento.
• Os agendamentos de atualização variam conforme o caso de uso, podendo ser várias vezes ao dia, diários ou semanais.
• Não existe hoje caso de atualização em tempo real na camada de visualização. Foi registrado que, mesmo que o dado chegasse em tempo real ao lake, ainda haveria a carga para o cache.
• Foi mencionada a escala aproximada de oito mil relatórios construídos na organização como um todo, dos quais cerca de quinhentos são administrados diretamente pela TI.
• A estimativa verbal apresentada indica mais de vinte mil colaboradores, com pelo menos dez mil consumindo relatórios, e três capacidades licenciadas da plataforma de visualização.

A evolução desejada, registrada na sessão, é integrar a atualização da camada de visualização ao próprio fluxo de trabalho da plataforma de processamento: concluído o pipeline com sucesso, o refresh seria disparado automaticamente, eliminando a defasagem adicional entre o dado pronto e o relatório atualizado. Foi mencionada também a possibilidade de estabelecer espelhamento entre o catálogo da plataforma de processamento e o ambiente de visualização, com ligação direta entre os dois por identidade de serviço.

1.15.10. Licenciamento Oracle e alternativa à replicação para grandes volumes

A equipe relatou possuir contrato de licenciamento ilimitado da Oracle, que contempla o uso da ferramenta de replicação em configuração limitada, voltada à movimentação entre bancos. A ampliação dessa licença para a modalidade destinada a grandes volumes, que permitiria entregar os eventos diretamente ao lake, foi estimada verbalmente em valor da ordem de seis milhões de reais, considerado inviável de ser absorvido por um único projeto.

A consequência prática é direta: sem essa capacidade, alguns fluxos precisam consultar janelas históricas extensas nas bases Oracle, chegando a reler o último ano de dados para atualizar o conteúdo no lake, o que eleva o custo e a carga sobre o ambiente de origem.

1.15.10.1. Contorno em avaliação

1. Habilitar a captura de mudanças sobre uma tabela específica de grande volumetria.

2. Persistir os eventos capturados em uma tabela paralela no próprio banco Oracle, em lugar de encaminhá-los ao lake.

3. Fazer o serviço de orquestração de dados ler essa tabela paralela, de tamanho muito menor, em lugar de reler a base histórica completa.

A abordagem foi descrita como um estudo em andamento com resultados aparentemente positivos. Foi observado na sessão que o arranjo equivale a manter a captura ativa, invertendo apenas o sentido: em lugar de a ferramenta entregar o conteúdo, o consumidor vai buscá-lo.

1.15.10.2. Extração incremental por marcador temporal

A consultoria levantou um refinamento dessa alternativa: acrescentar um campo de marcador temporal à estrutura de eventos persistida, ainda que a tabela de origem não o possua. Com esse campo, a extração passa a ser incremental, consultando apenas o que ocorreu após o último marcador processado, sem depender de estrutura preexistente no modelo de dados do fornecedor.

A viabilidade técnica foi considerada plausível pelos participantes, com a ressalva de que a possibilidade de acrescentar colunas nesse contexto precisa ser confirmada, uma vez que versões mais antigas do mecanismo poderiam não oferecer esse recurso. Ficou acordado validar o ponto com a equipe de administração de banco de dados.

Ponto contratual a verificar Foi levantada na sessão uma questão que extrapola a técnica: contratos de licenciamento ilimitado normalmente permitem instalar em qualquer ambiente, mas as condições de uso em nuvem podem ter validade restrita ao período do contrato, perdendo efeito no seu encerramento. Como o ambiente de homologação já reside em nuvem do próprio fabricante, o ponto merece verificação junto à área de licenciamento antes de qualquer decisão que amplie a dependência desse mecanismo.

1.15.11. Qualidade de dados, harmonização e evolução de esquema

1.15.11.1. Distinção conceitual estabelecida na sessão

Boa parte da conversa foi dedicada a distinguir quatro operações frequentemente tratadas como sinônimos, distinção relevante porque define o que existe hoje e o que ainda não existe.

Conversão de tipos	Adequar os tipos da fonte aos tipos suportados na plataforma de destino.	Implementada, com mapeamento de correspondência construído entre origem e destino.
Harmonização	Tornar o dado coerente semanticamente, padronizando códigos, siglas e nomenclaturas de modo que a mesma informação seja representada da mesma forma.	Implementada na camada intermediária, incluindo identificadores e códigos das empresas.
Enriquecimento	Acrescentar informação ao registro, relacionando-o a outras entidades ou incluindo atributos adicionais.	Implementado na camada intermediária.
Qualidade	Verificar completude, validade e consistência do dado, decidindo o que fazer com o que não atende às regras.	Não implementada como disciplina formal. Reconhecida como capacidade futura.

A discussão explorou exemplos concretos para delimitar o que a qualidade endereça: um cliente sem documento cadastrado, uma transação sem cliente associado, um campo obrigatório ausente. Foi apresentado o conceito de acompanhar o percentual desses casos como indicador, de modo que um crescimento acima do patamar habitual sinalize um problema de processo na origem, e não apenas um registro a descartar.

1.15.11.2. Prática desejável reconhecida

Quarentena em lugar de descarte Foi reconhecido pela própria equipe que o tratamento adequado para um registro que viola uma regra não é descartá-lo silenciosamente, e sim movê-lo para uma área de quarentena, onde alguém possa avaliar se ele deve ou não ser removido. A formulação registrada é precisa: com um processo de qualidade suficientemente robusto, o ideal seria identificar o caso e segregá-lo para decisão humana. A prática foi qualificada como desejável e ainda não implantada, descrita literalmente como um objetivo a alcançar.

1.15.11.3. Evolução de esquema e quebra de pipelines

Foi confirmado que alterações na origem quebram pipelines. As causas relatadas incluem mudança de tipo em um campo, remoção de campo que deixa de ser enviado e alteração de regra de negócio. Como a camada bruta espera uma estrutura tipada, uma alteração de tipo na origem impacta diretamente o processamento.

• As fontes Oracle incluem tanto sistemas desenvolvidos internamente quanto sistemas de terceiros, o que amplia a variedade de origens das mudanças.
• Existem alertas iniciais no processo de gestão de mudanças, comunicando que determinada alteração será feita em uma tabela e solicitando a verificação de impactos.
• Essa prática foi descrita como recente e ainda incipiente, com a própria equipe registrando que a previsibilidade de problemas está começando a se desenvolver.
• Existem casos em que o problema foi percebido apenas após a quebra do pipeline e a reclamação do consumidor.

Convergência com a Ata 12: a mesma classe de problema foi relatada pelas equipes de banco de dados sob a perspectiva do fornecedor do ADMS, que altera views e tabelas sem comunicação prévia. A diferença é que, ali, o efeito recai sobre a materialização das views e, aqui, sobre os pipelines do lake. O tratamento recomendado é o mesmo: contratos de dados versionados, detecção de desvio de esquema e comunicação prévia como requisito, e não como cortesia.

1.15.11.4. Monitoramento e resposta

Foi confirmado que não existe monitoração integrada de qualidade de dados, ponto que converge diretamente com o registrado na Ata 11 sobre a ausência de monitoramento previsto para os componentes da plataforma de dados. Existe uma equipe de sustentação disponível em regime contínuo, que é acionada em caso de problema e que, por sua vez, aciona a equipe de engenharia de dados para diagnóstico e correção.

Risco central identificado Em um ambiente com obrigação regulatória, um pipeline pode permanecer tecnicamente bem-sucedido enquanto os valores publicados estão semanticamente incorretos. Sem regras de qualidade e sem reconciliação, essa condição só é percebida pelo consumidor ou por reclamação. A atuação, portanto, é predominantemente reativa: a equipe é acionada depois que o efeito já se manifestou. Foi reconhecido na sessão que um processo de qualidade traria ganho de produtividade justamente por antecipar essa detecção.

1.15.12. Consumo regulatório e criticidade operacional

1.15.12.1. Projeto de indicadores regulatórios

O projeto de indicadores regulatórios foi apresentado como o principal exemplo de criticidade. O órgão regulador consome os dados por meio de APIs e aceita defasagem máxima de 30 minutos. O processo opera em micro-batch, com execução a cada 20 minutos, e não constitui streaming contínuo ponta a ponta.

Primeira API	Mantém o histórico das fotografias de até sete dias, por solicitação expressa do regulador, permitindo que o consumidor recupere o conteúdo caso perca dados na própria integração. Expõe a quantidade de incidentes em aberto no momento da consulta.
Segunda API	Disponibiliza a quantidade de atendimentos em aberto no momento da consulta. Não possui o mesmo requisito de histórico.
Terceira API	Consulta sob demanda, acionada apenas quando existe necessidade específica.
Reconstrução histórica	Apenas a primeira API suporta recuperação dentro da janela de sete dias. Para as demais, seria necessário construir mecanismo adicional, estruturando a captura do estado em uma data determinada.
Responsabilidade pelos requisitos	Existe área específica que levanta os requisitos junto ao regulador, converte-os para linguagem técnica e os encaminha às equipes.
Risco	Atrasos ou dados incorretos podem gerar penalidades em um ambiente descrito como altamente regulamentado.

Foi esclarecido um ponto de arquitetura relevante: o que a Energisa disponibiliza hoje é o estado corrente, ou seja, tudo o que está em aberto no momento da consulta. O histórico de sete dias existe apenas na primeira API e por exigência do consumidor, que precisa dessa janela para o caso de perder algum dado na própria integração. Um dos requisitos declarados é que o histórico permaneça armazenado na base do regulador, de modo que, em condições normais, não haveria necessidade de mantê-lo do lado da distribuidora.

Ao ser questionada sobre a capacidade de reenviar dados corrigidos e notificar o consumidor após a descoberta tardia de um erro, a equipe registrou que essa facilidade não existe pronta e precisaria ser construída, o que reforça a recomendação sobre reprocessamento e reconstrução histórica.

1.15.12.2. Criticidade operacional

Foi delimitado que a indisponibilidade do lake ou dos relatórios não é apenas um problema analítico. Foram citados aproximadamente sessenta relatórios relacionados ao contexto operacional, cobrindo desde o pré-operacional até o pós-operacional, incluindo o uso de dados para alocação de equipes no atendimento a contingências.

• O ADMS foi caracterizado como sistema de monitoramento da rede elétrica, com impacto direto na operação.
• O backlog de relatórios possui priorização por nível de criticidade, e os mais críticos são atendidos primeiro.
• De modo geral, os participantes classificaram como críticos os processos ligados ao ADMS, ainda que existam níveis distintos de prioridade.
• Uma indisponibilidade prolongada do lake impactaria tanto as entregas regulatórias quanto decisões operacionais, ainda que o ADMS permanecesse funcionando.

A distinção estabelecida na sessão é importante para o dimensionamento do risco: o ADMS continuar operando não significa que a operação esteja plenamente atendida, porque parte relevante da informação utilizada nos centros de operação chega por essa cadeia de dados.

1.15.13. Resiliência da integração entre o ambiente próprio e a nuvem

Ao ser questionada sobre as dores que mais impactam a área, a resposta foi direta e constitui o achado central desta sessão: a maior preocupação está na camada de integração entre o ambiente próprio e a nuvem.

Componente de execução	Não é uma máquina única. Foi informado que existe cluster com duas ou três máquinas, com contingência entre elas, embora a topologia exata não tenha sido confirmada.
Conectividade	O tráfego ocorre atualmente pela internet pública.
Enlace dedicado	Está em validação a possibilidade de adotar o serviço de conectividade dedicada do provedor de nuvem, cujo nome não foi recordado na sessão.
Latência	Não houve relato de problema nos fluxos em lote. Não foi apresentada medição conclusiva para os fluxos contínuos ou de tempo quase real.
Operação	Mesmo com o cluster, faltou detalhamento sobre failover, testes de contingência, monitoramento e acordo de nível de serviço do caminho completo.

Formulação do risco pela própria equipe O argumento apresentado merece registro literal em sua estrutura: processamento e qualidade de dados são preocupações legítimas, mas dizem respeito ao que já está do outro lado. Se o componente intermediário entre os dois ambientes cai, não há qualidade, não há processamento e não há dado. Trata-se, portanto, de um ponto único de falha para toda a cadeia analítica e regulatória, e é a dor de maior severidade declarada na sessão.

1.15.14. Reprocessamento, captura incremental de estado e idempotência

O tema foi levantado de forma articulada ao final da sessão, reunindo três lacunas relacionadas.

• Os conectores do barramento estão ativados hoje apenas para o fluxo corrente, sem mecanismo de reconstrução do estado anterior.
• Foi registrado o interesse em testar, com a equipe de barramento, a captura incremental de estado, que permitiria reconstruir o conteúdo sem recorrer a uma carga completa.
• Foi explicitado que qualquer mecanismo de reenvio exige que os consumidores tratem idempotência, sob pena de duplicidade, e foi reconhecido que isso não está implementado.
• Foi reconhecida a necessidade de ampliar ou segmentar a retenção dos eventos além dos sete dias para os fluxos críticos.
• Foi mencionada a persistência histórica de eventos, discutida em sessão anterior do assessment, como possível solução para o problema de recuperação além da janela.

A observação sobre idempotência partiu da própria coordenação da Energisa e converge com o achado registrado na Ata 09 sobre os consumidores dos eventos de ocorrência técnica. É a segunda frente independente a identificar a mesma lacuna, o que a consolida como requisito transversal de arquitetura, e não como característica desejável de um fluxo específico.

1.15.15. Governança de arquitetura e padronização de entregáveis

Após o encerramento da parte técnica, houve alinhamento sobre a necessidade de aproximar a consultoria da equipe de arquitetura, para compreender processos, restrições e padrões de entrega, de modo que as recomendações do assessment sejam aderentes ao modelo interno.

• A equipe de arquitetura é relativamente recente e está amadurecendo suas práticas.
• Até recentemente predominava a emissão de pareceres de arquitetura voltados a um projeto ou questão específica.
• A prática de registros de decisão arquitetural teria começado cerca de seis meses antes da sessão e ainda está em formatação.
• A base de conhecimento e os registros de decisão são considerados também para uso com a iniciativa interna de inteligência artificial.
• A consultoria pretende produzir recomendações, registros de decisão e modelos alinhados à base de conhecimento e aos padrões existentes.
• Foi solicitado o documento de domínios apresentado no início do trabalho, para validar restrições e conferir o que já foi extraído no assessment.

Foi registrado que o momento é adequado para essa aproximação, uma vez que o assessment entra na fase de geração do material e a própria equipe interna está estruturando seus padrões, o que permite convergência entre as duas frentes.

1.15.16. Dores e lacunas consolidadas

Integração entre o ambiente próprio e a nuvem	Interrupção total da cadeia de ingestão, processamento e disponibilização.	Alta
Retenção uniforme de sete dias na área de aterrissagem	Impossibilidade de reprocessar eventos descobertos tardiamente. Caso concreto já ocorrido.	Alta
Qualidade de dados não formalizada	Dados semanticamente incorretos podem ser publicados e detectados apenas pelo consumidor.	Alta
Alterações de esquema na origem	Quebra de pipeline por mudança de tipo, remoção de campo ou alteração de regra, com prevenção ainda incipiente.	Alta
Ausência de idempotência nos consumidores	Impede reenvio seguro e cria risco de duplicidade em qualquer reprocessamento.	Alta
Monitoramento fragmentado	Atuação reativa, com acionamento a partir da sustentação e não da detecção automática.	Média
Dependências entre fontes heterogêneas	Publicação parcial ou inconsistente caso as fontes não estejam completas.	Média
Custo do ambiente de processamento	Custo acima do planejado, com necessidade de avaliação entre modalidades de execução.	Média
Ausência de disparo integrado da camada de visualização	Defasagem adicional entre o dado pronto e o relatório atualizado.	Média
Custo do licenciamento de replicação para grandes volumes	Necessidade de releituras históricas volumosas e adoção de arquiteturas alternativas.	Média
Padrões de documentação arquitetural em amadurecimento	Risco de recomendações do assessment não aderentes ao padrão interno.	Média

1.15.17. Recomendações derivadas

As recomendações abaixo decorrem da análise da discussão e não representam decisões formalmente aprovadas na sessão.

Arquitetura de ingestão resiliente	Documentar e testar o caminho completo entre o ambiente próprio e a nuvem, incluindo o componente de execução, resolução de nomes, rede, firewall, conectividade dedicada, failover e retomada automática.
Política de retenção por criticidade	Substituir a regra uniforme de sete dias por classes de retenção fundamentadas em criticidade, obrigação regulatória e custo de reconstrução.
Reprocessamento e idempotência como requisitos	Estabelecer contrato arquitetural obrigatório para reprocessamento, deduplicação, chave de idempotência, controle de posição e captura incremental de estado.
Framework de qualidade de dados	Definir regras de completude, validade, consistência, unicidade, integridade e atualidade, com quarentena, indicadores e fluxo de decisão sobre os registros retidos.
Contratos de dados e evolução de esquema	Adotar contratos versionados entre fonte e consumidores, com validação automatizada na esteira e alerta preventivo para mudanças incompatíveis.
Observabilidade ponta a ponta	Consolidar métricas de ingestão, atraso, volume, erros, posição, duração, custo e qualidade em painéis operacionais com alertas.
Objetivos de nível de serviço por fluxo	Definir atualidade, disponibilidade e objetivos de recuperação para os fluxos regulatórios, para as APIs e para os relatórios operacionais.
Orquestração dirigida por eventos	Avaliar o disparo por conclusão do fluxo anterior em lugar de agendamentos independentes, especialmente entre o processamento e a camada de visualização.
Gestão de custo por caso de uso	Medir o custo por pipeline e comparar as modalidades de execução com base no prazo efetivamente exigido.
Governança de decisões	Registrar as decisões em registros de decisão arquitetural, manter os diagramas de fluxo de dados e associar riscos, alternativas e evidências do assessment.

1.15.18. Plano de ação sugerido

P0	Mapear e validar a alta disponibilidade do componente de integração e a conectividade entre o ambiente próprio e a nuvem	Arquitetura, nuvem, redes, dados e DevOps	Diagrama, testes de failover, objetivos de recuperação e riscos
P0	Definir política de reprocessamento e de retenção para os fluxos regulatórios e críticos	Dados, barramento, arquitetura e área de requisitos regulatórios	Política de retenção e procedimento de reprocessamento
P0	Mapear a linhagem e as dependências do projeto de indicadores regulatórios	Dados, negócio e área de requisitos regulatórios	Inventário de fontes, fluxos, APIs, prazos e controles
P1	Desenhar a versão mínima do framework de qualidade de dados e da quarentena	Engenharia de dados, governança e negócio	Regras mínimas, indicadores, alertas e fluxo de exceção
P1	Implementar governança de esquema e contratos de dados	Aplicações de origem, dados e DevOps	Contrato versionado e testes automatizados
P1	Testar a captura incremental de estado e a idempotência dos consumidores	Barramento, dados e consumidores	Prova de conceito com reprocessamento controlado e deduplicação
P1	Validar a alternativa de extração incremental no Oracle	Administração de banco, arquitetura, dados e licenciamento	Parecer técnico e econômico, com análise dos riscos contratuais
P2	Integrar o fluxo de processamento à atualização da camada de visualização	Dados e visualização	Disparo automático e redução da defasagem
P2	Padronizar os modelos de registro de decisão e de documentação	Arquitetura e consultoria	Modelos compatíveis com a base de conhecimento interna
P2	Criar modelo de gestão de custo por pipeline	Dados e nuvem	Custo unitário, orçamento, alertas e recomendações

1.15.19. Questões em aberto

• Qual é a topologia exata do componente de integração, seus nós, distribuição, failover, monitoramento e acordo de nível de serviço?
• Qual é o mecanismo de conectividade dedicada em avaliação e quais ganhos de disponibilidade e de latência são esperados?
• Como a área de aterrissagem é particionada e quais políticas diferenciadas de retenção devem ser aplicadas por criticidade?
• Quais fluxos são efetivamente contínuos, quais são micro-batch e quais são em lote?
• Qual é a latência ponta a ponta de cada classe de integração, da fonte ao consumidor?
• Quais regras de qualidade são obrigatórias antes da camada final e antes das APIs regulatórias?
• Como serão tratados evolução de esquema, teste de contrato e notificação prévia de alteração?
• Como reenviar dados corrigidos e informar o consumidor quando o erro for descoberto após a publicação?
• Quais consumidores suportam idempotência e quais precisariam ser adaptados?
• Qual é a viabilidade técnica e contratual da alternativa de extração incremental no Oracle, inclusive quanto ao uso em nuvem?
• Quais relatórios e processos possuem criticidade máxima e quais são os objetivos de recuperação correspondentes?
• Quais modelos e padrões oficiais devem ser utilizados para registro de decisão, parecer, recomendação e documentação?

1.15.20. Encaminhamentos registrados

1. O fluxo atual e seus componentes principais foram considerados suficientemente compreendidos para avançar no assessment.

2. Será realizada sessão com a equipe de DevOps sobre componentes de engenharia, repositórios, análise de código e automação.

3. Será realizada sessão com o desenvolvedor sênior, após o retorno de férias, para esclarecer dúvidas essenciais e enriquecer o desenho técnico.

4. Será realizada sessão específica com a equipe de arquitetura para alinhar processo, entregáveis, registros de decisão, modelos, domínios e integração com a base de conhecimento.

5. A viabilidade do marcador temporal incremental e da alternativa com a ferramenta de replicação será validada com a equipe de administração de banco de dados.

6. A captura incremental de estado e a idempotência serão avaliadas com a equipe de barramento e conectores.

7. O documento de domínios apresentado no início do trabalho será disponibilizado para conferência do que já foi extraído.

8. As transcrições e os documentos consolidados do assessment continuarão sendo depositados no repositório compartilhado.

1.15.21. Conclusão do assessment desta sessão

A sessão forneceu uma visão ampla e tecnicamente consistente da plataforma de dados associada ao ADMS. O desenho atual é moderno e escalável, com separação clara de camadas, orquestração estruturada e governança de catálogo. As lacunas identificadas não decorrem de escolhas tecnológicas inadequadas, e sim do estágio de maturidade de disciplinas que ainda não foram implantadas.

Quatro eixos concentram o risco. O primeiro é a resiliência da integração entre o ambiente próprio e a nuvem, apontada pela própria equipe como a maior preocupação, por constituir ponto único de falha para toda a cadeia. O segundo é a capacidade de reprocessamento, limitada pela retenção uniforme de sete dias e pela ausência de idempotência nos consumidores, com caso concreto de perda já registrado. O terceiro é a qualidade de dados, que hoje se restringe a harmonização e conversão de tipos, sem regras de consistência, quarentena ou reconciliação. O quarto é a observabilidade, que permanece reativa e sem integração com a monitoração corporativa.

A criticidade desses eixos é ampliada por dois fatores registrados na sessão. O primeiro é regulatório: existe obrigação de entrega com defasagem máxima de 30 minutos e penalidade associada ao atraso ou ao dado incorreto. O segundo é operacional: cerca de sessenta relatórios sustentam processos que vão do pré-operacional ao pós-operacional, incluindo a alocação de equipes em contingência, de modo que a indisponibilidade da cadeia de dados afeta a operação ainda que o ADMS permaneça funcionando.

Um padrão transversal merece registro: pela segunda vez no assessment identifica-se um componente crítico criado sob pressão de prazo e mantido em produção sem propriedade formal. O serviço de gravação em Go, aqui, e o procedimento de materialização das views, na Ata 12, compartilham a mesma origem e a mesma lacuna. Isso sugere que a recomendação sobre propriedade e sustentação de componentes customizados deve ser formulada como política, e não caso a caso.

Anexo A · Registro cronológico revisado da sessão

Registro cronológico revisado do conteúdo inteligível da sessão, com a marcação de tempo da gravação. Como a identificação automática de falantes não permite associar com segurança as vozes aos nomes, as falas são atribuídas por papel funcional. Saudações, problemas de acesso e de áudio, sobreposições, conversas paralelas e trechos corrompidos pelo reconhecimento automático de voz foram condensados ou omitidos, e os termos técnicos capturados de forma imprecisa foram normalizados quando o contexto permitiu identificação segura.

00:03:32 Coordenação Energisa: Abre a sessão apresentando os participantes da equipe de dados e registra que todos passaram a integrar a equipe de arquitetura em migração recente.

00:03:53 Coordenação Energisa: Contextualiza o assessment conduzido pela consultoria, com gestão e arquitetura, e informa que se trata de uma avaliação ponta a ponta das integrações que envolvem o ADMS, não restrita a relatórios.

00:04:03 Coordenação Energisa: Registra que já foram realizadas cerca de treze ou catorze conversas com equipes distintas, para entender a situação atual, identificar dores e compreender os fluxos.

00:04:26 Coordenação Energisa: Explica o método: capturar as informações para o levantamento, formar a visão da situação atual e, depois, propor soluções para as questões identificadas nas integrações.

00:04:45 Coordenação Energisa: Solicita que a equipe apresente primeiro o fluxo de trabalho e depois as dores, inclusive as já conhecidas.

00:05:14 Engenharia de dados: Apresenta-se como responsável por engenharia de dados, atuando junto à arquitetura.

00:05:34 Engenharia de dados: Apresenta-se como engenheiro de dados atuante na frente junto ao time de arquitetura, responsável pelos processos de ingestão e transformação e com apoio à construção dos relatórios.

00:05:45 Engenharia de dados: Contextualiza que, antes da constituição da equipe de dados, a operação funcionava como um BI tradicional, com a mesma equipe realizando transformação, limpeza e construção dos relatórios.

00:06:12 Engenharia de dados: Apresenta-se como engenheira de dados cedida temporariamente à equipe de arquitetura para o projeto, atuando em engenharia e em visualização.

00:06:32 Arquitetura Energisa: Apresenta-se como profissional oriundo da equipe de dados, atuando em arquitetura.

00:06:44 Arquitetura Energisa: Contextualiza a trajetória: desde agosto de 2024 o modelo de atuação era mais próximo do ambiente próprio, apoiado em ferramenta de extração e carga, e a mudança para arquitetura teve como objetivo a concepção da plataforma de dados corporativa, uma vez que existiam apenas repositórios parciais, sem estrutura consolidada.

00:07:26 Arquitetura Energisa: Informa que responde temporariamente pela liderança da frente de engenharia de dados do ADMS.

00:10:29 Coordenação Energisa: Inicia a apresentação do fluxo: existe captura de dados alterados configurada no banco do ADMS, que fica na DMZ e é um SQL Server.

00:10:37 Coordenação Energisa: Detalha os componentes: um conector de origem, com o plugin de leitura das mudanças, publicando no barramento, e um componente de destino do outro lado.

00:10:48 Coordenação Energisa: Esclarece que o componente de destino, embora conste no desenho como conector para o lake, é hoje um serviço que captura as informações e as grava no destino.

00:11:14 Coordenação Energisa: Registra o uso do componente de execução de integração, que se conecta às bases Oracle e captura informações.

00:11:27 Coordenação Energisa: Menciona a existência de um conector adicional que realiza captura de mudanças sobre alguns bancos Oracle em uma das frentes.

00:11:37 Consultoria: Retoma o ponto do serviço que não é o conector padrão e pergunta se foi desenvolvido internamente.

00:11:54 Coordenação Energisa: Explica que havia a necessidade de adquirir o conector do fabricante da plataforma de streaming, mas a equipe de projeto não concluiu a compra no prazo, e o projeto tinha compromisso de natureza regulatória com data definida.

00:12:14 Coordenação Energisa: Registra que, diante do prazo curto, a equipe interna, com a equipe de DevOps, desenvolveu um serviço em Go que funciona como conector, realizando o consumo e a gravação no lake.

00:12:45 Coordenação Energisa: Informa que o formato gravado é o mesmo do esquema de eventos, funcionando como um espelho.

00:12:57 Consultoria: Confirma o entendimento de que o conteúdo grava as mudanças de estado, identificando a operação, com a representação do registro antes e depois da alteração, e também os casos de exclusão.

00:13:17 Arquitetura Energisa: Confirma que são os eventos.

00:13:44 Arquitetura Energisa: Detalha o processamento: os eventos chegam à área de aterrissagem e são processados pela plataforma de processamento, atualizando as camadas sucessivas conforme a qualidade dos dados e as regras de negócio aplicadas.

00:14:04 Arquitetura Energisa: Informa que a gestão do catálogo é feita pelo catálogo unificado da plataforma, que constitui a ferramenta de governança, e que o compartilhamento com os relatórios ocorre por mecanismo de compartilhamento de tabelas ou por virtualização via camada de consulta SQL.

00:14:27 Consultoria: Confirma o entendimento de que a plataforma consome a área de aterrissagem em armazenamento de objetos, onde deve existir particionamento dos eventos.

00:14:49 Consultoria: Pergunta qual é a janela de execução: micro-batch ou lote.

00:15:09 Arquitetura Energisa: Informa que o projeto de indicadores regulatórios executa em micro-batch a cada 20 minutos e que, para o ADMS, já existe previsibilidade de casos mais próximos de tempo real, com sete fluxos executando com cluster ligado continuamente.

00:15:28 Consultoria: Confirma o entendimento do mecanismo: o cluster é iniciado, processa o que está disponível e grava.

00:15:48 Consultoria: Pergunta se todo o conteúdo presente é processado a cada execução.

00:15:53 Arquitetura Energisa: Esclarece que são processados todos os eventos a partir do último ponto registrado.

00:16:03 Consultoria: Pergunta sobre a estratégia de particionamento adotada, se por dia ou por hora.

00:16:39 Arquitetura Energisa: Registra não saber precisar como o particionamento foi configurado pela equipe de nuvem, mas afirma que ele existe.

00:17:05 Consultoria: Constrói o cenário para verificar a mecânica: gravados mil eventos na área de aterrissagem, o processo é acionado, processa e grava na camada bruta. Vinte minutos depois chegam mais três mil. Pergunta como o processo sabe que os primeiros mil já foram tratados.

00:17:38 Arquitetura Energisa: Responde que existe um registro de posição mantido pela própria plataforma, com um diretório onde essas marcações são gravadas, permitindo continuar a partir do ponto anterior.

00:18:17 Arquitetura Energisa: Esclarece que o registro de posição não corresponde necessariamente à partição, uma vez que as partições são estruturas de pastas e cada pasta possui o seu próprio registro.

00:18:37 Consultoria: Pergunta como se procede caso seja necessário reprocessar aqueles primeiros mil eventos em razão de um problema.

00:18:49 Arquitetura Energisa: Informa que existe uma regra de limpeza da área de aterrissagem em sete dias, de modo que os eventos permanecem disponíveis nesse período.

00:19:06 Arquitetura Energisa: Confirma que, para reprocessar, basta reposicionar o registro de posição e executar novamente a partir dali.

00:19:10 Consultoria: Consolida o entendimento de que existe uma janela de sete dias para identificar e resolver o problema.

00:19:25 Arquitetura Energisa: Passa à camada de visualização, informando que a disponibilização dos dados ocorre na ferramenta de relatórios, hoje sob a plataforma unificada do fabricante.

00:19:49 Consultoria: Pergunta o significado de cada camada, confirmando que a primeira corresponde ao dado bruto, idêntico ao da tabela de origem.

00:20:01 Arquitetura Energisa: Confirma, acrescentando que a separação por empresas existente nos bancos comerciais é preservada, e que nessa camada ainda não há agrupamento, embora os dados sejam estruturalmente os mesmos.

00:20:26 Consultoria: Pergunta qual o procedimento aplicado para obter um dado mais tratado.

00:20:34 Arquitetura Energisa: Explica que na camada intermediária ocorrem a limpeza e o alinhamento dos dados, com agrupamento por empresa e algumas regras de negócio aplicadas antes da agregação.

00:20:49 Consultoria: Confirma que a camada final corresponde aos dados agregados, organizados para consumo.

00:20:57 Arquitetura Energisa: Confirma e acrescenta que nem sempre a organização é em dimensões e fatos, existindo também tabelas amplas.

00:21:14 Consultoria: Levanta a questão do tempo total: se o processamento da área de aterrissagem leva vinte minutos, questiona em quanto tempo o dado se torna confiável, ou seja, quando alcança a camada tratada.

00:21:47 Arquitetura Energisa: Responde que depende do caso de uso, existindo operações de segundos e operações que podem levar horas.

00:21:57 Consultoria: Observa que, com clusters efêmeros, é necessário iniciar o cluster e depois encerrá-lo, e pergunta como funciona o agendamento e quanto tempo demora a inicialização.

00:22:17 Arquitetura Energisa: Informa que a inicialização leva normalmente de três a cinco minutos, exceto na modalidade sem servidor, praticamente imediata, porém com custo superior ao dos clusters efêmeros de trabalho.

00:22:37 Consultoria: Pergunta qual evento dispara o início do processamento.

00:23:09 Arquitetura Energisa: Informa que a orquestração é feita pelos fluxos de trabalho da própria plataforma.

00:23:33 Consultoria: Detalha o cenário para confirmar: subiu o cluster, processou os mil eventos, gravou na camada bruta, e pergunta o que dispara a limpeza e a aplicação de regras na camada seguinte.

00:24:12 Arquitetura Energisa: Esclarece que não existe cluster específico por camada: trata-se de um pipeline único, com início, meio e fim, executado pelo mesmo cluster.

00:24:35 Consultoria: Confirma o entendimento de que o cluster sobe, executa o pipeline inteiro até a agregação e depois é encerrado.

00:25:09 Consultoria: Levanta o cenário de dependência: para gerar uma agregação, pode ser necessário dispor de métricas provenientes de sistemas heterogêneos, que chegam em momentos distintos, e questiona como se assegura a completude antes da publicação.

00:25:57 Arquitetura Energisa: Confirma que esse tipo de problema existe, inclusive com dependência entre tabelas de projetos distintos, citando o projeto de indicadores regulatórios, que depende de dados do ADMS e de outros sistemas corporativos.

00:26:26 Arquitetura Energisa: Explica a solução adotada: um estudo prévio identifica as dependências e existem processos transversais, independentes do projeto, que atualizam a sequência de tabelas dependentes umas das outras. Cita também o caso em que uma tabela é consumida de forma contínua e outra em lote.

00:27:17 Consultoria: Consolida a distinção entre fluxos isolados, que executam o pipeline completo, e fluxos com dependência, que exigem o processo transversal.

00:28:02 Consultoria: Pergunta o que aciona esse processo transversal, sugerindo que seja por tempo.

00:28:07 Arquitetura Energisa: Confirma que o acionamento é por tempo.

00:28:25 Consultoria: Observa que o acionamento por tempo pode gerar custo, uma vez que o cluster pode iniciar sem conteúdo a processar.

00:28:36 Arquitetura Energisa: Informa que não houve casos assim, porque a volumetria das bases é significativa e as tabelas encaminhadas ao lake têm alta movimentação.

00:28:53 Arquitetura Energisa: Reconhece que existem problemas de custo e que a equipe trabalhou nos dois meses anteriores para reduzi-los, uma vez que estavam acima do planejado, com resultado descrito como contornado.

00:29:17 Arquitetura Energisa: Informa que a camada de visualização consome entre a camada intermediária e a final, normalmente na final.

00:29:31 Arquitetura Energisa: Registra que não há casos de atualização em tempo real na camada de visualização, e que ela possui agendamento próprio, consumindo o dado do lake de tempos em tempos.

00:29:57 Arquitetura Energisa: Apresenta a evolução desejada: integrar a atualização da visualização ao próprio fluxo de trabalho da plataforma, disparando automaticamente ao final do pipeline concluído com sucesso.

00:30:19 Consultoria: Confirma o entendimento de que não existe conexão direta e contínua, sendo o dado carregado para o cache da ferramenta e consultado a partir dele.

00:30:32 Arquitetura Energisa: Confirma e explica que o modelo semântico é montado do lado da camada de visualização, também por questão de custo, para aproveitar o ambiente já contratado.

00:31:28 Arquitetura Energisa: Informa que existem agendamentos diversos, várias vezes ao dia, diários ou semanais, e cita a escala aproximada de oito mil relatórios construídos na organização, dos quais cerca de quinhentos são administrados pela TI.

00:31:49 Arquitetura Energisa: Registra que ainda não existem fluxos em tempo real na plataforma de processamento e que, com o ADMS, esse estudo passa a ser necessário, incluindo a possibilidade de espelhamento entre o catálogo e o ambiente de visualização com ligação direta por identidade de serviço.

00:32:21 Consultoria: Pergunta quantos usuários utilizam a ferramenta de visualização.

00:32:29 Arquitetura Energisa: Informa que, quando deixou a área de dados, eram cerca de setecentos usuários licenciados, e estima mais de vinte mil colaboradores, com pelo menos dez mil consumindo relatórios.

00:33:11 Arquitetura Energisa: Informa a existência de três capacidades licenciadas da plataforma de visualização.

00:33:32 Consultoria: Retoma o ponto do uso de fluxo contínuo e pergunta quais processos efetivamente necessitam dessa modalidade, observando que o lake não atende apenas à visualização.

00:34:05 Arquitetura Energisa: Informa que hoje não existe caso de necessidade real de tempo real na plataforma de processamento, e que o barramento é utilizado sobretudo para evitar o processamento repetido em lote por janelas de data.

00:34:31 Arquitetura Energisa: Registra que outros projetos ainda buscam grandes intervalos de dados diretamente no banco e que existe um contorno em estudo, utilizando a ferramenta de replicação para persistir os eventos em tabela paralela.

00:35:05 Arquitetura Energisa: Detalha o contexto: a organização possui contrato de licenciamento ilimitado da Oracle, com direito de uso da ferramenta de replicação apenas na configuração entre bancos. O upgrade para a modalidade voltada a grandes volumes teria custo estimado em torno de seis milhões de reais, inviável para um único projeto.

00:35:28 Arquitetura Energisa: Explica o impacto: sem essa persistência direta no lake, é necessário buscar massas de dados extensas no banco Oracle, como o último ano, e carregá-las.

00:35:48 Arquitetura Energisa: Descreve o contorno adotado: habilitar a captura sobre uma tabela específica de grande volumetria, capturar os eventos e persisti-los em tabela separada, passando a ler essa tabela em lugar de todo o intervalo histórico.

00:36:16 Arquitetura Energisa: Sintetiza que o arranjo equivale a manter a captura ativa, invertendo o sentido: em lugar de entregar, o consumidor vai buscar.

00:36:30 Consultoria: Levanta a questão contratual do licenciamento ilimitado e do escopo de uso das instâncias.

00:37:01 Consultoria: Explica que contratos dessa natureza normalmente permitem instalar em qualquer ambiente, mas que as condições variam no encerramento, e que licenças para uso em nuvem podem ter validade restrita ao período do contrato.

00:37:34 Consultoria: Propõe o cenário alternativo: se a camada bruta corresponde à tabela do banco de origem, seria possível utilizar o serviço de orquestração de dados para consultar diretamente o Oracle.

00:38:22 Arquitetura Energisa: Avalia que a alternativa seria viável.

00:38:27 Consultoria: Explica o ganho: evita-se manter na área de aterrissagem os eventos de captura, uma vez que o serviço de orquestração possui conector para o banco.

00:38:56 Consultoria: Detalha o refinamento: acrescentar um campo de marcador temporal à estrutura, permitindo extração incremental mesmo que a tabela de origem não o possua.

00:39:10 Coordenação Energisa: Pede esclarecimento sobre como seria implementado esse marcador.

00:39:16 Consultoria: Explica que, ao capturar a transação, é possível acrescentar campos, ainda que não seja possível realizar transformações complexas. Com o marcador gravado, a consulta seguinte parte do último valor processado.

00:40:13 Consultoria: Confirma que essa abordagem permite extração incremental mesmo em estruturas que não a suportariam originalmente, e recorda ter questionado a equipe de banco sobre a existência de tal estrutura, com resposta negativa.

00:40:28 Coordenação Energisa: Registra desconhecer se a opção de adicionar coluna existe, uma vez que versões mais antigas poderiam não oferecê-la, e propõe validar com a equipe de administração de banco de dados.

00:40:42 Arquitetura Energisa: Avalia que a versão utilizada provavelmente contempla o recurso, observando que o ambiente de homologação reside em nuvem do próprio fabricante.

00:41:18 Consultoria: Passa ao tema de qualidade, observando que na camada bruta não há tratamento e questionando o que ocorre na camada intermediária, uma vez que o dado chega fortemente tipado.

00:41:49 Arquitetura Energisa: Informa que a tipagem é aplicada no momento da persistência em formato estruturado, uma vez que a tipagem da origem difere da adotada na plataforma.

00:42:14 Engenharia de dados: Complementa que, no contexto geral dos projetos com ingestão pelo serviço de orquestração, existe uma etapa intermediária que consulta os tipos da tabela de origem e aplica um mapeamento de correspondência previamente construído.

00:42:59 Engenharia de dados: Confirma que o dado permanece fortemente tipado no destino, tratando-se apenas de conversão controlada entre os dois modelos de tipos.

00:43:15 Engenharia de dados: Acrescenta que, na camada intermediária, são incluídos os identificadores, os códigos e as siglas das empresas, entre outras tratativas.

00:43:30 Coordenação Energisa: Complementa que também há ajuste de nomenclatura de colunas, para manter coerência.

00:43:37 Consultoria: Reconhece que se trata de enriquecimento do dado e estabelece a distinção: enriquecer é diferente de limpar.

00:44:00 Consultoria: Exemplifica o conceito de limpeza com um fluxo de dados externos, no qual conteúdo sem relevância para a regra de negócio precisa ser identificado e eliminado antes da tipagem e do enriquecimento.

00:45:08 Consultoria: Delimita que não se trata de tipagem, e sim de consistência: um cliente sem documento cadastrado pode não servir ao cenário e ser removido, e o percentual desses casos pode ser acompanhado como indicador, sinalizando problema de processo na origem quando cresce acima do habitual.

00:46:05 Consultoria: Apresenta o segundo exemplo: um cliente sem transação associada ou uma transação sem cliente configura erro de consistência, que precisa ser resolvido para que o dado seja confiável.

00:46:31 Consultoria: Pergunta se é a esses conceitos que a equipe se refere ao falar em limpeza.

00:46:39 Arquitetura Energisa: Esclarece que o que existe hoje se aproxima mais de qualidade de dado do que de limpeza propriamente dita, e que os processos de limpeza praticados são simples, como padronização de nomenclatura.

00:47:16 Engenharia de dados: Informa que casos como o de cliente sem telefone cadastrado são tratados quando o dado é consolidado nas camadas superiores.

00:47:41 Consultoria: Caracteriza a prática como harmonização: valores diferentes que representam a mesma informação são padronizados conforme regras definidas, tornando o dado semanticamente coerente.

00:48:03 Arquitetura Energisa: Confirma e explica a razão: ao organizar o dado em dimensões e fatos na camada final, o atributo que qualifica o fato precisa estar padronizado.

00:48:21 Consultoria: Consolida o entendimento: o que ocorre hoje na camada intermediária é harmonização e controle semântico, e a verificação de consistência precisa ocorrer antes da camada final, para que a inconsistência não seja propagada.

00:48:59 Arquitetura Energisa: Registra que os processos futuros definirão o tratamento. Utilizando o exemplo do documento inválido, formula que descartar o dado é a alternativa simples, mas que, com um processo de qualidade robusto, o ideal seria identificá-lo e movê-lo para uma quarentena, para que alguém decida sobre a remoção.

00:49:26 Consultoria: Confirma o entendimento e acrescenta que o processo só deveria ser interrompido caso um limite de aceitação fosse ultrapassado, uma vez que algum grau de inconsistência é esperado.

00:50:07 Consultoria: Pergunta se esse processo de qualidade já existe ou é um planejamento.

00:50:15 Arquitetura Energisa: Responde que ainda não existe, e que em alguns momentos há quebra de pipelines, seja por questões técnicas, por mudança de regra de negócio, por campo que deixa de vir ou por alteração de tipagem na origem, que impacta a camada seguinte por não corresponder ao tipo esperado.

00:50:48 Arquitetura Energisa: Confirma que existe previsão de implantar o processo de qualidade, mas que ainda não é a realidade, descrevendo-o como um objetivo a alcançar.

00:51:09 Consultoria: Pergunta se os sistemas Oracle são desenvolvidos internamente ou de terceiros.

00:51:23 Coordenação Energisa: Responde que há dos dois tipos.

00:51:32 Consultoria: Pergunta como a equipe lida com mudança de esquema promovida pelo fornecedor ou pelo desenvolvedor e se isso provoca quebra de pipeline.

00:51:46 Arquitetura Energisa: Confirma que normalmente há quebra. Informa que existe processo de gestão de mudanças com alertas sobre alterações previstas em tabelas, solicitando verificação de impactos, prática descrita como recente e ainda incipiente. Registra que existem casos em que o problema foi percebido após a quebra e a reclamação do consumidor.

00:52:29 Consultoria: Pergunta se a quantidade de problemas é grande e qual o impacto no negócio.

00:52:44 Arquitetura Energisa: Responde que depende da solução afetada, citando que um impacto no projeto de indicadores regulatórios envolveria demanda legal, cujos dados são consumidos pelo órgão regulador, com possibilidade de punição.

00:53:00 Consultoria: Pergunta com que periodicidade o regulador consome esses dados.

00:53:12 Arquitetura Energisa: Informa que é aceita defasagem máxima de trinta minutos.

00:53:17 Consultoria: Confirma que o processo é próximo de tempo real.

00:53:22 Arquitetura Energisa: Esclarece que não é fluxo contínuo, mas tampouco carga única diária.

00:53:34 Consultoria: Pergunta se a consequência pode ser multa para a empresa.

00:53:39 Arquitetura Energisa: Confirma que toda demanda legal tem peso significativo, por se tratar de ambiente altamente regulamentado.

00:53:57 Consultoria: Pergunta se, nesse processo, existe controle de qualidade mais robusto ou se segue o mesmo padrão dos demais.

00:54:07 Arquitetura Energisa: Responde que não existe processo de qualidade, registrando que há atenção maior e monitoração associada, mas não processo estruturado.

00:54:24 Coordenação Energisa: Recorda a conversa mantida com a equipe de monitoração e confirma que ainda não existe integração com aquela frente.

00:54:37 Arquitetura Energisa: Informa que existe equipe de sustentação disponível em regime contínuo, acionada em caso de problema, que por sua vez aciona a equipe de engenharia de dados para melhoria ou correção.

00:55:08 Arquitetura Energisa: Detalha o consumo pelo regulador: trata-se de API, consumida a cada trinta minutos, com a expectativa de que o dado esteja atualizado nesse intervalo.

00:55:25 Consultoria: Constrói o cenário de falha: uma inconsistência na origem não detectada passa a gerar dados incorretos, o pipeline processa normalmente, o problema é identificado depois e a correção envolve outras equipes, levando um dia.

00:56:03 Consultoria: Pergunta se é possível reenviar os dados do período afetado e notificar o consumidor de que o conteúdo correto está disponível.

00:56:17 Arquitetura Energisa: Solicita apoio da equipe de engenharia para responder, por se tratar de processo específico daquela área.

00:56:28 Engenharia de dados: Informa que foram disponibilizadas três APIs. A primeira mantém o histórico de sete dias, requisito solicitado pelo próprio regulador.

00:56:42 Engenharia de dados: Detalha que a terceira API é consultada sob demanda, acionada apenas quando existe necessidade específica.

00:56:51 Engenharia de dados: Registra que a segunda API não possui essa facilidade pronta e que seria necessário estruturar mecanismo para capturar o estado de uma data determinada, uma vez que o que se disponibiliza hoje é tudo o que está em aberto.

00:57:08 Engenharia de dados: Esclarece o conteúdo: a primeira API expõe a quantidade de incidentes em aberto no momento da consulta, e a segunda a quantidade de atendimentos em aberto.

00:57:22 Consultoria: Pergunta por que o regulador necessita do histórico.

00:57:32 Engenharia de dados: Explica que se trata de solicitação do próprio regulador, para manter a fotografia do momento por até sete dias, permitindo recuperação caso ele perca algum dado na sua integração, e registra que a segunda API não possui essa exigência.

00:58:03 Arquitetura Energisa: Observa que a organização atende passivamente ao que é solicitado, mas que, havendo problema, a responsabilidade de entregar o dado corretamente permanece com a distribuidora.

00:58:21 Engenharia de dados: Registra que um dos requisitos é que o histórico fique armazenado na base do regulador, de modo que, em condições normais, não haveria necessidade de mantê-lo internamente.

00:58:45 Consultoria: Pergunta como a estratégia com o regulador foi desenvolvida e quem captou os requisitos.

00:59:03 Arquitetura Energisa: Informa que existe área específica responsável por levantar os requisitos junto ao regulador, convertê-los para linguagem técnica e encaminhá-los às equipes.

00:59:41 Arquitetura Energisa: Contextualiza a criticidade: o ADMS realiza o monitoramento das redes elétricas, com impacto direto na operação, e a parte do lake que cobre esse escopo é igualmente crítica.

01:00:21 Consultoria: Constrói o cenário para dimensionar o impacto: se o lake ficar dois dias indisponível e o ADMS continuar funcionando, questiona quais entregas seriam afetadas.

01:00:54 Arquitetura Energisa: Responde que o impacto não é apenas regulatório: são cerca de sessenta relatórios, do pré-operacional ao pós-operacional, incluindo dados utilizados para a alocação de equipes no atendimento a contingências.

01:01:35 Consultoria: Pergunta se existe classificação de criticidade desses processos.

01:01:50 Arquitetura Energisa: Confirma que o backlog possui níveis de criticidade e que os relatórios mais críticos são atendidos primeiro, acrescentando que, de modo geral, todo processo que envolve o ADMS pode ser considerado crítico.

01:02:43 Consultoria: Consolida que a qualidade de dados é tratada de maneira reativa, por reclamação ou por monitoramento, exigindo mobilização de equipe para os ajustes, e observa que um processo estruturado traria ganho de produtividade.

01:03:35 Consultoria: Pergunta quais são as dores que mais impactam a área.

01:03:47 Arquitetura Energisa: Responde que a maior dor está na camada de integração: considera extremamente crítico o ponto em que o ambiente próprio se conecta ao ambiente de nuvem.

01:04:05 Arquitetura Energisa: Exemplifica com o componente de execução de integração: se essa máquina cai, haverá problemas.

01:04:14 Arquitetura Energisa: Formula o argumento central: processamento e qualidade de dados são preocupações relativas ao que já está do outro lado, mas se o componente intermediário entre os dois ambientes cai, não há qualidade, não há processamento e não há dado.

01:04:50 Coordenação Energisa: Acrescenta outra dor já discutida: houve caso em que foi necessário capturar novamente os dados para reprocessamento e a janela de sete dias havia sido ultrapassada, de modo que o conteúdo já estava expurgado.

01:05:29 Coordenação Energisa: Registra que a persistência histórica de eventos mencionada anteriormente poderia ser uma solução para esse caso.

01:05:38 Coordenação Energisa: Informa que os conectores estão ativados apenas para o fluxo corrente e que pretende avaliar com a equipe de barramento a captura incremental de estado, que permitiria reconstruir o conteúdo quando necessário.

01:06:07 Coordenação Energisa: Ressalva que qualquer mecanismo de reenvio exige que os consumidores tratem idempotência, para evitar duplicidade, e registra que isso não está implementado, sendo ponto a levantar no assessment.

01:06:32 Consultoria: Pergunta se o componente de execução de integração é uma máquina única ou se possui cluster e contingência.

01:06:49 Arquitetura Energisa: Informa que é um cluster, com duas ou três máquinas, e que existe contingência entre elas.

01:06:58 Consultoria: Pergunta se existe estratégia de conectividade dedicada para essa comunicação.

01:07:08 Arquitetura Energisa: Responde que o tráfego ocorre pela internet e informa que está em validação a possibilidade de adotar o enlace dedicado do provedor de nuvem, cujo nome não recorda no momento.

01:07:33 Consultoria: Pergunta se existe problema de latência nesse processo.

01:07:45 Engenharia de dados: Informa que atuou predominantemente em fluxos em lote, para os quais não houve diferença perceptível.

01:08:00 Arquitetura Energisa: Registra que a equipe de engenharia está integrada há apenas três semanas, o que explica o encaminhamento de algumas respostas.

01:08:24 Coordenação Energisa: Propõe sessão seguinte com a equipe de DevOps, para tratar de repositórios, análise de código e componentes de esteira.

01:08:53 Consultoria: Avalia que a sessão cobriu os pontos previstos e agradece a disponibilidade.

01:09:31 Consultoria: Retoma pendências de documentação, solicitando o depósito das transcrições e do documento consolidado no repositório compartilhado, bem como a apresentação de domínios do início do trabalho.

01:10:47 Consultoria: Propõe reunião específica com a equipe de arquitetura, para compreender o processo, os entregáveis e os padrões, e apresentar a forma de trabalho da consultoria, de modo a alinhar o formato dos entregáveis do assessment.

01:11:10 Coordenação Energisa: Registra convergência: já pretendia convocar a consultoria para esse alinhamento com a equipe de arquitetura.

01:11:32 Consultoria: Explicita a motivação: o assessment entra na fase de geração do material e é necessário definir o padrão dos entregáveis.

01:11:58 Consultoria: Detalha que o resultado poderá incluir recomendações de arquitetura e também registros de decisão, com modelos que se ajustem ao que a organização já entrega ou que sejam criados quando não houver padrão preexistente.

01:12:34 Coordenação Energisa: Contextualiza que a equipe de arquitetura é recente, que até pouco tempo predominavam pareceres de arquitetura voltados a projetos específicos e que a prática de registros de decisão começou há cerca de seis meses, ainda em formatação, sendo considerada também para uso com a iniciativa interna de inteligência artificial.

01:13:16 Coordenação Energisa: Avalia que o momento é oportuno, uma vez que a prática interna está sendo aprimorada em paralelo ao trabalho da consultoria.

01:13:36 Consultoria: Registra que a discussão será proveitosa para as duas partes.

01:14:41 Consultoria: Reforça a solicitação do documento de domínios, para conferir o que já foi extraído no assessment.

01:15:01 Coordenação Energisa: Relaciona as sessões pendentes: desenvolvedor sênior, equipe de DevOps e eventuais revisitas a áreas já entrevistadas.

01:15:22 Coordenação Energisa: Propõe realizar a sessão de arquitetura após a do desenvolvedor sênior, que trará mais detalhes, e informa que a agenda depende do retorno de férias.

01:17:20 Coordenação Energisa: Consolida a agenda: sessões com o desenvolvedor sênior, com a área de arquitetura e possivelmente com DevOps na quinta ou na sexta-feira da semana seguinte, preferencialmente pela manhã.

Anexo B · Termos normalizados e itens que exigem confirmação

A transcrição automática apresenta qualidade reduzida em nomes de produtos, siglas e números. Nesta ata, os componentes foram descritos preferencialmente por sua função. Os itens abaixo devem ser confirmados antes de constarem em desenho de arquitetura ou em decisão formal.

Plataforma de dados corporativa	Data lake corporativo da Energisa, referido pela sigla própria da organização.	A denominação oficial deve ser confirmada.
Área de aterrissagem	Camada inicial de persistência dos eventos em armazenamento de objetos na nuvem.	O formato de serialização com esquema foi indicado, mas não confirmado formalmente.
Catálogo unificado	Ferramenta de catalogação e governança da plataforma de processamento.	A transcrição registra o nome de forma imprecisa.
Serviço próprio em Go	Componente desenvolvido internamente que consome do barramento e grava na área de aterrissagem.	Substitui o conector comercial não adquirido. Propriedade e sustentação a formalizar.
Componente de execução de integração	Elemento instalado no ambiente próprio que conecta as bases locais à nuvem.	A topologia, o número de nós e o modelo de failover devem ser confirmados.
Serviço de orquestração de dados	Serviço da nuvem utilizado para ingestão a partir das bases relacionais.	Nomenclatura a confirmar.
Projeto de indicadores regulatórios	Frente com obrigação legal, que expõe dados ao órgão regulador por três APIs.	O nome do projeto e o do órgão aparecem grafados de formas variadas.
Área de requisitos regulatórios	Área responsável por levantar os requisitos junto ao regulador e traduzi-los para linguagem técnica.	A sigla da área deve ser confirmada.
Ferramenta de replicação Oracle	Mecanismo licenciado em configuração entre bancos, cujo upgrade para grandes volumes foi considerado inviável.	O valor de seis milhões de reais foi citado verbalmente e deve ser confirmado.
Capacidades da plataforma de visualização	Três capacidades licenciadas, com identificação de porte citada de memória.	A identificação exata deve ser confirmada.
Sistemas de origem citados	Sistemas corporativos que fornecem tabelas dependentes ao projeto regulatório.	As siglas aparecem corrompidas na transcrição.

Além dos termos, os seguintes dados quantitativos foram registrados como informados e devem ser confirmados por inventário:

• A execução em micro-batch a cada 20 minutos e os sete fluxos com cluster contínuo.
• O tempo de inicialização de três a cinco minutos dos clusters efêmeros.
• A retenção de sete dias na área de aterrissagem e o histórico de sete dias na primeira API regulatória.
• A defasagem máxima de 30 minutos aceita pelo órgão regulador.
• Os cerca de oito mil relatórios na organização e os quinhentos administrados pela TI.
• Os setecentos usuários licenciados, os vinte mil colaboradores e os dez mil consumidores estimados.
• Os cerca de sessenta relatórios relacionados ao contexto operacional.
• O valor estimado para o upgrade da ferramenta de replicação.

1.15.22. Observações finais

Esta ata foi consolidada a partir de dois documentos referentes à mesma sessão: o relatório técnico produzido sobre a reunião e a transcrição integral da gravação. Os temas foram unificados por assunto, preservando o conteúdo das duas fontes, incluindo os pontos em que a transcrição traz detalhe adicional, entre eles a trajetória organizacional da equipe de dados, a mecânica completa do controle de posição e do reprocessamento, a distinção conceitual construída ao longo da conversa entre conversão de tipos, harmonização, enriquecimento e qualidade, o detalhamento das três APIs regulatórias e o alinhamento sobre padronização dos entregáveis do assessment.

A atribuição nominal das falas não foi aplicada no registro cronológico porque a identificação automática não permite associar com segurança as vozes aos nomes. Os participantes estão identificados no item 1.15.2, com base nas apresentações feitas na abertura. As classificações de severidade, as prioridades do plano de ação e as estimativas têm caráter indicativo e serão refinadas com as evidências solicitadas e com as sessões complementares já acordadas.