Kolumne: Stropek as a Service

Wer in SaaS einsteigt, wird von der Erfinderin zur Produzentin
Keine Kommentare

SaaS bedeutet nicht, dass man einfach eine Software bekommt und alles automatisch perfekt funktioniert. Stattdessen beinhaltet das Konzept anfangs sogar mehr Arbeit. Worin genau der Mehraufwand liegt und ob sich das Ganze am Ende lohnt, erörtert diese Ausgabe von Stropek-as-a-Service.

Der weltbekannte Unternehmer Elon Musk war vor ein paar Monaten im Podcast der New York Times zu Gast. Er zeigte sich etwas frustriert angesichts der Meldungen nach dem kürzlich zuvor stattgefundenen Tesla Battery Day. Musk sagte: „Smart people on Wall Street have […] not the faintest clue about manufacturing and how difficult it is. They think that once you have come up with a prototype, well, that’s the hard part. And everything else is trivial copying after that. It is not.“ [1]

Musks Aussagen können meiner Meinung nach in vielen Punkten auch für das Software-as-a-Service-Geschäft gelten. Ich darf regelmäßig Softwarefirmen beraten, die seit Jahrzehnten am Markt und in ihren Branchen oft führend sind. Ihre Teams haben bewiesen, dass sie qualitativ hochwertige, funktionsreiche Software entwickeln und auch über lange Zeit am Leben halten können. Cloud Computing und SaaS gehen aber auch an diesen Firmen nicht spurlos vorüber. Sie spüren vermehrt den Druck, alternative Geschäftsmodelle anzubieten, bei denen den Kunden nicht „nur“ Software angeboten wird, sondern ein kompletter Dienst, der ihnen die Sorgen des Betriebs und der Wartung abnimmt.

In diesen Projekten stelle ich oft fest, dass gerade Entscheidungsträger in Firmen, die lange im Softwaregeschäft tätig sind, SaaS falsch einschätzen. Sie sind wie die von Musk zitierten „smart people on Wall Street“ und glauben, dass SaaS nur ein weiterer technologischer Schritt ist wie die Umstellung von WinForms auf Webtechnologie oder der Schwenk von Data Sets auf Entity Framework. Meiner Erfahrung nach ist ein Aufbruch in Richtung SaaS aber ein Schritt in Richtung Strukturwandel der gesamten Organisation. Das Unternehmen wird quasi vom Erfinder zum Produzenten. Software zu entwickeln und sie dann auch zu betreiben, verändert alle Ebenen einer Firma. Die Konsequenzen machen nicht bei der Softwareentwicklung halt, es zeigen sich auch deutliche Auswirkungen im Vertrieb, im Support, im rechtlichen Bereich, im Personalmanagement etc. Auf alle Aspekte einzugehen, würde den Rahmen dieser Kolumne sprengen. Ich möchte in Folge aber ein paar unbequeme Wahrheiten aussprechen, die ich Teams mit auf den Weg gebe, die sich konsequent von klassischem Lizenzgeschäft hin zu SaaS wandeln wollen, und hoffe, dass ich dadurch der einen oder anderen Leserin unangenehme Überraschungen ersparen kann.

Die Arbeit wird mehr

Cloud-Computing-Plattformen wie Azure sind enorm leistungsfähig. Eine einzelne Anwendung dort auf PaaS- oder Serverless-Basis zu betreiben, ist ein Genuss im Vergleich zum Betrieb eigener Server. Viele Teams lassen sich dadurch in die Irre führen und meinen, dass SaaS auf Cloud-Basis ohne großen Zusatzaufwand quasi nebenher funktioniert. Das ist nicht der Fall. Es ist ein großer Unterschied, eine einzelne kleine oder mittelgroße Anwendung auf Azure zu betreiben oder für eine nennenswerte Kundenanzahl eine Multi-Tenant-SaaS-Lösung stabil am Leben zu halten. Deployment-Automatisierung, Monitoring, Mechanismen für Datenschutz und Datensicherheit, Fehleranalyse u. v. a. m. erledigen sich nicht von selbst. Wenn Ihrem Team gerade nicht langweilig ist und Sie in Richtung SaaS gehen wollen, wird eine zumindest temporäre Vergrößerung des Teams während der Umstellungsphase nicht ausbleiben. Das gilt selbst dann, wenn Sie konsequent auf PaaS und Serverless setzen. Die zusätzlich notwendigen Personalressourcen wären noch viel mehr, wenn Sie auf eigenes Serverhosting oder IaaS bauen.

