Resilienz und Autarkie in der IT

Die Grundvoraussetzung schlechthin für jeden nachhaltigen Erfolg ist das Erzielen von (ausreichend) Stabilität.

Ohne ein gutes Gleichgewicht stehen alle nachfolgenden Ergebnisse und Bemühungen auf sehr wackeligen Beinen. Das gilt für den menschlichen Körper wie für Brücken, Gebäude, Gesellschaften – und auch für unsere IT-Systeme.

Neben der Beachtung von allgemeinen Grundvoraussetzungen beim Design und bei der Entwicklung von IT-Systemen ist es insbesondere auch wichtig, dass – allen Widrigkeiten zum Trotz – ein stabiler Betrieb gewährleistet werden kann. Das klingt zunächst einmal banal und wird aus Sicht des Managements vielfach als Selbstverständlichkeit eingefordert, ist aber nur als komplexer und energieintensiver, kontinuierlicher Prozess realisierbar.

Offene/geschlossene Systeme

Ganz generell entsteht umso mehr Stabilität, je mehr wir den Möglichkeitsraum der Systeme beschränken. Das isolierte, abgeschlossene System mit wenigen Zuständen ist extrem zuverlässig und stabil (aber weniger nutzbringend).

Abstraktionen können uns dabei helfen, Fehlerquoten zu verringern, bergen aber die Gefahr der falschen Anwendung in unterschiedlichen Kontexten. Ein hoher Abstraktionsgrad sorgt nur dann für mehr Stabilität, wenn (mathematisch) verifiziert werden kann, dass die Zielzustände durchgehend gesichert sind.

Das isolierte, abgeschlossene System mit wenigen Zuständen ist extrem zuverlässig und stabil (aber weniger nutzbringend).

Indem wir in einem Schalenmodell aus System-System-Umgebungs-Paaren einzelne Systeme und Systemumgebungen voneinander isolieren (und das auf verschiedenen Stufen der Granularität), können wir Abhängigkeiten reduzieren und Angriffsflächen verringern.

Entscheidende, die Stabilität beeinflussende, Faktoren sind unter anderem: Funktionsumfang, Komplexitätsgrad, Abhängigkeiten, Komposition, Variabilität, Universalität.

Um globale Stabilität zu erreichen (zum Beispiel bei der Bereitstellung von Plattform-as-Service-Diensten), muss diese zuerst auf lokaler Ebene für alle Komponenten umgesetzt werden. Erst danach gilt es, auch die Abhängigkeiten zueinander so auszugestalten, dass Stabilität realisiert werden kann.

In der Realität haben wir es jedoch immer mit offenen, dynamischen IT-Systemen zu tun. Äußere Faktoren bestimmen hier maßgeblich das Gesamtverhalten mit und gefährden die Stabilität direkt und indirekt. Hier kommt Resilienz ins Spiel.

Was Resilienz für das offene System ist, bedeutet Autarkie für das geschlossene System.

Resilienz

Damit wir äußeren Umständen zum Trotz stabile IT-Systeme verfügbar halten können, benötigen wir weitere Strategien. Es gilt, auf Veränderungen so reagieren zu können, dass die eigenen Strukturen und Funktionen auf alternativem Weg aufrecht erhalten werden können.

Konkret bedeutet das zum Beispiel:

• die Abstraktion von Third-Party Integrationen, sowie die In-Evidenz-Haltung alternativer Lösungen (vergleichbar mit gelungenem Supply Chain Management).
• den Einsatz von cloudagnostischen Frameworks und Plattformen
• das Einziehen von Barrieren zwischen Development, Build + Composition, Deployment, Staging/Production Environments
• mehr Awareness durch Monitoring und Analytics in Verbindung mit Regulationsmechanismen
• redundante, fehlertolerante Services (wie mittels OTP Supervisors in Erlang/Elixir)
• eine strukturierte kontinuierliche Systemevolution, um proaktiv mittel- und langfristig destabilisierenden Veränderungsprozessen entgegenzuwirken

Autarkie

Was Resilienz für das offene System ist, bedeutet Autarkie für das geschlossene System. Vor zwei Jahrzehnten war Autarkie noch die zentrale Philosophie in der IT-Organisation. Erst durch das enorme Wachstum von Cloud-Ressourcen und durch die Dominanz der Plattform-Ökonomie änderte sich dieses Bild. Die damit verbundene Steigerung von Komplexität und Customer Experience (CX) führte Organisationen zum Outsourcing vieler IT-Dienstleistungen.

Es ist dennoch nicht nur möglich, sondern auch empfehlenswert, immer im Detail zu entscheiden, wo Autarkie möglich ist – und diese zu bevorzugen.

Konkret bedeutet das zum Beispiel:

• den Verzicht auf Cloud Functions und externe APIs
• Self Hosting (auch in der Cloud)
• statische Integrationen gegenüber dynamischen Integrationen zu bevorzugen
• die Verwendung von FLOSS (Free/Libre Open Source Software), sofern diese aktuell, gepflegt und überschaubar ist
• transparente (Prozess-)Automatisierung mit manuellem Fallback