Arquitetura de Dados

1. O problema que a arquitetura resolve

Toda organização que opera sistemas produz dados antes de decidir o que fazer com eles. O primeiro relatório nasce de uma consulta direta ao banco de produção. O segundo nasce de uma planilha que alguém exporta toda segunda-feira. O terceiro nasce de um script que copia tabelas durante a madrugada. Nenhuma dessas decisões é irracional isoladamente: cada uma resolve um problema imediato com o menor esforço disponível naquele momento.

A dificuldade aparece na soma. Após dois anos, a organização possui dezenas de rotas de dados não documentadas, três definições incompatíveis de receita líquida, um banco de produção sobrecarregado por consultas analíticas e nenhum registro de quem depende de quê. Quando um campo muda de nome na origem, ninguém consegue prever quais relatórios param de funcionar. Entende-se por arquitetura de dados o conjunto de decisões, de reversão custosa, que impede esse desfecho.

Arquitetura como registro de justificativas

Um diagrama de caixas conectadas por setas comunica topologia; a arquitetura compreende também as justificativas que produziram essa topologia. Duas organizações podem produzir diagramas idênticos por motivos opostos: uma escolheu processamento em lote porque a decisão de negócio ocorre uma vez ao dia; a outra escolheu o mesmo porque não dispunha de equipe para operar processamento contínuo. As topologias coincidem, as arquiteturas divergem, e apenas o registro das justificativas permite distinguir uma da outra quando a restrição mudar.

Essa distinção tem consequência prática direta. Quando um novo integrante propõe migrar a plataforma para processamento em tempo real, a resposta adequada é: a decisão de operar em lote foi registrada no ADR-ARQ-02, cuja premissa era a inexistência de decisão de negócio, além do antifraude, sensível a latência inferior a quinze minutos; se essa premissa deixou de valer, a decisão deve ser reavaliada. Com a decisão documentada, a discussão passa a examinar a validade da premissa registrada.

O caso que acompanha este material

Como percorrer este material

O material está organizado em quatorze seções, com tempo estimado indicado ao início de cada uma e no sumário lateral. A leitura integral demanda aproximadamente noventa minutos. O encontro presencial desta aula é integralmente dedicado à Ponderada em Sala, atividade avaliativa individual, manuscrita e sem consulta, que pede a reconstrução do cubo do próprio grupo e do caminho das bases de origem do parceiro até ele. Este material constitui o estudo preparatório dessa atividade. As seções 2 a 7 tratam dos seis temas conceituais da arquitetura de dados e encerram-se com checklist de aplicação; as seções 8 a 11 aprofundam o tema; a Seção 12 propõe um exercício preparatório de autoverificação, não entregue; as seções 13 e 14 reúnem glossário e referências.

Quatro exercícios resolvidos estão distribuídos ao longo do texto. A resolução permanece recolhida por padrão, e recomenda-se formular a própria resposta antes de expandi-la, pois o exercício perde a função diagnóstica quando a resolução é lida primeiro. Cada diagrama introduz distinção que o texto não enuncia integralmente, e a leitura que os ignora perde parte do argumento.

Onde esta aula se encaixa no módulo

As aulas anteriores trataram da modelagem dimensional: grão, tabelas de fato, dimensões, esquemas estrela e floco de neve. Modelagem responde à pergunta como os dados devem ser organizados para serem consultados. Arquitetura responde a uma pergunta anterior e mais ampla: por onde os dados entram, onde repousam, quem os transforma, quem os consome, quem responde quando falham e o que acontece quando a estrutura precisa mudar. Um modelo dimensional correto, inserido em arquitetura sem contratos, responsáveis e plano de recuperação, continua sujeito a produzir relatórios incorretos.

2. Requisitos arquiteturais: comece pelas decisões

Arquitetura responde a restrições. Enquanto as restrições permanecerem enunciadas em termos qualitativos — muitos dados, precisa ser rápido, não pode cair —, não existe critério para escolher entre alternativas, porque qualquer alternativa as satisfaz retoricamente. O primeiro trabalho arquitetural consiste em converter adjetivos em números.

As oito dimensões de restrição

