Grundsätze für beherrschbare Systeme

Wie Offenheit, Reparierbarkeit, Dokumentation und klare Abhängigkeiten robuste IT ermöglichen.

Robuste IT ist nicht die IT mit den meisten Produkten. Sie ist die IT, deren Zweck, Abhängigkeiten und Wiederherstellungswege verstanden werden. Technik darf anspruchsvoll sein; ihr Betrieb darf aber nicht von Zufall, Einzelwissen oder undurchsichtigen Schnittstellen abhängen.

Mit der Funktion beginnen

Bevor Komponenten ausgewählt werden, muss klar sein, welche Funktion erhalten werden soll. Wer benötigt welche Information? Welche Antwortzeit ist notwendig? Was darf vorübergehend ausfallen, und was nicht? Erst diese Fragen geben Architekturentscheidungen einen belastbaren Rahmen.

Eine Funktionsbeschreibung trennt Bedarf von Produktnamen. Dadurch bleibt eine Lösung auch dann prüfbar, wenn Hersteller, Versionen oder Betriebsmodelle wechseln.

Die Informationskette betrachten

Eine Anwendung steht selten allein. Endgeräte, Identitäten, Netze, Namensauflösung, Zeitquellen, Speicher, Sicherungen und Kommunikationswege bilden eine Kette. Eine Störung an einem unscheinbaren Glied kann eine sichtbare Fachanwendung stilllegen.

Deshalb betrachten wir Anwendungen, Prozesse, Schnittstellen, Netze und Kommunikationswege zusammen. Die Darstellung muss so konkret sein, dass Abhängigkeiten im Normalbetrieb und im Störfall erkennbar bleiben.

Offenheit mit einem Zweck einsetzen

Open Source und offene Standards sind Werkzeuge, keine Dekoration. Sie sind dann wertvoll, wenn sie Austauschbarkeit, Prüfbarkeit, Wartbarkeit oder Wissenstransfer verbessern. Eine offene Komponente ohne Verantwortlichkeit und Betriebswissen löst dagegen kein Problem.

Herstellerunabhängigkeit bedeutet auch nicht, jeden Hersteller zu meiden. Sie bedeutet, Entscheidungen an der Aufgabe auszurichten und vermeidbare Bindungen sichtbar zu machen.

Reparierbarkeit einplanen

Reparierbarkeit beginnt vor dem Defekt. Ersatzwege, Konfigurationssicherungen, nachvollziehbare Änderungen und erreichbare Dokumentation müssen vorhanden sein, bevor eine Störung eintritt. Ein System ist nicht robust, wenn seine Wiederherstellung nur in den Köpfen einzelner Personen existiert.

Wo möglich, sollten Komponenten einzeln austauschbar sein. Schnittstellen, Formate und Zuständigkeiten müssen dokumentiert werden. Wiederherstellungsschritte gehören getestet, nicht nur aufgeschrieben.

Abhängigkeiten sichtbar halten

Jede Abhängigkeit kann sinnvoll sein. Problematisch wird sie, wenn sie unbekannt, unnötig oder nicht beeinflussbar ist. Dazu zählen technische Abhängigkeiten ebenso wie Verträge, Konten, Schlüsselpersonen und externe Dienste.

Eine gute Übersicht beantwortet mindestens:

• Welche Funktion hängt davon ab?
• Wer ist verantwortlich?
• Wie wird die Abhängigkeit überwacht?
• Welche Alternative oder welcher Notbetrieb existiert?
• Wie lässt sich der Zustand wiederherstellen?

Dokumentation als Betriebsmittel behandeln

Dokumentation ist kein Abschlussfoto eines Projekts. Sie ist ein Betriebsmittel und muss die Fragen beantworten, die bei Änderung, Übergabe und Störung tatsächlich entstehen.

Entscheidungen verdienen dabei ebenso viel Aufmerksamkeit wie Konfigurationen. Wer später nur sieht, was gebaut wurde, aber nicht warum, wird dieselben Abwägungen erneut durchführen oder wichtige Randbedingungen übersehen.

Wissen übertragbar machen

Ein beherrschbares System darf nicht dauerhaft von Einzelwissen abhängen. Übergaben, gemeinsame Durchgänge und verständliche Begriffe machen Wissen belastbar. Das Ziel ist nicht, jedes Detail zu vereinfachen, sondern die richtigen Details für die jeweilige Rolle zugänglich zu machen.

Sicherheit und Datenschutz zusammen denken

Sicherheit entsteht nicht durch eine einzelne Kontrolle. Identitäten, Berechtigungen, Netzgrenzen, Updates, Sicherungen, Protokollierung und Wiederherstellung wirken zusammen. Datenschutz verlangt zusätzlich, Datenflüsse, Zwecke und externe Empfänger zu kennen.

Offene und nachvollziehbare Strukturen erleichtern diese Prüfung. Sie ersetzen jedoch weder eine fachliche Risikoanalyse noch eine rechtliche Bewertung.

Weniger, aber bewusst

Jede zusätzliche Komponente erhöht Betriebs-, Aktualisierungs- und Dokumentationsaufwand. Eine kleinere Architektur ist nicht automatisch besser, doch unnötige Schichten sollten begründet oder entfernt werden.

Die einfachste tragfähige Lösung ist häufig die robusteste: klar genug für den Betrieb, offen genug für Veränderungen und vollständig genug für den Störfall.

Eine praktische Prüfliste

Vor einer Architekturentscheidung helfen neun Fragen:

1. Welche Funktion muss zuverlässig erhalten bleiben?
2. Welche Menschen und Prozesse sind beteiligt?
3. Welche technischen und organisatorischen Abhängigkeiten entstehen?
4. Welche vorhandenen Komponenten können weiter genutzt werden?
5. Wo entsteht eine vermeidbare Hersteller- oder Dienstbindung?
6. Wie wird der Zustand gesichert und wiederhergestellt?
7. Wer kann das System warten und reparieren?
8. Welche Entscheidungen müssen dokumentiert werden?
9. Wie wird das notwendige Wissen übergeben?

Diese Fragen ersetzen keine Detailplanung. Sie verhindern aber, dass wichtige Betriebsfragen erst nach dem Kauf gestellt werden.