Referência de Arquitetura (Arquiteto Corporativo / Autoridade de Design)
Para contextos regulados da UE/França (bancário, saúde, defesa). Os detalhes regulatórios evoluem: qualquer coisa marcada como "verificar" deve ser conferida no texto oficial atual antes de ser usada em uma entrega.
Índice de referências
references/togaf-archimate.md— leia ao estruturar um esforço de arquitetura (fases ADM, entregáveis, governança, revisões de conformidade) ou modelar com ArchiMate (camadas, elementos, relacionamentos, viewpoints). Caminho completo${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.mdreferences/urbanisation.md— leia ao produzir ou usar mapas de SI franceses (zonas/quartiers/îlots, cartografias), um schéma directeur, avaliação de portfólio de aplicações (TIME) ou um plano de racionalização/descomissionamento. Caminho completo${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.mdreferences/adr.md— leia ao escrever ou revisar um Registro de Decisão de Arquitetura ou uma matriz de decisão (Nygard, MADR, Y-statements, critérios ponderados, exemplos fictícios). Caminho completo${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md
Modelos de entregáveis relacionados: ${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md, interface-contract.md, flow-matrix.md.
Detalhes regulatórios (GDPR, DORA, NIS2, HDS, II 901, IGI 1300…) vivem na skill sector-compliance e em suas referências setoriais (${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/); esta skill cobre apenas as implicações arquitetônicas.
1. Papel: autoridade de design
É responsável por: princípios e padrões de arquitetura; arquitetura alvo e roadmap; decisões estruturais (ADRs); coerência entre domínios e especialistas; dispensas (dérogations) com prazo de validade; revisões de conformidade de arquitetura; registro de dívida técnica em nível de arquitetura. Não é responsável por: aceitação de risco de segurança (proprietário do risco de negócio / autoridade de homologação, assessorado pelo RSSI); decisões de dados pessoais (controlador, assessorado pelo DPO); arbitragem de orçamento/cronograma (COPIL); mudanças em produção (CAB).
Portões de revisão
| Portão | Quando | Verificações |
|---|---|---|
| G0 Escopo | Nota de cadrage | Alinhamento com alvo/roadmap, opções identificadas, perímetro regulatório, classe de soberania dos dados |
| G1 Design | DAT / rascunhos de contratos de interface | Conformidade com princípios, NFRs quantificados, padrão de integração, propriedade de dados, arquitetura de segurança, reversibilidade |
| G2 Pré-construção | Design congelado | ADRs aceitas, dispensas assinadas, matriz de fluxo completa, design de operações/DR |
| G3 Pré-go-live | Antes do go/no-go | As-built vs DAT, dívida incorrida registrada, DR testado, registro DORA / mapa de dependências atualizado |
Resultado de uma revisão: conforme / conforme com reservas (ações + prazos) / dispensa (proprietário do risco + prazo de validade) / não conforme (bloqueante).
2. Princípios de arquitetura
Formato (estilo TOGAF): Nome — Declaração — Justificativa — Implicações. Mantenha 10-15, cada um testável em uma revisão. Conjunto padrão para contextos de integração regulados:
| # | Princípio | Implicação testável |
|---|---|---|
| P1 | Continuidade de negócios por design | Toda função crítica tem RTO/RPO declarado atendido por design e testado |
| P2 | Segurança e privacidade por design e por padrão (GDPR Art. 25) | Dados classificados (DICT) antes do design; privilégio mínimo; criptografia em trânsito e em repouso |
| P3 | Fonte única de verdade por domínio de dados | Cada entidade de dados tem um sistema mestre e um proprietário nomeado; outros mantêm cópias governadas |
| P4 | Acoplamento fraco através de interfaces gerenciadas | Nenhum acesso direto ao banco de dados de outra aplicação; todas as trocas via APIs contratadas, mensagens ou arquivos |
| P5 | Reutilizar antes de comprar antes de construir | Plataformas compartilhadas existentes (MFT, gateway de API, IAM, agendamento) usadas a menos que um ADR diga o contrário |
| P6 | Padrões e formatos abertos | Protocolos/formados abertos preferidos; proprietário apenas com plano de reversibilidade |
| P7 | Reversibilidade e saída | Todo serviço externo tem um plano de saída; dados exportáveis em formatos documentados |
| P8 | Operabilidade é um requisito | Monitoramento, logs, agendamento, reinicialização e DEX projetados com a solução |
| P9 | Rastreabilidade e auditabilidade | IDs de correlação ponta a ponta; trilhas de auditoria retidas conforme requisitos legais |
| P10 | Residência e soberania de dados por classificação | Escolha de hospedagem derivada da classe de dados (ver §6) |
| P11 | Simplicidade e racionalização | Novo componente apenas se nenhum existente atender; descomissionamento planejado a cada substituição |
| P12 | Automatizar a cadeia de entrega | Infraestrutura e implantações como código, ambientes reproduzíveis |
3. Arquiteturas alvo vs. transição
- Linha de base (as-is), Alvo (to-be no horizonte, tipicamente 3-5 anos), Arquiteturas de transição (platôs: estados intermediários estáveis e operáveis entregando valor), Análise de lacunas (o que é adicionado, removido, alterado), Roadmap (pacotes de trabalho, dependências, datas de descomissionamento).
- Cada transição deve ser operável por si só (suportada, monitorada, coberta por DR, documentada) — o projeto pode parar ali.
- Pontes de coexistência (sincronização temporária, evitar escrita dupla, camadas de anti-corrupção) são componentes de primeira classe: proprietário, custo, data de desativação, entrada de dívida.
- "Temporário" sem data de desativação torna-se permanente: recuse no G1.
- Prefira migração incremental (strangler fig: rotear funcionalidade progressivamente para o novo sistema por trás de uma fachada) em vez de substituição big-bang quando o legado é grande e mal documentado.
4. Arquitetura de integração (nível macro)
O design detalhado pertence ao especialista em integração; o arquiteto define o padrão e as regras.
| Padrão | Adequado para | Evitar quando | Cuidados |
|---|---|---|---|
| Ponto a ponto | ≤ poucos fluxos estáveis, tático | Muitos consumidores, mudanças frequentes | Espaguete (n² links), sem monitoramento central |
| Hub & spoke / EAI / ESB | Muitos sistemas heterogêneos, transformações, governança central | Hub se torna gargalo/monólito de lógica de negócios | Manter lógica de negócios fora do barramento |
| Transferência de arquivos via MFT | Lote, alto volume, trocas com parceiros, legado (muito comum em bancos/IBM i) | Necessidades em tempo real | Verificações de integridade, nomenclatura, horários de corte, reenvio, criptografia, não repúdio |
| Liderado por API (camadas de sistema / processo / experiência) | Serviços reutilizáveis, canais digitais, APIs de parceiros | Movimentação de dados em massa | Gerenciamento de API, versionamento, cotas, OAuth2/mTLS |
| Orientado a eventos (pub/sub, streaming de eventos, CDC) | Reações desacopladas, propagação em tempo real, muitos consumidores | Consistência transacional forte necessária entre sistemas | Ordenação, idempotência, evolução de esquema, replay, propriedade do evento |
| Plataforma de dados (DWH, lake, lakehouse, data mesh) | Análises, relatórios regulatórios, ML | Integração transacional operacional | Linhagem, qualidade, retenção, segregação de dados sensíveis |
| MDM / référentiels | Dados mestre compartilhados (cliente, produto, organização, identidade do paciente) | Dados com um único proprietário natural | Esforço de governança e administração é o custo real |
Regras práticas: chamadas síncronas apenas quando o chamador realmente precisa da resposta agora; assíncrono por padrão entre domínios; projete todo fluxo para falha (retry com backoff, dead-letter, replay, consumidores idempotentes); use o padrão outbox em vez de escritas duplas; modelos de dados canônicos apenas dentro de um escopo limitado (modelos canônicos em toda a empresa raramente sobrevivem); versione cada contrato; um ID de correlação ponta a ponta.
5. Requisitos não funcionais
Quantifique cada NFR; "alta disponibilidade" não é um requisito.
| Categoria | Métricas / perguntas | Armadilhas |
|---|---|---|
| Disponibilidade | % ao longo de um período, horário de serviço, tempo de inatividade planejado permitido | Ignorar a cadeia de dependência; medir infra não serviço |
| Continuidade | RTO / RPO (DMIA / PDMA) por função de negócio, MTPD | RPO 0 prometido com replicação assíncrona; reinicialização em lote ignorada |
| Desempenho | Throughput, latência p95/p99, janela de lote, fator de pico, crescimento | Testar média não pico; picos de fim de mês esquecidos |
| Escalabilidade | Volumes no horizonte, elasticidade | Modelos de licença que escalam custo não linearmente |
| Segurança | Classificação DICT, IAM, criptografia, registro, segregação | Segurança adicionada após o design |
| Operabilidade | Monitoramento, alertas, logs, reinicialização, agendamento, automação | DEX escrito após o go-live |
| Observabilidade | Traços, métricas, logs, correlação, KPIs de negócio | Nenhuma visão ponta a ponta entre middlewares |
| Reversibilidade | Plano de saída, formatos de exportação, tempo e custo para sair | Apenas contratual, nunca testada |
| Interoperabilidade | Padrões (ex.: ISO 20022 em pagamentos, HL7 FHIR em saúde — verificar mandatos setoriais) | Dialetos locais de padrões |
| Conformidade / residência | Localização dos dados, retenção, retenções legais, auditoria | Backups e logs armazenados fora da zona acordada |
| Mantenabilidade | Cadência de atualização, datas de suporte do fornecedor | Fim de suporte no meio do projeto |
| Sustentabilidade | Eficiência de recursos (diretrizes de ecodesign RGESN na França — verificar status) | Ambientes de não produção superdimensionados |
Folha de dicas de disponibilidade (por ano): 99 % ≈ 3,65 dias; 99,5 % ≈ 1,83 dias; 99,9 % ≈ 8,76 h; 99,95 % ≈ 4,38 h; 99,99 % ≈ 52,6 min; 99,999 % ≈ 5,3 min. Cadeia serial: A = A1 × A2 × … ; par redundante: A = 1 − (1 − A1)(1 − A2) (assume falhas independentes — raramente totalmente verdade). Coerência RPO/RTO: RPO é limitado pelo modo de replicação e frequência de backup; RTO inclui detecção, decisão, failover, reparo de dados, atualização em lote e ressincronização de parceiros — não apenas o tempo de comutação técnica.
6. Estratégia de nuvem e soberania
Classifique primeiro, depois hospede: a classe de dados orienta a opção de hospedagem.
| Classe de dados / sistema | Opções típicas de hospedagem (verificar contra as regras atuais) |
|---|---|
| Público / interno, não sensível | Nuvem pública aceitável com controles padrão |
| Dados pessoais (GDPR) | Hospedagem na UE preferida; transferências para fora do EEE precisam de base do Capítulo V e avaliação de impacto de transferência |
| Dados pessoais de saúde (França) | Provedor de hospedagem certificado HDS necessário (Code de la santé publique, Art. L.1111-8); referencial HDS recente adiciona requisitos de localização de dados no EEE — verificar versão atual e datas de transição |
| Dados de sensibilidade particular (données d'une sensibilité particulière) de serviços do Estado, operadores do Estado e GIP listados | Oferta qualificada SecNumCloud, ou uma certificação UE/EEE que a ANSSI reconhece como equivalente: Lei SREN Art. 31 (2024), decreto n° 2026-272 (14 de abril de 2026), portaria de 12 de agosto de 2026; a doutrina "cloud au centre" (2021, atualizada em 2023) estende a expectativa a outros SI do Estado — regime de isenção nesses textos |
| Diffusion Restreinte (DR) | Sistemas acreditados conforme II 901; restrições específicas de hospedagem — verificar |
| Classificado (Secret / Très Secret, IGI 1300) | Infraestrutura dedicada acreditada; nuvem pública geralmente excluída |
| Funções bancárias críticas ou importantes | Permitido com requisitos de terceiros DORA, regras de terceirização (diretrizes EBA) e notificação ao supervisor quando necessário — verificar |
SecNumCloud: Qualificação ANSSI de provedores de serviços em nuvem contra o référentiel d'exigences v3.2 (8 de março de 2022; a versão aprovada pela portaria de 12 de agosto de 2026). Além dos requisitos técnicos de segurança, seu §19.6 protege contra leis extraterritoriais não-UE: provedor estabelecido na UE, acionistas não-UE limitados a 24 % individualmente e 39 % coletivamente, dados armazenados e serviço administrado e supervisionado a partir da UE. Rótulos de marketing "soberano" não são qualificação: peça o certificado de qualificação e seu escopo de serviço exato. Exposição extraterritorial: avalie o risco de acesso legal não-UE (ex.: US CLOUD Act, FISA s.702) contra a classe de dados; criptografia com chaves retidas pelo cliente (HSM/BYOK/HYOK) reduz, mas nem sempre remove. Cláusulas de reversibilidade (contrato + arquitetura): plano de saída e período de assistência; exportação de dados e metadados em formatos abertos documentados a custo não proibitivo; certificado de exclusão; exportação de documentação e configuração; continuidade do serviço durante a saída; prazos de aviso; lista de subprocessadores; direitos de auditoria. Lei de Dados da UE (Regulamento (UE) 2023/2854, Capítulo VI) aplica-se desde 12 de setembro de 2025: provedores devem suportar a troca e podem cobrar apenas seus custos reais de troca/saída até 12 de janeiro de 2027, nada após essa data. Habilitadores de arquitetura: cargas de trabalho portáteis (contêineres, IaC), bancos de dados padrão ou caminhos de migração documentados, evitar acoplamento profundo a PaaS proprietário para funções principais, a menos que um ADR aceite, teste periódico de saída (pelo menos exportar + restaurar em outro lugar). Opções de migração para nuvem (6R/7R): aposentar, reter, rehospedar, realocar, replataformar, refatorar, recomprar — decida por aplicação a partir da avaliação de portfólio (veja referência de urbanização).
7. Gestão de dívida técnica
- Tipos: arquitetura (padrão errado, acoplamento), obsolescência (versões sem suporte), código, dados (qualidade, duplicatas), operacional (etapas manuais), documentação, segurança (correções adiadas).
- Registro: item, tipo, localização, causa (deliberada via ADR / acidental), juros (custo ou risco por período), principal (custo para corrigir), proprietário, prazo, link para ADR/ dispensa.
- Calendário de obsolescência: datas de fim de suporte do fornecedor para SO, BD, middleware, runtimes, versões ERP, releases IBM i; sinalize qualquer coisa que termine nos próximos 24 meses.
- Financiamento: reserve capacidade explícita (comumente citado 15-20 % da capacidade de entrega — específico da organização); dívida de uma dispensa de projeto é custeada nesse projeto.
- Dívida que afeta funções críticas é um risco TIC: reporte-o no framework de risco, não apenas nos backlogs de TI.
8. Risco TIC DORA sob uma perspectiva arquitetônica
Regulamento (UE) 2022/2554, aplicável desde 17 de janeiro de 2025, complementado por RTS/ITS. Os números de artigo abaixo são indicativos: confirme-os no EUR-Lex antes de citá-los em uma entrega.
| Tópico DORA | Contribuição da arquitetura |
|---|---|
| Estrutura de gestão de risco TIC (Art. 6) | Princípios de arquitetura, padrões e arquitetura alvo como controles documentados |
| Identificação (Art. 8) | Inventário de ativos TIC e ativos de informação; mapeamento de dependências de processos de negócio, funções de TI e terceiros; classificação de dados e sistemas |
| Proteção e prevenção (Art. 9) | Segurança por design, criptografia, segregação de rede, princípio do menor privilégio; resiliência de integrações (dead-letter, retry, idempotência); continuidade entre zonas de disponibilidade e regiões |
| Detecção (Art. 10) | Observabilidade: logs centralizados, métricas, correlação de alertas; trilhas de auditoria imutáveis; baseline de comportamento normal |
| Resposta e recuperação (Art. 11) | Planos de DR e continuidade desenhados em nível de arquitetura (não apenas infra); procedimentos de failover e fallback testados; backups e replicação de dados |
| Aprendizado e evolução (Art. 12) | Pós-mortem de incidentes alimentando mudanças de arquitetura; atualização de ADRs com base em lições aprendidas |
| Comunicação (Art. 14) | Dependências de terceiros mapeadas e disponíveis para notificação; DR e contatos operacionais documentados |
| Gestão de risco de terceiros (Art. 28-44) | Registro de provedores de TIC: tipo de serviço, criticidade, classificação de dados compartilhados, plano de saída, avaliação da cadeia de dependência; cláusulas contratuais cobrindo reversibilidade, direitos de auditoria, continuidade |
Provedores de TIC críticos (Art. 31, supervisionados pelo ESMA/EBA/EIOPA): se um provedor de terceiros para uma função crítica estiver designado como crítico, requisitos de supervisão mais rigorosos se aplicam — verifique a lista no site da ESMA.
9. Estratégia de dados
Cada domínio de dados nomeia um proprietário de dados (papel de negócio) e um custódio de dados (papel de TI). Custódios publicam contratos de dados (esquema, SLA de qualidade, localização, classe, retenção, linhagem).
| Atividade | Descrição |
|---|---|
| Streaming vs lote | Decidir por caso de uso. Onde os consumidores precisam de reação em tempo real, prefira streaming + materialized views em vez de lotes noturnos; para relatórios regulatórios, lote acionado por eventos (CDC para o data lake) frequentemente se adequa |
| Linhagem | Ferramenta de linhagem end-to-end (ex.: Apache Atlas, Collibra, data catalog do fornecedor de nuvem) para rastrear origem, transformações e consumo; especialmente para métricas regulatórias e de relatórios |
| Qualidade | Regras por domínio (completude, unicidade, conformidade a um referencial — ex.: código ISO de país); monitorada e relatada; ações corretivas vinculadas ao ciclo de vida da dívida técnica |
| Mestre vs referencial | Mestre: sistema de registro para uma entidade de negócio (ex.: CRM para cliente). Referencial: código/label padrão usado por várias aplicações (ex.: tabela de código de país) |
10. Lista de verificação de coerência entre especialistas
Use no final do G1 (Design) antes de congelar; cada item é uma verificação de coerência entre domínios atendida por pares especialistas.
| Especialidade | Verificação |
|---|---|
| Segurança | DICT atribuído? Fluxos criptografados e autenticados? Identidade e acesso (IAM/HID) projetados? Segregação de rede desenhada (DMZ, zonas)? Logs de segurança conservados? |
| Operações | Monitoramento e alertas por componente? Logs centralizados e correlacionados? Agendamento de lotes (janela, dependências)? Procedimentos de restart e DR testados? Documentação operacional (runbook) esboçada? |
| Dados | Propriedade declarada? Contrato de dados publicado? Qualidade medida? Linhagem documentada? Conformidade com retenção e exclusão cumprida? |
| Aplicações | APIs contratadas e versionadas? Dependências reversíveis? Obsolescência planejada (upgrade stack)? Testes de desempenho e resiliência no critério de aceitação? |
| Infraestrutura | Portabilidade da carga de trabalho (contêiner, IaC)? Limites de capacidade conhecidos? Zonas de disponibilidade/regiões usadas para resiliência? Licenciamento verificado (sem surpresa de escala)? |
| Integração | Padrão escolhido e justificado para cada fluxo? Propriedade e monotoramento de filas/tópicos/APIs? Retry, dead-letter, idempotência projetados? SLA de integração documentado? |
| Negócios | Valor e criticidade de cada função conhecidos? RTO/RPO por função validados com o negócio? Patrocínio e orçamento para a arquitetura alvo confirmados? Prontidão para mudança organizacional avaliada? |
11. Metadados da skill
- Propósito: Referência de autoridade de design para ambientes regulados — princípios, padrões de integração, NFRs quantificados, estratégia de nuvem, dívida técnica, risco DORA e verificação de coerência entre pares.
- Ativadores: ["Projetar arquitetura alvo", "Revisar design de solução", "Escrever ADR", "Avaliar opção de nuvem", "Planejar migração", "Auditar conformidade arquitetônica"]
- Tags: arquitetura, togaF, urbanisation, SecNumCloud, DORA, dívida-técnica, soberania, design-authority
- Referências: See top of file