API Conference 2021
Dr. Gobe Hobona

OGC APIs: A Suite of Standards to Spatially Enable Web APIs

Dr. Gobe Hobona (Open Geospatial Consortium (OGC))

Microservices Summit - Das große Online-Trainingsevent für Microservices, DevOps, Continuous Delivery, Docker & Cloud
Thilo Frotscher

Microservices mit Service Mesh: Hands-on mit Istio

Workshop mit Sascha Selzer und Tammo van Lessen (INNOQ)

Lars Röwekamp

Shared Data in verteilten Architekturen

Workshop mit Lars Röwekamp (Open Knowledge GmbH)

Zu hohe Erwartungen an die Cloud

Cloud-Plattformen haben das Potenzial, einen hohen Automatisierungsgrad zu erreichen, dadurch kann man im Lauf der Zeit die Produktivität bei SaaS steigern. Wer allerdings glaubt, dass man diese Automatisierung in der Cloud geschenkt bekommt, liegt falsch. Man bekommt die Plattformen, die sie ermöglichen. Die darauf aufbauenden, konkreten Prozesse müssen aber selbst entwickelt werden. Das gilt besonders für Firmen, die schon lange im Geschäft sind und dadurch eine Menge Code haben, der in der Prä-Cloud-Ära entwickelt wurde.

Cloud-Umgebungen wie Azure werden zwar laufend schlauer, besonders Serverless nimmt DevOps-Teams viel Arbeit ab. Mit jeder Innovation steigen aber auch die Erwartungen der Kunden und der Druck durch neu in den Markt einsteigende Marktbegleiter ohne Historie und damit ohne technische Schulden. Seien Sie sich bewusst, dass Cloud Computing eine gute und notwendige Basis ist, aber man auch dort nichts geschenkt bekommt.

Softwareanpassungen

Den Begriff Cloud-native Software gibt es nicht von ungefähr. Es ist ein großer Unterschied, ob eine Software für den effizienten SaaS-Betrieb in der Cloud gemacht worden ist oder nicht. Es stimmt schon, Ihre Software läuft heute auf .NET beim Kunden und morgen auf .NET in der Cloud. Daraus zu schlussfolgern, dass beim Wechsel auf SaaS keine oder kaum Änderungen am Code notwendig sind, ist falsch. Für pure Geschäftslogik mag das gelten. Alles drumherum von Sicherheitsmechanismen bis Datenzugriff, von Kommunikationsprotokollen bis zur Schichtenarchitektur wird sich mehr oder weniger stark ändern müssen.

Die Gründe für notwendige Änderungen sind in der Cloud manchmal keine rein technischen Einschränkungen. In vielen Projekten zwingt die Kostenstruktur der Cloud zu Anpassungen. Die Cloud ist vieles, aber keinesfalls billig. Alles in der Cloud ist ausgelegt auf Hochverfügbarkeit und Hochsicherheit, und das kostet Geld. Richtig kombiniert lassen sich in der Cloud SaaS-Lösungen sehr kosteneffizient betreiben. Software allerdings, die nicht auf die Cloud ausgelegt ist, verhindert oft die Ausnutzung attraktiver PaaS- und Serverless-Dienste. Dann heißt es, in Softwareentwicklung zu investieren, damit die eigene Software wenn schon nicht Cloud-native, dann zumindest Cloud-ready gemacht wird.

