Wie man ein Dreirad zum Rennwagen umbaut

Gewisse Leute vergleichen gerne die Softwareentwicklung mit der Automobilproduktion. Dieser Vergleich hinkt auf jedem Bein. Meist wird gefragt, warum sich Software nicht am Fließband herstellen läßt, möglichst von billigen angelernten Kräften. Ein anderer Vergleich dreht sich darum, daß meist fehleranfälligere Software produziert wird wie Automobile (nicht das Automobile nicht fehlerhaft aus der Fabrik kommen würden, ich fahre ein solches Modell).

Bei der Produktion von Software haben wir aber einen Vorteil gegenüber der Automobilproduktion. Wir können mit dem Plan für ein Dreirad anfangen und am Ende doch einen Rennwagen bekommen.

Neue Software

Wenn Software komplett neu erstellt wird, dann werden die Prozesse, die die Software unterstützen soll, bislang vermutlich manuell bewältigt. Man kann jetzt versuchen, eine komplette Lösung, die alle denkbaren Spezialfälle abdeckt, zu entwerfen und umzusetzen. Der Vertrieb wird dafür sein, da so eine Lösung viel Umsatz verspricht. Das Management auf Kundenseite wird möglicherweise auch dafür sein, da anscheinend große Lösungen dem Management besser stehen als pragmatische.

Eine allesumfassende Lösung bedeutet aber eine Reihe von Problemen. Zuerst dauert die Erstellung entsprechend lange. Während dieser Zeit gibt es für die alten Prozesse keinerlei Unterstützung, was Geld kosten dürfte. Die Spezifikation verliert sich oft in den Details, die sich in der Praxis dann oft als irrelevant herausstellen oder ganz anders aussehen. Zuletzt gibt es gewöhnlich auch ein technologisches Risiko. Da sich die Technologie immer noch schnell entwickelt, kann man es sich gewöhnlich nicht leisten, nur auf bewährte und bekannte Komponenten zu setzen. Bei neuen Komponenten ist die Belastbarkeit aber nicht bekannt. Das kann bedeuten, daß die Entwicklung länger als geplant dauert oder daß am Ende die gewünschte Performance und Stabilität nicht zu erreichen ist.

Alternativ kann man das System so konzeptionieren, daß es gut mit manuellen Prozessen zusammenarbeitet. Das empfiehlt sich immer, denn es wird immer Sonderfälle geben, die niemand bedacht hat oder deren Umsetzung in Software einfach zu teuer wäre. Nun kann man sich den Prozeß herauspicken, der bei einer Automatisierung am meisten bringt verglichen zum Implementierungsaufwand und -risiko.

Wenn sich der Ansatz bewährt, kann man so Schritt für Schritt weitermachen. Wenn sich aber unvorhergesehene Probleme auftun, ist es noch nicht zu spät, mit einem anderen Ansatz neu anzufangen.

Die Wahrscheinlichkeit ist hoch, daß man so beginnend von einem ganz einfachen Ansatz (Dreirad) im Laufe der Zeit eine bestens getunete Software bekommt, die Formel 1 Qualitäten besitzt.

Altsysteme

Heutzutage ist es wahrscheinlicher das eine Software erstellt wird, um ein bestehendes System abzulösen anstatt einen manuellen Prozeß. Auch in diesem Fall ist es möglich, schrittweise vorzugehen. Mir fallen da zwei Ansätze ein, wobei das Ergebnis unter Umständen bei beiden Ansätzen ähnlich aussehen kann.

Der erste Ansatz beschäftigt sich mit den Verantwortlichkeiten. Ein System ist gewöhnlich für mehr als eine Sache verantwortlich. Wenn ein kleines Webshopsystem sowohl den Kundenbestand als auch das Lager verwaltet, so läßt sich zuerst eine dieser Verantwortlichkeiten herauslösen. Hierzu muß das Altsystem natürlich soweit angepaßt werden, daß sich die entsprechenden Schnittstellen ergeben.

Der andere Ansatz dreht sich um die Datenhoheit. Daten werden oft in mehreren Systemen gleichzeitig gehalten. Aber eins ist verantwortlich für die Daten. Der Datenbestand in den anderen Systemen stellt im wesentlichen ein Cache dar, um die Zugriffe auf die Originaldaten zu minimieren. Eventuell kommt auch eine geänderte Sichtweise hinzu. Auf jeden Fall lassen sich die Daten aller weiteren System aus denen des Systems mit der Datenhoheit immer wiederherstellen. Was man jetzt tun kann, ist, die Datenhoheit von dem Alt- auf das Neusystem zu verschieben. Dazu muß sichergestellt werden, daß das neue System in jede Datenänderung einbezogen wird. Wenn das neue System über die Daten verfügt, können z.B. alle Schnittstellen, die mit diesen Daten bedient werden schrittweise vom Alt- auf das Neusystem übertragen werden. Zu Beginn hält das Neusystem nur Daten, hat aber noch keine Funktion. Am Ende hat das Altsystem nur noch Daten, die aber dort keiner mehr braucht. Es kann jetzt abgeschaltet werden.

Insbesondere bei dem Ansatz, bei dem die Daten zeitweise doppelt gehalten werden, hat man eine hohe Sicherheit und kann im Prinzip noch lange Zeit den Umstieg wieder rückgängig machen. Das wird erst dann schwierig, wenn sich die Funktionalität im Neusystem fortentwickelt hat und im Altsystem nicht mehr nachgezogen wurde. Zu diesem Zeitpunkt hat sich das Neusystem aber schon bewährt.

Schiefe Metapher

Natürlich ist ein solcher evolutionärer Ansatz nicht in der Softwareindustrie erfunden worden. Wenn man sich z.B. die ersten Automobile anschaut, so erkennt man die Evolution vom Fahrrad und der Kutsche zum Automobil. Das Problem an dem Bild ist, daß die Softwareentwicklung der Entwicklung eines neuen Modells in der Automobilindustrie entspricht. Der Produktionsprozeß in der Automobilindustrie ist am ehesten mit der Installation der fertigen Software zu vergleichen. Das andere Problem ist, daß es sich bei der Software, deren Preis und Risiken diskutiert werden meist um Individualanfertigungen handelt, wo es definitionsgemäß nur wenig Routine gibt.