Wir alle haben sie schon gehört, die einfachste Anforderung der Welt:

Diese Anforderung hört sich zunächst plausibel an. Sie tritt fast immer auf, wenn Unternehmen aus folgenden Gründen ein Softwaresystem modernisieren oder erneuern müssen:

• „Wir machen jetzt Microservices!“
  Ein neues vielversprechendes Architekturparadigma soll verfolgt werden
• „Finger weg! Keiner weiß was passiert, wenn wir das anfassen!“
  Niemand traut sich mehr, bestimmte Teile des Systems überhaupt noch zu ändern
• „Das zahlt uns doch kein Kunde!“
  Eine unzureichende Wartbarkeit macht Änderungen viel zu teuer
• „Wir gehen jetzt in die Cloud!“
  Ein neues Geschäftsmodell soll verfolgt werden
• „Silverlight ist tot!“
  Eine bisher eingesetzte Technologie wird abgekündigt
• „So wie bei Apple!“
  Das User Interface soll moderner werden
• „Unser Vertrieb braucht jetzt auch Apps!“
  Neue Interaktionsgeräte sollen genutzt werden

In allen diesen Fällen scheint es zunächst plausibel, dass das modernisierte oder erneuerte Softwaresystem das Gleiche können soll wie das alte. Schließlich ändern sich nicht die Features, sondern nur die Architektur (die ersten fünf Fälle) oder die User Experience (die letzten vier Fälle).

Schauen wir uns die Fälle also genauer an:

Die Architektur soll sich ändern: Das Softwaresystem ist offensichtlich schon älter! Das heißt, dass seit dem Zeitpunkt der ursprünglichen Konzeption schon einiges an Zeit vergangen ist. In dieser Zeit wurden viele Ergänzungen und Änderungen umgesetzt. Jede dieser Ergänzungen und Änderungen wurde mit Rücksicht auf den jeweiligen Zustand des Systems oder die Situation des Unternehmens durchgeführt:

• „Das haben wir auf die Schnelle mal reingebaut!“
• „Das sollte eigentlich nie so lange drin bleiben!“
• „Das benutzt schon seit Jahren keiner mehr, aber die Entfernung ist zu riskant!“
• „Wir mussten damals auf vorhandene Features Rücksicht nehmen: Hätten wir die Freiheit gehabt, hätten wir es ganz anders gemacht!“

Offensichtlich wurden in der Lebenszeit des Systems (oft aus guten Gründen) viele Kompromisse eingegangen, die sich im heutigen System widerspiegeln. Diese Kompromisslösungen wollte eigentlich niemand haben und somit ist auch das System nicht so, wie man es eigentlich haben wollte. Wird das System jetzt massiv modernisiert oder gar erneuert (wie es für eine Architekturänderung nötig ist), dann ist es offensichtlich, dass das neue System gerade nicht das Gleiche machen soll wie das alte.

Anforderungen im Lebenszyklus eines Softwaresystems

Die User Experience soll sich ändern: Hier geht es gerade darum, das System anders zu benutzen als zuvor.

• „Es soll einfacher zu benutzen sein!“
• „Es soll nicht mehr so kompliziert sein!“
• „Wir benutzen nur 15% der Features!“
• „Es sieht noch aus wie in den 80ern!“
• „Auf meinem iPad geht alles einfacher!“

Der Wunsch nach veränderter Benutzung führt immer dazu, dass sowohl Interaktionsdesign als auch visuelles Design massiv überarbeitet werden müssen. Deshalb ist es offensichtlich, dass das neue System gerade nicht das Gleiche machen soll wie das alte. Eine massive Überarbeitung des Interaktionsdesigns oder der Einsatz einer neuen Client-Plattform (z.B. Mobile statt Desktop) führt so gut wie immer auch zu einer Anpassung der darunterliegenden Architektur und damit zu noch mehr Aufwand.

Sowohl für die Veränderung der Architektur als auch der User Experience stellen wir somit fest:

• Die Veränderungen führen zu massivem Aufwand!
• Das neue System soll gerade nicht das Gleiche machen wie das alte!

Die einfachste Anforderung der Welt ist somit unsinnig und führt immer zu stark unterschätztem (und auch unnötigem) Aufwand für die Rekonstruktion aller alten Anforderungen, da diese natürlich nie konsistent und vollständig dokumentiert sind. Dennoch hören wir diese Anforderung immer wieder. Und warum? Weil sie so einfach zu formulieren ist, und zwar von jedem, egal wie gut er das System kennt.

Trotzdem hat diese Anforderung auch einen wahren Kern. Natürlich muss man für eine Modernisierung oder Erneuerung viele der alten Anforderungen wieder rekonstruieren und berücksichtigen, aber eben nicht pauschal alle.

Den signifikanten Einfluss, den ein Technologiewechsel sowohl auf die Architektur eines Systems, als auch auf die User Experience hat, zeigt das Evolutionsbeispiel der Nikon F100 Spiegelreflex-Kleinbildkamera zur Nikon D100 Spiegelreflex-Digitalkamera. Eine neue Technologie eröffnet oft auch neue Möglichkeiten (hier z.B. die Vorschaufunktion am eingebauten Monitor) und macht bisherige Funktionen überflüssig (hier z.B. das Zurückspulen eines Films).

Die Kunst liegt nun genau darin, die Unterscheidung zu treffen, welche Anforderungen vom alten System noch gebraucht werden und welche nicht. Der Ansatz, um auf die zukünftigen Anforderungen zu kommen, besteht gerade nicht darin, zunächst alle alten Anforderungen genau zu erheben und dann die irrelevanten wieder zu streichen. Stattdessen empfehlen wir, die Hauptanforderungen konstruktiv aus der intendierten Benutzung abzuleiten und nicht aus den Features des alten Systems. Dies ist die neue Grundlage für die zukünftige Architektur des Systems. Auf diesem stabilen Fundament kann dann das neue System aufgebaut werden. Bei bestätigtem Bedarf können Detailfeatures aus dem alten System konsistent ergänzt werden.

Wir haben gezeigt, dass die Modernisierung oder Erneuerung eines Systems für eine Verbesserung der Architektur und der User Experience IMMER zu hohem Aufwand führt und das neue System NIE das Gleiche machen soll wie das alte. Wer also diesen hohen Aufwand auf sich nimmt, sollte bei einer Modernisierung oder Erneuerung NIE versuchen, die gleichen Anforderungen wie vorher umzusetzen.

Vortragsvideo zum Thema

Wir hatten einen Vortrag zu diesem Thema auf der OOP 2021 Konferenz, die leider nur digital stattgefunden hat. Alle Vortragenden sollten ein Backup-Video erstellen, für den Fall, dass es beim Live-Vortrag Probleme geben sollte. Bei uns hat aber live alles geklappt. Wir wünschen dir jetzt viel Spaß beim (Backup-)Vortrag.

Lass uns gerne einen Kommentar da, wie dir der Vortrag oder der Artikel gefallen hat.

[Wir hatten diesen Beitrag schon einmal in unserem alten, nicht mehr existierenden, Blog veröffentlicht. Er bildet die Grundlage für unseren Artikel im JavaSPEKTRUM 6/2021, Seite 34ff. „Das neue System muss aber das Gleiche können wie das alte!“ – Software richtig modernisieren .]