Kunden wertschätzen die Arbeit kaum

Wer auf Applaus der Kunden für die viele Arbeit hofft, die man reinstecken muss, um eine Software auf professionellen SaaS-Betrieb umzustellen, wird enttäuscht werden. Kunden sind aufgrund ihrer privaten Erfahrungen mit Outlook, Gmail, Facebook, Twitter und Co. verwöhnt. Zugegeben fallen auch diese Dienste alle paar Monate mal aus. Diese Ausfälle werden aber in Minuten oder Stunden gemessen, im Regelfall laufen die SaaS-Dienste reibungslos. Wenn ein Kunde daher heute SaaS beruflich in Anspruch nimmt, ist die Erwartungshaltung hoch.

Multi-Tenancy ist auch ein Bereich, der in Cloud-Projekten viel Aufmerksamkeit braucht, aber Kunden ziemlich egal ist. Am Ende soll Multi-Tenancy die Hosting-Density erhöhen, damit mehr Kunden auf einer kleineren, gemeinsamen Infrastruktur betrieben werden können. Es geht also um Senkung der Betriebskosten, nicht um funktionale Erweiterungen, über die sich der Kunde freuen würde. Solche Aspekte des Produktionsbetriebs sind für die meisten Endnutzer zu abstrakt, als dass sie diese wertzuschätzen wüssten.

Begleitende Reorganisation

Die Organisation einer auf SaaS ausgerichteten Firma sieht anders aus als die einer Softwarefirma, die Lizenzen für den Betrieb einer Software bei Endkunden vergibt. Früher waren Softwareentwicklerinnen und -entwickler Erfinder, während die Administratoren der Endkunden die Betriebsaspekte innehatten. Daher rührten auch viele Konflikte, bei denen die Wünsche von Entwicklungsteams, wie z. B. häufige Softwareupdates oder moderne Basisinfrastruktur, von Administratoren abgeschmettert wurden, um die Stabilität und Sicherheit im Betrieb zu gewährleisten.

SaaS ist die Zeit von DevOps. Entwicklungsfirmen müssen plötzlich ihren Betriebsmuskel trainieren, viele müssen ihn von Null weg aufbauen. Wenn man in einer SaaS-Firma weiterhin Entwicklung und Produktionsbetrieb getrennt lässt, sind die gleichen Konflikte unvermeidbar, die es früher mit Kundenadministratoren gab. Entwicklungsteams müssen die Konsequenzen ihrer Designs und ihres Codes im Betrieb unmittelbar spüren. DevOps erfordert organisatorische Maßnahmen. Teams werden anders zusammengestellt, die Aufgaben von Teammitgliedern wandeln sich, viele Personen haben ein verändertes Aufgabenumfeld. Wie wir alle wissen, sind organisatorische Änderungen manchmal schmerzhaft. Sie sind auf dem Weg zu SaaS aber unvermeidbar.

Zahlt es sich aus?

Sie finden diese beispielhaft herausgegriffenen Punkte abschreckend und fragen sich: „Lohnt sich der Wandel zu Saas überhaupt?“ Die Antwort meinerseits ist ein klares „Ja“. Ich behaupte sogar, dass ein großer Teil der Softwarefirmen sowieso keine Wahl hat. Wer sehenden Auges in den Wandel geht und offen für Veränderung ist, den werden die zu überwindenden Hürden nicht frustrieren. Herausforderungen sind etwas Spannendes, sie zu überwinden, ist ungemein befriedigend. Ganzheitlich gesehen wird die Situation für die Softwarefirma und ihre Kunden durch SaaS besser, da Ressourcen für Produktionsbetrieb gebündelt werden und dadurch die Professionalität und Effizienz steigt.

Links & Literatur

  • [1] https://www.nytimes.com/2020/09/28/opinion/sway-kara-swisher-elon-musk.html
Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -