Die Planung der Geschäftskontinuität scheitert meist nicht während einer Krise, sondern bereits in der Vorbereitungsphase. Unternehmen erstellen Business-Impact-Analysen, dokumentieren Wiederherstellungszeitvorgaben, entwickeln umfassende Wiederherstellungspläne und stellen dann im ungünstigsten Moment fest, dass ein scheinbar unkritischer, veralteter Authentifizierungsdienst einen Single Point of Failure für ihre gesamte E-Commerce-Plattform darstellt, dass das COBOL-Batchprogramm, das alle für unwichtig hielten, den Echtzeit-Zahlungsvalidierungsdienst speist oder dass zwei Anwendungen, denen dieselbe Wiederherstellungsstufe zugewiesen ist, eine undokumentierte Abhängigkeit aufweisen, die eine sequentielle Wiederherstellung unmöglich macht. Die Prioritäten wurden ermittelt. Die Abhängigkeiten jedoch nicht.
Die Bewertung der Anwendungskritikalität ist der Prozess, jeder Anwendung im Portfolio einer Organisation eine quantitative oder abgestufte Wichtigkeitskennzahl zuzuweisen. Diese Kennzahl bestimmt ihre Priorität bei der Wiederherstellung, den erforderlichen Redundanzaufwand, die Anforderungen an das Änderungsmanagement und ihre Position in der Abfolge der Notfallwiederherstellung. Basieren diese Bewertungen ausschließlich auf Umfragen zu den Geschäftsauswirkungen und Interviews mit den Anwendungsverantwortlichen, spiegeln sie die subjektive Wahrnehmung der Anwendungsfunktion wider. Werden sie hingegen durch eine Strukturanalyse der tatsächlichen Anwendungsfunktionen, der Kommunikationswege, der Datenflüsse und der gemeinsam genutzten Komponenten im kritischen Pfad mehrerer Systeme mit höherer Priorität untermauert, bildet sie die operative Realität ab.
Die Diskrepanz zwischen Glauben und Realität ist der Punkt, an dem Notfallpläne scheitern.
Wiederherstellungssequenzen, die tatsächliche Abhängigkeiten widerspiegeln
SMART TS XL Identifiziert jedes Programm im kritischen Pfad Ihrer Tier-1-Anwendungen – über alle Sprachen Ihres Portfolios hinweg.
MEHR ERFAHREN…Was die Bewertung der Anwendungskritikalität tatsächlich misst
Kritikalität ist keine eindimensionale Angelegenheit. Um den Kritikalitätswert einer Unternehmensanwendung zu ermitteln, können Benutzereingaben berücksichtigt werden, um die Kritikalität oder Bedeutung einer Unternehmensanwendung zu bewerten. Dazu gehören die größten Auswirkungen auf strategische Geschäftsbedürfnisse, Auswirkungen auf Geschäftspartner, Kundeninteraktionen und Auswirkungen auf andere Unternehmensanwendungen. Jede dieser Dimensionen erfasst einen anderen Aspekt dessen, was „kritisch“ bedeutet:
Die geschäftlichen Auswirkungen beschreiben die Verluste, die dem Unternehmen pro Stunde Ausfallzeit entstehen. Umsatzeinbußen sind die sichtbarste Dimension: Ein Zahlungsabwicklungssystem, das 10 Millionen US-Dollar pro Stunde verarbeitet, verursacht messbare Kosten pro Ausfallminute. Die geschäftlichen Auswirkungen reichen jedoch über den Umsatz hinaus und umfassen regulatorische Risiken (welche Compliance-Pflichten entstehen durch den Ausfall?), Reputationsschäden (sind Kunden direkt betroffen?) und Vertragsstrafen (lösen SLAs Strafklauseln aus?).
Betriebliche Abhängigkeit : Wie viele andere Systeme oder Prozesse sind von dieser Anwendung abhängig? Eine Anwendung mit geringer direkter Auswirkung auf das Geschäft kann eine hohe Kritikalität aufweisen, da sie im Abhängigkeitspfad von Anwendungen mit hoher direkter Auswirkung liegt. Der Authentifizierungsdienst, der alle anderen kundenorientierten Anwendungen ermöglicht, ist kritischer, als seine eigene Funktion vermuten lässt.
Die Komplexität der Wiederherstellung beschreibt , wie schwierig und zeitaufwändig die Wiederherstellung der Anwendung ist. Eine Anwendung mit moderaten Auswirkungen auf das Geschäft und einer Wiederherstellungszeit von 48 Stunden erfordert möglicherweise höhere Investitionen in Redundanz als eine Anwendung mit größeren Auswirkungen auf das Geschäft und einer Wiederherstellungszeit von 2 Stunden, da das Gesamtausfallrisiko höher ist.
Regulatorische Verpflichtungen betreffen Anwendungen, die regulatorischen Anforderungen an die Aufrechterhaltung des Geschäftsbetriebs unterliegen. Finanzinstitute, die dem DORA unterliegen, müssen nachweisen, dass kritische oder wichtige Funktionen auch in festgelegten Störungsszenarien funktionsfähig bleiben. Gesundheitsorganisationen, die dem HIPAA unterliegen, müssen die Verfügbarkeit von Systemen mit geschützten Gesundheitsdaten gewährleisten. Die regulatorischen Anforderungen können die Bewertung der Geschäftsauswirkungen für bestimmte Anwendungen außer Kraft setzen.
Der Kritikalitätswert ist ein zusammengesetzter Wert aus allen vier Dimensionen, gewichtet nach der spezifischen Risikotoleranz der Organisation, dem regulatorischen Umfeld und dem Geschäftsmodell.
Die Standardkritikalitätsstufen
Die meisten Anwendungsportfolios in Unternehmen verwenden ein vierstufiges Kritikalitätsmodell. Die Kategorien der Kritikalität in einer Anwendungskritikalitätsmatrix sind: geschäftskritisch, unternehmenskritisch, betriebsorientiert und administrativ. Die folgenden Definitionen entsprechen der aktuellen Branchenpraxis in Übereinstimmung mit ISO 22301 (Managementsysteme für Geschäftskontinuität) und den Leitlinien für bewährte Verfahren des Business Continuity Institute:
Tier 1: Geschäftskritische Anwendungen, deren Ausfall den Geschäftsbetrieb sofort unterbricht oder ein inakzeptables regulatorisches oder sicherheitsrelevantes Risiko darstellt. Wiederherstellungszeitziel (RTO): typischerweise 0–4 Stunden. Wiederherstellungspunktziel (RPO): typischerweise 0–1 Stunde. Beispiele: Transaktionsverarbeitung im Kernbankwesen, Echtzeit-Handelssysteme, Notrufsysteme, industrielle Steuerungsschnittstellen, Zahlungsautorisierungssysteme. Diese Anwendungen rechtfertigen höchste Investitionen in die Infrastruktur: Aktiv-Aktiv-Redundanz, Zero-RPO-Replikation, automatisiertes Failover und strengstes Änderungsmanagement.
Tier 2: Geschäftskritische Anwendungen, deren Ausfall den Geschäftsbetrieb erheblich beeinträchtigt, ihn aber nicht sofort unterbricht. Wiederherstellungszeitziel (RTO): typischerweise 4–24 Stunden. Wiederherstellungspunktziel (RPO): typischerweise 1–4 Stunden. Beispiele: CRM-Systeme, ERP-Module, Auftragsverwaltung, HR-Systeme während der Gehaltsabrechnungsperiode, Berichtssysteme während der Fristen für die Einreichung von behördlichen Unterlagen. Diese Anwendungen erfordern eine hochverfügbare Infrastruktur, regelmäßig getestete Failover-Verfahren und eine priorisierte Wiederherstellungsreihenfolge.
Tier 3: Geschäftliche Anwendungen, die den Geschäftsbetrieb unterstützen, deren vorübergehende Nichtverfügbarkeit jedoch durch manuelle Maßnahmen behoben werden kann. Wiederherstellungszeitziel (RTO): typischerweise 24–72 Stunden. Wiederherstellungspunktziel (RPO): typischerweise 4–24 Stunden. Beispiele: interne Kollaborationstools, nicht kundenorientierte Berichtsfunktionen, Verwaltungsportale, Schulungsplattformen. Standardmäßige Datensicherungs- und Wiederherstellungsverfahren sind angemessen.
Tier 4: Administrative Anwendungen, die administrative Funktionen unterstützen, ohne direkte Auswirkungen auf den Betrieb. Wiederherstellungszeitziel (RTO): typischerweise mindestens 72 Stunden. Wiederherstellungspunkt (RPO): mindestens 24 Stunden oder letztes Backup. Beispiele: interne Dokumentations-Wikis, nicht unbedingt notwendige Entwicklungswerkzeuge, historische Berichte. Wiederherstellung aus dem Backup nach Bedarf.
Die Tier-Zuordnung ist nicht permanent. Eine Anwendung, die den Großteil des Jahres in Tier 3 eingestuft ist, kann beispielsweise zum Monatsabschluss, in Berichtsperioden oder während der Hochsaison im Handel in Tier 2 fallen. Dynamische Kritikalität, bei der sich die Tier-Zuordnung je nach Betriebskalender ändert, ist eine Optimierung, die Organisationen mit ausgereiften BCP-Programmen nach Festlegung der grundlegenden Tier-Struktur implementieren.
Die Bewertungsmethodik: Dimensionen in Zahlen übersetzen
Eine strukturierte Bewertungsmethodik wandelt die vier Kritikalitätsdimensionen in einen numerischen Wert um, der die Einstufung objektiv und nicht durch interne Politik bestimmt. Der folgende Ansatz erzeugt anhand gewichteter Kriterien einen Gesamtwert von 0 bis 100:
Dimension 1: Geschäftliche Auswirkungen (Gewichtung: 35 %)
| Umsatzauswirkungen pro Stunde Ausfallzeit | Score |
|---|---|
| > 1 Million Dollar pro Stunde | 35 |
| 100 bis 1 Million US-Dollar pro Stunde | 28 |
| 10 bis 100 US-Dollar pro Stunde | 21 |
| 1 bis 10 US-Dollar pro Stunde | 14 |
| < 1 US-Dollar pro Stunde | 7 |
| Keine direkten Auswirkungen auf den Umsatz | 0 |
Die regulatorischen Auswirkungen (DORA, HIPAA, PCI-DSS, SOX-Compliance-Verpflichtungen, die durch den Ausfall ausgelöst werden) tragen bis zu 10 zusätzliche Punkte zu dieser Dimension bei.
Dimension 2: Operative Abhängigkeit (Gewichtung: 30 %)
| Fan-In: Anwendungen, die von dieser Anwendung abhängen | Score |
|---|---|
| > 20 abhängige Anwendungen | 30 |
| 10-20 abhängige Anwendungen | 24 |
| 5-9 abhängige Anwendungen | 18 |
| 2-4 abhängige Anwendungen | 12 |
| 1 abhängige Anwendung | 6 |
| Keine Angehörigen (Einzelperson) | 0 |
Die hier verwendete Anzahl an Folgezugriffen (Fan-in Count) gibt die strukturelle Abhängigkeit an, also die Anzahl der Anwendungen, die diese Anwendung aufrufen, ihre Ausgaben lesen oder von ihren Daten abhängen – nicht die Anzahl der Nutzer oder die wahrgenommene Wichtigkeit. Diese Dimension wird in Umfragen am häufigsten falsch berechnet, da Anwendungsbetreiber nicht alle ihre nachgelagerten Nutzer kennen.
Dimension 3: Wiederherstellungskomplexität (Gewichtung: 20 %)
| Geschätzte Wiederherstellungszeit ohne vorkonfigurierte DR | Score |
|---|---|
| > 72 Stunden | 20 |
| 24-72 Stunden | 16 |
| 8-24 Stunden | 12 |
| 2-8 Stunden | 8 |
| <2 Stunden | 4 |
| Automatisches Failover < 15 Minuten | 0 |
Dimension 4: Datensensibilität und regulatorische Verpflichtung (Gewichtung: 15 %)
| Datenklassifizierung und regulatorische Anforderungen | Score |
|---|---|
| Regulierte personenbezogene Daten (PII/PHI/CHD) mit expliziter Verpflichtung zur Wiederherstellungszeit | 15 |
| Regulierte Daten ohne spezifische Wiederherstellungszeitverpflichtung | 12 |
| Sensible interne Daten (Geschäftsgeheimnisse, Finanzunterlagen) | 9 |
| Interne Betriebsdaten | 6 |
| Nicht sensible interne Daten | 3 |
| Keine Daten gespeichert | 0 |
Zuordnung der Gesamtpunktzahl zu den Tier-Kategorien:
| Zusammengesetzte Punktzahl | Tierzuordnung |
|---|---|
| 75-100 | Stufe 1, Missionskritisch |
| 50-74 | Tier 2, geschäftskritisch |
| 25-49 | Stufe 3, Geschäftsbetrieb |
| 0-24 | Stufe 4, Verwaltung |
Das Abhängigkeitsproblem: Warum umfragebasierte Auswertungen falsch sind
Die Dimension der betrieblichen Abhängigkeiten ist am ehesten von Fehlkalkulationen betroffen und hat im Falle einer falschen Einschätzung die gravierendsten Folgen. Ein scheinbar unkritischer, veralteter Authentifizierungsdienst kann zum Single Point of Failure einer gesamten E-Commerce-Plattform werden und im schlimmsten Fall alle umsatzgenerierenden Transaktionen zum Erliegen bringen. Dieser Prozess geht über abstrakte Bedrohungen hinaus und verdeutlicht konkrete, messbare Auswirkungen auf Service-Level-Agreements.
Anwendungsbetreiber kennen ihre direkten vorgelagerten Abhängigkeiten, also die Systeme, die sie aufrufen. Ihre vollständigen nachgelagerten Abhängigkeiten, also die Systeme, die sie aufrufen, sind ihnen jedoch selten bekannt. Ein interner Benutzerauthentifizierungsdienst wird von seinem Betreiber möglicherweise als wenig kritisch eingestuft (er generiert keine Einnahmen, ist einfach und funktioniert selten), obwohl er von zwölf kundenorientierten Anwendungen der Stufe 1 genutzt wird. Die tatsächliche Kritikalität des Authentifizierungsdienstes (Stufe 1) ergibt sich nicht aus seiner eigenen Funktion, sondern aus seiner Position im Abhängigkeitsdiagramm der höherstufigen Systeme.
Die auf Umfragen basierende Kritikalitätsbewertung führt systematisch zu diesem Fehler. In einer Umfrage unter Anwendungsbesitzern wird gefragt: „Wie kritisch ist diese Anwendung?“ Der Besitzer des Authentifizierungsdienstes antwortet basierend auf der Funktion des Dienstes mit „niedrig bis mittel“. Die zwölf Besitzer abhängiger Anwendungen beantworten diese Umfrage nicht zum Authentifizierungsdienst, sondern zu ihren eigenen Anwendungen. Die Abhängigkeitsbeziehung wird somit nicht erfasst.
Die Folge zeigt sich in der Wiederherstellungsreihenfolge: Der Notfallplan legt die Wiederherstellungsreihenfolge anhand der aus der Umfrage abgeleiteten Kritikalitätswerte fest, und der Authentifizierungsdienst wird für die Wiederherstellung der Stufe 3 eingeplant. Im Ernstfall können die Anwendungen der Stufe 1, die zuerst wiederhergestellt werden sollten, dies nicht, da der von ihnen abhängige Authentifizierungsdienst nicht wiederhergestellt wurde. Die Wiederherstellungsreihenfolge scheitert an der Stelle ihrer kritischsten Abhängigkeit.
Drei Abhängigkeitsarten, die in Umfragen systematisch übersehen werden:
Versteckte, gemeinsam genutzte Komponenten. Ein internes COBOL-Programm, das die Währungsumrechnung für drei separate Geschäftsprozesse durchführt – von denen keiner laut der Untersuchung eine gemeinsame Komponente aufweist –, stellt eine versteckte Abhängigkeit dar, die die Wiederherstellung aller drei Prozesse beeinträchtigt. Befindet sich das Währungsumrechnungsprogramm auf Stufe 3 und einer der drei Geschäftsprozesse auf Stufe 1, so ist die effektive Kritikalität des Währungsumrechnungsprogramms ebenfalls Stufe 1.
Abhängigkeiten in Datenpipelines. Anwendungen, die stapelverarbeitete Daten anderer Anwendungen verarbeiten, weisen eine zeitliche, nicht Echtzeit-Abhängigkeit auf. Das Risiko besteht nicht in einem gleichzeitigen, sondern in einem sequenziellen Ausfall: Die nachgelagerte Anwendung erholt sich zwar, ihre Datenquelle wurde jedoch nicht auf denselben Wiederherstellungspunkt zurückgesetzt, wodurch der Anschein entsteht, als würden veraltete Daten korrekt verarbeitet. Diese Art von Abhängigkeit wird in Netzwerktopologiekarten oder Aufrufdiagrammanalysen nicht sichtbar, sofern der Datenfluss nicht direkt nachverfolgt wird.
Gemeinsame Konfigurations- und Schemaabhängigkeiten. Anwendungen, die Datenbankschemata, Konfigurationsdienste oder Identitätsanbieter gemeinsam nutzen, weisen eine implizite Abhängigkeit auf, selbst wenn sie sich nie direkt aufrufen. Eine Schemaänderung in einer gemeinsam genutzten Datenbank kann mehrere Anwendungen beeinträchtigen. Die Wiederherstellung einer Anwendung nach einer Schemabeschädigung, ohne alle Anwendungen, die das Schema gemeinsam nutzen, wiederherzustellen, führt zu einem inkonsistenten Zustand im gesamten Anwendungsportfolio.
BCP-Integration: Wie Kritikalitätsbewertungen Wiederherstellungsentscheidungen beeinflussen
Der Kritikalitätswert dient als Grundlage für sechs spezifische Entscheidungen im Rahmen des BCP-Designs:
1. Definition der Wiederherstellungsreihenfolge. Anwendungen werden in der Reihenfolge ihrer Kritikalität wiederhergestellt, wobei Stufe 1 vor Stufe 2 und dann vor Stufe 3 steht. Innerhalb einer Stufe bestimmt der Abhängigkeitsgraph die Reihenfolge. Anwendungen ohne eingehende Abhängigkeiten (von denen keine andere Anwendung abhängt) können innerhalb ihrer Stufe in beliebiger Reihenfolge wiederhergestellt werden. Anwendungen mit hohem Fan-In müssen vor ihren abhängigen Anwendungen wiederhergestellt werden, unabhängig von deren relativer Kritikalität innerhalb der Stufe. Die Wiederherstellungsreihenfolge ergibt sich daher aus der Stufenreihenfolge, angewendet auf die abhängigkeitsbeschränkte Teilsequenz innerhalb jeder Stufe.
2. Festlegung der RTO- und RPO-Ziele. Der Kritikalitätswert dient zur Kalibrierung der RTO- und RPO-Ziele. Die maximal tolerierbare Ausfallzeit (MTD) und das Recovery Point Objective (RPO) jeder Produktionsanwendung bilden die technische Grundlage der gesamten Kontinuitätsstrategie. Die MTD ist die maximale Zeit, die das Unternehmen tolerieren kann, wenn eine Anwendung nicht verfügbar ist. Die RTO muss kürzer als die MTD sein. Die Differenz zwischen RTO und MTD stellt den Sicherheitspuffer dar. Anwendungen der Stufe 1 mit hohen Auswirkungen auf das Geschäft pro Stunde Ausfallzeit weisen geringe MTD/RTO-Margen auf und benötigen eine Infrastruktur, die für eine schnelle, automatisierte Wiederherstellung ausgelegt ist.
3. Kalibrierung von Infrastrukturinvestitionen. Kritikalitätsbewertungen beeinflussen direkt die Investitionsentscheidungen für die Disaster-Recovery-Infrastruktur. Anwendungen der Stufe 1 rechtfertigen eine aktiv-aktive, regionsübergreifende Redundanz. Anwendungen der Stufe 2 rechtfertigen eine aktiv-passive Redundanz mit getestetem Failover. Anwendungen der Stufe 3 rechtfertigen regelmäßige Backups mit dokumentierten Wiederherstellungsverfahren. Anwendungen der Stufe 4 können auf Standard-Backup-Richtlinien zurückgreifen. Ohne Kritikalitätsbewertungen führen Infrastrukturinvestitionsentscheidungen standardmäßig entweder zu einer einheitlichen Überinvestition (teuer) oder zu einer einheitlichen Unterinvestition (riskant).
4. Anforderungen an das Änderungsmanagement. Anwendungen mit höherer Kritikalität erfordern ein strengeres Änderungsmanagement: längere Sperrfristen für Änderungen, mehr Genehmigungsberechtigte, umfangreichere Tests vor Änderungen und konservativere Rollback-Verfahren. Die Anwendung des Änderungsmanagements der Stufe 1 auf Anwendungen der Stufe 4 verschwendet Entwicklungszeit. Die Anwendung des Änderungsmanagements der Stufe 4 auf Anwendungen der Stufe 1 birgt ein inakzeptables Risiko.
5. Test- und Validierungshäufigkeit. BCP erfordert regelmäßige Tests von Wiederherstellungsverfahren, Planspielübungen, Failover-Tests auf Komponentenebene und vollständige Notfallwiederherstellungssimulationen. Die Testhäufigkeit richtet sich nach der Kritikalität: Anwendungen der Stufe 1 erfordern vierteljährliche Notfallwiederherstellungstests, Anwendungen der Stufe 4 jährliche. Es ist weder praktikabel noch notwendig, alle Anwendungen gleich häufig zu testen.
6. SLA-Anforderungen der Anbieter. Bei Anwendungen, die auf Drittanbieterdienste angewiesen sind, bestimmt der Kritikalitätswert die in den Anbieterverträgen enthaltenen SLA-Anforderungen. Eine Anwendung der Stufe 1 mit einer RTO von 4 Stunden benötigt eine Drittanbieter-SLA, die eine Verfügbarkeit entsprechend dieser RTO garantiert. Eine Anwendung der Stufe 4 benötigt dies nicht.
Die Legacy-System-Komplikation
Legacy-Systeme erschweren die Kritikalitätsbewertung auf eine Weise, die moderne Frameworks für das Anwendungsportfoliomanagement nicht ausreichend berücksichtigen. Die Standard-Kritikalitätsbewertung setzt voraus, dass Anwendungsbesitzer wissen, was ihre Anwendungen leisten und wer von ihnen abhängt. Für Legacy-Systeme – COBOL-Programme, die von mehreren Entwicklergenerationen betreut wurden, JCL-Jobstreams, deren Abhängigkeiten zuletzt 2008 dokumentiert wurden, und RPG-Programme, die Ausgabedateien erzeugen, die von Prozessen verwendet werden, die aktuell niemand im Unternehmen geschrieben hat – trifft diese Annahme nicht zu.
Die tatsächliche Abhängigkeitsstruktur eines Altsystems ist nur im Code selbst sichtbar. Ein COBOL-Programm, das in einen Datensatz schreibt, auf den zwölf nachgelagerte Programme zugreifen, hat zwölf nachgelagerte Abhängigkeiten. Diese Tatsache ist dem Besitzer des COBOL-Programms jedoch möglicherweise nicht bekannt, da er nur die Funktion des Programms (die Verarbeitung täglicher Transaktionen) und nicht dessen strukturelle Rolle (die Erstellung des Datensatzes, der zwölf andere Prozesse ermöglicht) sieht.
Bei Altsystemen erfordert die Abhängigkeitsdimension der Kritikalitätsbewertung eine Codeanalyse anstelle von Befragungen der Systemverantwortlichen. Die Anzahl der Abhängigkeiten eines COBOL-Programms lässt sich nur ermitteln, indem jedes andere Programm in der Umgebung untersucht und festgestellt wird, welche Programme auf die Ausgabedatensätze, Aufrufkonventionen oder gemeinsam genutzten Copybooks des ersten Programms zugreifen. Genau diese Analyse leisten Plattformen für die strukturelle Codeanalyse. Ohne sie ist die Abhängigkeitsdimension einer Kritikalitätsbewertung für ein Altsystem bestenfalls eine fundierte Schätzung.
Die Folgen einer Fehleinschätzung der Kritikalität von Altsystemen sind besonders gravierend, da diese Systeme häufig sowohl hochkritisch sind (sie enthalten oft über Jahrzehnte gewachsene Kernlogik) als auch schlecht bewertet werden (ihre Betreiber können die Abhängigkeiten nicht genau benennen und vergeben daher konservative Bewertungen). Das Ergebnis sind Altsysteme der Stufe 3, die sich tatsächlich im kritischen Pfad von Geschäftsprozessen der Stufe 1 befinden – genau der Fehlermodus, der bei tatsächlichen Störungen in der Wiederherstellungssequenz auftritt.
Wie SMART TS XL Liefert die Abhängigkeitsnachweise für die Kritikalitätsbewertung
SMART TS XL Geht direkt auf die Abhängigkeitsdimension der Bewertung der Kritikalität von Anwendungen ein, und zwar für die Klasse von Anwendungen, bei denen umfragebasierte Ansätze am wenigsten zuverlässig sind.
Die Funktion zur Abbildung von Anwendungsabhängigkeiten erstellt den vollständigen Abhängigkeitsgraphen für jede Sprache in der Umgebung: jedes COBOL-Programm, das jedes andere aufruft, jeder JCL-Jobschritt, der Daten erzeugt, die von nachgelagerten Programmen verwendet werden, jedes gemeinsam genutzte Copybook, das eine implizite Abhängigkeit zwischen Programmen erzeugt, die sich nie direkt aufrufen, und jeder Datensatz, der zwischen produzierenden und konsumierenden Programmen fließt. Dieser Graph bildet die strukturelle Grundlage für die Abhängigkeitsdimension der Kritikalitätsbewertung, die Fan-In-Zählungen, die Identifizierungen gemeinsam genutzter Komponenten und die verborgenen Datenpipeline-Abhängigkeiten, die durch Umfragen nicht zuverlässig erfasst werden können.
Die Auswirkungsanalyse ermöglicht die Abfrage des Abhängigkeitsgraphen für die Notfallplanung: Für jede Anwendung im Portfolio werden alle anderen Anwendungen aufgelistet, die direkt oder transitiv von ihr abhängen und somit ihre Verfügbarkeitsanforderungen erben. Ein COBOL-Programm mit drei direkten und zwanzig transitiven Abhängigkeiten (Programme, die von den direkten Abhängigkeiten abhängen) hat eine effektive Kritikalität, die die 23 Programme widerspiegelt, deren kritischer Pfad es ist, und nicht nur seine eigene Funktion.
Die statische Codeanalyse ermittelt die Strukturkomplexitätsmetriken, die die Komplexität der Wiederherstellung bestimmen: zyklomatische Komplexität, Kopplungsmetriken, Anteil ungenutzten Codes und Indikatoren für technische Schulden. Diese Kennzahlen prognostizieren, wie lange und wie riskant die Wiederherstellung jeder Anwendung sein wird. Eine Anwendung mit hoher Komplexität und starker Kopplung ist aufwändiger in der Wiederherstellung und weist einen höheren Komplexitätswert in Dimension 3 auf als eine funktionsgleiche Anwendung mit sauberer Architektur.
Die unternehmensweite Suchfunktion ermöglicht die Abfrage des gesamten Abhängigkeitsinventars während des gesamten BCP-Lebenszyklus: Sie findet jedes Programm, das auf einen bestimmten Datensatz zugreift (und identifiziert damit alle Programme, die von dessen Verfügbarkeit abhängen), jedes Programm, das ein bestimmtes Copybook gemeinsam nutzt (und identifiziert damit alle Programme, die von dessen Verfügbarkeit betroffen sind), und jeden JCL-Job, der in einem bestimmten Batch-Fenster ausgeführt wird (und identifiziert damit alle Programme, die vor Beginn des Fensters wiederhergestellt werden müssen). Diese Suchfunktion unterstützt die jährliche Überprüfung der Kritikalitätsbewertung und den Aktualisierungsprozess, der die Bewertungen im Zuge der Weiterentwicklung des Anwendungsportfolios aktuell hält.
Für Organisationen, die Modernisierung des Altbestands Programme im Zusammenhang mit der BCP-Entwicklung, SMART TS XLDie Analyse dient beiden Zwecken gleichzeitig: Die Abhängigkeitskarte, die die Kritikalitätsbewertung beeinflusst, bestimmt auch die Migrationsreihenfolge, und die Komplexitätsmetriken, die die Bewertung der Wiederherstellungskomplexität beeinflussen, bestimmen auch die Abschätzung des Modernisierungsaufwands.
Aktuelle Ergebnisse sichern: Der jährliche Überprüfungszyklus
Eine Reifegradanalyse für Business Continuity sollte Ihnen drei Dinge ermöglichen: Ihren aktuellen Zustand verstehen, die wichtigsten Schwachstellen identifizieren und einen realistischen Verbesserungsplan entwickeln. Dadurch wird aus einer Reifegradanalyse ein effektiveres Programm.
Die Kritikalitätsbewertungen von Anwendungen weichen mit den Veränderungen in Organisationen von der Realität ab. Neue Anwendungen werden hinzugefügt. Alte Anwendungen werden außer Betrieb genommen, aber nicht vollständig abgeschaltet. Es werden Integrationen zwischen Anwendungen erstellt, die zuvor unabhängig voneinander waren. Geschäftsprozesse ändern sich und damit auch die Anwendungen, auf die sie angewiesen sind. Regulatorische Anforderungen entwickeln sich weiter und bringen neue Wiederherstellungspflichten mit sich.
Der jährliche Überprüfungszyklus für Kritikalitätsbewertungen sollte Folgendes umfassen:
Strukturelle Reanalyse. Führen Sie die Abhängigkeitsanalyse erneut durch, um seit der letzten Überprüfung neu hinzugekommene Abhängigkeiten zu identifizieren. Anwendungen, die zuvor eigenständig liefen, können nun Abhängigkeiten aufweisen, die ihre Kritikalität erhöhen. Bei stark abhängigen Anwendungen könnten die Nutzer auf neuere Systeme migriert sein, wodurch sich deren Kritikalität verringert hat.
Neubewertung der Geschäftsauswirkungen. Umsatz- und Betriebskennzahlen ändern sich mit dem Unternehmenswachstum und der Weiterentwicklung des Anwendungsportfolios. Eine Anwendung, die vor drei Jahren einen Geschäftswert von 1 US-Dollar pro Stunde generierte, kann nach dem Unternehmenswachstum nun das Zehnfache erreichen.
Einbeziehung der Ergebnisse von Wiederherstellungstests. DR-Tests decken Diskrepanzen zwischen angenommener und tatsächlicher Wiederherstellungskomplexität auf. Eine Anwendung, die in der ersten Bewertung eine niedrige Wiederherstellungskomplexität aufwies, könnte in einer Planspielübung schlecht abgeschnitten haben, was eine Erhöhung der Bewertung nahelegt.
Überprüfung regulatorischer Änderungen. Neue oder geänderte Vorschriften können neue Wiederherstellungszeitverpflichtungen für bestimmte Anwendungen mit sich bringen. Die Anforderungen der DORA-Verordnung an die operative Resilienz von EU-Finanzinstituten haben beispielsweise spezifische RTO-Verpflichtungen für „kritische oder wichtige Funktionen“ eingeführt, die in den Kritikalitätsbewertungen vor DORA möglicherweise nicht berücksichtigt wurden.
Organisationen mit ausgereiften BCP-Programmen betrachten die Kritikalitätsbewertung nicht als einmalige Übung, sondern als kontinuierlichen Prozess: Die Bewertungen werden aktualisiert, wenn sich wesentliche Änderungen bei den Anwendungsabhängigkeiten, den Auswirkungen auf das Geschäft oder den regulatorischen Verpflichtungen ergeben, und jährlich durch eine strukturierte Überprüfung validiert.
Die Aussagekraft des Ergebnisses hängt maßgeblich von den Belegen für seine Abhängigkeit ab.
Die Bewertung der Anwendungskritikalität ist am aussagekräftigsten, wenn die Abhängigkeitsdimension auf strukturellen Erkenntnissen und nicht auf Umfragen basiert. Die Dimensionen Geschäftsauswirkungen und regulatorische Verpflichtungen lassen sich zuverlässig durch Interviews und Geschäftsprozessanalysen ermitteln. Die Dimension der operativen Abhängigkeit hingegen nicht, da sie voraussetzt, die Abhängigkeiten jeder einzelnen Anwendung zu kennen, und Anwendungsbetreiber ihre nachgelagerten Nutzer systematisch unterschätzen.
Der Fehlermodus ist vorhersehbar: Eine auf aus Umfragen abgeleiteten Kritikalitätswerten basierende Wiederherstellungssequenz scheitert an den verborgenen Abhängigkeiten. Ein veralteter Authentifizierungsdienst wird verzögert wiederhergestellt. Ein COBOL-Währungsumrechnungsprogramm ist offline, wenn die davon abhängigen Anwendungen versuchen, es wiederherzustellen. Ein gemeinsam genutztes Datenbankschema befindet sich an einem anderen Wiederherstellungspunkt als die Anwendungen, die darauf zugreifen. Jeder dieser Fehler ist durch die von der Strukturanalyse bereitgestellten Abhängigkeitsnachweise vermeidbar und verursacht hohe Kosten, wenn er während eines tatsächlichen Vorfalls und nicht während einer Planspielübung auftritt.
Die Bewertungsmethodik ist etabliert. Die Rahmenbedingungen sind vorhanden. Die Lücke, die die meisten Organisationen haben, liegt nicht im Bewertungsrahmen selbst, sondern in der Datengrundlage für dessen wichtigste Dimension. Diese Lücke muss durch eine Strukturanalyse geschlossen werden, bevor der nächste Vorfall die Funktionsfähigkeit des Notfallplans erfordert.
