Kapitel 1. Die SaaS-Mentalität

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Ich habe mit einer Reihe von Teams zusammengearbeitet, die Software-as-a-Service (SaaS)-Lösungen entwickelt haben. Wenn ich mich mit ihnen zusammensetze, um ihren Weg zu SaaS zu skizzieren, neigen sie dazu, zunächst eine vernünftige Vorstellung davon zu haben, was es bedeutet, SaaS zu sein. Wenn ich jedoch eine Ebene tiefer gehe und mich mit den Details ihrer Lösung befasse, entdecke ich oft erhebliche Unterschiede in ihren Vorstellungen. Stell dir zum Beispiel vor, dass dir jemand erzählt, er wolle ein Gebäude bauen. Wir alle haben eine Vorstellung von einem Gebäude mit Wänden, Fenstern und Türen, aber die tatsächliche Art dieser Strukturen kann sehr unterschiedlich sein. Einige Teams stellen sich vielleicht einen Wolkenkratzer vor, andere bauen ein Haus.

Es ist ganz natürlich, dass es Verwirrung darüber gibt, wie SaaS aussieht. Wie in allen Bereichen der Technologie entwickelt sich auch das SaaS-Universum ständig weiter. Das Aufkommen der Cloud, die sich ändernden Kundenbedürfnisse und die Wirtschaftlichkeit der Softwarebranche sind ständig in Bewegung. Wie wir SaaS gestern definiert haben, ist vielleicht nicht die Art und Weise, wie wir es heute definieren werden. Ein weiterer Teil der Herausforderung ist, dass SaaS weit über das Technische hinausgeht. Es ist in vielerlei Hinsicht eine Denkweise, die sich über alle Dimensionen der Organisation eines SaaS-Anbieters erstreckt.

Vor diesem Hintergrund ist es naheliegend, zu Beginn dieser Reise zu klären, wie ich SaaS definiere und wie ich denke, dass diese Definition unsere Herangehensweise an die Architektur, das Design und den Aufbau einer SaaS-Lösung beeinflusst. Das Ziel dieses Kapitels ist es, ein grundlegendes mentales Modell zu entwickeln, das die Verwirrung darüber, was SaaS bedeutet, verringert. Wir werden einige der vagen Vorstellungen von SaaS hinter uns lassen und - zumindest für den Rahmen dieses Buches - die Definition von SaaS mit konkreteren Leitprinzipien verbinden, die die Strategien prägen werden, die wir in den folgenden Kapiteln untersuchen werden.

Um dorthin zu gelangen, müssen wir uns die Kräfte ansehen, die den Wechsel zu SaaS motiviert haben, und sehen, wie diese Kräfte die daraus resultierenden Architekturmodelle direkt beeinflusst haben. Wenn wir diese Entwicklung verfolgen, erhalten wir einen konkreteren Einblick in die grundlegenden Prinzipien, die für die Entwicklung einer SaaS-Lösung verwendet werden, die den vollen Wertbeitrag von SaaS ausschöpft und die technischen und geschäftlichen Parameter vereint, die den Kern der Entwicklung moderner SaaS-Umgebungen bilden. Für SaaS-Architekten ist es wichtig zu verstehen, dass SaaS keine technologieorientierte Denkweise ist. Ein SaaS-Architekt entwirft nicht zuerst eine mandantenfähige Architektur und überlegt dann, wie die Geschäftsstrategie darauf aufbaut. Stattdessen arbeiten das Unternehmen und die Technologie zusammen, um die beste Schnittstelle zwischen den Geschäftszielen und den mandantenfähigen Lösungen zu finden, mit denen diese Strategien umgesetzt werden können. Dieses Thema wird uns in diesem Buch durchgängig begleiten.

Auch wenn du dich mit dem, was SaaS für dich bedeutet, wohlfühlst, ist es möglich, dass die grundlegenden Konzepte, die wir hier erkunden, deine Sicht auf SaaS und die Terminologie, die wir zur Beschreibung von SaaS-Umgebungen verwenden, in Frage stellen. Auch wenn es verlockend ist, dieses Kapitel als optional zu betrachten, ist es vielleicht eines der wichtigsten Kapitel des Buches. Es ist nicht nur eine Einführung, sondern es geht darum, ein gemeinsames Vokabular und ein mentales Modell zu schaffen, das in die Architektur, die Codierung und die Implementierungsstrategien einfließt, die wir im Laufe des Buches behandeln werden.

Wo wir angefangen haben

Bevor wir uns mit der Definition von SaaS befassen können, müssen wir verstehen, wie diese Reise begann und welche Faktoren die Dynamik des SaaS-Bereitstellungsmodells angetrieben haben. Schauen wir uns zunächst an, wie Software traditionell entwickelt, betrieben und verwaltet wurde. Vor dem SaaS-Modell wurden die Systeme in der Regel als "installierte Software" geliefert, bei der der Kunde eine Rolle bei der Installation und Einrichtung der Software spielte. Das IT-Team des Kunden konnte die Software in einer vom Anbieter bereitgestellten Umgebung installieren oder sie in seiner eigenen Infrastruktur betreiben. In diesem Modus könnte die Verwaltung und der Betrieb dieser Umgebungen bis zu einem gewissen Grad an das IT-Team des Kunden übertragen werden. Ein professionelles Serviceteam könnte auch eine gewisse Rolle bei der Installation, Anpassung und Konfiguration der Kundenumgebung spielen.

In diesem Modell waren die Software-Entwicklungsteams eher von diesen Liefer- und Einrichtungsdetails entfernt. Sie konzentrierten sich eher darauf, die funktionalen Fähigkeiten ihrer Lösungen kontinuierlich auszubauen. Die Bereitstellung und der Betrieb wurden oft auf der anderen Seite der Mauer und etwas nachgelagert von den täglichen Entwicklungsbemühungen behandelt.

Abbildung 1-1 zeigt einen konzeptionellen Überblick über die Grundzüge des traditionellen Softwarebereitstellungsmodells.

Abbildung 1-1. Das Modell der installierten Software

Oben links in Abbildung 1-1 siehst du, dass ich einen unabhängigen Softwareanbieter (ISV) vorgestellt habe, der die Software an seine Kunden verkauft. Außerdem habe ich zwei Kunden gezeigt, die derzeit die Software des ISV besitzen: Kunde 1 und 2. Jeder dieser Kunden hat eine bestimmte Version des Produkts des ISV im Einsatz. Als Teil ihrer Einarbeitung benötigten sie auch einmalige Anpassungen des Produkts, die vom Professional Services Team des ISV vorgenommen wurden. Wir haben auch andere Kunden, die andere Versionen unseres Produkts einsetzen, die möglicherweise keine Anpassungen haben .

Bei jedem neuen Kunden muss die Betriebsorganisation des Anbieters möglicherweise spezielle Teams bilden, die sich um die alltäglichen Bedürfnisse dieser Kundenumgebungen kümmern. Diese Teams können für einen einzelnen Kunden zuständig sein oder einen Querschnitt von Kunden unterstützen.

Bei dieser klassischen Art der Softwarebereitstellung handelt es sich um ein eher vertriebsorientiertes Modell, bei dem sich das Unternehmen darauf konzentriert, Kunden zu akquirieren und sie an die Technikerteams zu übergeben, die sich um die spezifischen Bedürfnisse jedes neuen Kunden kümmern. Du kannst dir vorstellen, wie diese Dynamik die gesamte Kultur und den Entwicklungszyklus der Erfahrung prägt. Wie dein Produkt entwickelt wird, wie neue Funktionen eingeführt werden, wie du über Anpassungen denkst - all das sind Bereiche, die von diesem Ansatz beeinflusst werden. Die Denkweise hier ist eine, bei der der Abschluss eines Geschäfts Vorrang vor der Notwendigkeit von Flexibilität, Skalierbarkeit und betrieblicher Effizienz haben kann. Außerdem werden diese Lösungen häufig mit langfristigen Verträgen verkauft, die es dem Kunden erschweren, problemlos zu einem anderen Anbieter zu wechseln.