A última dimensão é a mais frequentemente omitida e a que mais determina o desenho. Uma plataforma cujos consumidores são analistas de negócio com ferramenta visual exige uma camada semântica estável, com métricas nomeadas e pré-agregadas. Uma plataforma cujos consumidores são cientistas de dados exige acesso ao dado granular, inclusive ao registro bruto anterior à limpeza, porque a limpeza descarta exatamente os desvios que interessam ao modelo. A Rede Aurora possui os dois perfis, e essa coexistência justificará o padrão adotado na Seção 4.

Do requisito à decisão: o funil arquitetural

Requisitos não funcionais verificáveis

Um requisito não funcional exige três componentes para ser verificável: uma métrica, um limite numérico e um instrumento de medição. A ausência de qualquer um deles impede a construção de um cenário de aceite, e um requisito sem cenário de aceite não é passível de reprovação e, por isso, não restringe a implementação.

3. Camadas e responsabilidades

A estruturação em camadas é o mecanismo pelo qual uma plataforma de dados isola mudanças. Cada camada recebe um contrato de entrada, um contrato de saída, um responsável nomeado e uma política de qualidade declarada. Quando uma origem altera o nome de um campo, a mudança é absorvida na fronteira de ingestão e não se propaga até o relatório da diretoria — desde que as camadas tenham responsabilidades distintas.

As cinco camadas canônicas

A nomenclatura bronze, prata e ouro, difundida por plataformas de lakehouse, corresponde às camadas de bruto, tratado e serviço. A escolha do vocabulário é indiferente; o que importa é a existência de contratos distintos. Uma organização que possui três esquemas de banco chamados bronze, silver e gold contendo as mesmas colunas, com as mesmas regras e o mesmo responsável, possui, na prática, uma camada e duas cópias, com o custo de armazenamento triplicado e nenhum ganho de isolamento.

Por que a camada bruta deve ser imutável

A camada de armazenamento bruto guarda a cópia fiel do que a origem entregou, sem correção, sem tipagem e sem descarte. O custo de armazenamento dessa cópia justifica-se no primeiro incidente de regra incorreta. Quando se descobre, três meses após a implantação, que a regra de conversão de moeda estava incorreta, a existência do dado bruto permite reprocessar todo o histórico com a regra corrigida. Sua ausência torna o erro permanente, porque a informação original foi destruída no momento da transformação. A imutabilidade admite uma exceção legal: o pedido de eliminação de dados pessoais por titular, previsto na LGPD, que a Seção 6 trata por descarte criptográfico da chave do titular.

O contrato de dados na prática

Contrato de dados é a especificação, acordada entre produtor e consumidor, do formato, da semântica e das garantias de qualidade de um conjunto de dados. Sua função é converter uma expectativa implícita em obrigação verificável: sem contrato, o produtor não sabe o que pode alterar sem causar dano, e o consumidor não sabe com o que pode contar.

O contrato deve ser artefato versionado no repositório. O exemplo abaixo especifica a saída da camada tratada para a tabela de itens de venda da Rede Aurora.

# contratos/silver.item_venda.yaml
nome: silver.item_venda
versao: "2.1.0"
dono: engenharia-de-dados
origem: bronze.cupom_item
particionamento: data_particao # diário; habilita reprocessamento idempotente

chave_unica: [id_cupom, sequencia_item]

campos:
  - nome: id_cupom
    tipo: string
    obrigatorio: true
  - nome: valor_total_com_imposto
    tipo: decimal(12,2)
    obrigatorio: true
    semantica: "valor do item incluindo tributos incidentes"
  - nome: id_cliente_substituto
    tipo: string
    obrigatorio: false
    classificacao: pseudonimizado # CPF não trafega a partir desta camada

garantias:
  - regra: unicidade(chave_unica)
    acao_se_violada: rejeitar_carga
  - regra: valor_total_com_imposto >= 0
    acao_se_violada: rejeitar_carga
  - regra: completude(id_cupom) == 100%
    acao_se_violada: rejeitar_carga
  - regra: contagem_diaria >= 0.8 * media_movel_7d
    acao_se_violada: alertar_dono # queda abrupta indica falha na origem

evolucao:
  politica: retrocompatibilidade_obrigatoria
  prazo_de_transicao_dias: 30

