Paradigmenwechsel bei der Innovation von Softwareprodukten

Wir können Probleme nicht mit derselben Denkweise lösen, mit der wir sie geschaffen haben. -AlbertEinstein

Softwareunternehmen sind sich der disruptiven Kräfte, die im Spiel sind, sehr wohl bewusst

Im Laufe des letzten Jahres habe ich mit vielen Softwareunternehmen in meinem Kundenumfeld gesprochen und zahlreiche Gespräche über die Herausforderungen geführt, denen sie sich bei der Innovation von Softwareprodukten stellen müssen. Dabei ist mir aufgefallen, dass diese Unternehmen ein gutes Verständnis für die Art der Herausforderungen haben, denen sie sich mit ihrem Produktstapel stellen müssen, und für den ständigen Druck, mit der technologischen Disruption und der veränderten Marktdynamik Schritt zu halten.

Diese Unternehmen haben in der Regel mit der Entwicklung eines generischen Produkts begonnen, das von mehreren Kunden verwendet werden kann. Jeder Kunde ist jedoch einzigartig und hat spezifische Anforderungen. Um diesen Anforderungen gerecht zu werden, wird das Produkt in hohem Maße konfigurierbar gemacht und (hier und da hart kodiert) an die Bedürfnisse eines bestimmten Kunden angepasst. Diese Flexibilität im Produkt ist ein beliebter und erfolgreicher Ansatz, um ein etablierter und unabhängiger Softwareanbieter zu werden.

Die meisten der Softwareunternehmen, mit denen wir zusammenarbeiten, haben dies sehr gut gemacht und betonen, dass sie dank dieses Ansatzes wachsen und zu einem wichtigen Akteur in ihrem Geschäft werden konnten. Und nicht nur das - die Flexibilität des Produkts unterstützt verschiedene Nutzungsszenarien und generiert neue Geschäfte in angrenzenden Marktsegmenten.

Die Anpassungsfalle bei der Innovation von Softwareprodukten

Leider hat dieser Ansatz auch einen Nachteil. Unterschiedliche Kundenbedürfnisse zu befriedigen ist ein bewährter Ansatz für ein gutes Geschäft. Die Erfüllung dieser Bedürfnisse durch ein hochgradig konfigurierbares und maßgeschneidertes Produkt hat jedoch zu einer enormen Komplexität innerhalb des Produkts geführt, die weitere Innovationen erstickt und abwürgt. Zu viele Tabellen, zu viele Parameter(ich spreche hier von Tausenden), zu wenig Layering und Modularisierung und kaum eine automatisierte Testabdeckung. Im Laufe der Zeit wird das Verhalten dieser angepassten Versionen unvorhersehbar, schwer zu verfolgen und zu unterstützen. Die Produkte sind außerdem schwer zu integrieren und haben lange Implementierungszyklen. Nur sehr wenige Mitarbeiter kennen alle Feinheiten des Systems, was sie zu Engpässen bei Support, Änderungsmanagement und Kundenimplementierungen macht.

Ich nenne dies die "Alles wissen, um etwas zu ändern "-Falle. Aufgrund der Komplexität und der spaghettiartigen Abhängigkeiten des Systems ist es schwierig, die Auswirkungen von Änderungen zu überblicken. Man muss das ganze System in- und auswendig kennen, um etwas zu ändern, ohne dass einem das System um die Ohren fliegt. Wie bereits erwähnt, verstehen die Unternehmen, mit denen wir zusammenarbeiten, diese Situation sehr gut. Und das ist ein guter Anfang.

Paradigmen der Vergangenheit können keine Lösungen für die Zukunft schaffen

Ich sehe viele Unternehmen, die versuchen, die Herausforderungen von Altlasten zu bewältigen, indem sie neue Softwareprodukte von Grund auf entwickeln und sie flexibel und anpassungsfähig machen. Dieser Ansatz hat einen guten Grund: Wenn wir Flexibilität von Grund auf ermöglichen und unsere Kernfunktionalität auf dieser flexiblen Schicht aufbauen, dann sind wir in einer viel besseren Verfassung, um die kundenspezifische Nachfrage zu erfüllen.