Die verteilte und unterschiedliche Natur dieser Kundenumgebungen verlangsamt oft die Veröffentlichung und Einführung neuer Funktionen. In diesen Umgebungen haben die Kunden die Kontrolle und bestimmen oft, wie und wann sie auf eine neue Version aktualisieren können. Die Komplexität der Tests und des Einsatzes dieser Umgebungen könnte zu schwerfällig werden und die Anbieter zu viertel- oder halbjährlichen Releases zwingen.

Fairerweise muss man sagen, dass die Entwicklung und Bereitstellung von Software nach diesem Modell für einige Unternehmen ein absolut gültiger Ansatz ist und bleiben wird. Die Altlasten, die Einhaltung von Vorschriften und die geschäftlichen Gegebenheiten eines bestimmten Bereichs können gut zu diesem Modell passen. Für viele Unternehmen bringt diese Art der Softwarebereitstellung jedoch eine Reihe von Herausforderungen mit sich. Im Kern geht es bei diesem Ansatz darum, den Kunden alles zu verkaufen, was sie brauchen, und dafür Kompromisse in Bezug auf Skalierbarkeit, Agilität und Kosten-/Betriebseffizienz einzugehen.

Auf den ersten Blick scheinen diese Kompromisse nicht so wichtig zu sein. Wenn du nur eine begrenzte Anzahl von Kunden hast und nur ein paar pro Jahr an Land ziehst, könnte dieses Modell völlig ausreichend sein. Du würdest zwar immer noch Ineffizienzen haben, aber sie wären weit weniger auffällig. Stell dir jedoch ein Szenario vor, in dem du einen großen Kundenstamm hast und dein Unternehmen schnell wachsen will. In diesem Fall werden die Probleme dieses Ansatzes für viele Softwareanbieter zu einem echten Problem.

Betriebs- und Kosteneffizienz gehören oft zu den ersten Bereichen, in denen Unternehmen, die dieses Modell anwenden, den Schmerz zu spüren bekommen. Der zusätzliche Aufwand für die Betreuung jedes neuen Kunden wirkt sich auf das Unternehmen aus, schmälert die Gewinnspanne und macht das Betriebsprofil immer komplexer. Jeder neue Kunde könnte mehr Supportteams, mehr Infrastruktur und mehr Aufwand erfordern, um die einmaligen Änderungen zu bewältigen, die mit jeder Kundeninstallation einhergehen. In einigen Fällen erreichen Unternehmen sogar einen Punkt, an dem sie ihr Wachstum aufgrund der betrieblichen Belastungen dieses Modells absichtlich verlangsamen.

Das größere Problem ist jedoch, wie sich dieses Modell auf Agilität, Wettbewerb, Wachstum und Innovation auswirkt. Es liegt in der Natur der Sache, dass dieses Modell alles andere als wendig ist. Wenn Kunden ihre eigenen Umgebungen verwalten können, für jeden Kunden eine eigene Version zur Verfügung steht und einmalige Anpassungen möglich sind - all das untergräbt die Schnelligkeit und Agilität. Stell dir vor, was es bedeuten würde, eine neue Funktion in diesen Umgebungen einzuführen. Die Zeit zwischen der Idee für eine neue Funktion, der Entwicklung und der Bereitstellung für alle Kunden ist oft ein langsamer und bedächtiger Prozess. Wenn eine neue Funktion auf den Markt kommt, haben sich die Bedürfnisse der Kunden und des Marktes vielleicht schon geändert. Das kann sich auch auf die Wettbewerbsfähigkeit dieser Unternehmen auswirken und ihre Fähigkeit einschränken, schnell auf neue Lösungen zu reagieren, die auf einem reibungsärmeren Modell basieren.

Während der betriebliche und entwicklungsbezogene Fußabdruck immer schwieriger zu skalieren war, veränderten sich auch die Bedürfnisse und Erwartungen der Kunden. Die Kunden legen weniger Wert darauf, ihre Umgebungen zu verwalten oder zu kontrollieren. Stattdessen sind sie mehr daran interessiert, den Wert, den sie aus ihrer Software ziehen können, zu maximieren. Sie verlangen zunehmend nach reibungsloseren Lösungen, die sich kontinuierlich an ihre Bedürfnisse anpassen und ihnen mehr Freiheit geben, je nach den sich entwickelnden Anforderungen ihres Unternehmens zwischen verschiedenen Lösungen zu wechseln.

Die Kunden interessieren sich auch mehr für Preismodelle, die besser zu ihrem Wert- und Konsumprofil passen. In manchen Fällen wünschen sie sich die Flexibilität von Abonnement- und/oder Umlagemodellen.

Du kannst das natürliche Spannungsfeld sehen, das hier im Spiel ist. Für viele passt das klassische Liefermodell einfach nicht zu ihrer Fähigkeit, ihr Geschäft zu skalieren oder zu erweitern und die sich verändernden Bedürfnisse ihrer Kunden zu erfüllen. Auch das Aufkommen der Cloud hat hier eine wichtige Rolle gespielt. Das Cloud-Modell hat die Art und Weise, wie Unternehmen das Hosting, die Verwaltung und den Betrieb ihrer Software betrachten, grundlegend verändert. Der Pay-as-you-go-Charakter und das Betriebsmodell der Cloud veränderten die Denkweise der Branche und legten den Schwerpunkt stärker auf Agilität und Skaleneffekte. Diese Kräfte haben die Softwareanbieter dazu gebracht, die Art und Weise, wie sie ihre Lösungen entwickeln, bereitstellen, betreiben und verkaufen, zu überdenken.

Der Übergang zu einem einheitlichen Modell

Inzwischen sollten die grundlegenden Herausforderungen des traditionellen Modells klar sein. Während einige Unternehmen mit diesem Modell zu kämpfen hatten, war anderen bereits klar, dass dieser Ansatz weder wirtschaftlich noch betrieblich skalierbar war. Wenn du zum Beispiel ein B2B ISV mit Tausenden von Kunden bist, ist es unwahrscheinlich, dass dein Unternehmen ein Modell unterstützen kann, bei dem jeder Kunde separat betreut, verwaltet und betrieben werden muss.

Für viele bestand die Antwort darin, zu einem Modell überzugehen, das mehr von der Erfahrung vereinheitlichte und die Komplexität und Kosten reduzierte, die mit der Unterstützung des Pro-Kunde-Modells einhergingen. Hier haben wir gesehen, wie Teams ein gemeinsames Infrastrukturmodell eingeführt haben, das es ihnen ermöglicht, ihr Geschäft zu skalieren und ihr Betriebsmodell effizienter zu gestalten.

Dieser Wechsel zu einem einheitlicheren, gemeinsam genutzten Modell eröffnete eine Reihe neuer Möglichkeiten für Softwareanbieter. Abbildung 1-2 zeigt ein Konzept für eine vereinfachte SaaS-Umgebung mit gemeinsam genutzter Infrastruktur.

Abbildung 1-2. Ein SaaS-Modell mit gemeinsamer Infrastruktur

In Abbildung 1-2 siehst du eine vereinfachte Darstellung der traditionellen Vorstellung von SaaS. Du wirst feststellen, dass wir uns völlig von der verteilten, einmaligen und individuellen Natur des klassischen Modells in Abbildung 1-1 entfernt haben. Stattdessen haben wir uns für eine einheitliche Strategie entschieden, bei der alle Anwendungsdienste und die Infrastruktur des Systems von den Kunden gemeinsam genutzt werden. Du wirst auch sehen, dass ich unter den Begriff "Kunde" durch "Mieter" ersetzt habe. In Kapitel 2 werden wir uns näher mit dem Begriff "Tenancy" befassen. Der Grundgedanke ist, dass wir unsere Umgebung anders betrachten, wenn wir zu dieser einheitlichen Denkweise übergehen. Es handelt sich nun um eine Reihe von Ressourcen, die von einem oder mehreren Verbrauchern genutzt werden. Die Idee ist, dass diese Verbraucher temporäre Bewohner deiner Umgebung sind, die nur die Ressourcen verbrauchen, die sie brauchen - daher der Begriff "Mieter".

