Traditionelle ISVs (und Legacy-Softwareprodukte) befinden sich in einer Todesspirale
Das traditionelle ISV-Geschäftsmodell(Independent Software Vendor), bei dem Softwareprodukte vor Ort installiert und unterstützt werden, und das auf der Lizenzierung basierende Umsatzmodell sterben immer mehr aus. Dank der Auswirkungen der sich beschleunigenden digitalen Technologien (SMAC, IoT, KI usw.)
Gartner schätzt den weltweiten Markt für öffentliche Cloud-Dienste auf 246,8 Milliarden Dollar im Jahr 2017 und prognostiziert, dass er bis 2020 auf 383 Milliarden Dollar ansteigen wird, und geht davon aus, dass sich der Markt für Cloud-Anwendungsdienste (SaaS) zwischen 2016-20 verdoppeln und 75 Milliarden Dollar überschreiten wird. Gartner erklärt weiter:
" Da die Käufer von Unternehmensanwendungen zunehmend einen Cloud-first-Ansatz verfolgen, verlagern sich neue Softwareinvestitionen großer Anbieter von einem Cloud-first- zu einem Cloud-only-Ansatz."
Bei diesem Tempo ist es ganz klar, dass jeder traditionelle ISV, der sich nicht modernisiert, bis 2025 tot und ausgestorben sein wird, wenn nicht sogar noch früher. In diesem Blog möchte ich mich auf die Herausforderungen konzentrieren, mit denen typische ISVs bei ihrer Modernisierungsarbeit konfrontiert sind, und einige der möglichen Modernisierungsstrategien skizzieren.
Was ist die Zukunft der Softwareprodukte?
Lassen Sie uns die kumulativen Auswirkungen von Technologie und Geschäftsmodellen auf Softwareprodukte und ISVs, die diese entwickeln, untersuchen. Einige allgemeine Trends zeichnen sich deutlich ab:
- Jedes Softwareprodukt wird als Software as a Service (SaaS) bereitgestellt und genutzt werden , und Unternehmenssoftware wandelt sich zu Enterprise SaaS.
- In einer zunehmend plattformzentrierten Welt, wird jedes Softwareprodukt Teil einer Plattform sein entweder als Produzent, Konsument oder Matchmaker. In dieser Plattformlandschaft, Konfigurierbarkeit, Integrationen und Funktionsvielfalt in Bezug auf die Fähigkeit zur Unterstützung mehrere Geschäftsprozesse zu wichtigen Produktüberlegungen werden.
- Monolithische Architekturen und Standalone-Anwendungen werden überflüssig sein; Auf Mikrodiensten basierende Architekturen und digitale native Anwendungen werden die Norm sein.
- Das Wort "unabhängig" in ISV wird in einer zunehmend vernetzten und interdependenten Welt schnell zu einem Oxymoron. voneinander abhängigen Landschaft.
- Mit der breiten Einführung von Utility Computing und SaaS bewegen sich Unternehmen (Konsumenten von Softwareprodukten) von einem Capex- zu einem Opex-Modus.
- Noch nie dagewesene Kundenerwartungen führen zu einer Nachfrage nach Ubiquitäres Computing - Zugriff jederzeit, überall und von jedem Gerät aus; skalierbare Leistung und UX/DX/CX auf Verbraucherniveau in SaaS-Unternehmensanwendungen.
Was hindert ISVs an der Modernisierung?
Selbst wenn allgemein anerkannt wird, dass der Business Case für eine technologische Modernisierung zweifelsfrei feststeht, was hält die traditionellen ISVs davon ab, ihre Softwareprodukte zu modernisieren?
Veraltete Technologien und überholte Fähigkeiten: Die ISV-Landschaft ist übersät mit Hunderten und Tausenden von Softwareprodukten, die immer noch auf veralteten Technologien wie Power Builder, Progress, Delphi, FoxPro, COBOL und VB usw. basieren. Oft haben diese Produkte eine monolithische und eng gekoppelte Architektur, was ihre Wartung und Unterstützung sehr schwierig macht. Doch leider sind die veralteten Fähigkeiten der Ingenieure und Entwickler, die diese Produkte entwickelt und unterstützt haben, einer der größten Stolpersteine bei den Bemühungen der ISVs um Modernisierung. Oft verfügen diese Ingenieure, die über ein enormes Fachwissen in verschiedenen Legacy-Technologien verfügen, nicht über die dringend benötigten Kenntnisse in den neuen Technologien, die für jede Modernisierung entscheidend sind.
Gefangen im Syndrom der versunkenen Kosten: In der Regel hat der ISV viel Zeit, Geld und Ressourcen(versunkene Kosten) in die Entwicklung von Softwareprodukten/Anwendungen der Unternehmensklasse investiert. Selbst wenn es offensichtlich ist, dass die Technologie veraltet ist und das Produkt keine Zukunft hat, verschwenden einige ISVs weiterhin Geld für ein eindeutig aussichtsloses Unterfangen. Unternehmen sind oft in der Falle des Sunk-Cost-Syndroms gefangen, hängen emotional an dem Produkt oder Projekt(Klebrigkeit an dem, was wir haben) und finden es schwierig, objektiv über die Zukunft nachzudenken.
Kurzsichtige Weltanschauung und reparieren Sie nicht, was nicht kaputt ist: Ich bin häufig auf einige sehr erfolgreiche ISVs gestoßen, die der Meinung sind, dass sie einen stabilen Kundenstamm haben, der mit ihren Produkten zufrieden ist, weiterhin Lizenz- und Supportgebühren zahlt und sich nicht beschwert. Die Logik dieser ISVs lautet: Wenn ihre Kunden zufrieden sind und keine Änderungen fordern, wo ist dann der Anreiz für sie, zu modernisieren? Mit anderen Worten: In ihrer kurzsichtigen Weltanschauung sollte man nicht reparieren, was nicht kaputt ist.
" Die globale Unternehmenslandschaft ist übersät mit vielen Giganten, die einst unangefochtene Marktführer waren, es aber versäumten, künftige Marktbedürfnisse und Technologietrends zu antizipieren, und so im Handumdrehen irrelevant wurden, als flinke Konkurrenten sie mit überlegenen Produkten und Dienstleistungen verdrängten."
Angst vor Misserfolg und Risikoaversion: Es gibt auch die tief verwurzelte Auffassung, dass die Modernisierung von Technologieprodukten ein riskantes Unterfangen mit vielen Unwägbarkeiten ist. Oft ist es so, dass der ISV nicht weiß, welche Modernisierungsstrategie die richtige ist, dass er nicht über die nötigen Mittel verfügt, um die richtige Technologie/Architektur zu wählen, und dass ihm einfach die Kapazitäten und Ressourcen für die Durchführung fehlen. Aus einer Vielzahl von Gründen, wie z.B. Risikoscheu, Angst vor dem Scheitern und Angst vor dem Unbekannten, wird jede Diskussion über eine Modernisierung vom Tisch gefegt.
Wahl der Technologieplattform und Anwendungsarchitektur
Sobald die Entscheidung getroffen ist, ein Legacy-Produkt/eine Legacy-Anwendung zu modernisieren, besteht eine der größten Herausforderungen für ISVs in der Wahl der Zieltechnologieplattform und der Anwendungsarchitektur. Aus der Perspektive der Zukunftssicherheit wäre es für ISVs ratsam, einen Modernisierungsansatz in Betracht zu ziehen, der digitale native Anwendungen bereitstellt. Es gibt zwar keine Einheitsgröße, aber der gewählte Technologie-Stack und das Architektur-Framework müssen die folgenden Faktoren berücksichtigen:
- Skalierbarkeit: Schnelle Skalierbarkeit (on-demand), Leistung und Sicherheit
- Verfügbarkeit: muss ständigen Zugriff (24x7), kontinuierliche Verfügbarkeit und Betriebszeit unterstützen
- Anpassungsfähigkeit: Flexibilität gegenüber Veränderungen, einfache Konfiguration und Modularität
Die unten stehende Infografik zeigt einige der in herkömmlichen Anwendungen weit verbreiteten Software-Stacks und Architekturen und listet die Architekturprinzipien und die Auswahl von Technologie-Stacks/Frameworks für digitale native Anwendungen auf.
Strategien für die Modernisierung
Die Wahl der Modernisierungsstrategie hängt von mehreren Faktoren ab, darunter (aber nicht nur) der aktuelle Software-Stack, die Anwendungsarchitektur, die Zielarchitektur und die technologischen Frameworks, die Hosting-Umgebung, die Verfügbarkeit von Ressourcen, der Zeitrahmen usw. Auf der Grundlage dieser Faktoren können Sie eine Modernisierungsstrategie wählen, die Ihren Anforderungen am besten gerecht wird. Diese kann von einem automatisierten (toolgestützten) Migrationsprozess bis hin zu manuellen Prozessen wie Re-Platforming, Re-Hosting, Refactoring, Re-Architektur, Re-Engineering und Ersatz reichen.
Modernisierung und Transformation sind der Schlüssel zur Vermeidung der ISV-Todesspirale
In einer sich schnell verändernden Technologielandschaft, in der die digitale Disruption die Norm ist, ist der Status quo für einen traditionellen ISV keine Option, da er zu Irrelevanz, Auslöschung und einem sicheren Tod führt. Um diese Todesspirale zu vermeiden, müssen ISVs die technologische Modernisierung in Angriff nehmen und ihre Legacy-Software in digitale native Anwendungen umwandeln, die entweder als Unternehmens-SaaS oder als Teil einer digitalen Plattform bereitgestellt werden können
Verfasst von
Steven ten Napel, CEO
Steven is a co-founder and CEO of coMakeIT. He has extensive experience in setting up and managing large scale, distributed development centers for global technology companies across Europe, North America, and India
Contact