Doch trotz dieser vernünftigen Überlegung begehen diese Unternehmen einen grundlegenden Fehler. Abgesehen von den Kosten für den Neuaufbau des gesamten Software-Stacks und den Herausforderungen bei der Migration des bestehenden Kundenstamms hat sich im Kern nur sehr wenig an der Herangehensweise an die Innovation von Softwareprodukten geändert - wie das Produkt konzipiert, entworfen und entwickelt wird. Sehr oft werden ähnliche architektonische Paradigmen (wie bei der Entwicklung des ursprünglichen Produkts) auch bei der Entwicklung des neuen Produkts angewandt, vielleicht mit neueren Technologien. Das Ergebnis ist, dass das Produkt, auch wenn es neu zu sein scheint und anfangs vielleicht einige der alten Probleme löst, früher oder später zu einer ähnlichen Komplexität und mangelnden Kohärenz wie das ursprüngliche Produkt führen wird.

Indem sie Produkte so gestalten, dass sie extrem konfigurierbar sind, zwingen die Softwareunternehmen ihre Kunden in Wirklichkeit dazu, alles auf ihrer Produktplattform aufzubauen. In gewisser Weise versuchen sie, zu Low-Code-Plattformen für ihre spezifischen Bereiche oder Funktionen zu werden. Das ist nicht die Essenz der Offenheit, die ein kollaboratives Ökosystem erfordert.

Mein Rat wäre: Hören Sie damit auf. Es gibt so viele kommerzielle und Open-Source-Plattformen (ich bevorzuge letztere, siehe mein vorheriges Blog) für Low-Code. Es ist eine völlig falsche Annahme zu glauben, dass Sie sich mit einer eigenen Low-Code-Plattform von Ihren Mitbewerbern abheben können.

Autonome, selbstanpassende Systeme der Zukunft erfordern einen Paradigmenwechsel

Die wirkliche Lösung besteht darin, diese veralteten Technologien und Architekturmuster der Softwareproduktinnovation aufzugeben. Autonome und selbstanpassende Systeme der Zukunft erfordern einen grundlegenden Wandel durch die Einführung moderner architektonischer, organisatorischer und einsatzbezogener Paradigmen, die dazu beitragen, offene, lose gekoppelte, vernetzte und partizipative Softwareprodukte zu entwickeln und aufrechtzuerhalten, die in den Ökosystemen ihrer Kunden leben. Um diesen Wandel und seine Folgen zu verstehen, müssen Sie die folgenden Themen auf Ihrem Radar haben:

• Nutzerzentrierung

• Datengesteuertes Design

• Plattform-Denken

• SaaS

• Für den Wandel konzipiert: Event Sourcing

• Organisatorische Entwurfsmuster müssen architektonischen Entwurfsmustern folgen

Es ist leicht, diese Themen aufzuzählen, aber umso schwieriger, den Wechsel zu vollziehen und die Auswirkungen auf Ihre spezielle Situation zu verstehen.

Deshalb habe ich unseren CTO Thijs Petter gebeten, eine Reihe von Blogs zu veröffentlichen und eine Reihe von Webinaren zu diesen Themen zu veranstalten und zu erläutern, wie sie in die Entwicklung moderner Softwareprodukte einfließen. Thijs hat sein ganzes Leben damit verbracht, Softwareentwicklungsplattformen zu bauen, bevor er seine Karriere wechselte und Unternehmen dabei hilft, dieses Wissen zu nutzen, um die Know-how-Do-how-Lücke zu überwinden.

Bleiben Sie dran, denn wir werden in Kürze den ersten Blog der Serie Software Product Innovation veröffentlichen.