APRENDER. PRATICAR. EVOLUIR.Comparar capacidades, não apenas inventários
Uma aplicação pode permanecer no inventário e ainda ter uma lacuna importante. Se hoje só permite recuperação integral e o objetivo exige recuperação seletiva, o nome igual não elimina a diferença. Regista a capacidade em falta e os requisitos associados antes de escolher a solução. A análise pode conduzir a alteração, substituição ou outra opção avaliada. Evita transformar a identificação da lacuna numa recomendação automática de produto: compreender a diferença e escolher como a resolver são passos relacionados, mas exigem evidência e decisões distintas.
Distinguir condições obrigatórias de preferências
Uma matriz de pontuação é útil quando se sabe o que pode ser compensado. No exemplo, residência num território é obrigatória e não há exceção autorizada. A opção de 92 pontos que viola essa condição não vence a de 81 por ter melhor experiência de utilização. Primeiro avalia viabilidade segundo condições explícitas; depois compara preferências das opções viáveis. Se o contexto ou a autoridade permitirem rever uma condição, isso é uma decisão separada e rastreável. Não a escondas numa alteração oportunista dos pesos.
Procurar dependências de falha comum
Distribuir aplicações por duas zonas melhora alguns cenários, mas não elimina a dependência de um serviço de identidade único necessário para arrancar. Representa o caminho de autenticação, as condições de arranque e as opções de recuperação. Pergunta também se os mecanismos de recuperação precisam do serviço indisponível. A análise de relações ajuda a encontrar este tipo de circularidade operacional. Não multipliques números de disponibilidade presumindo independência sem a demonstrar. O objetivo do exercício é identificar perguntas e evidência necessárias, não calcular uma disponibilidade bancária real a partir de um diagrama.
Ligar partições sem eliminar autonomia útil
As equipas de API e batch podem ter ritmos próprios enquanto cumprem um contrato partilhado. Alterar o significado de um campo exige coordenação mesmo sem mudar o nome ou tipo técnico. Regista consumidores e versões, define a incerteza a resolver e usa uma iteração para obter a evidência necessária. Um critério de saída, como concordância sobre exemplos e comportamento esperado, ajuda a estabilizar o contrato. Autonomia local continua possível onde não quebra relações acordadas; fundir todas as decisões não é uma consequência necessária de uma dependência.
Interpretar aprovação, vigência e implementação
O repositório pode guardar v3 aprovada para novembro quando v2 ainda está em produção em outubro. Uma vista operacional deve representar o estado relevante para operação; uma vista de planeamento precisa também do alvo aprovado. Guarda estados e datas que permitam selecionar corretamente, sem apagar histórico útil. A mesma disciplina aplica-se a exceções: aprovação com prazo não é conformidade permanente. Quando o prazo termina ou falta uma condição, o reporte deve mostrar a situação atual e encaminhar a decisão pela autoridade estabelecida, sem inventar uma renovação.
Usar relações para preparar a retirada
Um catálogo de ativos identifica o que existe. Para retirar uma base de dados, precisas também de saber quem lê, escreve ou depende dela para recuperar. Uma matriz pode tornar essas relações claras; o formato é escolhido pela pergunta a responder. No exemplo, A já migrou, mas B ainda lê uma vista em D. A responsabilidade financeira de A não prova exclusividade. Confirma o consumo de B, avalia a alternativa e inclui custo residual, responsável e condição de retirada. Desativar alertas não remove a dependência nem preserva reconciliação.
Montar um pacote de decisão verificável
Para o requisito de recuperar em 30 minutos, liga a opção arquitetural à evidência relevante, com versão, cenário, resultado e limitações. Acrescenta o responsável pela decisão e os próximos passos quando existir lacuna. Um diagrama bonito sem esta ligação pode ser insuficiente para decidir. Os modelos de entregáveis do fornecedor podem orientar estrutura, mas preencher secções não demonstra conformidade. Aqui usamos exemplos originais e informação pública sobre o âmbito Foundation; os exercícios não substituem o estudo do corpo de conhecimento completo nem equivalem a uma avaliação oficial.
Exercício guiado: desenha A → D e B → vista → D. Marca A como migrada e verifica que caminho permanece. Prepara uma recomendação de retirada que inclua o responsável de B e evidência da nova fonte.
Armadilhas comuns
Confundir a versão mais alta com a instalada; somar preferências para compensar restrições obrigatórias; inferir independência a partir de duas zonas; eliminar histórico de uma exceção expirada.
Tópicos relacionados: Análise de lacunas e opções · Conteúdo e rastreabilidade · Exceções e decommission
Relações e estados dão significado ao inventário. Usa-os para explicar o que depende de quê, qual evidência se aplica e quem pode decidir antes de retirar serviços ou aceitar diferenças.
Referência: How ArchiMate and TOGAF complement each other · OGEA-101, TOGAF Enterprise Architecture Foundation; body of knowledge drawn from TOGAF Standard, 10th Edition