Releasewechsel: was an einer gewachsenen Automatisierung bricht

Ein Releasewechsel ist der Sprung einer Software auf eine neue Version, eingespielt vom Hersteller, vom Rechenzentrum oder automatisch über Nacht. Für das Programm selbst ist das ein geplanter Vorgang. Für die Automatisierungen, die von außen daran hängen, ist es der Moment, in dem sie ohne Vorwarnung stehen bleiben.

Releasewechsel: warum eine Automatisierung ihn spürt

Eine gewachsene Automatisierung greift dort an, wo sie hinkommt: an der Eingabemaske, am Export, an einem Ablageort, an einer Datenbanksicht. Keine dieser Stellen ist ein Versprechen des Herstellers. Er darf die Maske umbauen, eine Spalte umbenennen, ein Format ablösen; für die Anwender ist das eine Verbesserung, für ein Skript ein Abbruch. Je weniger eine Lösung über einen vereinbarten Zugang läuft, desto größer die Fläche, die ein Versionssprung treffen kann.

Sechs Stellen, an denen es bricht

• Eingabemaske und Feldreihenfolge. Ein Roboter, der Felder nach ihrer Position anspringt, füllt nach einem Umbau das falsche Feld und meldet nichts, weil er formal gearbeitet hat. Das ist die bekannte Schwäche der Oberflächenautomatisierung.
• Umbenanntes Exportfeld. Die Auswertung sucht eine Spaltenüberschrift, die es nicht mehr gibt, und liefert leere Werte statt einer Fehlermeldung.
• Neues Dateiformat, andere Zeichenkodierung. Trennzeichen, Datumsformat, Umlaute: Die Datei sieht aus wie immer und wird trotzdem falsch gelesen.
• Verschärfte Rechte. Das technische Konto verliert eine Berechtigung, der nächtliche Export schreibt in ein leeres Verzeichnis.
• Abgeschaltete Altfunktion. Der Hersteller entfernt einen alten Berichtsweg, den eine Tabelle seit Langem anzapft.
• Geänderte Anmeldung. Kommt ein zweiter Faktor hinzu, endet jeder Ablauf, der sich mit Kennwort angemeldet hat. Ein Code auf dem Telefon eines Beschäftigten lässt sich nicht automatisieren; der Weg über ein technisches Benutzerkonto muss vorher eingerichtet sein.

Warum der Schaden spät auffällt

In einem Haus mit eigener Entwicklung liest jemand die Versionshinweise des Herstellers, weil es zu seiner Arbeit gehört. Ohne eigene Entwicklung liest sie niemand: Der Hersteller schickt sie an eine Sammeladresse, der Dienstleister, der den Roboter eingerichtet hat, antwortet nicht mehr, und die Kollegin, die das Makro geschrieben hat, ist nicht mehr im Haus.

Dazu kommt die Art des Fehlers. Ein abgestürztes Programm fällt sofort auf. Eine Automatisierung, die leere Werte überträgt oder einen Vorgang überspringt, arbeitet scheinbar weiter. Bemerkt wird das im Monatsbericht, in einer Mahnung oder bei der Inventur, also an einer Stelle, an der niemand an die neue Version denkt. Die Suche beginnt dann bei den Daten statt bei der Ursache, und genau das macht sie teuer.

Vorbereitung auf den nächsten Versionssprung

Vorbereitung heißt hier vor allem, aufzuschreiben, was voneinander abhängt.

• Abhängigkeitsliste. Welche Automatisierung hängt an welchem Programm, an welcher Version, an welchem Konto, an welchem Verzeichnis. Eine Seite genügt, solange sie stimmt.
• Eine Kopie zum Ausprobieren. Ein Testmandant oder eine Kopie des Systems, in der die neue Version zuerst läuft.
• Probelauf vor dem Umschalten. Alter und neuer Stand rechnen nebeneinander, die Unterschiede werden gelesen. Das passende Verfahren dafür ist der Schattenbetrieb.
• Ein Ersatzweg von Hand. Für das Fenster nach der Umstellung ist benannt, wer den Vorgang notfalls manuell erledigt.
• Ein Leser der Herstellerhinweise. Eine Person im Haus sichtet die Ankündigungen und legt die Abhängigkeitsliste daneben.

Oberfläche oder Schnittstelle: was einen Releasewechsel übersteht

Wo ein Hersteller eine dokumentierte Schnittstelle anbietet, hält er sie in der Regel stabil und kündigt Änderungen an; dafür ist sie da. Die Oberfläche darf sich dagegen jederzeit ändern, sie ist für Menschen gebaut. Eine Anbindung über die Schnittstelle übersteht den Sprung auf eine neue Version deshalb deutlich häufiger als ein Weg über den Bildschirm. Beim Umbau einer gewachsenen Automatisierung lohnt es sich daher, zuerst zu prüfen, ob ein offizieller Zugang existiert. Existiert keiner, bleibt der Bildschirmweg zulässig, braucht aber nach jeder neuen Version eine Prüfung, und dieser Aufwand gehört in die Planung.

Vertraglich verläuft hier ebenfalls eine Grenze. Ob ein Stillstand nach einer neuen Version ein Fall für die Mängelhaftung ist, entscheidet die vereinbarte Beschaffenheit. Eine Lösung, die für eine bestimmte Programmversion abgenommen wurde, ist nicht mangelhaft, weil der Hersteller später etwas anderes ausliefert; die Anpassung an die neue Version ist neue Arbeit und wird als solche beauftragt.

Wie wir Abhängigkeiten festhalten

Wenn wir eine vorhandene Automatisierung übernehmen, steht die Abhängigkeitsliste am Anfang und nicht am Ende: welches Programm, welche Version, welches Konto, welcher Weg hinein und hinaus. Wo ein offizieller Zugang existiert, wird der Bildschirmweg darauf umgestellt; wo keiner existiert, wird die verbliebene Stelle benannt und der Prüfschritt nach einer Aktualisierung beschrieben. Was geprüft wird und woran der Auftraggeber das Ergebnis misst, steht vor dem Start im Angebot; die Arbeit selbst steuert unsere Projektleitung. Wie wir einen ganzen Bestand solcher Abhängigkeiten übernehmen, steht unter Prozessautomatisierung im Bestand.