Dein System läuft großartig. Solange die Person arbeitet, die weiß, warum.
Das Unternehmen hat ein System, das über sieben Jahre entstanden ist. Es funktioniert. Es bedient Kunden. Es verbindet sich mit anderen Systemen. Es führt Prozesse aus, ohne die das Unternehmen eigentlich nicht normal funktionieren könnte.
In diesen sieben Jahren haben fünf Entwickler an dem Projekt gearbeitet. Dazu kamen zwei Freelancer und eine Agentur. Ein Teil der Dokumentation liegt in Confluence, ein Teil auf Google Drive, ein Teil in Tickets. Irgendwo gibt es noch ein altes Dokument zu einer der Integrationen. Und wenn jemand fragt, warum ein bestimmter Teil des Systems genau so funktioniert, lautet die Antwort: "Ich glaube, Michał hat sich daran erinnert."
Michał ist vor drei Jahren gegangen.
Und genau dann beginnt das eigentliche Problem.
Nicht, weil das System schlecht geschrieben ist. Nicht, weil es plötzlich aufgehört hat zu funktionieren. Das Problem ist, dass das Unternehmen nicht mehr über das vollständige Wissen zu seinem eigenen System verfügt.
Das System funktioniert, aber das Unternehmen kontrolliert es vielleicht nicht
Das ist eine der am meisten unterschätzten Formen technologischer Schuld.
Wenn wir über technische Schuld sprechen, denken wir meist an alten Code, veraltete Bibliotheken, architektonische Fehler, fehlende Tests oder Lösungen, die früher schnell waren, heute aber die Weiterentwicklung erschweren.
Dabei gibt es noch eine andere Art von Schuld. Wissensschuld.
Sie entsteht dann, wenn ein System von Informationen abhängt, die nicht in der Dokumentation, im Repository, in den Verfahren oder in der Organisation stehen, sondern in den Köpfen bestimmter Personen.
Und solange diese Personen verfügbar sind, kann alles normal aussehen.
Das Problem tritt bei Teamwechsel, beim Weggang eines Entwicklers, beim Ende der Zusammenarbeit mit einem Softwarehaus, bei einem Serverausfall, beim Wechsel des Administrators oder bei der Notwendigkeit auf, schnell eine neue Lösung einzuführen.
Plötzlich stellt sich heraus, dass das Unternehmen Code hat, aber kein Wissen.
Es hat einen Server, aber keine Gewissheit, wer Zugriff hat.
Es hat eine Integration, aber niemand weiß, unter welchem Konto sie eingerichtet wurde.
Es hat Dokumentation, aber niemand weiß, welche Version aktuell ist.
Es hat einen Prozess, aber niemand weiß, warum er genau so entworfen wurde.
Und dann taucht sehr schnell die Frage auf: Wer ist eigentlich der Eigentümer dieses Systems?
Bus Factor, also was passiert, wenn eine Person verschwindet?
In der IT gibt es den Begriff Bus Factor. Vereinfacht gesagt bezeichnet er die Anzahl von Personen, deren Nichtverfügbarkeit dazu führen kann, dass ein Team ein Projekt nicht mehr wirksam weiterentwickeln oder betreiben kann.
Es geht natürlich nicht um ein wörtliches Ereignis. Es ist eine Denkweise über die Konzentration von Wissen.
Wenn nur eine Person weiß, wie eine kritische Integration funktioniert, beträgt der Bus Factor für dieses Wissen eins.
Wenn nur ein Administrator Zugang zur Produktion hat, beträgt der Bus Factor eins.
Wenn nur ein Mensch weiß, warum das System jede Nacht einen bestimmten Prozess ausführt, kann der Bus Factor eins betragen.
Wenn ein Unternehmen mit einem externen Softwarehaus zusammenarbeitet und auf Kundenseite niemand die Architektur der Lösung versteht, entsteht ein noch größeres Problem - das Wissen kann außerhalb der Organisation liegen.
Das bedeutet nicht, dass jedes Unternehmen fünf Experten für jeden Teil des Systems haben muss.
Es geht um etwas viel Einfacheres: Das Unternehmen sollte wissen, wo sich kritisches Wissen befindet und ob es es ohne eine bestimmte Person zurückgewinnen kann.
Der Code sagt, wie. Nicht immer, warum.
Ein Entwickler kann den Code lesen und verstehen, was eine bestimmte Funktion tut.
Nicht immer wird er jedoch wissen, warum sie genau so geschrieben wurde.
Das ist ein gewaltiger Unterschied.
Man kann den Teil finden, der für das Senden von Daten an ein externes System verantwortlich ist. Man kann den Endpoint, die Parameter, die Autorisierung und die Fehlerbehandlung analysieren.
Aber der Code beantwortet nicht unbedingt die Fragen:
- Warum senden wir die Daten um 2:00 Uhr nachts?
- Warum wird dieser bestimmte Status übersprungen?
- Warum versucht das System nach einem Fehler genau drei Mal erneut?
- Warum wird ein Wert vor dem Senden umgerechnet?
- Warum darf die Reihenfolge dieser Vorgänge nicht geändert werden?
- Warum nutzt diese Integration ein bestimmtes Konto?
Die Antwort kann in der Projektgeschichte, in einem alten Ticket, in einer E-Mail von vor sechs Jahren oder - schlimmer noch - nur im Gedächtnis eines Menschen liegen, der nicht mehr im Unternehmen arbeitet.
Deshalb sollte gute Dokumentation nicht nur eine Anleitung sein, "was man anklicken muss".
Sie sollte auch Kontext und Entscheidungen bewahren.
Das größte Problem kann eine Integration sein, an die sich niemand mehr erinnert
Ein modernes System funktioniert fast nie völlig eigenständig.
Es verbindet sich mit einem ERP-System. CRM. Zahlungs-Gateway. SMS-Anbieter. Kurierdienst-System. Partner-API. Cloud-Dienst. Analyseplattform. Buchhaltungssystem. Authentifizierungsmechanismus.
Jede solche Verbindung ist Teil einer technologischen Kette.
Und jeder Teil dieser Kette kann einen eigenen Eigentümer, ein Konto, einen API-Schlüssel, ein Zertifikat, einen Vertrag, ein Limit, eine API-Version und einen Lebenszyklus haben.
Nach ein paar Jahren erinnert sich vielleicht niemand mehr daran, wer das Konto angelegt hat.
Und dann reicht das Ablaufen eines Zertifikats oder eine API-Änderung, damit das System aufhört zu funktionieren.
Noch schlimmer ist es, wenn das Unternehmen nicht einmal weiß, dass es diese Abhängigkeit gibt.
Deshalb gewinnt in einem reifen Umgang mit Systemen Software-Provenienz, das Management von Abhängigkeiten und die Transparenz der Software-Lieferkette immer mehr an Bedeutung. Das NIST weist in seinen aktuellen Materialien zur Sicherheit der Lieferkette unter anderem auf die Bedeutung von Informationen über Komponenten, ihre Herkunft, ihren Lebenszyklus und ihre Abhängigkeiten hin. SBOM, also Software Bill of Materials, ist eines der Werkzeuge, mit denen sich das Wissen darüber ordnen lässt, aus welchen Komponenten Software besteht.
Das ist nicht mehr ausschließlich ein Thema für das Security-Team.
Es ist auch ein Thema für die Geschäftsleitung.
Denn wenn ein Unternehmen nicht weiß, woraus sein System aufgebaut ist, kann es Risiko, Wartungskosten und die Folgen von Änderungen schwerer einschätzen.
Dokumentation ist kein Kostenfaktor. Sie ist eine Police.
In vielen Unternehmen wird Dokumentation als etwas betrachtet, das man "später macht".
Zuerst die Funktionalität.
Dann die Einführung.
Dann die Korrekturen.
Dann das nächste Projekt.
Und die Dokumentation?
"Wenn Zeit ist."
Das Problem ist, dass Zeit für Dokumentation meist erst dann auftaucht, wenn es schon zu spät ist.
Dokumentation sollte wie eine geschäftliche Versicherung funktionieren. Nicht, weil jemand sie täglich lesen wird. Ganz im Gegenteil - hoffentlich wird sie in einer Notfallsituation so selten wie möglich benötigt.
Aber wenn ein Problem auftritt, sollte das Unternehmen in der Lage sein, grundlegende Fragen zu beantworten:
- Wie funktioniert das System?
- Woraus besteht es?
- Wo befindet sich die Produktionsumgebung?
- Wer hat Zugriff?
- Welche Integrationen sind kritisch?
- Welche Konten und externen Dienste werden genutzt?
- Welche Abhängigkeiten gibt es?
- Wie werden Backups durchgeführt?
- Wie sieht der Deployment-Prozess aus?
- Was passiert bei einem Ausfall?
- Welche Elemente sind geschäftskritisch?
- Warum wurden die wichtigsten Architekturentscheidungen getroffen?
- Wer kann die Wartung des Systems übernehmen?
Das muss nicht hunderte Seiten Dokumentation bedeuten.
Gute Dokumentation sollte vor allem nützlich, aktuell und für die richtigen Personen zugänglich sein.
"Lasst uns nichts ändern, weil es funktioniert" ist nicht immer eine schlechte Entscheidung
Es gibt noch ein weiteres sehr häufiges Problem.
Das System läuft seit Jahren, also gilt im Unternehmen die Regel: "Wir rühren nichts an. Es funktioniert."
Und manchmal ist das absolut vernünftig.
Nicht jede alte Technologie muss sofort ersetzt werden. Nicht jeder ältere Codeabschnitt muss neu geschrieben werden. Nicht jede Bibliothek bedeutet eine Katastrophe. Nicht jede Architektur von vor einigen Jahren ist fehlerhaft.
Das Problem beginnt dann, wenn "wir rühren nichts an" auch bedeutet:
- "Wir analysieren nicht."
- "Wir dokumentieren nicht."
- "Wir prüfen keine Abhängigkeiten."
- "Wir fragen nicht, wer Zugriff hat."
- "Wir prüfen nicht, ob wir noch alle Konten haben."
- "Wir legen nicht fest, was passiert, wenn der aktuelle Dienstleister nicht mehr verfügbar ist."
Dann ist fehlende Veränderung keine Strategie.
Es ist das Aufschieben von Risiken.
Manchmal ist die beste technische Entscheidung tatsächlich, nichts umzubauen.
Aber diese Entscheidung sollte aus Wissen über das System entstehen, nicht aus fehlendem Wissen über das System.
Was sollte ein Audit eines geerbten Systems umfassen?
Wenn ein Unternehmen ein System von einem anderen Softwarehaus, einem Freelancer oder einem internen Team übernimmt, sollte der erste Schritt nicht das automatische Umschreiben von allem sein.
Zuerst muss man verstehen, was eigentlich übernommen wurde.
Ein Audit sollte mindestens einige grundlegende Bereiche beantworten.
Architektur. Wie ist das System aufgebaut? Was sind seine Hauptkomponenten? Wo liegen die Daten? Wie kommunizieren die einzelnen Elemente miteinander?
Code und Repositories. Verfügt das Unternehmen über den vollständigen Quellcode? Ist bekannt, welcher Branch und welche Version produktiv sind? Ist der Build- und Deployment-Prozess reproduzierbar?
Infrastruktur. Wo läuft die Produktion? Wie sieht die Testumgebung aus? Wer hat Zugriff? Wie sieht Monitoring und Backup aus?
Integrationen. Womit kommuniziert das System? Welche APIs werden genutzt? Wer ist Eigentümer der einzelnen Konten und Schlüssel?
Abhängigkeiten. Welche Bibliotheken, Frameworks und externen Komponenten werden genutzt? Werden sie aktualisiert? Gibt es bekannte Sicherheitsprobleme? Wie sieht ihr Lebenszyklus aus?
Deployment-Prozess. Ist eine neue Person in der Lage, eine Änderung vorzubereiten, zu testen und auszurollen, ohne den früheren Entwickler anzurufen?
Wissen. Was steht in der Dokumentation, und was existiert noch immer nur in den Köpfen der Menschen?
Geschäftsrisiko. Was passiert, wenn eine bestimmte Komponente eine Stunde, einen Tag oder eine Woche lang ausfällt?
Der moderne Ansatz zur Sicherheit der Software-Lieferkette betont immer stärker genau diese Notwendigkeit, Komponenten, Anbieter, Abhängigkeiten, ihre Herkunft und ihren Lebenszyklus zu kennen. Das NIST weist außerdem auf die Bedeutung der Due Diligence gegenüber Technologieanbietern und der Bewertung von Resilienz sowie des mit der gesamten Lieferkette verbundenen Risikos hin.
Ein Audit bedeutet nicht "lasst uns das System von Grund auf neu schreiben"
Das ist wichtig, weil ein technisches Audit oft fälschlicherweise mit einem Umbau gleichgesetzt wird.
Dabei kann ein Audit mit einer sehr einfachen Schlussfolgerung enden: "Das System ist in Ordnung. Man muss nur das Wissen ordnen und einige Risiken beseitigen."
Es kann sich auch herausstellen, dass das System nur in einem Bereich modernisiert werden muss.
Oder dass das größte Problem nicht der Code ist, sondern der fehlende Zugriff auf die Infrastruktur.
Oder dass die Anwendung gut geschrieben ist, aber niemand aktuelles Wissen über den Deployment-Prozess hat.
Oder dass alles funktioniert, aber das Unternehmen von einem einzigen externen Anbieter abhängig ist.
Deshalb sollte eine gute Analyse eines übernommenen Projekts die Frage beantworten: "Was muss wirklich geändert werden, und was muss nicht angerührt werden?"
Erst dann können Investitionsentscheidungen getroffen werden.
Und was, wenn du das Softwarehaus wechselst?
Das ist einer der Momente, in denen das Problem der unsichtbaren Wissensschuld ans Licht kommt.
Das Unternehmen beendet die Zusammenarbeit mit dem Dienstleister.
Der neue Partner erhält das Repository.
Und beginnt, Fragen zu stellen:
- "Wo ist die Produktion?"
- "Wie starte ich das Projekt lokal?"
- "Welche Version ist aktuell?"
- "Wozu dient dieser Dienst?"
- "Wer besitzt das Konto für diese API?"
- "Was macht dieser Cronjob?"
- "Warum startet dieser Prozess zu dieser Uhrzeit?"
- "Woher nehmen wir diesen Parameter?"
- "Was passiert, wenn wir ihn deaktivieren?"
Wenn die Antwort auf die meisten Fragen "wir wissen es nicht" lautet, übernimmt das neue Softwarehaus das Projekt nicht. Zuerst muss es es entdecken.
Und das Entdecken des Systems kostet Zeit. Zeit, die später der Kunde bezahlt.
Deshalb sollte die Übergabe eines Projekts zwischen Teams ein Prozess sein und nicht das Hochladen einer ZIP-Datei mit Code und dem Passwort für ein einziges Konto.
Das System sollte Menschen überleben
Das ist wohl die wichtigste Regel.
Menschen verändern sich. Entwickler wechseln den Job. Freelancer beenden die Zusammenarbeit. Softwarehäuser wechseln Kunden. Administratoren gehen zu anderen Unternehmen. Vorstände ändern sich.
Das System bleibt.
Deshalb sollte ein System so entworfen sein, dass das für seine Wartung notwendige Wissen wiederhergestellt werden kann.
Das bedeutet nicht, dass jeder Mitarbeiter alles wissen muss.
Es bedeutet, dass die Organisation einen Mechanismus zur Wissensspeicherung haben sollte:
- Repositories.
- Dokumentation.
- Integrationsregister.
- Informationen zur Infrastruktur.
- Vom Unternehmen verwaltete Zugriffe.
- Beschreibung der wichtigsten Prozesse.
- Historie der wesentlichen Entscheidungen.
- Informationen über Abhängigkeiten.
- Notfallverfahren.
- Und vor allem - Menschen, die wissen, wie man diese Dokumentation nutzt.
Das NIST weist in aktuellen Leitlinien zur Planung der Systemsicherheit ebenfalls auf die formale Festlegung von Verantwortlichkeiten, des Betriebsstatus des Systems sowie der Rollen der Personen hin, die das System verwalten, unterstützen oder darauf zugreifen.
Das zeigt einen breiteren Wandel im Denken über Technologie.
Ein System ist nicht nur Code. Ein System sind auch Menschen, Prozesse, Infrastruktur, Abhängigkeiten, Daten, Zugriff und Verantwortung.
Bei Web24 beginnen wir oft genau mit der Frage: "Was haben wir hier eigentlich?"
Die Übernahme eines bestehenden Projekts sollte nicht mit dem Versprechen beginnen, dass alles von Grund auf neu geschrieben wird.
Es sollte damit beginnen, die Situation zu verstehen:
- Was funktioniert?
- Was funktioniert nicht?
- Was ist kritisch?
- Was ist veraltet?
- Wo liegen die größten Risiken?
- Was fehlt in der Dokumentation?
- Welche Abhängigkeiten sind unsichtbar?
- Kann man das bestehende System sicher weiterentwickeln?
- Ist eine Modernisierung nötig oder nur eine Bereinigung?
Erst dann kann man entscheiden, ob das Projekt weiterentwickelt, neu aufgebaut, teilweise neu geschrieben oder einfach gut dokumentiert werden sollte.
Das ist besonders wichtig bei Projekten, die über Jahre von verschiedenen Personen und verschiedenen Unternehmen weiterentwickelt wurden.
Denn ein guter Technologiepartner sollte nicht deshalb nötig sein, weil nur er weiß, wie das System funktioniert.
Er sollte nötig sein, weil er dieses System weiterentwickeln, absichern und Wissen weitergeben kann.
Der gefährlichste Fehler kann ein Mensch sein, der bereits gegangen ist
Nicht immer ist alter Code das Problem.
Nicht immer ist veraltete Technologie das Problem.
Nicht immer ist das Fehlen des neuesten Frameworks das Problem.
Manchmal ist das größte Risiko eine Information, die niemand aufgeschrieben hat.
Ein Schlagwort.
Eine architektonische Entscheidung.
Eine Integration.
Eine Ausnahme im Prozess.
Ein Mensch, der über Jahre wusste, wie es funktioniert.
Und dann ging er.
Deshalb lohnt es sich, sich heute eine sehr einfache Frage zu stellen: Wenn morgen die Person aus dem Unternehmen verschwinden würde, die euer System am besten kennt, könntet ihr es dann immer noch verwalten?
Wenn die Antwort „ja“ lautet – großartig.
Wenn sie lautet „ich weiß nicht“ – lohnt es sich, das zu prüfen.
Und wenn sie lautet „ganz sicher nicht“ – dann habt ihr wahrscheinlich gerade einen der wichtigsten Bereiche technologischen Risikos in eurem Unternehmen gefunden.
Ein System sollte größer sein als das Gedächtnis einer einzelnen Person.