Die Übertragung einer Anwendung in eine gemeinsame Infrastruktur beseitigt viele der Nachteile, die mit getrennten Kundenumgebungen verbunden sind. Jetzt, wo alles gemeinsam genutzt wird, haben wir eine Reihe von Ressourcen, die gemeinsam skaliert, verwaltet und betrieben werden können. Auf der rechten Seite von Abbildung 1-2 siehst du, dass ich einen Kasten hinzugefügt habe, der die Verwaltung, den Betrieb und die Bereitstellung dieser Umgebung darstellt. Stell dir vor, wie das die Verteilung von Updates vereinfachen würde. Bei einer gemeinsam genutzten Infrastruktur würde deine Verteilungsautomatisierung das Update einfach in diese einheitliche SaaS-Umgebung einspielen, und alle deine Kunden hätten sofort Zugriff auf die Änderungen. Die Vorstellung, dass Kundenumgebungen separat bereitgestellt, versioniert, verwaltet und betrieben werden, gehört der Vergangenheit an.

Die Vorteile einer gemeinsam genutzten Infrastruktur erstrecken sich auf fast jeden Aspekt eines Softwareunternehmens. Sie kann das Sammeln und Erfassen von Betriebsdaten rationalisieren. Sie kann die Komplexität deiner DevOps-Automatisierung vereinfachen. Es macht das Onboarding von neuen Mietern einfacher. Der vielleicht größte Vorteil ist die Kosteneffizienz, die durch die gemeinsame Nutzung der Infrastruktur erreicht werden kann. Die Möglichkeit, den Verbrauch der Infrastruktur mit der tatsächlichen Aktivität der Mieter zu korrelieren, ermöglicht es den Teams, ihre Gewinnspannen zu maximieren und Größenvorteile zu erzielen.

Du kannst dir vorstellen, wie attraktiv dieses Modell für die Organisationen war, die mit den Kosten und betrieblichen Herausforderungen des klassischen Modells zu kämpfen hatten. Es vereinheitlicht nicht nur die Erfahrung, sondern bringt auch ein neues Maß an Agilität in diese Umgebungen. Richtig aufgebaut, bieten diese Umgebungen die Möglichkeit, neue Funktionen und Fähigkeiten viel schneller zu veröffentlichen, so dass Unternehmen flexibler auf die Bedürfnisse der Kunden und des Marktes reagieren können. Die Art dieses Modells schafft auch neue Wachstumschancen für einige ISVs, da sie schneller neue Tenants hinzufügen können, ohne ihre Gewinnspannen zu schmälern und zusätzliche betriebliche Gemeinkosten zu absorbieren. Die elastische, umlagefinanzierte Natur der Cloud-Infrastruktur passt ebenfalls gut zu diesem Modell und unterstützt die Preis- und Skalierungsmodelle, die natürlich zur Elastizität der Cloud passen.

Der Wechsel zu einer gemeinsamen Infrastruktur bringt auch eine Reihe neuer Herausforderungen mit sich. Im Laufe dieses Buches wirst du alle Nuancen und die Komplexität kennenlernen, die mit einer gemeinsam genutzten Infrastruktur einhergehen. Die Unterstützung einer gemeinsam genutzten Infrastruktur hat einen direkten Einfluss auf die Sicherheit, Leistung, Skalierung, Verfügbarkeit und Ausfallsicherheit deiner SaaS-Umgebung. Diese Faktoren haben einen deutlichen Einfluss darauf, wie du an die Gestaltung und Umsetzung deiner SaaS-Umgebung herangehst.

Hinweis

Der Gedanke, dass alle Mieter dieselbe Version deines Angebots nutzen, ist ein allgemeiner Lackmustest für SaaS-Umgebungen. Sie ist die Grundlage für viele der geschäftlichen Vorteile, die bei der Einführung eines SaaS-Bereitstellungsmodells im Mittelpunkt stehen.

Um ein einheitliches Erlebnis zu schaffen, müssen wir auch eine Reihe neuer, übergreifender Komponenten einführen, die alle Funktionen bieten, die für die zentrale Verwaltung, den Betrieb und die Bereitstellung einer SaaS-Anwendung erforderlich sind. Die Ausarbeitung dieser einzelnen Komponenten ist für den Aufbau eines erfolgreichen und skalierbaren SaaS-Geschäfts unerlässlich - auch wenn deine Anwendung keine gemeinsame Infrastruktur hat. In Wirklichkeit sind diese Komponenten das Herzstück der Agilität, Innovation und Effizienz von SaaS-Unternehmen. Um das besser zu verstehen, werfen wir einen etwas anderen Blick auf eine SaaS-Umgebung (siehe Abbildung 1-3).

Abbildung 1-3. Aufbau übergreifender SaaS-Fähigkeiten

In der Mitte von Abbildung 1-3 siehst du einen Platzhalter für deine SaaS-Anwendung. Hier werden die verschiedenen Komponenten deiner SaaS-Anwendung implementiert. Hier findest du auch die Infrastruktur deiner Anwendung. Rund um die Anwendung gibt es eine Reihe von Komponenten, die benötigt werden, um die allgemeinen Anforderungen deiner SaaS-Umgebung zu erfüllen. Oben habe ich zum Beispiel das Onboarding und die Identität hervorgehoben, die alle Funktionen bereitstellen, um einen neuen Mieter in dein System aufzunehmen. Auf der linken Seite siehst du die Platzhalter für die SaaS-Bereitstellungs- und Verwaltungsfunktionen. Und auf der rechten Seite siehst du die grundlegenden Konzepte wie Abrechnung, Zählung, Metriken und Analysen.

Für viele SaaS-Entwickler ist es verlockend, diese umgebenden Komponenten als sekundäre, weniger wichtige Elemente ihrer SaaS-Architektur zu betrachten. Tatsächlich habe ich mit Teams zusammengearbeitet, die sich entschieden haben, die Einführung dieser Komponenten/Dienste aufzuschieben und ihre gesamte Energie und Mühe in die Entwicklung ihrer mandantenfähigen Anwendungen zu stecken.

Die richtige Anwendungsarchitektur ist zwar ein wichtiger Teil deines SaaS-Modells, aber der Erfolg deines SaaS-Geschäfts wird stark von den Fähigkeiten der umgebenden Komponenten beeinflusst. Sie sind die Grundlage für die betriebliche Effizienz, das Wachstum, die Innovation und die Flexibilität, die Unternehmen dazu bewegen, ein SaaS-Modell einzuführen. Daher müssen diese Komponenten - die allen SaaS-Umgebungen gemeinsam sind - bei der Entwicklung deiner SaaS-Lösung im Vordergrund stehen. Deshalb habe ich SaaS-Teams immer dazu ermutigt, ihre SaaS-Entwicklung mit diesen Bausteinen zu beginnen. Diese Bausteine - die nichts mit der Funktionalität deiner Anwendung zu tun haben - werden einen erheblichen Einfluss auf den SaaS-Fußabdruck deiner Architektur, deines Designs, deines Codes und deines Geschäfts haben.

Dies soll verdeutlichen, dass es mehrere Dimensionen der SaaS-Effizienz und Agilität gibt. Ein Teil unserer Effizienz wird durch die hier gezeigten Dienste erreicht, ein anderer Teil durch die Strategien, die du für deine Anwendungsarchitektur anwendest. Wenn deine Anwendungsarchitektur die Infrastruktur gemeinsam nutzt, kann dies zu mehr Effizienz und Skaleneffekten in deiner Umgebung führen. Entscheidend ist, dass diese umgebenden Dienste die grundlegenden Elemente unseres einheitlichen Modells darstellen müssen. Von dort aus können wir dann überlegen, wie/ob die Anwendungsarchitektur ebenfalls optimiert werden kann, um die Effizienz und Agilität zu maximieren.

Multi-Tenancy neu definieren

Bis zu diesem Punkt habe ich es vermieden, den Begriff "Multi-Tenancy" einzuführen. Es ist ein Begriff, der im SaaS-Bereich häufig verwendet wird und im weiteren Verlauf dieses Buches immer wieder auftauchen wird. Wir müssen uns diesem Begriff jedoch mit Bedacht nähern. Die Idee der Multi-Tenancy kommt mit einer Menge Gepäck daher, und bevor ich es sortiere, möchte ich ein paar Grundlagen schaffen, die die Unternehmen zur Einführung des SaaS-Bereitstellungsmodells bewegt haben. Der andere Teil der Herausforderung besteht darin, dass der Begriff der Mandantenfähigkeit - wie wir ihn in diesem Buch definieren werden - über einige der traditionellen Definitionen hinausgeht, die mit diesem Begriff normalerweise verbunden sind.