Três elementos desse contrato merecem destaque. O campo semantica registra o significado por extenso, o que torna detectável a alteração descrita ao final da Seção 7 — mudar o significado mantendo nome e tipo. O par regra e acao_se_violada distingue as violações que interrompem a carga daquelas que apenas notificam: rejeitar a carga por queda de volume seria excessivo, pois um feriado produz legitimamente menos cupons, mas ignorá-la impediria detectar a falha silenciosa de uma origem. E o bloco evolucao declara antecipadamente a política, de modo que a admissibilidade de uma mudança seja discutida antes que ela ocorra.

A camada de serviço e o vocabulário do negócio

A camada de serviço é onde reside o modelo dimensional estudado nas aulas anteriores, e é também onde as métricas recebem definição única. Se receita líquida for calculada dentro de cada relatório, existirão tantas definições quantos forem os relatórios, e a divergência entre elas será descoberta em reunião de diretoria. Definir a métrica uma vez, na camada de serviço, com versionamento, é o que permite responder à pergunta por que os dois números diferem antes que ela seja feita.

4. Padrões de plataforma

Os padrões descritos a seguir são respostas históricas a restrições distintas. Nenhum deles é sucessor universal do anterior, ainda que a literatura comercial frequentemente os apresente em ordem cronológica sugerindo progresso. O critério de escolha é a correspondência entre o que o padrão resolve e o que a organização declarou como restrição.

Comparação estruturada

Topologias comparadas

O custo de governança e por que ele é subestimado

A comparação entre padrões costuma restringir-se ao custo de infraestrutura, que é visível, mensurável e cotado por fornecedores. O custo de governança é invisível na proposta e dominante na operação, pois consiste majoritariamente em tempo de pessoas. Ao avaliar um padrão candidato, devem ser estimados ao menos cinco itens recorrentes.

• Catalogação. Registro e manutenção da descrição de cada conjunto de dados publicado, incluindo significado dos campos e responsável.
• Manutenção física. Compactação de arquivos, reorganização de partições e expurgo de versões antigas — atividades que não produzem valor visível e cuja omissão degrada a consulta progressivamente.
• Revisão de acessos. Verificação periódica de quem detém quais privilégios, com revogação do que deixou de ser necessário.
• Conciliação de definições. Arbitragem entre áreas que calculam a mesma métrica de modos distintos, atividade tanto mais frequente quanto mais descentralizado for o padrão.
• Resposta a incidentes. Tempo dedicado à investigação e correção de falhas de carga e de qualidade, proporcional ao número de componentes independentes.

A relevância dessa estimativa aparece na comparação entre padrões centralizados e distribuídos. A distribuição reduz o gargalo da equipe central e aumenta os itens de conciliação e de resposta a incidentes, porque multiplica o número de produtores independentes. Uma organização com uma única equipe de dados que adota topologia distribuída mantém o gargalo e acrescenta custo de coordenação entre produtores independentes que ela não possui.

O princípio da simplicidade suficiente

Entre padrões que atendem às restrições declaradas, deve-se adotar o mais simples. A justificativa é operacional: cada elemento adicional da plataforma consome capacidade de operação, e a capacidade de operação é o recurso mais escasso em equipes pequenas. Uma arquitetura que a equipe não consegue operar em regime de incidente é, do ponto de vista da disponibilidade, pior do que uma arquitetura menos sofisticada que ela domina.

5. Batch e streaming

O processamento em lote agrupa registros por intervalo de tempo e os processa em conjunto. O processamento contínuo trata cada evento à medida que ocorre. A diferença aparente é de latência; a diferença substantiva é de complexidade operacional, e é esta que determina o custo total.

O que cada modelo simplifica e o que complica

O teste da decisão

A pergunta que determina a escolha é qual decisão muda por saber o dado mais cedo. Se nenhuma ação humana ou automática ocorre entre a chegada do dado às 7h e a sua chegada às 7h15, os quinze minutos de diferença não possuem valor econômico, e o custo de obtê-los é integralmente desperdiçado.

Como dimensionar a janela do lote

Definida a opção pelo processamento em lote, resta escolher a frequência de execução. A escolha é frequentemente arbitrada por hábito — toda madrugada —, quando decorre de três restrições verificáveis.

A primeira é o momento da decisão. Se a reposição de estoque é decidida às 7h, a carga deve concluir antes desse horário, com margem suficiente para uma reexecução em caso de falha. Uma carga que termina às 6h55 e falha uma vez por mês descumpre o requisito em todos os meses.

A segunda é a disponibilidade da origem. O sistema de ponto de venda encerra o movimento das lojas em horários distintos, e extrair antes do fechamento da última loja produz dados incompletos que serão silenciosamente tratados como completos. A janela precisa iniciar após a garantia de fechamento, não após o horário nominal.

A terceira é a duração da execução somada à margem de recuperação. Se a carga leva 40 minutos e o RTO declarado é de 4 horas, iniciar às 3h oferece margem para duas tentativas antes das 7h. Iniciar às 6h não oferece nenhuma, e o RTO declarado torna-se inatingível por construção — independentemente da qualidade da implementação.

Adoção por caso de uso

A conclusão prática é que lote e processamento contínuo coexistem na mesma arquitetura. A escolha do regime de processamento é feita para cada caso de uso, de modo que a mesma plataforma pode abrigar os dois. A Rede Aurora opera o antifraude em fluxo contínuo, com uma janela de estado de poucos minutos, e mantém todo o restante em lote horário e diário. O evento de pagamento é gravado no barramento uma única vez e consumido por dois caminhos independentes: o consumidor contínuo, que decide o bloqueio, e o consumidor em lote, que alimenta a camada bruta.

6. Governança e segurança

Governança de dados é o conjunto de processos que estabelece quem decide o quê a respeito dos dados, sob quais regras e com qual responsabilidade. O DAMA-DMBOK a posiciona no centro das demais funções de gestão de dados, e não como atividade posterior, porque cada função — qualidade, segurança, metadados, arquitetura — depende de uma atribuição de autoridade previamente definida.

Os componentes exigidos desde o desenho

Linhagem: por que ela é condição de avaliação de impacto

Linhagem é o registro verificável do percurso de um dado desde a origem até o consumo, incluindo as transformações intermediárias. Sua utilidade concentra-se em dois momentos. No primeiro, quando uma origem anuncia alteração de esquema, a linhagem responde a quais tabelas e relatórios essa alteração atinge. No segundo, quando um número é contestado, a linhagem permite percorrer o caminho inverso até o registro de origem e identificar em que transformação a divergência foi introduzida.

O grafo acima permite responder, sem inspeção manual de código, a duas perguntas de operação. Primeira: se a planilha de custo deixar de ser entregue, quais consumidores são afetados? O caminho indica que margem_bruta e o painel comercial degradam, enquanto o modelo de previsão de demanda permanece íntegro, pois deriva de silver.item_venda. Segunda: o modelo de previsão consome a camada tratada e não a de serviço, o que constitui exceção deliberada à regra de proibição de salto de camada — deve, portanto, estar registrada em ADR, com a justificativa de que o modelo exige granularidade anterior à agregação dimensional.

Proteção de dados pessoais

A Lei Geral de Proteção de Dados Pessoais (Lei nº 13.709/2018) impõe à arquitetura exigências que não podem ser satisfeitas posteriormente sem reconstrução. Entre elas, a finalidade declarada para cada tratamento, a minimização — coletar e reter apenas o necessário à finalidade —, e a capacidade de localizar e eliminar os dados de um titular mediante solicitação. Esta última exigência é decisiva: uma plataforma que replica identificadores pessoais por dezenas de tabelas derivadas, sem linhagem, não consegue atender a um pedido de eliminação sem varredura manual.

7. Resiliência e evolução

Plataformas de dados estão sujeitas a falhas: origens ficam indisponíveis, cargas são interrompidas pela metade, registros chegam duplicados, esquemas mudam sem aviso. A qualidade arquitetural mede-se pela previsibilidade do comportamento quando as falhas ocorrem.

Idempotência como pré-condição do reprocessamento

Uma operação é idempotente quando sua aplicação repetida produz o mesmo resultado de uma única aplicação. Em ingestão de dados, isso significa que reexecutar a carga do dia 12 deve deixar o sistema no mesmo estado em que ficaria se ela tivesse executado uma única vez com sucesso. A propriedade não é automática: uma rotina que insere registros incondicionalmente duplica-os a cada reexecução.

