Softwareentwicklung ist ein Zyklus – und kein einmaliges Projekt

Software entsteht selten nach dem einfachen Muster: Anforderungen definieren, programmieren, fertig. Besonders bei geschäftskritischen Anwendungen ist Entwicklung ein kontinuierlicher Zyklus. Neue Anforderungen entstehen, gesetzliche Vorgaben ändern sich, Schnittstellen kommen hinzu, Technologien entwickeln sich weiter und bestehende Prozesse werden angepasst.

Für Entscheidungsträger ist deshalb weniger wichtig, jede technische Methode im Detail zu kennen. Entscheidend ist zu verstehen, wie Änderungen kontrolliert von einer Geschäftsidee bis in den produktiven Betrieb gelangen – und welche Risiken auf diesem Weg beherrscht werden müssen.

Unabhängig davon, ob klassisch, agil oder in einer Mischform gearbeitet wird, durchläuft professionelle Softwareentwicklung im Wesentlichen immer dieselben Schritte.

Am Anfang sollte nicht die technische Lösung stehen, sondern die Frage:
Welches Problem soll gelöst oder welcher Nutzen erreicht werden?
Das kann beispielsweise eine Prozessautomatisierung, eine neue gesetzliche Anforderung, eine bessere Benutzerführung oder die Ablösung einer veralteten Schnittstelle sein. Bereits hier sollte geklärt werden, woran später erkennbar ist, ob die Änderung erfolgreich war. Eine unklare Zielsetzung führt fast zwangsläufig zu unnötigem Entwicklungsaufwand.

Nun wird untersucht, was die gewünschte Änderung tatsächlich bedeutet. In einer bestehenden IT-Landschaft ist dieser Schritt besonders wichtig. Eine scheinbar kleine Änderung kann Auswirkungen auf Programme, Datenbanken, Schnittstellen, Batchverarbeitungen, externe Systeme oder nachgelagerte Auswertungen haben.

Zur Analyse gehören unter anderem:
* betroffene Geschäftsprozesse
* bestehende Programme und Komponenten
* Daten und Datenflüsse
* Schnittstellen
* Abhängigkeiten zu anderen Systemen
* Sicherheits- und Berechtigungsanforderungen
* regulatorische Vorgaben

Eine gute Analyse beantwortet deshalb nicht nur die Frage „Was müssen wir ändern?“, sondern ebenso „Was könnte davon betroffen sein?“.

Erst danach wird entschieden, wie die Anforderung technisch umgesetzt werden soll. Dabei geht es beispielsweise darum, ob bestehende Komponenten erweitert, neue Module erstellt, Schnittstellen angepasst oder Funktionen in andere Systeme verlagert werden.

Eine technisch elegante Komplettlösung kann attraktiv erscheinen. In einer gewachsenen Unternehmensumgebung ist eine gezielte Erweiterung eines stabilen Systems jedoch häufig wirtschaftlicher und risikoärmer.

In dieser Phase erfolgt die eigentliche Programmierung beziehungsweise Konfiguration. Professionelle Entwicklung bedeutet dabei mehr als das Schreiben von Programmcode. Änderungen sollten nachvollziehbar dokumentiert, versioniert und möglichst klar von anderen Änderungen getrennt werden. Dadurch bleibt später erkennbar, warum eine Änderung vorgenommen wurde und welche Komponenten davon betroffen sind.

Eine Änderung ist nicht abgeschlossen, wenn sie technisch funktioniert.
Sie ist abgeschlossen, wenn nachgewiesen wurde, dass sie:
* die neue Anforderung korrekt erfüllt
* bestehende Funktionen nicht unbeabsichtigt verändert
* mit realistischen Daten funktioniert
* Fehlerfälle korrekt behandelt
* unter den erwarteten Betriebsbedingungen stabil läuft

Gerade der zweite Punkt wird häufig unterschätzt. Ein neues Feld, eine zusätzliche Schnittstelle oder eine geänderte Berechnungslogik kann vollkommen korrekt funktionieren und trotzdem an einer anderen Stelle einen unerwünschten Effekt auslösen. Deshalb gehören Regressionstests, also Tests bestehender Funktionen nach einer Änderung, zu den wichtigsten Instrumenten bei der Weiterentwicklung bestehender Systeme.