Jahrelang wurde in vielen Kreisen der Begriff "Multi-Tenant" verwendet, um die Idee zu vermitteln, dass eine Ressource von mehreren Mietern geteilt wird. Das kann in vielen Kontexten zutreffen. Wir könnten zum Beispiel sagen, dass ein Teil der Cloud-Infrastruktur als mandantenfähig gilt, weil er es den Mietern erlaubt, Teile der zugrunde liegenden Infrastruktur gemeinsam zu nutzen. Viele Dienste, die in der Cloud laufen, können in einem Multi-Tenant-Modell betrieben werden, um Größenvorteile zu erzielen. Als Cloud-Kunde kann dies außerhalb deines Blickfelds geschehen. Sogar in selbst gehosteten Umgebungen können Teams Lösungen entwickeln, bei denen ihre Rechen-, Datenbank- und anderen Ressourcen von den Tenants gemeinsam genutzt werden. Dadurch entsteht eine enge Verbindung zwischen Multi-Tenancy und der Idee einer gemeinsam genutzten Ressource. In diesem Zusammenhang ist dies sogar ein absolut gültiger Begriff für Multi-Tenancy.

Wenn wir nun anfangen, über SaaS-Umgebungen nachzudenken, ist es ganz natürlich, dass wir die Zuordnung von Multi-Tenancy mit einbeziehen. Schließlich teilen sich SaaS-Umgebungen die Infrastruktur, und diese gemeinsame Nutzung der Infrastruktur kann man durchaus als mandantenfähig bezeichnen.

Um diesen Punkt besser zu veranschaulichen, schauen wir uns ein SaaS-Beispielmodell an, das die in diesem Kapitel besprochenen Konzepte zusammenfasst. Das Bild in Abbildung 1-4 zeigt ein Beispiel für eine mandantenfähige SaaS-Umgebung.

Abbildung 1-4. Ein Beispiel für eine mandantenfähige Umgebung

In diesem Beispiel haben wir die gemeinsame Infrastruktur unserer Anwendungsdienste in eine Reihe von Microservices eingebettet, die alle beweglichen Teile unserer SaaS-Umgebung verwalten und betreiben. Wenn wir davon ausgehen, dass alle unsere Mandanten ihre Infrastruktur (Rechenleistung, Speicherung usw.) gemeinsam nutzen, entspricht dies der klassischen Definition von Multi-Tenancy und es ist nicht ungewöhnlich, dass SaaS-Anbieter ihre Lösung nach diesem Muster definieren und anbieten.

Die Herausforderung besteht darin, dass SaaS-Umgebungen nicht ausschließlich nach diesem Modell aufgebaut sind. Angenommen, ich erstelle eine SaaS-Umgebung, die wie in Abbildung 1-5 aussieht.

Abbildung 1-5. Mehrmandantenfähigkeit mit gemeinsam genutzten und dedizierten Ressourcen

Beachte, dass wir den Footprint einiger unserer Anwendungs-Microservices verändert haben. Der Microservice Produkt ist unverändert. Seine Rechen- und Speicherinfrastruktur wird weiterhin von allen Tenants gemeinsam genutzt. Wenn wir jedoch zum Microservice Order übergehen, wirst du sehen, dass wir die Dinge ein wenig durcheinander gebracht haben. Unsere Anforderungen an die Domäne, die Leistung und/oder die Sicherheit haben dazu geführt, dass wir die Speicherung für jeden Tenant getrennt haben. Die Rechenleistung unseres Microservices "Bestellung" wird also weiterhin gemeinsam genutzt, aber wir haben für jeden Tenant eine eigene Datenbank.

Schließlich hat sich auch unser Fulfillment Microservice verändert. Unsere Anforderungen drängten uns zu einem Modell, bei dem jeder Tenant über eigene Rechenressourcen verfügt. In diesem Fall wird die Datenbank jedoch weiterhin von allen Tenants gemeinsam genutzt.

Diese Architektur hat unserer Vorstellung von Multi-Tenancy eine neue Dimension verliehen. Wenn wir uns an die reinste Definition von Multi-Tenancy halten, können wir nicht sagen, dass alles, was hier läuft, der ursprünglichen Definition von Multi-Tenancy entspricht. Die Speicherung des Bestelldienstes zum Beispiel teilt sich keine Infrastruktur mit anderen Mietern. Die Rechenleistung unserer Fulfillment-Microservices wird ebenfalls nicht gemeinsam genutzt, aber die Datenbank für diesen Dienst wird von allen Tenants gemeinsam genutzt.

Im SaaS-Universum ist es üblich, die Grenzen zwischen den einzelnen Mandanten zu verwischen. Wenn du eine SaaS-Umgebung zusammenstellst, hältst du dich nicht an eine absolute Definition von Mandantenfähigkeit, sondern wählst die Kombinationen aus gemeinsam genutzten und dedizierten Ressourcen, die am besten zu den geschäftlichen und technischen Anforderungen deines Systems passen. Das alles ist Teil der Optimierung deiner SaaS-Architektur für die Bedürfnisse deines Unternehmens.

Auch wenn die Ressourcen hier nicht von allen Tenants gemeinsam genutzt werden, gelten die grundlegenden SaaS-Prinzipien, die wir zuvor beschrieben haben. In dieser Umgebung würde sich zum Beispiel unser Ansatz zur Anwendungsbereitstellung nicht ändern. Alle Tenants in dieser Umgebung würden immer noch dieselbe Version des Produkts verwenden. Außerdem würde die Umgebung nach wie vor von denselben Shared Services betrieben und verwaltet, auf die wir uns in unserem vorherigen Beispiel verlassen haben. Das bedeutet, dass wir immer noch einen Großteil der betrieblichen Effizienz und Agilität aus dieser Umgebung herausholen, die in einer vollständig gemeinsam genutzten Infrastruktur erreicht worden wäre (mit einigen Einschränkungen).

Um diesen Punkt zu verdeutlichen, betrachten wir ein etwas extremeres Beispiel. Angenommen, wir haben eine SaaS-Architektur, die dem in Abbildung 1-6 gezeigten Modell ähnelt. In diesem Beispiel müssen wir aufgrund von Markt- und/oder Legacy-Anforderungen alle Rechen- und Speicherressourcen in einem dedizierten Modell betreiben, bei dem jeder Tenant über eine völlig separate Infrastruktur verfügt.

Abbildung 1-6. Eine Multi-Tenant-Umgebung mit vollständig dedizierten Ressourcen

Unsere Mieter teilen sich in diesem Modell zwar nicht die Infrastruktur, aber du wirst sehen, dass sie weiterhin über dieselben gemeinsamen Funktionen, die sich durch alle unsere Beispiele ziehen, an Bord geholt, verwaltet und betrieben werden. Das bedeutet, dass alle Mieter immer noch dieselbe Version der Software nutzen und dass sie weiterhin gemeinsam verwaltet und betrieben werden.

Das mag ein unwahrscheinliches Szenario sein. In der Praxis können SaaS-Anbieter jedoch viele verschiedene Faktoren haben, die sie dazu zwingen, dieses Modell zu verwenden. Migrierende SaaS-Anbieter nutzen dieses Modell oft als erstes Sprungbrett zu SaaS. In anderen Branchen sind die Anforderungen an die Isolierung so hoch, dass eine gemeinsame Nutzung der Infrastruktur nicht möglich ist. Es gibt eine lange Liste von Faktoren, die einen SaaS-Anbieter zu diesem Modell zwingen können.

Vor diesem Hintergrund stellt sich die Frage, wie wir Multi-Tenancy im Kontext einer SaaS-Umgebung definieren wollen. Die buchstäbliche Definition von Mandantenfähigkeit als gemeinsam genutzte Infrastruktur scheint nicht gut zu den verschiedenen Modellen zu passen, die für die Bereitstellung einer Tenant-Infrastruktur verwendet werden können. Stattdessen scheinen die verschiedenen SaaS-Modelle zu verlangen, dass wir unsere Definition von Multi-Tenant weiterentwickeln.

