Die meisten IT-Servicemanagement-Tools sind auch als Software-as-a-Service (SaaS) aus der Cloud erhältlich. Die Software-Anbieter setzen bei der Bereitstellung ihrer Lösungen auf unterschiedliche technologische Plattformen, die jeweils spezifische Vor- und Nachteile mit sich bringen.
Dieser Artikel erläutert zwei grundsätzlich unterschiedliche Architekturmodelle und durch welche spezifischen Eigenschaften sie sich unterscheiden. Er zeigt auf, warum die zugrundeliegende Technologie auch bei einem reinen SaaS-Betrieb relevant für den jeweiligen Kunden ist und welche Entscheidungskriterien bei der Anbieterauswahl beachtet werden sollten.
Zwei gegensätzliche Architekturmodelle. SaaS-Architekturen unterscheiden sich vor allem im Anteil der gemeinsam von allen Kunden genutzten Ressourcen. Im Folgenden werden zwei gegensätzliche Modelle vorgestellt (Abbildung 1).
Abbildung 1: Zwei gegensätzliche Architekturmodelle von SaaS-Lösungen.
Im Architekturmodell 1 nutzen alle Kunden eine Applikation und eine Datenbank gemeinsam. Die Applikation kann aufgrund der Login-Daten unterscheiden, zu welchem Kunden ein Benutzer gehört. Alle Datensätze in der Datenbank werden mit einem Kundenattribut versehen, durch welches sie den jeweiligen Kunden zugeordnet werden. Im Architekturmodell 2 werden für jeden Kunden eine eigene Applikation und eine eigene Datenbank zur Verfügung gestellt.
Prinzipiell sind auch Mischformen dieser Modelle möglich. Für die Diskussion der grundsätzlichen Vor- und Nachteile spielen diese aber keine Rolle.
Gemeinsame Ressourcen senken die Kosten. Viele SaaS-Anbieter setzen auf das Architekturmodell 1, bei dem sich alle Kunden die Ressourcen teilen. Diese Architektur hat für den Anbieter die folgenden Vorteile:
- Betrieb: Es muss nur eine Applikation und eine Datenbank installiert, überwacht, gewartet und gesichert werden.
- Support: Es muss nur eine Produktversion, nämlich die aktuelle, vom Support unterstützt werden.
- Entwicklung: Auftretende Fehler müssen nur in einer Produktversion, nämlich der aktuellen, beseitigt werden.
Die Nutzung dieses Architekturmodells 1 ist also für den SaaS-Anbieter mit Kostenvorteilen verbunden, die er in Form günstiger SaaS-Gebühren an den Kunden weitergeben kann. Dieses Architekturmodell führt aber auch zu Nachteilen auf der Kundenseite:
- Datensicherheit / Datenschutz: Die Daten aller Kunden liegen in einer einzigen Datenbank. Mittels Programmlogik muss der Anbieter sicherstellen dass keine Datenlecks entstehen, durch die ein Anwender Zugriff auf die Daten eines anderen Kunden erhält. Da Software grundsätzlich nie fehlerfrei ist, stellt dies ein Sicherheitsrisiko dar.
- Anpassbarkeit: Da alle Kunden dieselbe Standardapplikation verwenden, ist die Umsetzung kundenindividueller Anforderungen nur eingeschränkt möglich. Die Bandbreite der Anpassungen ist durch die in der Software vorgegebenen Konfigurationsoptionen begrenzt. Darüber hinausgehende Anpassungswünsche können nicht realisiert werden.
- Versionsfreiheit: Alle Kunden müssen immer dieselbe, aktuelle Programmversion nutzen. Der Anbieter will neue Features möglichst schnell produktiv setzen, um die Attraktivität seiner Software gegenüber potenziellen Neukunden zu erhöhen. Die Bestandskunden erleben dadurch einen häufigen Versionswechsel, und Anwender müssen sich oft auf neue Funktionen und Produktoberflächen einstellen. Sie haben keine Möglichkeit zu beeinflussen, ob und wann ein Versionswechsel erfolgt.
- Integrationsunterstützung: Zur Integration der kundeneigenen Systeme mit der ITSM-Lösung in der Cloud stellen die Anbieter Web-Services zur Verfügung. Die Programmierung dieser Web-Services auf Seiten der Kundensysteme ist oft sehr aufwändig und liegt in der Verantwortung des Kunden. Eine Unterstützung in Form einer einfach zu konfigurierenden Middleware wird meist nicht angeboten.
- Wartungsplanung: Wartungsfenster werden von den SaaS-Anbietern selbst festgelegt. Die Kunden haben keine Möglichkeit, einen für sie geeigneten Zeitpunkt zu wählen.
- Betriebsmodellwahl: Die meisten SaaS-Anbieter mit dem Architekturmodell 1 setzen ausschließlich auf den SaaS-Betrieb. Sollte ein Kunde aus Gründen der höheren Geschwindigkeit und des geringeren Risikos zunächst mit dem SaaS-Modell starten, später aber aus Gründen der Wirtschaftlichkeit oder gestiegener Datenschutzanforderungen auf den On-Premises-Betrieb umsteigen wollen, ist dies nicht möglich.
Getrennte Ressourcen erhöhen die Leistungsfähigkeit. SaaS-Anbieter, die das Architekturmodell 2 einsetzen, nehmen zunächst eine Reihe von Nachteilen in Kauf:
- Betrieb: Für jeden Kunden muss eine eigene Applikation und eine eigene Datenbank installiert, überwacht, gewartet und gesichert werden.
- Support: Da die Kunden wählen können, ob und wann sie einen vom Anbieter angebotenen Versionswechsel durchführen, muss der Anbieter mehrere unterschiedliche Releases gleichzeitig betreiben und im Support unterstützen. Hotfixes zur Beseitigung bekannter Fehler müssen nicht nur in einer Instanz, sondern in allen betroffenen Kundeninstanzen eingespielt werden.
- Entwicklung: Auftretende Fehler müssen nicht nur in der aktuellen Produktversion, sondern auch in allen älteren, noch produktiven Versionen beseitigt werden. Hotfixes müssen also für mehrere Produktversionen erstellt und jeweils einzeln getestet werden.
Die Nutzung des Architekturmodells 2 ist somit für den SaaS-Anbieter mit erhöhten Kosten verbunden, die er über die SaaS-Gebühren an den Kunden weiterreichen muss. Dafür erhält der Kunde aber eine Lösung, die deutlich leistungsfähiger ist:
- Datensicherheit / Datenschutz: Die Applikationen und Datenbanken der Kunden sind voneinander getrennt. Programmierfehler oder Sicherheitslücken in der Applikation des Herstellers können somit grundsätzlich nicht zu einem Datenleck führen.
- Anpassbarkeit: Da die Applikationen und Datenbanken der Kunden getrennt voneinander betrieben werden, können diese auch unabhängig voneinander durch Customizing verändert werden. Häufig erlauben diese Tools auch Änderungen am Datenmodell, etwa durch Einführung neuer Objekttypen, oder Erweiterungen per Skripting oder Programmierung. Kundenindividuelle Anpassungen sind also mit einem Höchstmaß an Flexibilität möglich.
- Versionsfreiheit: Ist eine neue Softwareversion verfügbar, kann ein Kunde selbst bestimmen, ob und wann er auf die neue Version migrieren will. Er kann somit von Fall zu Fall beurteilen, ob die Vorteile der neuen Funktionalitäten die organisatorischen Aufwände für deren Einführung (etwa Prozessanpassungen, Mitarbeiterschulungen etc.) überwiegen. Entschließt sich der Kunde zur Migration, kann er den Zeitpunkt selbst wählen. Alternativ kann er aber auch mit der älteren Version weiterarbeiten.
- Integrationsunterstützung: SaaS-Lösungen nach dem Architekturmodell 2 wurden von den Herstellern meist aus Tools entwickelt, die zuvor als reine On-Premises-Lösung betrieben wurden. Da die Systemintegration bei den On-Premises-Projekten oft zum Lieferumfang dazugehört, haben die Hersteller leistungsfähige Middleware-Komponenten entwickelt. Diese werden im Kundennetzwerk installiert und haben auf Seiten der ITSM-Lösung die proprietären Web-Services bereits implementiert. Zur schnellen Integration gängiger ERP-, ITSM- oder Monitoring-Systeme stehen fertige Connectoren zur Verfügung. Individuelle Fremdsysteme lassen sich über zahlreiche Standardprotokolle wie etwa FTP, HTTP, SOAP, IDOC, XML o.ä. integrieren.
- Wartungsplanung: Wartungsfenster werden von den SaaS-Anbietern in Abstimmung mit dem Kunden festgelegt. Der Kunde hat somit die Möglichkeit, einen für ihn geeigneten Zeitpunkt zu wählen.
- Betriebsmodellwahl: Sowohl Applikation als auch Datenbank können entweder als SaaS-Lösung im Rechenzentrum des Anbieters betrieben werden oder auch als On-Premises-Lösung im Rechenzentrum des Kunden. Die Übertragung der Lösung in beide Richtungen ist mit geringem Aufwand möglich. Deshalb bieten SaaS-Anbieter mit dem Architekturmodell 2 ihren Kunden häufig die Möglichkeit, zwischen den Betriebsmodellen zu wechseln.
Abbildung 2: Vor- und Nachteile der unterschiedlichen SaaS-Modelle.
Fazit. Hersteller von ITSM-Lösungen aus der Cloud (SaaS), die auf einer gemeinsamen Applikation und einer gemeinsamen Datenbank basieren, positionieren sich vor allem über den Preis. Sie wollen ihre Software zu möglichst geringen Gebühren bereitstellen. Die Hersteller von SaaS-Lösungen mit getrennten Applikationen und getrennten Datenbanken positionieren sich dagegen anders: sie bieten ihren Kunden ein Höchstmaß an Sicherheit und Flexibilität.
Martin Landis ist seit 1999 bei der USU AG tätig. Er war zunächst für die Implementierung von USU-Lösungen bei vielen namhaften Kunden verantwortlich. Danach folgten Positionen im Produktmanagement, Presales und Global Sales. Seit 2015 ist Martin Landis Leiter des Produktmarketings im Bereich Business Service Management.
Illustration: © David Spieht /shutterstock.com
Hier folgt eine Auswahl an Fachbeiträgen, Studien, Stories und Statistiken die zu diesem Thema passen. Geben Sie in der »Artikelsuche…« rechts oben Ihre Suchbegriffe ein und lassen sich überraschen, welche weiteren Treffer Sie auf unserer Webseite finden. Diese Auswahl wurde von Menschen getroffen und nicht von Algorithmen.
Smart Services im Zeitalter der Digitalisierung USU World am 10. und 11. Mai 2017 im Kosmos Berlin
IT-Helpdesk und IT-Service Management (ITSM) – Der letzte Ausweg
Cloud Service und Unified Endpoint Management – Maßgeschneidertes IT-Management aus der Suite
Portfolio- und Service-Management – Kunden und Dienstleister profitieren gleichermaßen
Digitale Transformation – Digital in die Zukunft, aber richtig
Offen, agil und kompatibel – Die richtige Cloud für die Digitalisierung
Workflows mit Transit Map Design – IT Service Management: Alles im Fluss
IT Service Management: Reifegrad in DACH höher als in anderen Ländern