Nach erfolgreichem Test wird die Änderung produktiv gesetzt.

Auch dies sollte ein kontrollierter Prozess sein. Je nach Kritikalität gehören dazu beispielsweise:
* ein definiertes Einführungsfenster
* Datensicherungen
* Migrationsschritte
* Kontrollprüfungen unmittelbar nach der Einführung
* ein Rückfallplan

Die entscheidende Frage lautet: Was tun wir, wenn die neue Version wider Erwarten nicht funktioniert? Diese Frage sollte vor der Einführung beantwortet sein – nicht danach.

Mit der Produktivsetzung beginnt der nächste Teil des Zyklus. Das Verhalten der Anwendung wird beobachtet, Rückmeldungen werden ausgewertet und neue Anforderungen entstehen. Damit beginnt der Entwicklungszyklus erneut. Softwareentwicklung ist deshalb keine gerade Linie mit einem endgültigen Endpunkt, sondern ein Kreislauf.

Unter dem Begriff Softwareentwicklung werden sehr unterschiedliche Aufgaben zusammengefasst:

Bei einer vollständigen Neuentwicklung besteht zunächst eine grosse gestalterische Freiheit. Architektur, Technologien und Datenmodelle können weitgehend neu definiert werden. Das klingt ideal, birgt aber ein anderes Risiko: Bestehende Systeme enthalten häufig jahrzehntelang gewachsenes Fachwissen, das nicht vollständig dokumentiert ist. Bei einer Ablösung darf deshalb nicht nur untersucht werden, was das alte System technisch macht. Es muss verstanden werden, warum es dies macht.

In vielen Unternehmen ist dies der Normalfall. Ein bestehendes ERP-, Finanz-, Produktions- oder Branchensystem wird um neue Funktionen erweitert. Hier liegt die Herausforderung weniger in der neuen Funktion selbst als in ihrer Integration in die bestehende Landschaft. Stabilität und Kompatibilität sind häufig wichtiger als die Verwendung der neuesten Technologie.

Bei einer Modernisierung bleibt die fachliche Funktion teilweise oder vollständig bestehen, während technische Komponenten erneuert werden.

Typische Beispiele sind:
* neue Benutzeroberflächen
* neue Schnittstellen
* Modernisierung bestehender Programme
* Austausch technischer Komponenten
* schrittweise Ablösung alter Module

Eine Modernisierung muss deshalb nicht bedeuten, ein bewährtes System komplett zu ersetzen. Oft ist die schrittweise Modernisierung die sicherere und wirtschaftlichere Strategie.

Auch die Behebung eines Fehlers ist Softwareentwicklung. Dabei unterscheidet man beispielsweise zwischen der Korrektur eines Fehlers, der Anpassung an eine veränderte Umgebung und der vorsorglichen Verbesserung eines Systems, um zukünftige Probleme zu vermeiden.

Kaum eine Unternehmensanwendung arbeitet heute vollständig isoliert. CRM, ERP, Webanwendungen, Banken, Zahlungsdienstleister, Behörden, Logistiksysteme oder Cloud-Dienste tauschen Daten aus. Deshalb besteht ein zunehmender Teil der Softwareentwicklung nicht aus dem Bau neuer Anwendungen, sondern aus der kontrollierten Verbindung bestehender Systeme.

Neben der Art der Entwicklung unterscheiden sich auch die Vorgehensmodelle. Beim klassischen Vorgehen werden Anforderungen zunächst möglichst vollständig definiert, danach folgen Design, Entwicklung, Test und Einführung. Das funktioniert gut, wenn Anforderungen stabil sind und Änderungen sorgfältig geplant werden müssen. Agile Verfahren arbeiten dagegen mit kleineren Entwicklungsschritten. Anforderungen werden priorisiert, umgesetzt, überprüft und anschliessend weiterentwickelt. Dadurch kann schneller auf neue Erkenntnisse reagiert werden. In komplexen Unternehmenslandschaften ist häufig eine hybride Vorgehensweise sinnvoll. Die Gesamtarchitektur, Sicherheitsanforderungen und wesentliche Abhängigkeiten werden sorgfältig geplant. Die eigentliche Umsetzung erfolgt anschliessend in überschaubaren, kontrollierbaren Schritten. - "Agil" darf dabei nicht als "ungeplant" verstanden werden.

