O planejamento de continuidade de negócios falha com mais frequência não durante uma crise, mas sim durante a avaliação que a precede. As organizações realizam Análises de Impacto nos Negócios (BIA), documentam os Objetivos de Tempo de Recuperação (RTO), criam planos de recuperação abrangentes e, então, descobrem, no pior momento possível, que um serviço de autenticação legado aparentemente não crítico é um ponto único de falha para toda a sua plataforma de e-commerce, que o programa em lote COBOL que todos presumiam ser de baixa prioridade alimenta o serviço de validação de pagamentos em tempo real, ou que dois aplicativos atribuídos ao mesmo nível de recuperação possuem uma dependência não documentada que torna a recuperação sequencial impossível. A avaliação foi feita. As dependências, não.
A avaliação da criticidade de aplicações é o processo de atribuir uma medida quantitativa ou hierárquica de importância a cada aplicação no portfólio de uma organização. Essa medida determina sua prioridade de recuperação, seu nível de investimento em redundância, seus requisitos de controle de mudanças e sua posição na sequência de recuperação de desastres. Quando essa avaliação se baseia apenas em pesquisas de impacto nos negócios e entrevistas com os proprietários das aplicações, ela reflete o que as pessoas acreditam que as aplicações fazem. Quando se fundamenta em uma análise estrutural do que as aplicações realmente fazem, quem se comunica com quem, quais dados fluem por quais programas e quais componentes compartilhados estão no caminho crítico de múltiplos sistemas de maior prioridade, ela reflete a realidade operacional.
A discrepância entre a crença e a realidade é onde os planos de continuidade de negócios falham.
Sequências de recuperação que refletem dependências reais
SMART TS XL Identifica todos os programas no caminho crítico de suas aplicações de Nível 1 — em todos os idiomas do seu portfólio.
SAIBA MAIS…O que a pontuação de criticidade de aplicativos realmente mede?
A criticidade não é uma dimensão única. Para determinar a pontuação de criticidade de uma aplicação empresarial, pode-se levar em consideração a opinião do usuário para avaliar a criticidade ou importância da aplicação, incluindo o maior impacto nas necessidades estratégicas de negócios, os impactos nos parceiros comerciais, as interações com os clientes e os impactos em outras aplicações empresariais. Cada uma dessas dimensões captura um aspecto diferente do que significa "crítico":
Impacto nos negócios : o que a organização perde por hora de inatividade. A perda de receita é a dimensão mais visível: um sistema de processamento de pagamentos que movimenta US$ 10 milhões por hora tem um custo quantificável por minuto de inatividade. Mas o impacto nos negócios vai além da receita, abrangendo também a exposição a regulamentações (quais obrigações de conformidade a inatividade acarreta?), danos à reputação (os clientes são afetados diretamente?) e penalidades contratuais (os SLAs acionam cláusulas penais?).
Dependência operacional : quantos outros sistemas ou processos dependem desta aplicação? Uma aplicação com baixo impacto direto nos negócios pode ter alta criticidade por estar na cadeia de dependência de aplicações com alto impacto direto. O serviço de autenticação que viabiliza todas as outras aplicações voltadas para o cliente é mais crítico do que sua função em si sugere.
Complexidade de recuperação : o quão difícil e demorado é restaurar a aplicação. Uma aplicação com impacto moderado nos negócios e um tempo de recuperação de 48 horas pode exigir um investimento maior em redundância do que uma aplicação com maior impacto nos negócios e um tempo de recuperação de 2 horas, porque o risco total de inatividade é maior.
Obrigações regulatórias definem quais aplicações estão sujeitas a requisitos de continuidade regulatória. Instituições financeiras sujeitas à DORA devem demonstrar que funções críticas ou importantes podem resistir a cenários de interrupção específicos. Organizações de saúde sujeitas à HIPAA devem proteger a disponibilidade de sistemas que contenham informações de saúde protegidas. A dimensão regulatória pode sobrepor-se à avaliação de impacto nos negócios para aplicações específicas.
A pontuação de criticidade é uma composição das quatro dimensões, ponderada pela tolerância específica ao risco da organização, pelo ambiente regulatório e pelo modelo de negócios.
Os Níveis de Criticidade Padrão
A maioria dos portfólios de aplicações empresariais utiliza um modelo de criticidade de quatro níveis. As categorias de criticidade em uma matriz de criticidade de aplicações são: Missão Crítica, Negócios Críticos, Operações de Negócios e Administração. As definições abaixo refletem as práticas atuais do setor, alinhadas com a ISO 22301 (Sistemas de Gestão de Continuidade de Negócios) e as Diretrizes de Boas Práticas do Business Continuity Institute:
Aplicações de Nível 1, de Missão Crítica , cuja falha interrompe imediatamente as operações essenciais do negócio ou cria um risco regulatório ou de segurança inaceitável. Objetivo de Tempo de Recuperação (RTO): tipicamente de 0 a 4 horas. Objetivo de Ponto de Recuperação (RPO): tipicamente de 0 a 1 hora. Exemplos: processamento de transações bancárias essenciais, sistemas de negociação em tempo real, sistemas de despacho de emergência, interfaces de controle industrial, sistemas de autorização de pagamentos. Essas aplicações justificam o maior investimento em infraestrutura: redundância ativa-ativa, replicação com RPO zero, failover automatizado e o mais rigoroso controle de mudanças.
Nível 2: Aplicações críticas para os negócios, cuja falha prejudica significativamente as operações comerciais, mas não as interrompe imediatamente. Objetivo de Tempo de Recuperação (RTO): normalmente de 4 a 24 horas. Objetivo de Ponto de Recuperação (RPO): normalmente de 1 a 4 horas. Exemplos: sistemas CRM, módulos ERP, gerenciamento de pedidos, sistemas de RH durante períodos de folha de pagamento, sistemas de relatórios durante janelas de submissão regulatória. Essas aplicações justificam infraestrutura de alta disponibilidade, failover testado regularmente e sequenciamento de recuperação prioritário.
Nível 3: Aplicações operacionais de negócios que dão suporte às operações comerciais, mas cuja indisponibilidade temporária pode ser gerenciada com soluções alternativas manuais. Objetivo de Tempo de Recuperação (RTO): normalmente de 24 a 72 horas. Objetivo de Ponto de Recuperação (RPO): normalmente de 4 a 24 horas. Exemplos: ferramentas de colaboração interna, relatórios não voltados para o cliente, portais administrativos, plataformas de treinamento. Procedimentos padrão de backup e recuperação são apropriados.
Nível 4: Aplicações administrativas que dão suporte a funções administrativas sem impacto operacional direto. Objetivo de Tempo de Recuperação (RTO): normalmente 72 horas ou mais. Objetivo de Ponto de Recuperação (RPO): 24 horas ou mais, ou o último backup. Exemplos: wikis de documentação interna, ferramentas de desenvolvimento não essenciais, relatórios históricos. Restaurar a partir do backup de forma oportuna.
A atribuição de níveis não é permanente. Uma aplicação que é de Nível 3 durante a maior parte do ano pode passar para o Nível 2 durante o fechamento financeiro mensal, períodos de relatórios regulatórios ou épocas de pico de negociações. A criticidade dinâmica, em que a atribuição de níveis muda com base no calendário operacional, é um refinamento que as organizações com programas de continuidade de negócios (BCP) maduros implementam após estabelecer a estrutura de níveis básica.
Metodologia de Pontuação: Traduzindo Dimensões em Números
Uma metodologia de pontuação estruturada converte as quatro dimensões de criticidade em uma pontuação numérica que orienta a atribuição de níveis de forma objetiva, em vez de por meio de políticas organizacionais. A abordagem abaixo produz uma pontuação composta de 0 a 100 usando critérios ponderados:
Dimensão 1: Impacto nos Negócios (peso: 35%)
| Impacto na receita por hora de inatividade | Pontuação |
|---|---|
| > US$ 1 milhão por hora | 35 |
| US$ 100 mil a US$ 1 milhão por hora | 28 |
| De US$ 10 a US$ 100 por hora | 21 |
| De US$ 1 a US$ 10 por hora | 14 |
| Menos de US$ 1 por hora | 7 |
| Sem impacto direto na receita | 0 |
O impacto regulatório (obrigações de conformidade com DORA, HIPAA, PCI-DSS e SOX desencadeadas por uma interrupção) adiciona até 10 pontos adicionais a essa dimensão.
Dimensão 2: Dependência Operacional (peso: 30%)
| Fan-In: Aplicações que dependem desta aplicação | Pontuação |
|---|---|
| > 20 aplicações dependentes | 30 |
| 10-20 aplicações dependentes | 24 |
| 5-9 aplicações dependentes | 18 |
| 2-4 aplicações dependentes | 12 |
| 1 aplicação dependente | 6 |
| Sem dependentes (independente) | 0 |
A contagem de fan-in aqui se refere à dependência estrutural, ou seja, ao número de aplicações que chamam esta aplicação, leem suas saídas ou dependem de seus dados, e não ao número de usuários ou à importância percebida. Essa dimensão é a que mais frequentemente é calculada incorretamente em pesquisas, porque os proprietários de aplicações não conhecem todos os seus consumidores finais.
Dimensão 3: Complexidade da Recuperação (peso: 20%)
| Tempo estimado de recuperação sem DR pré-configurado | Pontuação |
|---|---|
| > 72 horas | 20 |
| 24-72 horas | 16 |
| 8-24 horas | 12 |
| 2-8 horas | 8 |
| <2 horas | 4 |
| Failover automático em menos de 15 minutos | 0 |
Dimensão 4: Sensibilidade dos dados e obrigação regulatória (peso: 15%)
| Classificação de dados e requisitos regulamentares | Pontuação |
|---|---|
| Informações pessoais identificáveis (PII) / informações de saúde protegidas (PHI) / dados cardíacos (CHD) regulamentados com obrigação explícita de tempo de recuperação. | 15 |
| Dados regulamentados sem obrigação específica de tempo de recuperação | 12 |
| Dados internos sensíveis (segredos comerciais, registros financeiros) | 9 |
| Dados operacionais internos | 6 |
| Dados internos não sensíveis | 3 |
| Nenhum dado armazenado | 0 |
Mapeamento da pontuação composta para níveis:
| Pontuação composta | Atribuição de Níveis |
|---|---|
| 75-100 | Nível 1, Missão Crítica |
| 50-74 | Nível 2, Crítico para os Negócios |
| 25-49 | Nível 3, Operacional de Negócios |
| 0-24 | Nível 4, Administrativo |
O Problema da Dependência: Por Que a Pontuação Baseada em Pesquisas Falha
A dimensão de dependência operacional é a que tem maior probabilidade de ser calculada incorretamente e é a que acarreta as maiores consequências quando equivocada. Um serviço de autenticação legado aparentemente não crítico pode representar um ponto único de falha para toda uma plataforma de comércio eletrônico, e sua falha pode paralisar todas as transações geradoras de receita. Este processo vai além de ameaças abstratas, chegando a impactos concretos e mensuráveis nos acordos de nível de serviço.
Os proprietários de aplicativos conhecem suas dependências diretas a montante, os sistemas que eles chamam. Raramente conhecem todas as suas dependências a jusante, os sistemas que os chamam. Um serviço interno de autenticação de usuários pode ser considerado de baixa criticidade por seu proprietário (não gera receita, é simples, raramente falha), embora seja utilizado por doze aplicativos voltados para o cliente, todos de Nível 1. A criticidade real do serviço de autenticação é de Nível 1, não por causa de sua própria função, mas por causa de sua posição no grafo de dependências de sistemas de níveis superiores.
A avaliação de criticidade baseada em pesquisas produz esse erro sistematicamente. Uma pesquisa com o proprietário do aplicativo pergunta: "Qual a criticidade deste aplicativo?". O proprietário do serviço de autenticação responde "baixa a média" com base na própria função do serviço. Os doze proprietários dos aplicativos dependentes não respondem a essa pesquisa sobre o serviço de autenticação, mas sim sobre seus próprios aplicativos. A relação de dependência nunca é registrada.
A consequência disso se manifesta na sequência de recuperação: o Plano de Continuidade de Negócios (PCN) define a ordem de recuperação com base nas pontuações de criticidade derivadas da pesquisa, e o serviço de autenticação é agendado para recuperação de Nível 3. Durante um incidente real, os aplicativos de Nível 1, que deveriam ser recuperados primeiro, não conseguem se recuperar porque o serviço de autenticação do qual dependem não foi restaurado. A sequência de recuperação falha no ponto de sua dependência mais crítica.
Três tipos de dependência que as pesquisas invariavelmente deixam de identificar:
Componentes compartilhados ocultos. Um programa COBOL interno que lida com a conversão de moeda para três processos de negócios distintos, nenhum dos quais a pesquisa identificou como compartilhando um componente, é uma dependência oculta que afeta a recuperação de todos os três. Se o programa de conversão de moeda for de Nível 3 e qualquer um dos três processos de negócios for de Nível 1, a criticidade efetiva do programa de conversão de moeda será de Nível 1.
Dependências de pipelines de dados. Aplicações que consomem dados processados em lote de outras aplicações possuem uma dependência temporal, e não em tempo real. O risco não é de falha simultânea, mas sequencial: a aplicação subsequente se recupera, mas sua fonte de dados não foi restaurada ao mesmo ponto de recuperação, produzindo a aparência de operação correta em dados desatualizados. Esse tipo de dependência não aparece em mapas de topologia de rede ou análises de grafos de chamadas, a menos que o próprio fluxo de dados seja rastreado.
Dependências de configuração e esquema compartilhadas. Aplicativos que compartilham esquemas de banco de dados, serviços de configuração ou provedores de identidade têm uma dependência implícita, mesmo que nunca se comuniquem diretamente. Uma alteração de esquema em um banco de dados compartilhado pode afetar vários aplicativos. Recuperar um aplicativo após uma corrupção de esquema sem recuperar todos os aplicativos que compartilham o esquema resulta em um estado inconsistente em todo o conjunto de aplicativos.
Integração do Plano de Continuidade de Negócios: Como as Pontuações de Criticidade Orientam as Decisões de Recuperação
A pontuação de criticidade serve de entrada para seis decisões específicas de projeto de continuidade de negócios (BCP):
1. Definição da sequência de recuperação. As aplicações se recuperam em ordem de criticidade, Nível 1 antes do Nível 2 antes do Nível 3, mas dentro de um nível, o grafo de dependências determina a sequência. Aplicações sem dependências de entrada (nenhuma outra aplicação depende delas) podem se recuperar em qualquer ordem dentro de seu nível. Aplicações com alto fan-in devem se recuperar antes de suas dependentes, independentemente de suas pontuações relativas dentro do nível. A sequência de recuperação é, portanto: a ordenação dos níveis aplicada à subsequência com restrição de dependência dentro de cada nível.
2. Definição de metas de RTO e RPO. A pontuação de criticidade calibra as metas de RTO e RPO. O Tempo Máximo de Inatividade Tolerável (MTD) e o Objetivo de Ponto de Recuperação (RPO) para cada aplicação de produção formam a base técnica de toda a estratégia de continuidade. O MTD é o tempo máximo que a empresa pode tolerar a indisponibilidade de uma aplicação. O RTO deve ser menor que o MTD. A margem entre o RTO e o MTD é a margem de segurança. Aplicações de nível 1 com alto impacto nos negócios por hora de inatividade têm margens estreitas de MTD/RTO e exigem infraestrutura projetada para recuperação automatizada rápida.
3. Calibração do investimento em infraestrutura. Os índices de criticidade influenciam diretamente as decisões de investimento em infraestrutura de recuperação de desastres (DR). Aplicações de Nível 1 justificam redundância ativa-ativa em múltiplas regiões. Aplicações de Nível 2 justificam redundância ativa-passiva com failover testado. Aplicações de Nível 3 justificam backups regulares com procedimentos de restauração documentados. Aplicações de Nível 4 podem confiar em políticas de backup padrão. Sem índices de criticidade, as decisões de investimento em infraestrutura tendem a resultar em superinvestimento uniforme (caro) ou subinvestimento uniforme (arriscado).
4. Requisitos de controle de mudanças. Aplicações com pontuações de criticidade mais altas exigem um controle de mudanças mais rigoroso: janelas de congelamento de mudanças mais longas, mais aprovadores obrigatórios, testes pré-mudança mais extensivos e procedimentos de reversão mais conservadores. Aplicar controle de mudanças de Nível 1 a aplicações de Nível 4 desperdiça tempo de engenharia. Aplicar controle de mudanças de Nível 4 a aplicações de Nível 1 cria um risco inaceitável.
5. Frequência de testes e validação. O Plano de Continuidade de Negócios (PCN) exige testes periódicos dos procedimentos de recuperação, exercícios de simulação, testes de failover em nível de componente e simulações completas de recuperação de desastres. A frequência dos testes é determinada pelos níveis de criticidade: aplicações de Nível 1 exigem testes de recuperação de desastres trimestrais; aplicações de Nível 4 exigem testes anuais. Testar todas as aplicações com a mesma frequência não é prático nem necessário.
6. Requisitos de SLA do fornecedor. Para aplicações que dependem de serviços de terceiros, a pontuação de criticidade determina os requisitos de SLA que devem constar nos contratos com os fornecedores. Uma aplicação de Nível 1 com um RTO de 4 horas requer um SLA de terceiros que garanta disponibilidade consistente com esse RTO. Uma aplicação de Nível 4 não requer.
A Complicação do Sistema Legado
Sistemas legados complicam a avaliação de criticidade de maneiras que as estruturas modernas de gerenciamento de portfólio de aplicações não abordam adequadamente. A avaliação de criticidade padrão pressupõe que os proprietários das aplicações saibam o que suas aplicações fazem e quem depende delas. Para sistemas legados, como programas COBOL mantidos por múltiplas gerações de desenvolvedores, fluxos de trabalho JCL cujas dependências foram documentadas pela última vez em 2008 e programas RPG que produzem arquivos de saída consumidos por processos que ninguém atualmente na organização escreveu, essa premissa não se aplica.
A estrutura real de dependências de um sistema legado só é visível no próprio código. Um programa COBOL que escreve em um conjunto de dados lido por doze programas subsequentes possui doze dependências subsequentes, mas esse fato pode não ser conhecido pelo proprietário do programa COBOL, que vê apenas a função do programa (processar transações diárias) em vez de seu papel estrutural (produzir o conjunto de dados que viabiliza outros doze processos).
Para sistemas legados, a dimensão de dependência da pontuação de criticidade exige análise de código em vez de pesquisas com os proprietários. A contagem de fan-in para um programa COBOL só pode ser obtida examinando todos os outros programas no ambiente e determinando quais deles referenciam os conjuntos de dados de saída, convenções de chamada ou copybooks compartilhados do primeiro programa. Essa análise é o que as plataformas de análise estrutural de código fornecem e, sem ela, a dimensão de dependência de qualquer pontuação de criticidade atribuída a um programa legado é, na melhor das hipóteses, um palpite fundamentado.
A consequência de avaliar erroneamente a criticidade de aplicações legadas é particularmente grave, pois esses sistemas tendem a ser altamente críticos (frequentemente contêm lógica de negócios essencial acumulada ao longo de décadas) e mal classificados (seus proprietários não conseguem articular o que depende deles, atribuindo, portanto, pontuações conservadoras). O resultado é a atribuição de níveis de criticidade 3 a programas legados que, na realidade, estão no caminho crítico de processos de negócios de nível 1, exatamente o modo de falha que se manifesta em falhas na sequência de recuperação durante incidentes reais.
Como SMART TS XL Fornece evidências de dependência para a pontuação de criticidade.
SMART TS XL Aborda diretamente a dimensão de dependência da pontuação de criticidade de aplicações, para a classe de aplicações onde as abordagens baseadas em pesquisas são menos confiáveis.
A funcionalidade de mapeamento de dependências de aplicações constrói o grafo de dependências completo em todas as linguagens do ambiente: cada programa COBOL que chama todos os outros, cada etapa de job JCL que produz dados consumidos por programas subsequentes, cada copybook compartilhado que cria uma dependência implícita entre programas que nunca se chamam diretamente, cada conjunto de dados que flui entre programas produtores e consumidores. Este grafo é a base de evidências estruturais para a dimensão de dependência da pontuação de criticidade, as contagens de fan-in, as identificações de componentes compartilhados e as dependências ocultas do pipeline de dados que as pesquisas não conseguem capturar de forma confiável.
A capacidade de análise de impacto torna o grafo de dependências consultável para o planejamento de continuidade de negócios (BCP): para qualquer aplicação no portfólio, enumere todas as outras aplicações que dependem dela, direta ou transitivamente, e que, portanto, herdam seu requisito de disponibilidade. Um programa COBOL com três dependentes diretos e vinte dependentes transitivos (programas que dependem dos dependentes diretos) tem uma criticidade efetiva que reflete os vinte e três programas nos quais ele está no caminho crítico, e não apenas sua própria função.
A capacidade de análise estática de código revela as métricas de complexidade estrutural que informam a dimensão de complexidade de recuperação: complexidade ciclomática, métricas de acoplamento, percentual de código morto e indicadores de dívida técnica que preveem quanto tempo e quão arriscada será a recuperação de cada aplicação. Uma aplicação com alta complexidade e acoplamento denso é mais cara de restaurar, e sua pontuação de complexidade de recuperação na Dimensão 3 é maior, do que uma aplicação com função equivalente e arquitetura limpa.
A funcionalidade de busca corporativa permite consultar todo o inventário de dependências ao longo do ciclo de vida do Plano de Continuidade de Negócios (BCP): encontre todos os programas que acessam um conjunto de dados específico (identificando todos os programas que dependem de sua disponibilidade), todos os programas que compartilham um copybook específico (identificando todos os programas afetados por sua disponibilidade) e todos os jobs JCL executados em uma janela de lote específica (identificando todos os programas que precisam ser recuperados antes do início da janela). Essa funcionalidade de busca auxilia na revisão anual da pontuação de criticidade, o processo de atualização que mantém as pontuações atualizadas conforme o portfólio de aplicações evolui.
Para organizações que realizam modernização legada programas em conjunto com o desenvolvimento do BCP, SMART TS XLA análise de [nome da empresa] serve a ambos os propósitos simultaneamente: o mapa de dependências que informa a pontuação de criticidade também determina a sequência de migração, e as métricas de complexidade que informam a pontuação de complexidade de recuperação também determinam a estimativa do esforço de modernização.
Mantendo as Notas Atualizadas: O Ciclo de Avaliação Anual
Uma avaliação de maturidade em continuidade de negócios deve ajudá-lo a fazer três coisas: entender seu estado atual, identificar as lacunas mais importantes e construir um caminho realista para a melhoria. É isso que transforma a pontuação de maturidade em um programa mais eficaz.
As pontuações de criticidade das aplicações se distanciam da realidade à medida que as organizações mudam. Novas aplicações são adicionadas. Aplicações antigas são desativadas, mas não completamente desmanteladas. Integrações são criadas entre aplicações que antes não tinham dependências. Os processos de negócio mudam e, com eles, as aplicações das quais dependem. Os requisitos regulatórios evoluem e impõem novas obrigações de recuperação.
O ciclo anual de revisão das pontuações de criticidade deve incluir:
Reanálise estrutural. Execute novamente o mapeamento de dependências para identificar novas dependências introduzidas desde a última revisão. Aplicações que eram independentes podem agora ter dependências que aumentam sua criticidade. Aplicações que eram altamente dependentes podem ter tido seus consumidores migrados para sistemas mais recentes, reduzindo sua criticidade.
Reavaliação do impacto nos negócios. Os números de impacto na receita e nas operações mudam à medida que o negócio cresce e seu portfólio de aplicativos evolui. Um aplicativo que processava US$ 1 por hora em valor de negócios há três anos pode agora processar dez vezes mais devido ao crescimento dos negócios.
Incorporação dos resultados dos testes de recuperação. Os testes de recuperação revelam discrepâncias entre a complexidade de recuperação presumida e a real. Uma aplicação que obteve baixa pontuação em complexidade de recuperação na avaliação inicial pode ter apresentado desempenho ruim em um exercício de simulação, sugerindo uma revisão da pontuação para cima.
Revisão de alterações regulamentares. Novas regulamentações ou alterações às existentes podem impor novas obrigações de tempo de recuperação a aplicações específicas. Os requisitos de resiliência operacional do regulamento DORA para instituições financeiras da UE, por exemplo, impuseram obrigações específicas de tempo de recuperação a "funções críticas ou importantes" que podem não ter sido consideradas nas pontuações de criticidade pré-DORA.
As organizações com programas de continuidade de negócios (BCP) maduros tratam a avaliação de criticidade não como um exercício pontual, mas como um processo contínuo: as pontuações são atualizadas quando ocorrem mudanças significativas nas dependências de aplicativos, no impacto nos negócios ou nas obrigações regulatórias, e validadas anualmente por meio de revisão estruturada.
A pontuação só é tão boa quanto as evidências de sua dependência.
A avaliação da criticidade de aplicações oferece maior valor quando sua dimensão de dependência se baseia em evidências estruturais, e não em pesquisas. As dimensões de impacto nos negócios e obrigações regulatórias podem ser avaliadas de forma confiável por meio de entrevistas e análise de processos de negócios. A dimensão de dependência operacional não pode, pois exige o conhecimento do que depende de cada aplicação, e os proprietários de aplicações sistematicamente subestimam seus consumidores finais.
O modo de falha é previsível: uma sequência de recuperação baseada em pontuações de criticidade derivadas de pesquisas falha nas dependências ocultas. Um serviço de autenticação legado é restaurado tardiamente. Um programa de conversão de moeda em COBOL fica offline quando os aplicativos que dependem dele tentam se recuperar. Um esquema de banco de dados compartilhado está em um ponto de recuperação diferente dos aplicativos que leem dele. Cada uma dessas falhas é evitável com as evidências de dependência fornecidas pela análise estrutural, e cada uma delas é dispendiosa quando ocorre durante um incidente real, em vez de durante um exercício de simulação.
A metodologia de pontuação está estabelecida. As estruturas existem. A lacuna que a maioria das organizações apresenta não está na estrutura de pontuação, mas sim na base de evidências para sua dimensão mais importante. Para que o Plano de Continuidade de Negócios (PCN) funcione, é necessário preencher essa lacuna com uma análise estrutural antes do próximo incidente.
