Viele Unternehmen kämpfen mit Effizienzverlusten bei der Software-Entwicklung. Dieser Artikel analysiert die Ursachen und zeigt, wie Unternehmen durch das Überführen ihrer Softwareprodukte in modulare Softwareplattformen effizienter arbeiten und Entwicklungskosten in der frühen Phase senken können.
Bei der Entwicklung von Software-Produkten entstehen Kosten entlang des gesamten Prozesses: Bei der Erstellung des Codes, beim Testen der entwickelten Programme und bei Support und Maintenance von Software-Versionen im Feld.
Besonders bei der Erstellung des Codes wird oft Zeit und Geld verschenkt. So werden beispielsweise ähnliche Technologien für verschiedene Teilsysteme entwickelt, Entwickler arbeiten langsamer durch den Effekt des so genannten „Task Shiftings“, und Code, der günstiger zugekauft werden könnte, wird in aufwändigen Prozessen intern geschrieben und getestet.
Dieser Artikel beleuchtet die Herausforderungen von Entwicklungsteams in der frühen Phase der Software-Entwicklung, identifiziert die Ursachen für Effizienzverluste und zeigt wie der Einsatz einer modularen Softwarearchitektur gemäß der Modular Function Development (MFD)-Methode zu enormen Kosteneinsparungen beitragen kann.
Die Entwicklungskosten machen einen großen Teil der Softwarekosten aus. Deshalb sollten wertvolle Entwicklungsressourcen sinnvoll eingesetzt werden, um die Effizienz der Entwicklungsprozesse zu erhöhen.
Leseempfehlung: Erfahren Sie in diesem Blogartikel, was die wichtigsten Kostentreiber bei der Softwareentwicklung sind und wie diese beeinflusst werden.
Eine modulare Softwarearchitektur ist hier der Schlüssel. Sie ermöglicht die Wiederverwendung von Code, schnellere Feedbackschleifen, klare Sourcing-Entscheidungen und Transparenz über die Auswirkung von Hardware-Änderungen.
Dafür kann es viele Gründe geben. Sie reichen vom Silodenken in der Forschung und Entwicklung über sich überschneidenden Technologien nach einer Unternehmensfusion bis hin zu einer opportunistischen Entwicklungsweise eines Start-ups, bei der neue Technologien schnell übernommen werden, ohne sich Gedanken über die Ablösung der alten zu machen.
Bei der Entwicklung einer modularen Softwarearchitektur sollten sich überschneidende technische Lösungen aufgedeckt und hinterfragt werden. Die Grundannahme ist, dass eine Anforderung nur eine Lösung erfordert.
Ein weiterer Aspekt, den es bei der Arbeit mit der Softwaremodularisierung zu analysieren gilt, ist die Entwicklungsgeschwindigkeit der verschiedenen verwendeten Technologien. Unternehmen müssen sich auf den Wechsel von Technologien mit kurzen Entwicklungszyklen, wie zum Beispiel Large Language Models (LLMs), vorbereiten, damit die Produktarchitektur zum Beispiel ihres virtuellen Assistenten schnell und einfach modernisiert werden kann.
Um Produkte erfolgreich in modulare Produktplattformen zu überführen, setzen Unternehmen auf Modular Function Deployment (MFD). Dieses Vorgehen unterteilt Module in drei Gruppen. Aus Ihnen lassen sich Strategien zur Wiederverwendung von Code ableiten. So gibt es Module, die unter starkem Einfluss wechselnder Kundenbedürfnisse stehen (siehe in der Abbildung „Kundennähe“). Es wäre falsch, sich hier zu sehr auf die Wiederverwendung von Code zu konzentrieren, da es wichtiger ist, schnell zu sein und viele der Ideen der agilen Entwicklung zu nutzen. Technologien, die sich schnell entwickeln und bei denen große Teile des Codes regelmäßig verändert werden, sollten strategisch in "Produktführerschaft"-Module gebündelt werden. Dieser Ansatz legt zwar Wert auf die Wiederverwendung von Code, zielt aber in erster Linie darauf ab, die Entwicklung und Bereitstellung zu beschleunigen. Den höchsten Grad an Wiederverwendung ermöglichen die „Operative Exzellenz“-Module. Sie basieren auf Technologien, die in einem langsamen Rhythmus gewartet werden können und verfügen über stabile Schnittstellen. Sie bilden die Grundlage für die modulare Plattform. Durch den einfachen Einsatz von Frameworks zur Testautomatisierung können enorme Einsparungen erzielt werden.
Abbildung 1: Unterscheidung der drei Modulgruppen gemäß der MFD-Methode und ihre Einstufung hinsichtlich Wiederverwendung
Der häufige Wechsel von Aufgaben, auch „Task Switching“ genannt, gilt als eine der wichtigsten Ursachen für Produktivitätsverluste in der Software-Entwicklung. Sobald ein Entwickler lange auf die Ergebnisse einer Tätigkeit warten muss, wird er für eine Weile zu einer anderen Aufgabe wechseln, bis er die notwendigen Ergebnisse hat und zur ursprünglichen Aufgabe zurückkehrt. Das verlangsamt den Entwicklungsprozess. Denn ein Mensch kann nur eine begrenzte Anzahl von Aufgaben im „mentalen Arbeitsspeicher“ ablegen. Das Abrufen von Wissen aus dem Langzeitgedächtnis kostet Zeit, und es dauert eine Weile, bis wieder eine produktive Bearbeitung der Aufgabe möglich ist.
Zusätzlich zu den Zeitverlusten, die durch das Wechseln von Aufgaben entstehen, kann das Einrichten einer Entwicklungsumgebung für eine andere Aufgabe ein erheblicher Zeitverlust sein. Dies gilt insbesondere dann, wenn die Entwicklungsumgebung eine andere Hardware-Einrichtung erfordert, die unter Umständen auch nur in begrenztem Umfang zur Verfügung steht.
Eine Möglichkeit, um diese Verzögerungen zu vermeiden ist, die Durchlaufzeit von Tests zu verkürzen. Dies gelingt, wenn Einzel- sowie Integrationstest regelmäßig und in kurzen Abständen durchgeführt werden. Hierfür setzen viele Unternehmen auf so genannte Continuous Integration and Continuous Deployment (CI/CD) Workflows mit automatisierten Tests. Damit diese Strategie funktioniert, bedarf es jedoch einer gut strukturierten, modularen Softwarearchitektur, die eine Parallelisierung von Aufgaben wie „Build“, „Test“, „Integration“ und „Bereitstellung“ ermöglicht. Das hat zudem den Vorteil, dass Standard CI/CD-Tools verwendet werden können und so Kosten für aufwendige Eigenentwicklungen vermieden werden können. Unter dieser Prämisse sind Verkürzungen der Lieferzeiten um mehr als 90 % möglich.
Die folgende Abbildung zeigt, wie einzelne Module unabhängig voneinander entwickelt und getestet werden können, was eine Parallelisierung von Arbeiten verschiedener Teams ermöglicht. Die Gesamtentwicklungszeit kann vor allem dann stark verkürzt werden, wenn es zu Anpassungen in einzelnen Modulen kommt, was bei einer monolithischen Entwicklung zu starken Verzögerungen führen würde.
Structuring the code with these strategies in mind can substantially increase the efficiency and ability to meet new demands in the digital era. The essential method to make this possible is to implement solid and well-defined interfaces between the software modules, which allow for innovation in the respective “swim-lane” without cross-interface effects. The strategies applied to the module code also apply to the interfaces the modules are implementing.
Abbildung 2: Verkleinerung der Rückkopplungsschleifen mithilfe einer modularen Softwarearchitektur
Sourcing-Entscheidungen sind oft nicht einfach. Modulare Produktarchitekturen und die zuvor definierten Modulgruppen helfen bei der Entscheidung:
Stabile Software-Module, d.h. „Operative Exzellenz“-Module, sollten nicht unbedingt ausgelagert werden, da sie intern kosteneffizient gewartet werden können.
Module für die Produktführerschaft (PL) hingegen haben eine hohe Änderungsrate und Kosten und erfordern erhebliche Anstrengungen, um wettbewerbsfähig zu bleiben. Wenn das PL-Modul nicht zu den Kernkompetenzen Ihrer Entwicklungsabteilung gehört, ist die Wahrscheinlichkeit groß, dass ein Softwarepartner besser geeignet ist, es auf dem neuesten Stand zu halten. Es könnte viel kosteneffizienter sein, diese Entwicklung auszulagern und Ihre Entwicklungsressourcen auf die Dinge zu konzentrieren, die für Ihr Geschäftsmodell von zentraler Bedeutung sind.
Auch die Freigabe von Software unter einer Open-Source-Lizenz ist an dieser Stelle eine Option. Der entscheidende Unterschied zum Outsourcing besteht darin, dass das Unternehmen die vollständige Kontrolle über das Urheberrecht behält. Lediglich in die Moderation der Code-Basis muss investiert werden.
Aufgrund ihrer langen Geschichte und ihres Wissens über ihre Hardware haben Unternehmen viele Ressourcen in die Entwicklung intelligenter Plattformen rund um Hardware und Mechatronik gesteckt. In den letzten 20 Jahren ist es jedoch immer schwieriger geworden, mit den Fortschritten in der Elektronik Schritt zu halten. Nur sehr wenige Unternehmen sind in der Lage, diese verschiedenen Schichten einer Produktarchitektur auf einheitliche und vernünftige Weise zu orchestrieren.
Die Unternehmen sind heute oft gezwungen, die von ihnen produzierte Hardware zu ändern, was wiederum Softwareänderungen erfordert. Der Grund dafür ist, dass sie z. B. dringend einen Chipsatz ersetzen müssen, weil der Lieferant seine Produktion einstellt (End-of-life) oder weil die ursprünglichen Komponenten am Markt nicht in ausreichender Stückzahl verfügbar sind. Die Änderungen in der Elektronik können auch durch einen erhöhten Bedarf an Rechenleistung, Speicher oder anderen Funktionen bedingt sein, um ein neues, stärker kundenorientiertes Software- oder Serviceangebot zu unterstützen, wie z. B. Over-the-Air-Updates (OTA).
Modularisierte Software kann sicherstellen, dass die Produktplanung in verschiedenen Schichten des Produkts besser aufeinander abgestimmt werden kann. Bei richtiger Anwendung kann genau nachvollzogen werden, welche Software-Module von einer Hardware-Änderung betroffen sein werden und welche nicht. Auf diese Weise kann neue Hardware eingeführt werden, um End-of-Life-Probleme zu lösen, ohne die Entwicklung in anderen Bereichen der Software zu stören, was indirekte Qualitätskosten und kostspielige Projektabbrüche einsparen kann. Es kann auch dazu verwendet werden, eine Alternative aus zweiter Hand einzuführen, die die Kosten für die Elektronik senkt und die Ausfallsicherheit der Lieferkette erhöht.
Abbildung 3: Transparenz über die Auswirkungen von Hardware-Änderungen auf Softwarekomponenten durch modulare Architektur
Durch eine modulare Software-Architektur mit einem klaren Verständnis dafür, wie sich Abweichungen in der Hardware auf die Software auswirken, können Sie bei gleichbleibender Produktqualität Entwicklungskosten und Einkaufskosten reduzieren.
Insgesamt macht dieser Artikel deutlich, dass sich die Investition in eine modulare Produktarchitektur lohnt – und zwar bereits in der frühen Phase der Software-Entwicklung. Durch die Wiederverwendung von Code kann sichergestellt werden, dass Funktionen nicht mehrfach redundant entwickelt werden. Die Entwickler konzentrieren sich aufs Wesentliche und werden durch die Verkürzung der Feedbackschleifen weniger stark durch die Auswirkungen von „Task Switching“ beeinflusst. Durch die neu gewonnene Transparenz über die Auswirkungen von Hardware-Änderungen auf die Software-Entwicklung und klare Sourcing-Entscheidungen besteht deutlich mehr Kontrolle über die Code-Entwicklung und es entstehen enorme Kosteneinsparpotenziale.
In unserer Webinar-Aufzeichnung „Best Practices für Software-Architekturen in Hardware-Unternehmen“ erfahren Sie alles über modulare Software-Architekturen, deren Skalierungspotenzial und konkrete Anwendungsfälle.
EVP and President Modular Management Asia Pacific AB
thomas.enocsson@modularmanagement.com
LinkedIn
Senior Specialist Software Architectures
roger.kullang@modularmanagement.com
+46 70 279 85 92
LinkedIn