Bei einem Neubau kennt man die Komponenten, die gerade entwickelt werden. Bei einer seit Jahren oder Jahrzehnten gewachsenen IT-Landschaft sieht dies anders aus. Programme rufen andere Programme auf. Daten werden nachts verarbeitet. Dateien werden an externe Partner übertragen. Benutzer haben individuelle Arbeitsweisen entwickelt. Historische Sonderfälle existieren, deren ursprünglicher Entwickler das Unternehmen vielleicht längst verlassen hat.

Das grösste Risiko einer Änderung ist deshalb oft nicht das, was man kennt, sondern das, was man übersehen hat. Vor grösseren Veränderungen sollte deshalb eine möglichst vollständige Landkarte der betroffenen Systeme erstellt werden:
Geschäftsprozess → Anwendung → Programme → Daten → Schnittstellen → abhängige Systeme
Je kritischer die Anwendung, desto wichtiger ist dieses Wissen.

Ein Programm oder Datenfeld wird an anderer Stelle verwendet, ohne dass dies ausreichend dokumentiert ist.
Gegenmassnahme: Abhängigkeitsanalyse, technische Analyse bestehender Programme und Regressionstests.

Alte Anwendungen enthalten Regeln, deren Hintergrund kaum noch bekannt ist.
Gegenmassnahme: Bestehendes Verhalten analysieren und mit Fachbereichen sowie erfahrenen Mitarbeitern verifizieren, bevor es ersetzt wird.

Je mehr Komponenten gleichzeitig geändert werden, desto schwieriger ist die Ursache eines Fehlers zu finden.
Gegenmassnahme: Modernisierung in kontrollierbare Etappen aufteilen.

Programme können erneut installiert werden. Fehlerhaft migrierte Geschäftsdaten sind wesentlich problematischer.
Gegenmassnahme: Migration mehrfach testen, Mengen und Kontrollsummen vergleichen und einen Fall-Back definieren.

Zeitdruck führt gelegentlich dazu, dass Tests verkürzt oder gar ganz weggelassen werden. Damit wird jedoch lediglich Zeit vom Projekt in die spätere Störungsbehebung verschoben – meist zu erheblich höheren Kosten.

Eine neue Technologie ist nicht automatisch eine bessere Lösung. Sie sollte gewählt werden, weil sie ein konkretes Problem löst – nicht weil sie moderner ist und schöner aussieht.

Die wichtigste Erkenntnis für die Weiterentwicklung einer bestehenden IT-Landschaft lautet deshalb:
Nicht jede alte Anwendung ist schlecht und nicht jede neue Technologie ist automatisch besser.
Unternehmenskritische Systeme stellen häufig einen erheblichen Wert dar. In ihnen stecken nicht nur Programme und Daten, sondern Geschäftsregeln, Prozesswissen und jahrelange Erfahrung.
Eine nachhaltige IT-Strategie unterscheidet deshalb zwischen Komponenten, die ersetzt werden müssen, solchen, die modernisiert werden sollten, und solchen, die weiterhin zuverlässig ihren Zweck erfüllen.
Der beste Entwicklungsprozess ist nicht derjenige mit den meisten Methoden oder den neuesten Technologien.
Es ist derjenige, der Veränderungen verständlich, kontrollierbar, testbar und reversibel macht. Denn professionelle Softwareentwicklung bedeutet nicht, Veränderungen zu vermeiden. Sie bedeutet, Veränderungen so zu beherrschen, dass aus technischer Weiterentwicklung ein kalkulierbarer geschäftlicher Nutzen entsteht.