Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Migration über SaaS
Viele der Anbieter, die SaaS einführen, migrieren von einem traditionellen installierten Softwaremodell (zuvor beschrieben) zu SaaS. Für diese Anbieter ist es besonders wichtig, die Kernprinzipien von SaaS gut aufeinander abzustimmen.
Auch hier kann es zu einiger Verwirrung darüber kommen, was es bedeutet, zu einem SaaS-Modell zu migrieren. Manche betrachten beispielsweise die Umstellung auf die Cloud als Migration zu SaaS. Andere betrachten das Hinzufügen von Automatisierung zu ihrem Installations- und Bereitstellungsprozess als Erfolg der Migration.
Man kann mit Fug und Recht sagen, dass jedes Unternehmen an einem anderen Ort anfängt, unterschiedliche Überlegungen zur Altlasten anstellt und wahrscheinlich einem unterschiedlichen Markt- und Wettbewerbsdruck ausgesetzt ist. Das bedeutet, dass jede Migration anders aussehen wird.
Obwohl jeder Weg anders ist, gibt es einige Bereiche, in denen es Unterschiede in Bezug auf die Kernprinzipien gibt, die die Migrationsstrategien prägen. Eine gute Abstimmung der Konzepte und Prinzipien kann erhebliche Auswirkungen auf den Gesamterfolg Ihrer SaaS-Migration haben.
Auf der Grundlage der zuvor skizzierten Konzepte sollte klar sein, dass die Umstellung auf SaaS mit der Geschäftsstrategie und den Unternehmenszielen beginnt. Dieser Punkt kann in einer Migrationsumgebung verloren gehen, in der der Druck besteht, so schnell wie möglich zu SaaS zu gelangen.
In diesem Modus betrachten Unternehmen die Migration oft in erster Linie als technische Maßnahme. Die Realität ist, dass jede SaaS-Migration mit einem klaren Überblick über die Zielkunden, das Serviceerlebnis, die betrieblichen Ziele usw. beginnen sollte. Ein klarerer Fokus darauf, wie Ihr SaaS-Geschäft aussehen muss, hat tiefgreifende Auswirkungen auf die Form, die Prioritäten und den Weg, den Sie bei der Migration Ihrer Lösung auf SaaS einschlagen.
Wenn Sie von Beginn Ihrer Migration an diese klare Vision haben, legen Sie die Grundlage dafür, wie Sie im Rahmen Ihrer Umstellung auf SaaS sowohl die Technologie als auch das Geschäft migrieren. Wenn Sie sich auf diesen Weg begeben, konzentrieren Sie sich auf die Fragen, die Ihnen am meisten darüber sagen können, wohin Sie wollen.
Die folgende Tabelle gibt einen Überblick über den unterschiedlichen Charakter der Denkweisen zur technischen Migration und zur Unternehmensmigration.
Tabelle 1 — Migration an erster Stelle in technischer Hinsicht im Vergleich zur unternehmenseigenen Migration
Die Denkweise, bei der Technik an erster Stelle steht | Die betriebswirtschaftliche Denkweise |
---|---|
Wie isolieren wir Mandantendaten? | Wie kann SaaS uns helfen, unser Geschäft auszubauen? |
Wie verbinden wir Benutzer mit Mietern? | Auf welche Segmente zielen wir ab? |
Wie vermeiden wir laute Nachbarschaftsbedingungen? | Was ist die Größe und das Profil dieser Segmente? |
Wie führen wir A/B-Tests durch? | Welche Stufen müssen wir unterstützen? |
Wie skalieren wir basierend auf der Auslastung der Mieter? | Welches Serviceerlebnis streben wir an? |
Welchen Abrechnungsanbieter sollten wir verwenden? | Was ist unsere Preis- und Verpackungsstrategie? |
Im Folgenden finden Sie ein Beispiel dafür, wie eine Migration über Technologie aussehen könnte. Das Entwicklungsteam konzentriert sich sehr darauf, die klassischen Multi-Tenant-Themen zu verfolgen, die für jede SaaS-Architektur sicherlich wichtig sind.
Das Problem ist, dass die Antworten auf viele der Fragen auf der linken Seite oft direkt von den Antworten auf die Frage auf der rechten Seite beeinflusst werden. Es ist unwahrscheinlich, dass dieser Punkt für jemanden neu ist, der sich mit Migration befasst. Die Realität ist jedoch, dass viele Unternehmen zunächst der Betriebs- und Kosteneffizienz als ersten Schritt nachjagen, vorausgesetzt, dass sich die geschäftlichen Aspekte von selbst regeln.
Im Rahmen dieser Migrationsstrategie kann es auch zu Unklarheiten darüber kommen, wie Ihre Legacy-Umgebung weiterentwickelt werden könnte, um in ein SaaS-Modell zu passen. Auch in diesem Bereich gibt es eine Vielzahl von Optionen für die Migration zu SaaS. Es gibt jedoch ein gemeinsames Wertesystem, das wir generell für jede Migration befürworten.
In unserer vorherigen Diskussion der SaaS-Prinzipien haben wir verschiedene Muster und Terminologien skizziert, die zur Beschreibung von SaaS-Umgebungen verwendet werden. Ein gemeinsames Thema, das all diese Lösungen durchzieht, ist die Idee, gemeinsam genutzte Dienste zu haben, die Ihre Anwendung umgeben. Identität, Onboarding, Metriken, Abrechnung — all dies werden als gemeinsame Elemente bezeichnet, die für jede SaaS-Umgebung von zentraler Bedeutung sind.
Wenn wir uns nun die Migration ansehen, werden Sie feststellen, dass dieselben Shared Services in jeder Migrationsgeschichte eine wichtige Rolle spielen. Das folgende Diagramm bietet eine konzeptionelle Ansicht der Migrationslandschaft.

Migration zu SaaS
Dieses Diagramm stellt das Zielerlebnis für jeden Migrationspfad dar. Es umfasst dieselben gemeinsamen Dienste, die zuvor beschrieben wurden. In der Mitte befindet sich ein Platzhalter für Ihre Bewerbung.
Die Grundidee ist, dass Sie inmitten dieser Umgebung beliebig viele Anwendungsmodelle platzieren können. In Ihrem ersten Schritt der Migration wird möglicherweise jeder Tenant in seinem eigenen Silo ausgeführt. Oder Sie haben vielleicht eine Hybridarchitektur, in der Elemente isoliert sind und andere Funktionalitäten durch eine Sammlung modernisierter Microservices abgedeckt werden.
Wie stark Sie Ihre Anwendung zunächst modernisieren, hängt von der Art Ihrer Legacy-Umgebung, den Marktanforderungen, Kostenüberlegungen usw. ab. Was sich nicht ändert, ist die Einführung dieser Shared Services.
Jede SaaS-Migration muss diese grundlegenden Shared Services unterstützen, damit Ihr Unternehmen in einem SaaS-Modell arbeiten kann. Alle Variationen der Anwendungsarchitektur benötigen beispielsweise eine SaaS-Identität. Für die Verwaltung und Überwachung Ihrer SaaS-Lösung benötigen Sie Prozesse, bei denen die Mandanten berücksichtigt werden.
Wenn Sie diese Shared Services an der Spitze Ihrer Migration einsetzen, können Sie Ihren Kunden ein SaaS-Erlebnis bieten — auch wenn die zugrunde liegende Anwendung immer noch in einem Full-Stack-Silo für jeden Mandanten ausgeführt wird.
Das allgemeine Ziel besteht darin, Ihre Anwendung in einem SaaS-Modell zum Laufen zu bringen. Anschließend können Sie sich der weiteren Modernisierung und Verfeinerung Ihrer Anwendung zuwenden. Dieser Ansatz ermöglicht es Ihnen auch, die anderen Bereiche Ihres Unternehmens (Marketing, Vertrieb, Support usw.) schneller voranzubringen. Noch wichtiger ist, dass Sie auf diese Weise beginnen können, Kundenfeedback einzuholen und zu sammeln, das zur Gestaltung der laufenden Modernisierung Ihrer Umgebung verwendet werden kann.
Es ist wichtig zu beachten, dass die von Ihnen bereitgestellten Shared Services möglicherweise nicht alle Funktionen oder Mechanismen beinhalten, die Sie letztendlich benötigen. Das Hauptziel besteht darin, die gemeinsamen Mechanismen zu schaffen, die zu Beginn Ihrer Migration erforderlich sind. Auf diese Weise können Sie sich auf die Elemente des Systems konzentrieren, die für die Entwicklung Ihrer Anwendungsarchitektur und Ihre betriebliche Entwicklung von entscheidender Bedeutung sind.