Zumindest im Rahmen dieses Buches wird der Begriff "Multi-Tenant" auf jeden Fall erweitert, um den hier beschriebenen Realitäten Rechnung zu tragen. Im weiteren Verlauf wird sich der Begriff "Multi-Tenant" auf jede Umgebung beziehen, in der Tenants über eine einzige, vereinheitlichte Erfahrung aufgenommen, eingerichtet, verwaltet und betrieben werden. Die gemeinsame Nutzung einer Infrastruktur hat nichts mit dem Begriff "Multi-Tenancy" zu tun.

In den folgenden Kapiteln werden wir neue Terminologie einführen, die uns helfen wird, einige der Unklarheiten zu beseitigen, die mit Multi-Tenancy verbunden sind.

Wo liegen die Grenzen von SaaS?

Wir haben eine Grundlage dafür geschaffen, was es bedeutet, SaaS zu sein, aber es gibt viele Nuancen, über die wir nicht wirklich gesprochen haben. Stell dir zum Beispiel vor, deine SaaS-Anwendung erfordert, dass Teile des Systems an einem externen Ort bereitgestellt werden, oder stell dir Szenarien vor, in denen deine Anwendung von den Lösungen anderer Anbieter abhängig ist. Vielleicht nutzt du ein Abrechnungssystem eines Drittanbieters, oder deine Daten müssen in einer anderen Umgebung liegen. Es gibt eine Vielzahl von Gründen, warum du Teile deiner SaaS-Umgebung an einem Ort hosten lassen musst, der nicht vollständig unter deiner Kontrolle steht.

Wie passt diese verteilte Struktur mit der Idee zusammen, ein einziges, einheitliches Erlebnis für alle deine Mieter/innen zu schaffen? Wenn du die volle Kontrolle über alle beweglichen Teile deines Systems hast, kannst du sicherlich schneller innovieren und handeln. Gleichzeitig ist es unpraktisch zu denken, dass einige SaaS-Anbieter nicht mit Domain- und Technologie-Realitäten konfrontiert werden, die sie dazu zwingen, extern gehostete Komponenten, Tools oder Technologien zu unterstützen.

An dieser Stelle sollten wir mit unserer Definition von SaaS nicht zu extrem werden. Für mich liegt die Grenze eher darin, wie diese externen Abhängigkeiten konfiguriert, verwaltet und betrieben werden. Wenn diese Abhängigkeiten für deine Mieter/innen nicht sichtbar sind und sie trotzdem über deine zentrale Erfahrung verwaltet und betrieben werden, ist das für mich immer noch SaaS. Es mag neue Komplexitäten mit sich bringen, aber es ändert nichts am Geist des SaaS-Modells, das wir aufzubauen versuchen.

Interessant wird es, wenn SaaS-Anbieter auf externe Ressourcen zurückgreifen, die von ihren Kunden direkt eingesehen werden können. Wenn meine SaaS-Lösung zum Beispiel Daten in einer vom Mieter gehosteten Datenbank speichert, wird die Sache brenzlig. Es kann sein, dass du von einer Infrastruktur abhängig bist, die nicht vollständig unter deiner Kontrolle steht. Die Aktualisierung dieser Datenbank, die Änderung ihres Schemas, die Verwaltung ihres Zustands - all das wird bei diesem Modell komplizierter. An dieser Stelle stellt sich die Frage, ob diese externe Ressource die dritte Wand von SaaS durchbricht, die Tenants der Infrastruktur aussetzt und Erwartungen oder Abhängigkeiten schafft, die die Agilität, den Betrieb und die Innovation deiner SaaS-Umgebung untergraben.

Meine allgemeine Faustregel (mit einigen Ausnahmen) lautet , dass wir eine Serviceerfahrung anbieten. In einem Servicemodell ist die Sicht unserer Kunden auf die Oberfläche unseres Dienstes beschränkt. Die Werkzeuge, Technologien und Ressourcen, mit denen dieser Dienst zum Leben erweckt wird, sollten für unsere Kunden völlig verborgen bleiben. In vielerlei Hinsicht ist dies die harte Barriere, die verhindert, dass unser System in Muster zurückfällt, die zu einmaligen Abhängigkeiten und Variationen führen könnten.

Das Modell des Managed Service Providers

Es gibt noch einen letzten Punkt, den wir auf ansprechen müssen, wenn wir versuchen, unsere Vorstellung von einer mandantenfähigen SaaS-Umgebung zu verfeinern. Einige Unternehmen haben sich für ein Modell entschieden, das als Managed Service Provider (MSP) bezeichnet wird. In manchen Fällen wird MSP als eine Variante von SaaS eingestuft. Das hat zu einiger Verwirrung im SaaS-Bereich geführt. Um die Herausforderungen besser zu verstehen, schauen wir uns zunächst eine MSP-Umgebung an und sehen, wie und wo sie in diese Diskussion passt. Abbildung 1-7 zeigt eine konzeptionelle Darstellung einer MSP-Umgebung.

Dieses Modell ähnelt dem klassischen Modell der installierten Software, das wir bereits beschrieben haben. Unten in diesem Diagramm siehst du eine Reihe von Kunden, die verschiedene Versionen des Produkts eines Softwareanbieters einsetzen. Jeder dieser Kunden wird in seiner eigenen Infrastruktur oder Umgebung betrieben.

Mit MSP versuchen wir jedoch, Effizienz- und Skaleneffekte zu erzielen, indem wir den Betrieb an ein zentrales Team oder Unternehmen übertragen. Das ist der Service, den diese MSPs anbieten. Sie sind oft selbst für die Installation, Verwaltung und Unterstützung jedes einzelnen Kunden verantwortlich und versuchen, aus den Werkzeugen und Mechanismen, die sie für den Betrieb dieser Kundenumgebungen einsetzen, eine gewisse Skalierbarkeit und Effizienz herauszuholen.

Abbildung 1-7. Das Modell eines Managed Service Providers (MSP)

Ich habe auch den Softwareanbieter oben im Diagramm dargestellt. Damit soll zum Ausdruck gebracht werden, dass der Softwareanbieter möglicherweise Beziehungen zu einem oder mehreren MSPs unterhält, die die Umgebungen ihrer Kunden verwalten.

Du kannst dir vorstellen, dass einige das MSP-Modell mit SaaS gleichsetzen könnten. Schließlich scheint es ja auch darum zu gehen, allen Kunden ein einheitliches Verwaltungs- und Betriebserlebnis zu bieten. Wenn du dir jedoch die Prinzipien ansiehst, die wir zur Beschreibung von SaaS verwendet haben, wirst du feststellen, dass es erhebliche Unterschiede zwischen dem MSP-Modell und SaaS gibt. Einer der größten Unterschiede besteht darin, dass es den Kunden erlaubt ist, verschiedene Versionen zu betreiben. Es gibt zwar einige Versuche, die Verwaltung und den Betrieb zu zentralisieren, aber der MSP muss seine Betriebserfahrungen individuell anpassen, um die verschiedenen Umgebungen seiner Kunden zu unterstützen. Dies kann spezielle Teams erfordern, zumindest aber Teams, die sich mit den komplexen Anforderungen jedes einzelnen Kunden auseinandersetzen können. Auch hier bietet das MSP-Modell einen großen Mehrwert und schafft zweifellos Effizienzgewinne, aber es ist definitiv anders als eine einzelne Glasscheibe, die ihre Effizienz dadurch erhält, dass die Kunden eine einzige Version eines Produkts einsetzen und in vielen Fällen durch die gemeinsame Nutzung eines Teils oder der gesamten Infrastruktur Größenvorteile erzielen. Auf einer bestimmten Ebene des MSP-Modells wirst du wahrscheinlich immer noch mit den Problemen zu kämpfen haben, die sich aus den einmaligen Kundenvariationen ergeben. MSPs können einige Maßnahmen ergreifen, um einige der Herausforderungen auszugleichen, aber sie werden immer noch mit der Komplexität des Betriebs und der Agilität konfrontiert sein, die mit der Unterstützung einzigartiger, einmaliger Anforderungen separater Kundenumgebungen einhergehen.

Der andere Unterschied bezieht sich auf die Art und Weise, wie SaaS-Teams strukturiert sind und arbeiten . Im Allgemeinen versuchen wir in einer SaaS-Organisation zu vermeiden, harte Grenzen zwischen den Betriebsteams und dem Rest der Organisation zu ziehen. Wir wollen, dass Betriebsteams, Architekten, Product Owner und die verschiedenen Rollen unseres Teams eng zusammenarbeiten, um das Serviceerlebnis ihres Angebots kontinuierlich zu bewerten und zu verbessern.

