Ihr System läuft großartig. Solange die Person arbeitet, die weiß, warum.
Stellen Sie sich ein Unternehmen vor, das ein System hat, das seit sieben Jahren läuft. Es entstand schrittweise. Zuerst wurde es von einer Softwarefirma entwickelt. Dann übernahm ein Freelancer einen Teil. Später ergänzte ein weiteres Team das B2B-Modul. Eine weitere Agentur band das CRM an. Jemand anderes integrierte die Zahlungen.
Das System funktioniert.
Das Unternehmen verdient damit Geld.
Die Mitarbeiter nutzen es täglich.
Die Kunden wissen nicht einmal, wie viele Prozesse im Hintergrund ablaufen.
Nur gibt es ein Problem.
Niemand weiß mehr genau, wie das alles funktioniert.
Die Dokumentation liegt teilweise in Confluence. Etwas wurde auf Google Drive abgelegt. Einige Informationen finden sich in Tickets. Eine Integration wurde in einer E-Mail von vor vier Jahren beschrieben.
Und das Wichtigste hat "wahrscheinlich Łukasz noch gewusst".
Nur ist Łukasz vor drei Jahren gegangen.
Und drei Jahre lang ist nichts passiert.
Bis zu einem bestimmten Dienstagmorgen.
Das System läuft. Also ist alles in Ordnung?
Das ist einer der trügerischsten Zustände, in dem sich ein Unternehmenssystem befinden kann.
Es funktioniert.
Es gibt keine Ausfälle.
Die Nutzer sind zufrieden.
Der Vertrieb nutzt die Anwendung.
Bestellungen gehen durch.
Daten landen im CRM.
Berichte werden erstellt.
Die natürliche Reaktion lautet also: Lasst uns nichts ändern. Warum an etwas herumdoktern, das funktioniert?
Und tatsächlich - es gibt keinen Grund, ein funktionierendes System nur deshalb zu ändern, weil man es kann.
Das Problem ist, dass ein System technisch stabil sein kann und gleichzeitig organisatorisch sehr instabil.
Es kann heute funktionieren, aber niemand weiß, was passiert, wenn ein Server, ein API-Anbieter, eine Domain, eine Bibliothek, die Authentifizierungsmethode oder ein Teil des Geschäftsprozesses geändert werden muss.
Es kann funktionsfähig sein, aber von einer einzigen Person abhängen.
Es kann sicher sein, aber niemand weiß, wo sich alle Zugangsschlüssel befinden.
Es kann weiterentwickelt werden, aber nur von dem Menschen, der die Geschichte aller Entscheidungen kennt.
Und genau hier kommt der Begriff Bus-Faktor ins Spiel.
Wie viele Personen können verschwinden, bevor das Projekt zum Problem wird?
Der Bus-Faktor ist ein sehr einfaches, wenn auch brutales Konzept.
Wir fragen: Wie viele Personen müssen nicht mehr verfügbar sein, damit das Projekt nicht mehr vernünftig zu betreiben ist?
Wenn die Antwort lautet: "Eine", haben wir ein Problem.
Wenn die Antwort lautet: "Zwei, aber beide arbeiten in einer anderen Firma", haben wir ein noch größeres Problem.
Es geht natürlich nicht um das wörtliche "Verschwinden" von Menschen.
Ein Programmierer kann das Unternehmen verlassen.
Ein Freelancer kann die Zusammenarbeit beenden.
Eine Softwarefirma kann aufhören, den Kunden zu betreuen.
Ein Administrator kann den Job wechseln.
Die für eine bestimmte Integration verantwortliche Person kann in eine andere Abteilung wechseln.
Der Wissensträger kann einfach krank werden oder mehrere Wochen lang nicht verfügbar sein.
Wenn mit ihm die Möglichkeit verschwindet, das System zu verstehen, hat das Unternehmen kein Personalproblem.
Es hat ein Geschäftsproblem.
Code sagt nicht immer, warum etwas funktioniert
Man könnte sagen: "Aber wir haben doch den Quellcode. Im Zweifel liest ihn sich ein neuer Programmierer durch."
Theoretisch ja.
In der Praxis beantwortet Code vor allem die Frage: wie das System etwas macht.
Nicht immer beantwortet er die Frage: warum es genau auf diese Weise gemacht wird.
Und das ist ein gewaltiger Unterschied.
Im Code kann eine Bedingung stehen: "Wenn der Kunde einen bestimmten Kontotyp hat, führe Operation X aus."
Ein neuer Entwickler kann sie finden.
Aber woher soll er das Warum kennen?
Es kann eine geschäftliche Anforderung sein.
Es kann ein Überbleibsel aus einer alten Integration sein.
Es kann eine Absicherung gegen einen Fehler einer externen API sein.
Es kann ein Workaround für ein Problem sein, das vor fünf Jahren auftrat.
Es kann die Lösung eines ungewöhnlichen Falls eines der größten Kunden sein.
Es kann aus einem sehr guten Grund dort stehen.
Oder aus keinem.
Ohne Kontext ist das schwer zu beurteilen.
Deshalb sollte sich die Systemdokumentation nicht auf Anweisungen beschränken:
"Klicken Sie hier, dann hier".
Die wertvollste Dokumentation beschreibt oft Entscheidungen und Abhängigkeiten, nicht nur die Bedienung von Funktionen.
Das gefährlichste Wissen ist das, das nur in jemandes Kopf existiert
Unternehmen haben sehr oft Dokumentation. Nur ist Dokumentation nicht immer dasselbe wie Wissen.
Wir können eine API-Beschreibung haben - aber keine Information darüber, warum wir gerade diese API nutzen.
Wir können eine Deploy-Anleitung haben - aber keine Liste aller Stellen, an denen die Konfiguration geändert werden muss.
Wir können eine Integrationsbeschreibung haben - aber nicht wissen, was passiert, wenn der externe Anbieter die Art der Autorisierung ändert.
Wir können eine Serverliste haben - aber nicht wissen, welcher davon für einen bestimmten Prozess kritisch ist.
Wir können Zugriff auf das Repository haben - aber keinen Zugang zu dem Konto, auf dem sich die Produktionsinfrastruktur befindet.
Das sind genau die Elemente, die eine scheinbar einfache Änderung in eine tagelange Untersuchung verwandeln können.
Eine seit fünf Jahren funktionierende Integration bleibt dennoch eine Abhängigkeit
Einer der am häufigsten ignorierten Bereiche sind externe Dienste;
- Zahlungen.
- SMS.
- E-Mail.
- CRM.
- ERP.
- Karten.
- Kuriersysteme.
- Marketingplattformen.
- Buchhaltungssysteme.
- Cloud-Dienste.
- Externe APIs.
- Open-Source-Bibliotheken.
Jede dieser Dinge ist Teil eines größeren Ökosystems.
Wenn ein System zehn externe Dienste nutzt, haben wir nicht ein System. Wir haben ein System plus zehn Abhängigkeiten. Und jede davon kann sich ändern.
Der Anbieter kann die API ändern.
Er kann den Dienst einstellen.
Er kann das Preismodell ändern.
Er kann die alte Version zurückziehen.
Er kann neue Sicherheitsanforderungen einführen.
Er kann von einem anderen Unternehmen übernommen werden.
Deshalb gewinnt auch das Wissen über die Herkunft von Komponenten und Softwareabhängigkeiten zunehmend an Bedeutung. Das NIST weist unter anderem auf die Bedeutung von SBOM hin, also der Software Bill of Materials - einer formalen Aufstellung der Komponenten, die zur Erstellung der Software verwendet wurden. Eine solche Liste hilft zu verstehen, woraus das System besteht, und die Auswirkungen von Schwachstellen oder Änderungen in der Lieferkette schneller einzuschätzen.
Für das Business lässt sich das auf eine sehr einfache Frage reduzieren:
Wissen Sie, wovon Ihr System abhängt?
Und stellen Sie sich jetzt einen Wechsel der Softwarefirma vor
Das ist einer der Momente, in denen alle Lücken ans Licht kommen.
Das Unternehmen arbeitete über Jahre mit einem einzigen Dienstleister zusammen. Plötzlich endet die Zusammenarbeit. Die Gründe können vielfältig sein; Strategiewechsel. Budgetänderung. Übernahme der Agentur. Organisatorische Probleme. Mangelnde Kompetenzen für die weitere Entwicklung. Oder das Unternehmen möchte einfach mit einem anderen Partner arbeiten.
Der neue Software House fragt:
"Wo ist das Repository?" - Es ist da.
"Wo ist die Infrastruktur?" - Sie ist da.
"Wie deployen wir in die Produktion?" - "Wir wissen es nicht, das hat das vorherige Team gemacht."
"Wie funktioniert die Integration mit dem ERP?" - "Wahrscheinlich über diesen Server."
"Welche API-Schlüssel haben wir?" - "Sie sollten in einer E-Mail sein."
"Welche APIs sind produktiv?" - "Wir wissen es nicht."
"Welche Prozesse sind kritisch?" - "Das muss man Łukasz fragen."
Łukasz arbeitet dort schon nicht mehr...
Und genau deshalb ist die Übernahme eines Projekts nicht nur die Übernahme von Code. Es muss auch Wissen übertragen werden.
Dokumentation ist kein Kostenpunkt. Sie ist eine Versicherung.
In vielen Unternehmen wird Dokumentation als etwas behandelt, das man macht, "wenn Zeit ist".
Also normalerweise nie.
Oder am Ende des Projekts.
Oder wenn jemand fragt.
Das ist ein Fehler.
Dokumentation ist einer der Mechanismen, die das operationelle Risiko begrenzen. Sie erzeugt nicht direkt Umsatz. Sie verbessert nicht die Conversion. Sie sieht auf einer Präsentation nicht spektakulär aus.
Aber in einer Krisensituation kann sie der Unterschied sein zwischen: "wir beheben das heute"
und: "zuerst müssen wir den Menschen finden, der sich erinnert, wie das funktioniert hat".
In den neuen NIST-Leitlinien zu Sicherheits-, Datenschutz- und Lieferketten-Risikomanagementplänen wird die Dokumentation des Zwecks eines Systems, seines Zustands, der Kontrollen sowie der Verantwortlichkeiten und des Verhaltens der Personen, die es verwalten, als Element einer geordneten Systemverwaltung behandelt.
Das zeigt sehr gut den Wandel im Denken.
Dokumentation ist nicht nur ein Werkzeug für Entwickler.
Sie ist ein Element der Geschäftskontinuität einer Organisation.
Was sollte dokumentiert werden?
Es geht nicht darum, eine 800-seitige Dokumentation zu erstellen, die niemals jemand öffnen wird.
Gute Dokumentation sollte vor allem die Fragen beantworten, die dann auftauchen, wenn sich etwas ändert oder nicht mehr funktioniert.
- Wer ist Eigentümer des Systems?
- Wo befindet sich der Code?
- Wo befindet sich die Produktion?
- Wie sieht der Deployment-Prozess aus?
- Welche Umgebungen gibt es?
- Welche kritischen Integrationen gibt es?
- Welche externen Dienste nutzen wir?
- Wer ist ihr Anbieter?
- Welche Verträge und Konten haben wir?
- Wo sind die Schlüssel und Zugangsdaten?
- Wer hat Berechtigungen?
- Wie sieht das Backup aus?
- Wie sieht die Wiederherstellung des Systems aus?
- Welche Open-Source-Komponenten werden verwendet?
- Welche Bibliotheken sind veraltet?
- Was sind die wichtigsten architektonischen Entscheidungen?
- Welche Elemente sind für das Geschäft kritisch?
- Was passiert, wenn ein bestimmter externer Dienst ausfällt?
Das ist keine Dokumentation "für Programmierer".
Das ist eine Landkarte der Abhängigkeiten des Geschäfts von der Technologie.
"Es läuft, also lassen wir es in Ruhe" kann eine Strategie sein. Aber man muss ihren Preis kennen.
Nicht jedes Unternehmen braucht eine Überarbeitung eines alten Systems.
Nicht jedes Legacy-System ist schlecht.
Nicht jeder alte Code muss neu geschrieben werden.
Im Gegenteil - manchmal ist ein stabiles, älteres System eine viel bessere Lösung als eine teure Migration ohne konkreten Grund.
Das Problem ist nicht das Alter des Systems.
Das Problem ist das fehlende Wissen über seinen Zustand.
Wenn wir wissen, wie das System funktioniert, welche Abhängigkeiten es hat, wo die Risiken liegen und wer es warten kann, können wir bewusst entscheiden:
- wir lassen es so,
- wir modernisieren es,
- wir schreiben einen Teil neu,
- wir migrieren es,
- oder wir ändern gar nichts.
Wenn wir das nicht wissen, ist die Entscheidung "wir ändern nichts" keine Strategie.
Es ist eine Wette.
Wie sieht ein Audit eines geerbten Systems aus?
Wenn ein bestehendes System in einen Software House gelangt, sollte der erste Schritt nicht sein: "Lassen wir es neu schreiben." - Zuerst muss man es verstehen.
Ein gutes Audit sollte unter anderem die Anwendungsarchitektur, den Quellcode, die Datenbank, die Infrastruktur, den Deployment-Prozess, Abhängigkeiten, Integrationen, Sicherheit, den Zugriff auf Dienste und die Dokumentation umfassen.
Aber ebenso wichtig ist das Verständnis des Geschäfts;
- Welche Prozesse sind kritisch?
- Welche Funktionen werden täglich genutzt?
- Welche Module sind für den Umsatz verantwortlich?
- Welche Elemente können ohne Konsequenzen abgeschaltet werden?
- Was passiert, wenn eine bestimmte Integration ausfällt?
- Welche Elemente sind am riskantesten?
Erst nach dem Zusammenspiel der technischen und geschäftlichen Perspektive kann man sagen, was wirklich geändert werden muss.
Ein Audit muss nicht mit einer Revolution enden.
Manchmal ist das Ergebnis eines Audits überraschend einfach.
Das System ist in Ordnung, man muss nur:
- Die Dokumentation ergänzen.
- Die Zugriffe ordnen.
- Ein paar Bibliotheken aktualisieren.
- Das Eigentum an Konten übertragen.
- Den Deployment-Prozess beschreiben.
- Monitoring hinzufügen.
- Backups festlegen.
- Eine zweite Person in Bereiche einarbeiten, die nur ein Entwickler kannte.
Und plötzlich verändert sich der Bus Factor von 1 auf 3.
Man muss nicht die ganze Anwendung neu schreiben.
Man muss nicht sieben Jahre Arbeit wegwerfen.
Man muss nicht alles von Grund auf neu bauen.
Manchmal ist das größte Problem nicht die Technologie.
Es ist der fehlende Überblick.
Das System sollte die Menschen überleben, die es geschaffen haben.
Das ist wohl die wichtigste Regel: Ein gutes System sollte in der Lage sein, das Ausscheiden eines Entwicklers zu überstehen.
Es sollte einen Wechsel des Administrators überstehen.
Es sollte einen Wechsel des Software House überstehen.
Es sollte eine Umstrukturierung des Unternehmens überstehen.
Es sollte mehrere Jahre Entwicklung überstehen.
Das bedeutet nicht, dass jeder Programmierer jede Codezeile verstehen muss. Es bedeutet, dass das für den Geschäftsbetrieb kritische Wissen nicht nur im Kopf einer einzigen Person existieren darf.
Denn ein Mitarbeiter kann gehen.
Ein Freelancer kann die Zusammenarbeit beenden.
Eine Agentur kann verschwinden.
Ein Anbieter kann seinen Dienst ändern.
Und das Unternehmen muss trotzdem weiter funktionieren.
Technologie sollte Eigentum der Organisation sein, nicht das Gedächtnis einer einzelnen Person.
Das ist besonders wichtig bei Systemen, die über viele Jahre aufgebaut wurden.
Wenn ein Unternehmen für Software bezahlt, sollte es nicht nur wissen, wo sich der Code befindet.
Es sollte wissen:
- was es besitzt,
- wovon es abhängt,
- wer Zugang hat,
- wer es ändern kann,
- wie man es bereitstellen kann,
- wie man es wiederherstellen kann,
- wie man es an ein anderes Team übergeben kann.
NIST weist in aktuellen Materialien zum Supplier Due Diligence unter anderem auf Herkunft, Resilienz, Cybersicherheitspraktiken und Abhängigkeiten in der Lieferkette hin. Das zeigt eine breitere Richtung: Organisationen sollten immer häufiger nicht nur wissen, wer das System geliefert hat, sondern auch, woraus das System besteht und welche Risiken mit seiner Wartung verbunden sind.
Das ist längst nicht mehr nur ein Thema für die IT-Abteilung.
Das ist ein Thema des Business-Risikomanagements.
Der schlechteste Moment, das eigene System kennenzulernen, ist ein Ausfall
Man kann ein paar Tage für ein Audit aufwenden.
Man kann die Dokumentation ordnen.
Man kann Abhängigkeiten überprüfen.
Man kann die Architektur beschreiben.
Man kann Zugriffe verifizieren.
Man kann festlegen, wer wirklich für die einzelnen Bereiche verantwortlich ist.
Man kann den Bus-Faktor senken.
Oder man kann warten.
Bis zu dem Moment, in dem das System nicht mehr funktioniert.
Dann werden die Fragen genau dieselben sein.
Nur der Druck wird größer sein, die Nutzer werden warten, der Verkauf kann zum Stillstand kommen, und jede Stunde wird Geld kosten.
Deshalb lohnt es sich, sich eine Frage zu stellen, bevor ein Problem auftritt: Wenn morgen die Person verschwände, die Ihr System am besten kennt, wüssten wir dann immer noch, wie wir es betreiben können?
Wenn die Antwort "nein" lautet, bedeutet das noch nicht, dass das System schlecht ist.
Es bedeutet, dass das Unternehmen ein verstecktes Risiko hat, das es bisher nicht aktivieren musste.
Bei Web24 übernehmen wir nicht nur den Code
Die Übernahme eines bestehenden Projekts ist eine völlig andere Aufgabe als der Start eines neuen Systems von Grund auf.
Zuerst muss man verstehen, was bereits existiert.
Was funktioniert.
Was kritisch ist.
Was eine Abhängigkeit ist.
Was das Problem ist.
Was nur ein Überbleibsel früherer Entscheidungen ist.
Und vor allem - wo sich das Wissen befindet, ohne das das System nicht sicher weiterentwickelt werden kann.
Erst dann kann man die weiteren Schritte planen.
Manchmal wird es eine Modernisierung sein.
Manchmal Wachstum.
Manchmal das Ordnen der Infrastruktur.
Manchmal die Übernahme der Wartung.
Und manchmal einfach die Erstellung einer sauberen Systemkarte, für die jahrelang niemand Zeit hatte.
Denn ein verantwortungsbewusstes Softwarehaus sollte keine Technologie bauen, die nur dann funktioniert, wenn die richtige Person am Computer sitzt.
Ein System sollte größer sein als das Gedächtnis einer einzelnen Person.
Und das Unternehmen sollte die Gewissheit haben, dass die Technologie nicht mitgeht, wenn jemand geht.
