Um wettbewerbsfähig zu bleiben, stehen Unternehmen vor der Aufgabe neue Produktgenerationen in regelmäßigen Abständen auf den Markt zu bringen, die die Kunden mit neuen Eigenschaften begeistern. Die meisten Produkte haben heutzutage auch eine Softwarekomponente, die bei der Entwicklung eines neuen Produkts parallel zur Hardware modernisiert und verbessert werden muss. Auch bei Produkten, die früher zum größten Teil aus Mechanik bestanden nimmt der Anteil der Software stetig zu und macht einen immer größeren Teil aus, wie die Grafik zeigt (Quelle: Automationspraxis). Bei den meisten Produkten ist heute Innovation überwiegend gekoppelt an Softwarefunktionalität.
Viele Unternehmen stehen in diesem Kontext vor einer schwierigen Entscheidung: Soll die Software von Grund auf neu entwickelt werden, oder kann die alte Softwarearchitektur angepasst werden? Entwicklerteams streben häufig danach den Quellcode, die sogenannte Codebase, komplett neu zu schreiben und die Gelegenheit zu nutzen, eine schlankere Softwarearchitektur für das Produktportfolio zu schaffen und dabei neue Technologien einzubinden. Das Entwickeln einer komplett neuen Softwarearchitektur geht aber auch mit großen Risiken einher. Je nach Größe und Produktpalette des Unternehmens könnte ein Fehlschlag eines solchen Projekts fatale Auswirkungen haben.
Eine mögliche Alternative besteht darin, die Codebase der bestehenden Software “aufzuräumen”, indem man diese modularisiert. Was genau man unter Modularisierung der Softwarearchitektur versteht, welche Vor- und Nachteile das Modularisieren beziehungsweise Neuschreiben der Codebase jeweils hat, und wann es sinnvoll ist, die Softwarearchitektur zu modularisieren, statt von Grund auf neu zu entwickeln, verraten wir Ihnen in diesem Blog-Artikel.
Code neu schreiben: Herausforderungen und Vorteile
Soll eine neue Softwaregeneration eingeführt werden, sehen viele Entwickler darin die Chance, sich von der veralteten und häufig unnötig komplizierten Softwarearchitektur zu verabschieden und stattdessen neu anzufangen. Dabei sollte jedoch bedacht werden, dass das Entwickeln einer völlig neuen Softwarearchitektur eine große Herausforderung darstellt und einige Nachteile mit sich bringt.
Alte Software beinhaltet wichtiges Produktwissen
Im Laufe der Jahre wird der Code einer Software konstant angepasst und verbessert, um auftretende Bugs zu beheben. Neben den ursprünglich geplanten Features werden immer mehr Modifikationen durchgeführt, um die Funktionalitäten zu verbessern, die Stabilität und Qualität zu verbessern und nicht zuletzt, um Sicherheit vor Manipulation zu gewährleisten. Diese Anpassungen werden häufig kurzfristig in Form sogenannter „Hotfixes“ oder „Bugfixes“ umgesetzt. Während die Versionskontrolle bei Software jede dieser Änderungen in der Codebase nachvollziehbar macht, werden die Anforderungen an die Software nicht nachträglich angepasst.
Die Mitarbeiterfluktuation im Unternehmen ist ein weiterer zu beachtender Faktor. Entwickler, die über die Jahre hinweg an der alten Software gearbeitet haben, sind unter Umständen gar nicht mehr im Unternehmen verfügbar. Soll die Software für eine neue Produktgeneration nun komplett neu geschrieben werden, führt das zu folgendem Problem: Bevor mit dem Entwickeln der neuen Software begonnen werden kann, fällt erst einmal ein erheblicher Arbeitsaufwand an, um den in der alten Softwarestruktur versteckten Wert zu extrahieren und das über die Jahre angehäufte Wissen über Features und Modifikationen zusammenzutragen.
Nur so kann sichergestellt werden, dass zum Zeitpunkt der Neuentwicklung alle notwendigen Informationen vorliegen, um beim Neuschreiben alle Erkenntnisse und Verbesserungen in Bezug auf Qualität, Sicherheit und Funktionalitäten, die im Laufe des Betriebs der letzten Produktgeneration in die alte Softwarearchitektur eingearbeitet wurden, in die nächste Generation überführen zu können. Dieser mühsame und zeitaufwändige Schritt wird häufig vernachlässigt oder nur unvollständig durchgeführt, so dass Teile des alten Produktwissens verloren gehen und die Lernkurve, die im Betrieb der letzten Produktgeneration durchlaufen wurde, nicht voll genutzt werden kann.
Chance alten Software-Ballast loszuwerden
Was auf der einen Seite zu Herausforderungen führt, bietet auf der anderen Seite auch Möglichkeiten zur Verbesserung. Eine Software, die über mehrere Jahre in Betrieb war, ist nicht nur “realitätserprobt”, sondern beinhaltet auch viele Komponenten und Elemente, die überflüssig sind. In der Realität kommt es nicht selten vor, dass bestimmte Features entwickelt werden, die dann nie genutzt werden und über den Produktlebenszyklus einfach als unliebsamer Ballast mitgeschleppt werden. Diese blähen den Umfang der Software unnötig auf.
Auch schlecht ausgeführte Modifikationen, die in der Softwarearchitektur versteckt sind, führen dazu, dass das Code-Geflecht unnötig kompliziert ist. Für eine neue Produktgeneration bei Null anzufangen ist vor diesem Hintergrund eine gute Möglichkeit, überflüssige Features und komplizierte Code-Strukturen loszuwerden und die neue Software schlank zu gestalten, was sich letztlich auch positiv auf die Instandhaltung und Aktualisierung der Software auswirkt.
Steigende Kundenanforderungen an die Software führen zu längeren Entwicklungszeiten
Das Kano-Modell zur strategischen Produktplanung auf der Basis von Kundenwünschen beschreibt, wie sich verschiedene Produkteigenschaften auf die Zufriedenheit der Kunden mit dem Produkt auswirken. Das Modell unterscheidet in Bezug auf die Produkteigenschaften zwischen Basismerkmalen und Begeisterungsmerkmalen. Während Basismerkmale solche Eigenschaften sind, die vom Kunden von einem Produkt erwartet werden, umfassen Begeisterungsmerkmale die USPs eines Produkts, die es von anderen (ähnlichen) Produkten abheben. Das Modell berücksichtigt auch die Veränderung der Eigenschaften im Laufe der Zeit. So werden Produkteigenschaften die heute noch außergewöhnlich sind und von der Konkurrenz differenzieren, im Laufe der Zeit zu Basismerkmalen, an die sich die Kunden gewöhnt haben und die auch von der Konkurrenz angeboten werden. Die Grafik stellt den Einfluss der Begeisterungs-, Leistungs- und Basismerkmale auf die Kundenzufriedenheit dar (Quelle: Wikipedia).
Eine neue Produktgeneration muss daher über das Funktionsniveau der letzten Generation hinausgehen. Sie muss die bereits bekannten Eigenschaften bieten und gleichzeitig neue USPs einführen. Diese Zunahme im Funktionsumfang betrifft auch ggf. überwiegend den Softwareanteil des Produkts. Die Software von Grund auf neu zu entwickeln, erlaubt es Ihnen zwar, eine neue und verbesserte Softwarearchitektur zu gestalten und dabei nicht genutzte Funktionen zu entfernen und den Code effizienter zu strukturieren, aber die Implementierung wird einiges an Zeit in Anspruch nehmen. Zeit, die sowohl für die Ausarbeitung der notwendigen Produkteigenschaften als auch für die Entwicklung an sich benötigt wird.
Da die Innovationszyklen am Markt immer kürzer werden, ist gleichzeitig die Zeit, die für die Entwicklung einer neuen Generation zur Verfügung steht, zunehmend knapper. Ein neues Produkt, das in seiner Entwicklung länger braucht als geplant und von der Marktentwicklung überholt wird, läuft Gefahr zum Zeitpunkt der Einführung bereits veraltet zu sein.
Leseempfehlung: Mehr zum Thema Entwicklungszeiten, Variantenvielfalt und Innovationsdruck lesen Sie in unserem Blog-Artikel ”Produktlebenszyklen werden immer kürzer, Ihre Entwicklungszeiten auch?”.
Dass zu lange Entwicklungszeiten dazu führen können, von der Konkurrenz überholt zu werden, zeigt das Beispiel von Netscape. Im Jahr 1997 entschied die Netscape Communications Corporation die Codebase für den Netscape Navigator 6.0 komplett neu zu schreiben, da der alte Code als zu unstrukturiert und die Geschwindigkeit, mit der neue Seiten geladen wurden, als zu gering angesehen wurde. Das Projekt war ein Fehlschlag und der Navigator 6.0 wurde nie fertig ausgereift. Da es dem verfügbaren Navigator 4.0 an Innovationen mangelte, wurde Netscape schließlich von Microsoft mit dem Internet Explorer 6 (IE6) überholt.
Verbesserungspotentiale dank neuer Technologien müssen abgewogen werden
Einer der Hauptgründe, eine neue Software zu entwickeln besteht häufig darin, von neuen Technologien zu profitieren. Diese können es beispielsweise erlauben schneller und effizienter zu entwickeln, vereinfacht neue Funktionalitäten einzubinden oder neue Sicherheitsfunktionen zu ermöglichen. Um den Aufwand einer Neuentwicklung zu rechtfertigen, müssen diese Potentiale überwiegen. Der Vergleichswert ist der Aufwand, den es braucht, um die existierende Softwarearchitektur auf das gewünschte Funktionalitäts- und Leistungsniveau zu bringen.
Dazu müssen die Kosten der Investition mit der geschätzten Lebensdauer der neuen Softwarearchitektur verglichen werden. Als Faustregel gilt hierbei: Kann die Produktivität mit den neuen Tools und Technologien nicht mindestens um das Doppelte gesteigert werden, lohnt es sich nicht, die Software komplett neu zu entwickeln.
Ein gutes Beispiel ist die Ablösung der damaligen Hauptprogrammiersprache Assembly durch die Programmiersprachen C und FORTRAN in den 90er Jahren. Der Wechsel zu C und FORTRAN ermöglichte eine Produktivitätssteigerung auf mindestens das Vierfache, was die Kosten für das Neuschreiben der Software in der neuen, produktiveren Sprache in diesem Kontext gerechtfertigt hat. Da derartige Technologiesprünge heutzutage jedoch selten sind, müssen Unternehmen die mögliche Effizienzsteigerung sorgfältig kalkulieren. Gerade auch vor dem Hintergrund limitierter eigener Ressourcen in einem traditionell Mechatronik lastigen Produktportfolio.
Softwarearchitektur modularisieren statt neuschreiben
Die zweite Möglichkeit, die sich Unternehmen bietet, wenn sie eine passende Software für eine neue Produktgeneration entwickeln wollen, besteht darin, den Code nicht neu zu schreiben, sondern die Struktur der bestehenden Software zu verbessern und so ihre Lesbarkeit, Wartbarkeit und Verwendbarkeit zu optimieren. Im Fachjargon spricht man in diesem Zusammenhang von Refactoring, auch bekannt als Restrukturierung der Software. Beim Refactoring wird der Code einer Software so umstrukturiert, dass er modularer wird. Man könnte also folglich von Softwaremodularisierung sprechen.
So funktioniert die Modularisierung der Softwarearchitektur
Die Kernidee hinter der Modularisierung einer Produktsoftware besteht darin, den existierenden Code “aufzuräumen”, indem verschiedene Features und Micro-Services in einzelne Software-Module verpackt und für neue Produkteigenschaften neue Module hinzugefügt werden. Darin liegt auch der grundlegende Unterschied zu einer monolithischen Softwarearchitektur, bei der alle Funktionen und Features in einem einzigen zentralen System gebündelt werden.
Leseempfehlung: Wie Sie die Kapazitäten Ihres Entwicklerteams während eines Modularisierungsprojekts Ihrer Software am effizientesten einsetzen lesen Sie in unserem Blog-Artikel “Von Hardware-First zu Software-First mit einer modularen Softwarearchitektur”.
Um einen modularen Baukasten für eine Software zu erstellen, müssen die folgenden Schritte durchlaufen werden:
- Komponenten bestimmen: Zu Beginn muss die Software in einzelne Komponenten, beziehungsweise Funktionen zerlegt werden. Die sich hierbei stellende Herausforderung ist die Entscheidung, wie granular oder aggregiert dabei vorgegangen werden soll. In anderen Worten: Wie weit muss ich die Funktionen unterteilen, um daraus später strategisch sinnvolle Module bilden zu können.
- Abhängigkeiten zwischen den einzelnen Komponenten analysieren: Hier geht es darum zu schauen, wie verschiedene Softwarekomponenten miteinander interagieren und welche Schnittstellen bestehen müssen, um die Interaktion und damit das reibungslose Funktionieren der Software zu gewährleisten.
- Komponenten zu Modulen gruppieren: Nach der anfänglichen Zerlegung der Software in einzelne Komponenten, geht es im dritten Schritt darum, die einzelnen Elemente sinnvoll zu Softwaremodulen zu gruppieren. Bei einem Software Modul handelt es sich um einen eigenständigen Teil des Codes, der separat entwickelt und flexibel in verschiedenen Systemen eingebaut werden kann. Beim Definieren strategischer Softwaremodule gilt es darauf zu achten, dass verschiedene Softwarefunktionen so in Modulen gruppiert werden, dass nachträgliche Änderungen der Funktionsweise jeweils nur ein Modul betreffen.
Leseempfehlung: Einen tieferen Einblick in das Definieren passender Module für Ihren modularen Baukasten gibt Ihnen unser Blog-Artikel “Mehr als nur geometrische Module: Warum Strategie im Baukasten wichtig ist”.
Welche Vorteile bietet eine modulare Softwarearchitektur?
Die Softwarearchitektur zu modularisieren, statt neu zu schreiben bringt eine ganze Reihe an Vorteilen mit sich, sowohl was die Struktur und Übersichtlichkeit als auch die Entwicklung und Aktualisierung der Software angeht. So wird die Codebase insgesamt schlanker, da Funktionalitäten, die vorher an mehreren Stellen unabhängig voneinander verankert waren, in ein gemeinsames Softwaremodul überführt werden, welches dann an entsprechender Stelle eingesetzt werden kann. Auch das Durchführen von Updates wird einfacher, da Aktualisierungen jeweils nur bestimmte Softwaremodule betreffen, während die anderen Module dank der standardisierten Schnittstellen von den Änderungen unberührt bleiben. Updates und neue Funktionen können so auch für bereits ausgelieferte Produkte nachträglich noch zur Verfügung gestellt werden.
Sind die einzelnen Funktionen und Features erst einmal in Softwaremodulen gebündelt, ist es außerdem recht einfach, verschiedene Versionen der Software für unterschiedliche Produkttypen zu entwickeln. Hierzu genügt es, die gewünschten Module auszuwählen und zu kombinieren. Das Gleiche gilt für das Entwickeln neuer Funktionen, die jeweils in Form eines neuen Softwaremoduls hinzugefügt werden können. Wenn neue Features keine aufwendigen Änderungen im zentralen Softwaresystem erfordern, sondern lediglich als Zusatzbausteine ins modulare System eingefügt werden müssen, bietet das viel Spielraum für Innovation und Entwicklung.
Zudem verkürzt eine modulare Softwarearchitektur die Entwicklungszeiten, und dass in zweierlei Hinsicht. Zum einen sind neue Produktgenerationen schneller verfügbar, weil parallel zur Restrukturierung der Codebase in Module, bereits die neuen Funktionalitäten entwickelt werden können. Zum anderen steigert Modularisierung die Effizienz und Qualität der Softwaretests, indem zum Beispiel eine frühzeitige Fehlererkennung durch Testautomatisierung möglich wird.
Ein weitere Vorteil der Modularisierung der Softwarearchitektur, ist das im Vergleich zum Neuschreiben der Codebase verminderte Risiko eines Fehlschlags. Die Modularisierung kann Schritt für Schritt erfolgen und die Software bleibt während des Prozesses weiterhin funktional. Dank der schrittweisen Vorgehensweise können mögliche Fehler zudem meist schnell ausfindig gemacht und behoben werden.
Wie bei der Modularisierung von Hardware muss auch bei der Modularisierung der Software der Einfluss von Funktionalitäten, Kundenbedürfnissen und Unternehmensstrategie berücksichtigt werden. Weder eine monolithische Software noch eine Zerlegung in die kleinstmöglichen Module ist sinnvoll, da jede Schnittstelle zwischen Modulen auch verwaltet werden muss.
Leseempfehlung: Erfahren Sie mehr über die richtige Größe von Modulen und die Vorteile von Modularisierung in der Softwareentwicklung in unserem Blogartikel “Erhöhte Qualität und Effizienz in der Softwareentwicklung durch Modularisierung”.
Modularisierung der Softwarearchitektur: In den meisten Fällen die bessere Option
Zu Beginn des Artikels haben wir die Frage aufgeworfen, ob es sinnvoller ist, bei der Entwicklung einer neuen Produktgeneration die notwendige Software komplett neu zu schreiben oder zu modularisieren. Wie wir bei der Betrachtung der jeweiligen Vor- und Nachteile gesehen haben, hängt diese Entscheidung von mehreren Faktoren ab. Nur in wenigen Fällen, wenn signifikante Veränderungen bei Technologie und Funktionalitäten umgesetzt werden sollen, lohnt es sich, die Softwarearchitektur von Grund auf neu zu entwickeln. In den meisten Fällen ist es effizienter und mit weniger Risiko verbunden, die existierende Software zu modularisieren. Dies auch im Hinblick eigener, meist stark limitierten Kapazität an Softwareentwicklern.
Eine bereits bestehende Software von Grund auf neu zu schreiben, geht mit einem hohen finanziellen Risiko einher. Große Unternehmen wie Apple, Google und Microsoft verfügen über die finanziellen Ressourcen, um einen solchen Misserfolg abzufedern, und sind auch nicht auf ein einziges Produkt angewiesen, um ihre Rentabilität zu erhalten. Für Unternehmen, auf die das nicht zutrifft, ist es sinnvoller, stattdessen die Modularisierung ihrer Software in Betracht zu ziehen. Der Aufbau einer modularen Softwarearchitektur ist der schnellste und sicherste Weg, die Verbesserung der Software in Profit umzuwandeln. Die einzelnen Softwaremodule können Schritt für Schritt entwickelt werden, und ein modulares Baukastensystem für die Software ist ein wertvolles Asset, das Ihrem Unternehmen auch in der Zukunft dabei helfen kann, profitabel zu bleiben.
Ein zentrales Element auf dem Weg zu einer modularen Softwarearchitektur ist das Festlegen und Dokumentieren der einzelnen Module. Eine Vorlage zur Dokumentation der einzelnen Module Ihrer Software können Sie sich hier kostenlos herunterladen.