A estratégia de substituição de partição é a mais simples e deve ser preferida quando a janela de reprocessamento é delimitável por data. Quando não é — por exemplo, em correções que afetam registros arbitrários —, a alternativa é a operação de mesclagem com chave de negócio declarada, que atualiza o registro existente em vez de inserir um novo. Em ambos os casos, a condição necessária é a existência de uma chave que identifique inequivocamente o registro na origem.

A operação de mesclagem exige a declaração explícita da chave de negócio. O exemplo a seguir aplica-se à camada tratada da Rede Aurora e é idempotente por construção: executá-la duas vezes com a mesma entrada produz o mesmo conjunto de registros e valores, com exceção da coluna de auditoria atualizado_em.

-- Carga idempotente por mesclagem, com chave de negócio declarada.
-- Reexecutar esta instrução não duplica registros; apenas atualizado_em muda.
MERGE INTO silver.item_venda AS destino
USING (
    -- A deduplicação na origem é obrigatória: MERGE falha ou produz
    -- resultado não determinístico se a fonte trouxer a chave repetida.
    -- QUALIFY não é ANSI; em PostgreSQL, filtrar ordem = 1 em subconsulta.
    SELECT id_cupom, sequencia_item, valor_total_com_imposto, data_particao,
           ROW_NUMBER() OVER (
             PARTITION BY id_cupom, sequencia_item
             ORDER BY extraido_em DESC
           ) AS ordem
    FROM bronze.cupom_item
    WHERE data_particao = '2026-08-12'
    QUALIFY ordem = 1
) AS origem
ON  destino.id_cupom      = origem.id_cupom
AND destino.sequencia_item = origem.sequencia_item

WHEN MATCHED THEN UPDATE SET
    valor_total_com_imposto = origem.valor_total_com_imposto,
    atualizado_em           = CURRENT_TIMESTAMP

WHEN NOT MATCHED THEN INSERT
    (id_cupom, sequencia_item, valor_total_com_imposto, data_particao)
VALUES
    (origem.id_cupom, origem.sequencia_item,
     origem.valor_total_com_imposto, origem.data_particao);

Duas condições sustentam a idempotência dessa instrução. A primeira é a existência de uma chave que identifique o registro na origem — sem ela, não há critério para distinguir atualização de inserção, e a operação degenera em acréscimo. A segunda é a deduplicação prévia da fonte: quando a mesma chave aparece duas vezes no conjunto de origem, o padrão SQL exige erro de cardinalidade, e os mecanismos que não o aplicam produzem resultado dependente da ordem de leitura, o que anula a propriedade que se pretendia obter.

Fila de mensagens não processáveis

Registros que falham repetidamente no processamento não devem interromper o fluxo nem ser descartados. O destino adequado é uma fila de mensagens não processáveis, na qual permanecem íntegros, com o registro do erro que os impediu de prosseguir, disponíveis para inspeção e reprocessamento após a correção. Descartá-los produz perda silenciosa; mantê-los na fila principal produz bloqueio indefinido do fluxo.

RPO e RTO: dois números distintos

O objetivo de ponto de recuperação (RPO) declara quanto dado a organização aceita perder, medido em tempo: um RPO de uma hora significa que, após um incidente, admite-se a perda de até uma hora de dados anteriores à falha. O objetivo de tempo de recuperação (RTO) declara em quanto tempo o serviço deve voltar a operar. São grandezas independentes: uma organização pode exigir RPO baixo e tolerar RTO alto, e a recíproca.

Do diagrama decorre uma consequência de projeto frequentemente ignorada: o RPO é função da frequência com que se produzem pontos de recuperação, ao passo que o RTO é função da velocidade do procedimento de restauração. Exigir RPO de cinco minutos implica produzir pontos de recuperação a cada cinco minutos; exigir RTO de trinta minutos implica dispor de um procedimento testado que conclua nesse prazo. São investimentos distintos, e declará-los conjuntamente sem distinguir suas causas leva a dimensionamento incorreto.

Evolução de esquema e compatibilidade

Esquemas mudam. A política de evolução deve declarar, antes da primeira mudança, quais alterações são admitidas sem coordenação com os consumidores e quais exigem versionamento e prazo de transição. A distinção baseia-se em dois conceitos: uma alteração é retrocompatível quando consumidores escritos para o esquema antigo continuam operando sobre o novo; é compatível para frente quando consumidores escritos para o esquema novo operam sobre dados no formato antigo.