Das bedeutet in der Regel, dass diese Teams eng miteinander verbunden sind. Sie sind gleichermaßen daran interessiert, zu verstehen, wie ihre Kunden ihre Systeme nutzen, wie sie die Last auferlegen, wie sie an Bord kommen und viele andere wichtige Informationen. SaaS-Unternehmen wollen und müssen den Finger am Puls ihrer Systeme haben. Das ist wichtig, um den Erfolg des Unternehmens voranzutreiben und direkt mit dem Kundenerlebnis verbunden zu sein. Auch wenn dies eine weniger konkrete Grenze ist, so stellt sie doch einen wichtigen Unterschied zwischen SaaS und MSP dar.

Es ist wichtig, darauf hinzuweisen, dass MSP ein völlig gültiges Modell ist. Für einige Software-Anbieter ist es oft eine gute Lösung. Für einige SaaS-Anbieter kann MSP sogar ein Sprungbrett sein, das ihnen Zugang zu einigen Effizienzen verschafft, während das Team weiter auf sein SaaS-Bereitstellungsmodell zusteuert. Wichtig ist, dass wir die Grenzen zwischen SaaS und MSP genau kennen und vermeiden, SaaS und MSP als Synonym zu betrachten.

Im Kern ist SaaS ein Geschäftsmodell

Inzwischen solltest du eine bessere Vorstellung davon haben , was wir unter SaaS verstehen. Es sollte klar sein, dass es bei SaaS vor allem darum geht, eine technologische, geschäftliche und betriebliche Kultur zu schaffen, die sich ganz auf die Erzielung bestimmter Geschäftsergebnisse konzentriert. Es ist zwar verlockend, SaaS durch die Brille von Technologiemustern und -strategien zu betrachten, aber eigentlich sollte man SaaS eher als Geschäftsmodell sehen.

Um diese Denkweise besser zu verstehen, solltest du dir überlegen, wie sich die Einführung von SaaS auf das Geschäft eines SaaS-Anbieters auswirkt. Sie beeinflusst und prägt direkt, wie die Teams ihre Angebote entwickeln, verwalten, betreiben, vermarkten, unterstützen und verkaufen. Die SaaS-Prinzipien sind letztlich in die Kultur von SaaS-Unternehmen eingewoben und verwischen die Grenzen zwischen dem geschäftlichen und dem technischen Bereich. Bei SaaS konzentriert sich die Geschäftsstrategie darauf, einen Service zu entwickeln, mit dem das Unternehmen auf aktuelle und neue Marktbedürfnisse reagieren kann, ohne an Dynamik zu verlieren oder das Wachstum zu gefährden.

Ja, Features und Funktionen sind für SaaS-Unternehmen immer noch wichtig. In einem SaaS-Unternehmen werden die Funktionen jedoch selten auf Kosten der Agilität und betrieblichen Effizienz eingeführt. Wenn du eine mandantenfähige SaaS-Lösung anbietest, sollten die Bedürfnisse der Vielen immer wichtiger sein als die Bedürfnisse der Wenigen. Vorbei sind die Zeiten, in denen du einmaligen Gelegenheiten nachjagst, die einen speziellen, einmaligen Support erfordern, der auf Kosten des langfristigen Erfolgs des Dienstes geht.

Diese veränderte Denkweise beeinflusst fast jede Rolle in einem SaaS-Unternehmen. Die Rolle des Produktverantwortlichen ändert sich zum Beispiel erheblich. Produktverantwortliche müssen ihre Sichtweise erweitern und bei der Erstellung ihres Backlogs auch betriebliche Aspekte berücksichtigen. Onboarding-Erfahrung, Time-to-Value, Agilität - all das sind Beispiele für Punkte, die der Product Owner auf dem Radar haben muss. Er muss diese operativen Eigenschaften, die für den Aufbau eines erfolgreichen SaaS-Geschäfts unerlässlich sind, priorisieren und bewerten. Architekten, Ingenieure und QS-Mitarbeiter sind von diesem Wandel ebenfalls betroffen. Sie müssen sich jetzt mehr Gedanken darüber machen, wie die Lösung, die sie entwerfen, bauen und testen, die dynamischeren Anforderungen an das Serviceerlebnis erfüllen kann. Auch die Art und Weise, wie dein SaaS-Angebot vermarktet, bepreist, verkauft und unterstützt wird, ändert sich. Dieses Thema der neuen und sich überschneidenden Verantwortlichkeiten ist den meisten SaaS-Unternehmen gemeinsam.

Die Frage ist also: Was sind die Kernprinzipien, die das Geschäftsmodell von SaaS-Unternehmen prägen und leiten? Auch wenn die Antwort auf diese Frage umstritten ist, gibt es doch einige Kernthemen, die die Geschäftsstrategien von SaaS-Unternehmen zu bestimmen scheinen. Im Folgenden werden diese zentralen SaaS-Geschäftsziele beschrieben:

Agilität

Dieser Begriff wird in der Softwarebranche oft überstrapaziert . Gleichzeitig wird er im SaaS-Universum oft als einer der Grundpfeiler und Motivationsfaktoren eines SaaS-Geschäfts angesehen. Viele Unternehmen, die auf SaaS umsteigen, tun dies, weil sie mit ihrem derzeitigen Modell nicht mehr zurechtkommen. Bei der Einführung von SaaS geht es darum, zu einer Kultur und Denkweise überzugehen, die den Schwerpunkt auf Geschwindigkeit und Effizienz legt. Neue Versionen herausbringen, auf die Marktdynamik reagieren, neue Kundensegmente ansprechen, Preismodelle ändern - das sind nur einige der vielen Vorteile, die sich Unternehmen von der Einführung eines SaaS-Modells versprechen. Die Gestaltung, der Betrieb und der Verkauf deines Dienstes sind von dem Wunsch nach maximaler Flexibilität geprägt. Ein mandantenfähiges Angebot, das die Kosten senkt, ohne die Agilität zu erhöhen, würde das allgemeine Nutzenversprechen von SaaS mit Sicherheit verfehlen.

Operative Effizienz

Bei SaaS geht es in vielerlei Hinsicht um Skalierung . In einer Multi-Tenant-Umgebung konzentrieren wir uns darauf, unseren Kundenstamm kontinuierlich zu vergrößern, ohne dass wir spezielle Ressourcen oder Teams benötigen, um neue Kunden zu gewinnen. Bei SaaS geht es im Wesentlichen darum, eine betriebliche und technologische Basis zu schaffen, die ein kontinuierliches und im Idealfall schnelles Wachstum ermöglicht. Um dieses Wachstum zu unterstützen, musst du in den Aufbau einer effizienten betrieblichen Basis für dein gesamtes Unternehmen investieren. Ich frage SaaS-Unternehmen oft, was passieren würde, wenn sich morgen 1.000 neue Kunden für ihren Service anmelden würden. Manche würden sich darüber freuen, andere schrecken zurück. Diese Frage wirft oft wichtige Fragen über die betriebliche Effizienz eines SaaS-Unternehmens auf. Es ist wichtig zu wissen, dass es bei der betrieblichen Effizienz auch darum geht, auf Kundenbedürfnisse zu reagieren und diese zu erfüllen. Wie schnell neue Funktionen auf den Markt kommen, wie schnell Kunden an Bord kommen, wie schnell Probleme gelöst werden - all das ist Teil der betrieblichen Effizienz. Jeder Teil des Unternehmens kann eine Rolle beim Aufbau eines effizienten Angebots spielen.

Innovation

Die Möglichkeit, sich schneller zu bewegen hat viele Vorteile für SaaS-Unternehmen. Sie haben mehr Freiraum und sind offener für Experimente und Änderungen ihrer Strategie. Die Investitionen in Agilität und betriebliche Effizienz ermöglichen es den Unternehmen, viel beweglicher und flexibler zu sein. So können sie neue Chancen, neue Marktsegmente, neue Verpackungs- und Preisstrategien und eine Vielzahl anderer Möglichkeiten nutzen. Das übergeordnete Ziel ist es, die grundlegenden Stärken deines Betriebs- und Kostenmodells als Treibstoff für deinen Innovationsmotor zu nutzen. Diese Innovation kann eine große Rolle für den allgemeinen Erfolg deines SaaS-Geschäfts spielen.