8. RM-ODP: cinco pontos de vista sobre a mesma arquitetura

O Reference Model of Open Distributed Processing (RM-ODP), normalizado como ISO/IEC 10746, estabelece que um sistema distribuído deve ser descrito por cinco pontos de vista complementares. Cada ponto de vista responde a preocupações de partes interessadas distintas, e nenhum deles é redutível aos demais. Sua utilidade em arquitetura de dados é diagnóstica: permite identificar qual aspecto do sistema permaneceu não especificado.

A separação entre os dois últimos pontos de vista é a que produz maior efeito prático. Decisões de engenharia — particionar por data, exigir formato transacional, adotar barramento de eventos — condicionam a arquitetura de modo duradouro. Decisões de tecnologia — qual produto específico implementa o armazenamento — devem ser substituíveis. Uma arquitetura descrita exclusivamente por nomes de produtos não permite avaliar o que se perde ao trocá-los, porque o requisito que cada produto atendia nunca foi enunciado.

9. Ponte com a Aula 1: como este tema vira especificação

Os conceitos desta aula entram no projeto pelo vocabulário estabelecido na Aula 1. Uma decisão arquitetural orienta a implementação quando se converte em requisito, decisão registrada e cenário verificável. A seguir, a tradução completa do tema para os quatro artefatos do desenvolvimento orientado a especificação.

Requisito funcional

Requisito não funcional

Decisão registrada

Cenário de aceite

# Cenário que deve falhar antes da implementação
Funcionalidade: Reprocessamento de partição sem duplicação

  Cenário: Recuperar carga interrompida da camada prata
    Dado que a carga da camada prata falhou no dia 12
      E que a camada bronze preserva a cópia íntegra da origem
    Quando eu reprocesso a partição desse dia
    Então a camada ouro é reconstruída sem duplicar registros
      E a contagem de itens coincide com a da origem
      E a linhagem aponta a nova execução

O cenário acima possui a propriedade exigida de um critério de aceite: ele falha antes da implementação. Uma rotina de carga que insere incondicionalmente reprova na asserção de contagem, e a reprovação é automática, dispensando inspeção humana. Um requisito de resiliência enunciado apenas como o sistema deve ser resiliente não produz reprovação alguma e, por consequência, não impõe restrição ao implementador.

10. Estudo de caso integrado: a arquitetura da Rede Aurora

As seções anteriores produziram decisões isoladas. Esta seção as consolida em uma descrição arquitetural única, no formato que o exercício preparatório da Seção 12 solicita para o projeto do grupo. O objetivo é demonstrar que cada elemento do diagrama corresponde a uma restrição declarada.

Fluxo ponta a ponta

Três elementos do diagrama merecem justificativa explícita, pois sem ela pareceriam arbitrários.

O barramento alimenta dois destinos. O evento de pagamento é publicado uma única vez e consumido por dois caminhos independentes: o antifraude, que decide em segundos, e a camada bruta, que preserva o registro para o histórico. A duplicação ocorre no consumo, com publicação única, e permite atender à latência exigida por um caso de uso sem impor processamento contínuo aos demais.

A ciência de dados consome a camada prata. A linha tracejada representa uma exceção deliberada à proibição de salto de camada, estabelecida na Seção 3. A justificativa é que os modelos de previsão exigem granularidade anterior à agregação dimensional, e a camada ouro já a perdeu. Por constituir exceção a uma regra declarada, a decisão exige registro próprio em ADR — caso contrário, tornar-se-ia precedente informal para novos saltos, e a regra deixaria de existir na prática.

A substituição do CPF ocorre na transição para a camada prata. A camada bruta preserva o registro original, com os campos pessoais cifrados por chave de titular, porque a imutabilidade é condição do reprocessamento; o descarte da chave atende ao pedido de eliminação sem regravar a camada. A partir da camada prata, apenas o identificador substituto circula, o que limita a superfície de exposição sem impedir a correção retroativa de regras.

Quadro de decisões registradas

Riscos declarados e plano de evolução

11. Catálogo de anti-padrões

Os arranjos a seguir reaparecem com frequência em plataformas de dados. Cada um deles é localmente razoável e globalmente prejudicial, o que explica sua persistência.

Camadas nominais

Três esquemas com nomes distintos, mesmas colunas, mesma rotina e mesmo responsável. Diagnóstico e correção foram tratados no Exercício 3.1. O sinal característico é a impossibilidade de enunciar qual garantia distinta cada transição oferece.

Consulta analítica sobre o banco de produção

Relatórios executados diretamente sobre a base transacional. O arranjo funciona enquanto o volume é pequeno e falha de modo correlacionado: a consulta pesada degrada o sistema que atende ao cliente, e a degradação ocorre justamente nos períodos de maior movimento, quando ambos são mais exigidos.

Transformação na ferramenta de visualização

Regras de negócio implementadas dentro do painel. A regra passa a existir em um artefato que não é versionado, não é testado e não é reutilizável; quando um segundo painel precisa da mesma métrica, ela é reimplementada, e as duas implementações divergem sem que ninguém seja notificado.

Retenção indefinida por omissão

Ausência de política de descarte. O custo cresce de modo monotônico e a exposição a dados pessoais permanece muito além da finalidade que autorizou a coleta. Em matéria de dado pessoal, a retenção sem finalidade declarada constitui tratamento sem base legal.

Acesso concedido por conveniência

Privilégios amplos atribuídos para resolver um bloqueio pontual e nunca revistos. A revisão periódica de acessos deve constar do desenho, com frequência declarada, pois a tendência natural do conjunto de privilégios é crescer.

12. Exercício preparatório para a Ponderada em Sala

Critérios de autoverificação

1. A descrição declara o requisito funcional e ao menos um requisito não funcional mensurável.
2. A decisão estrutural está registrada em ADR, com alternativa descartada e consequência aceita.
3. Existe ao menos um cenário de aceite que falha antes da implementação.
4. Há responsável nomeado, forma de operação e caminho de reprocessamento.

Lista de verificação do exercício

Percorra a lista abaixo aplicando cada item à descrição produzida para o projeto do grupo. Os itens podem ser marcados diretamente nesta página.

• As restrições estão escritas em números, não em adjetivos.
• Está declarada a decisão de negócio que a plataforma sustenta.
• Ao menos uma alternativa foi descartada, com o motivo registrado.
• Cada camada possui contrato de entrada, contrato de saída e responsável nomeado.
• Nenhum consumidor lê a camada bruta, ou a exceção está registrada em ADR.
• A escolha do padrão de plataforma cita a restrição concreta que ele resolve.
• O custo de governança do padrão adotado foi estimado, e não apenas o de infraestrutura.
• Existe justificativa por caso de uso para cada trecho em processamento contínuo.
• Os dados sensíveis estão classificados antes de qualquer movimentação.
• A linhagem permite responder quem é afetado por uma alteração na origem.
• Há política de retenção e de descarte declarada por classe de dado.
• RPO e RTO estão declarados por domínio, com teste de recuperação previsto.
• As rotinas de carga são idempotentes antes de qualquer reprocessamento automático.
• A política de evolução de esquema declara o que quebra compatibilidade.
• Os riscos possuem sinal observável e resposta planejada.
• Existe ao menos um cenário de aceite que reprova a implementação atual.

13. Glossário

14. Referências

• TOGAF — Architecture Development Method. Método iterativo de desenvolvimento de arquitetura corporativa, com ênfase na rastreabilidade entre requisitos e decisões.
• DAMA-DMBOK2 — Data Management Body of Knowledge. Corpo de conhecimento em gestão de dados; posiciona a governança como função central e não posterior.
• ISO/IEC/IEEE 42010 — Architecture description. Norma que estabelece partes interessadas, preocupações e pontos de vista como elementos obrigatórios de uma descrição arquitetural.
• ISO/IEC 10746 — RM-ODP. Modelo de referência para processamento distribuído aberto; origem dos cinco pontos de vista tratados na Seção 8.
• AWS Well-Architected Framework. Conjunto de pilares e questões de avaliação aplicáveis à revisão de arquiteturas, incluindo excelência operacional e confiabilidade.
• Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais. Base normativa das exigências de finalidade, minimização e eliminação tratadas na Seção 6.