Reibungsloses Onboarding

SaaS-Unternehmen müssen sich genau überlegen, wie Kunden in ihre Umgebung eingeführt werden. Wenn du versuchst, so agil und effizient wie möglich zu arbeiten, musst du auch darüber nachdenken, wie das Onboarding der Kunden optimiert werden kann. Bei einigen SaaS-Unternehmen wird dies durch eine klassische Anmeldeseite erreicht, auf der die Kunden den Onboarding-Prozess vollständig selbständig abschließen können. In anderen Umgebungen verlassen sich Unternehmen vielleicht auf einen internen Prozess, um das Onboarding voranzutreiben. Entscheidend ist, dass sich jedes SaaS-Unternehmen darauf konzentrieren muss, ein Onboarding-Erlebnis zu schaffen, das Reibungsverluste beseitigt und Flexibilität und betriebliche Effizienz ermöglicht. Für einige wird dies ganz einfach sein. Für andere ist es vielleicht schwieriger, die Art und Weise zu überdenken, wie das Team den Onboarding-Prozess aufbaut, betreibt und automatisiert.

Wachstum

In jedem Unternehmen geht es um Wachstum. SaaS-Unternehmen haben jedoch in der Regel eine andere Vorstellung von Wachstum. Sie investieren in ein Modell und eine Organisationsstruktur, die auf Wachstum ausgelegt ist. Stell dir vor, du baust eine hocheffiziente Autofabrik, die jeden Schritt im Bauprozess optimiert und automatisiert. Dann stell dir vor, dass sie nur zwei Autos pro Tag produzieren soll. Das wäre ziemlich sinnlos. Mit SaaS bauen wir ein Unternehmen auf, das den gesamten Prozess der Kundenakquise, -anwerbung, -betreuung und -verwaltung rationalisiert. Ein SaaS-Unternehmen tätigt diese Investition in der Erwartung, dass sie die Wachstumsmaschine unterstützt und antreibt, die letztendlich die Gewinnspannen und den allgemeinen Erfolg des Unternehmens beeinflusst. Wenn wir hier also von Wachstum sprechen, meinen wir eine Beschleunigung, die ohne die Agilität, die betriebliche Effizienz und die Innovation, die Teil von SaaS sind, nicht möglich wäre. Wie viel Wachstum du erreichst, ist relativ. Für einige bedeutet Wachstum vielleicht 100 neue Kunden, für andere 50.000. Auch wenn die Art deiner Größe variieren kann, ist das Ziel, wachstumsorientiert zu sein, für alle SaaS-Unternehmen gleichermaßen wichtig.

Die hier dargestellten Punkte stellen einige der wichtigsten SaaS-Geschäftsprinzipien dar. Es handelt sich um Konzepte, die in einem SaaS-Unternehmen von oben nach unten vorangetrieben werden sollten, wobei die Unternehmensführung einen klaren Schwerpunkt auf eine Geschäftsstrategie legt, die sich auf die Schaffung von Wachstum durch Investitionen in Agilität, betriebliche Effizienz und Wachstumsziele konzentriert.

Fast jede Dimension deiner SaaS-Architektur und -Strategie leitet sich von deiner Geschäftsvision ab. Die Zielkunden-Personas, das Paket, die Preisgestaltung, das Kostenmodell und eine Vielzahl anderer Faktoren werden die Architektur, den Betrieb und die Verwaltung der Lösung beeinflussen, die du letztendlich aufbaust. Wenn du dir über diese Punkte nicht im Klaren bist und sie nicht mit deinem Unternehmen abstimmst, wirst du wahrscheinlich nicht in der Lage sein, ein SaaS-Angebot zu entwickeln, das deine Unternehmensziele vollständig umsetzt ( ).

Eine Dienstleistung aufbauen - kein Produkt

Viele Softwareanbieter sehen sich selbst als Hersteller von Produkten. Und in vielerlei Hinsicht passt das auch zu ihrem Geschäftsmodell. Wir stellen etwas her, der Kunde erwirbt es und kann es dann größtenteils selbst nutzen. Es gibt viele Varianten und Nuancen dieses produktzentrierten Modells, aber sie alle tendieren zu einem Modell, bei dem es darum geht, etwas Statisches zu entwickeln und es von den Kunden kaufen zu lassen.

Bei dieser produktorientierten Denkweise liegt der Schwerpunkt in der Regel auf der Definition von Merkmalen und Funktionen, die es einem Softwareanbieter ermöglichen, Lücken zu schließen und neue Chancen zu nutzen. Bei SaaS geht es nicht mehr darum, ein Produkt, sondern eine Dienstleistung zu entwickeln. Handelt es sich dabei nur um eine Terminologie oder hat sie einen bedeutenden Einfluss darauf, wie wir an die Entwicklung eines SaaS-Angebots herangehen? Es stellt sich heraus, dass es sich um mehr als nur eine terminologische Veränderung handelt.

Wenn du Software als Dienstleistung anbietest, denkst du anders darüber nach, wie Erfolg aussieht. Ja, deine Lösung muss die funktionalen Bedürfnisse deiner Kunden erfüllen. Diese Dimension des Problems wird nicht verschwinden. Als Dienstleistung konzentrierst du dich jedoch viel stärker auf das Kundenerlebnis in allen Bereichen deines Unternehmens.

Schauen wir uns ein Beispiel an, das die Unterschiede zwischen einer Dienstleistung und einem Produkt besser verdeutlicht. Ein Restaurant bietet eine gute Kulisse, um diese Unterschiede zu untersuchen. Wenn du zum Essen gehst, freust du dich natürlich auf das Essen (das Produkt). Aber auch der Service ist ein Teil deines Erlebnisses. Wie schnell du an der Tür begrüßt wirst, wie schnell der Kellner an deinen Tisch kommt, wie schnell du Wasser bekommst und wie schnell dein Essen kommt - all das ist ein Maßstab für dein Serviceerlebnis. Unabhängig davon, wie gut das Essen ist, hat die Qualität des Service viel mit deinem Gesamteindruck des Restaurants zu tun.

Betrachte das Ganze mal aus der Perspektive eines SaaS-Angebots. Deine SaaS-Kunden werden ähnliche Erwartungen an den Service haben. Wie leicht sie deine Lösung einführen können, wie lange es dauert, bis sie einen Nutzen daraus ziehen, wie schnell neue Funktionen veröffentlicht werden, wie leicht sie Feedback geben können, wie häufig das System ausfällt - all das sind Dimensionen eines Services, die für SaaS-Teams im Vordergrund stehen müssen. Ein tolles Produkt nützt nichts, wenn das Gesamterlebnis für die Kunden nicht ihren Erwartungen entspricht.

Dies ist besonders wichtig, wenn die Software in einem SaaS-Modell bereitgestellt wird, bei dem der Mieter nur die Oberfläche deiner SaaS-Lösung sieht. SaaS-Mieter haben keinen Einblick in die zugrunde liegenden Elemente deines Systems. Sie machen sich keine Gedanken über Patches, Updates und die Konfiguration der Infrastruktur. Für sie ist nur wichtig, dass der Dienst ihnen ein Erlebnis bietet, mit dem sie den Wert deiner Lösung maximieren können.

In diesem Servicemodell sehen wir auch oft, dass SaaS-Unternehmen ihre operative Agilität nutzen, um die Kundenbindung zu erhöhen. Diese SaaS-Anbieter bringen neue Funktionen auf den Markt, reagieren auf Feedback und entwickeln ihre Systeme in einem rasanten Tempo weiter. Diese ständige und schnelle Innovation gibt den Kunden die Gewissheit, dass sie von dieser ständigen Weiterentwicklung profitieren werden. Tatsächlich ist dies oft das Instrument, mit dem aufstrebende SaaS-Unternehmen den traditionellen Nicht-SaaS-Marktführern das Geschäft wegnehmen können. Einige große, etablierte Marktführer haben zwar einen viel umfangreicheren Funktionsumfang, aber ihre Unfähigkeit, schnell auf Markt- und Kundenbedürfnisse zu reagieren, kann Kunden zu flinkeren SaaS-basierten Angeboten führen.

Dieser Vergleich zwischen Produkt und Dienstleistung mag zwar etwas pedantisch erscheinen, aber ich halte ihn für einen wesentlichen Teil des SaaS-Mentalmodells. Er steht in direktem Zusammenhang mit dem Gedanken, dass SaaS eine Denkweise ist, die die Herangehensweise ganzer SaaS-Organisationen an ihre Aufgaben und ihre Kunden prägt. In der Tat werden viele SaaS-Unternehmen eine Reihe von Kennzahlen einführen, die ihre Fähigkeit messen, ihre serviceorientierten Ziele zu erreichen. Es mag verlockend sein, dies als etwas zu betrachten, das zu einem späteren Zeitpunkt auf aufgeschraubt werden kann. Viele erfolgreiche SaaS-Organisationen verlassen sich jedoch auf diese Metriken als eine der wichtigsten Säulen ihres SaaS-Geschäfts.

SaaS definieren

Ich habe den größten Teil dieses Kapitels darauf verwendet, mehr Klarheit über die Grenzen, den Umfang und die Art von SaaS zu schaffen. Es scheint nur fair, alle Informationen, die wir hier besprochen haben ( ), zusammenzufassen und zu versuchen, eine explizite Definition von SaaS zu geben, die idealerweise die Konzepte und Prinzipien, die wir behandelt haben, einbezieht. Diese Definition fasst meiner Meinung nach am besten die Sichtweise von SaaS zusammen, die ich im weiteren Verlauf dieses Buches verwenden werde:

SaaS ist ein Geschäfts- und Softwarebereitstellungsmodell, das es Unternehmen ermöglicht, ihre Lösungen in einem reibungsarmen, dienstleistungszentrierten Modell anzubieten, das den Wert für Kunden und Anbieter maximiert. Es setzt auf Agilität und betriebliche Effizienz als Säulen einer Geschäftsstrategie, die Wachstum, Reichweite und Innovation fördert.

Du wirst sehen, dass sich diese Definition an das Thema SaaS als Geschäftsmodell hält. Technologien oder Architekturüberlegungen werden nicht erwähnt. Deine Aufgabe als SaaS-Architekt/in ist es, die zugrunde liegenden Muster und Strategien zu entwickeln, die es dem Unternehmen ermöglichen, seine Ziele zu erreichen. Das mag zwar wie die Aufgabe eines jeden Architekten erscheinen, aber es sollte klar sein, dass die einzigartige Mischung aus geschäftlichen und technologischen Anforderungen für SaaS-Umgebungen direkt in das Design, die Architektur und die Implementierung deiner SaaS-Lösung einfließen wird.

Fazit

In diesem Kapitel ging es darum, die grundlegenden Elemente der SaaS-Mentalität zu erläutern und dir eine Reihe von Konzepten und Begriffen an die Hand zu geben, die bei der Vertiefung von SaaS-Architekturmustern und -Strategien entscheidend sein werden. Ein wichtiger Teil unserer Diskussion konzentrierte sich darauf, die grundlegenden Ziele von SaaS zu verstehen und die Schlüsselelemente hervorzuheben, die so viele Unternehmen zur Einführung eines SaaS-Bereitstellungsmodells motiviert haben. Dazu mussten wir uns die klassischen Softwarebereitstellungsmodelle genauer ansehen und einige der traditionellen Herausforderungen, die mit diesen Modellen verbunden sind, aufzeigen. Anschließend habe ich untersucht, wie SaaS diese Herausforderungen überwinden kann, indem es Effizienz, Skaleneffekte und Agilität bietet, die ein höheres Maß an Wachstum und Innovation ermöglichen. Ein wichtiger Punkt ist, dass SaaS-Architekten und -Entwickler sich nicht nur auf die Entwicklung einer soliden SaaS-Anwendung konzentrieren dürfen - sie müssen auch darüber nachdenken, wie ihre Lösung die umfassenderen betrieblichen, agilen und effizienten Ziele des Unternehmens erreichen kann.

Ein großer Teil dieses Kapitels war auch darauf ausgerichtet, einige Kernkonzepte zu vereinheitlichen. Ich habe die Idee der Mieter eingeführt und einige der wichtigsten Nuancen beim Aufbau von Umgebungen hervorgehoben, in denen die Infrastruktur in einem gemeinsamen Modell genutzt werden kann. In unserer Diskussion über gemeinsam genutzte Infrastrukturen haben wir auch einige der wichtigsten Unterschiede zwischen SaaS und traditionellen installierten Modellen pro Kunde herausgestellt. Im Mittelpunkt dieses Themas stand die Idee, eine einheitliche Erfahrung zu schaffen, die es dir ermöglicht, deine SaaS-Tenants gemeinsam zu verwalten, einzusetzen und zu betreiben.

Außerdem war es wichtig, klarer abzugrenzen, was SaaS ist und was nicht (zumindest für den Umfang dieses Buches). An dieser Stelle begann ich, mich mit dem Begriff "Multi-Tenancy" und der damit verbundenen Geschichte zu beschäftigen. Ziel war es, eine neue, SaaS-bezogene Sichtweise von Multi-Tenancy zu entwickeln, die sich von der engen, infrastrukturzentrierten Vorstellung von Multi-Tenancy entfernt. Ich überprüfte eine Reihe von SaaS-Bereitstellungsstrategien, um die Notwendigkeit einer breiteren Definition von Multi-Tenancy zu verdeutlichen, die nicht davon abhängt, ob wir eine Infrastruktur gemeinsam nutzen. Klarheit darüber zu haben, wann und wie der Begriff der Mandantenfähigkeit verwendet wird, ist von grundlegender Bedeutung dafür, wie wir über SaaS sprechen und wie wir SaaS-Architekturen beschreiben.

Im letzten Teil des Kapitels habe ich versucht, die Grenzen von SaaS weiter zu definieren. Ich habe mir zum Beispiel das MSP-Modell angeschaut und einige der Schlüsselfaktoren untersucht, die MSP- und SaaS-Modelle voneinander unterscheiden. Außerdem habe ich mir einige der Grundprinzipien angesehen, die meiner Meinung nach bei der Gestaltung der Vision für den Aufbau einer SaaS-Organisation und eines SaaS-Angebots angewendet werden sollten. Dazu gehörte auch die Überprüfung einiger der wichtigsten Unterschiede, die mit dem Aufbau einer Dienstleistung (anstelle eines Produkts) verbunden sind.

Wir hoffen, dass dieses Kapitel dir ein besseres Gefühl dafür vermittelt hat, wie wir SaaS im Laufe dieses Buches betrachten werden. Wenn wir uns an diesen Grundsätzen orientieren, können wir weitere, konkretere Konzepte mit einer gemeinsamen Sicht auf die Kräfte, die unsere architektonischen Entscheidungen beeinflussen und leiten, durchgehen. Im Idealfall beseitigt dies auch einen Teil der Verwirrung, die dieses Thema in der Vergangenheit umgeben hat.

Jetzt, da wir diese SaaS-Grundlagen kennen, können wir uns Gedanken darüber machen, wie diese Prinzipien auf spezifischere Architekturmuster und -konstrukte übertragen werden können. Im nächsten Kapitel werde ich alle wichtigen SaaS-Architekturmechanismen und -Strategien durchgehen, ohne dabei auf die Besonderheiten einer bestimmten Lösung oder Technologie einzugehen. Dadurch werden alle Überlegungen deutlich, die bei der Definition einer SaaS-Architektur angestellt werden sollten. Die Definition des Tenant-Kontextes, die Erörterung der gemeinsamen Dienste und Fähigkeiten, die wir benötigen, und die Erklärung der Datenpartitionierung - all das steht auf einer viel längeren Liste von detaillierteren Erkenntnissen, die wir behandeln werden. Ziel dieses Kapitels ist es, viele der übergeordneten Konstrukte der SaaS-Architektur zu besprechen, ihre Rolle und ihre Besonderheiten zu erläutern und zu zeigen, wie sie sich in die Gesamtlandschaft der SaaS-Architektur einfügen .

Get Aufbau von mandantenfähigen SaaS-Architekturen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial