Cloud

Kolumne: Stropek as a Service

Zehn Hausaufgaben für die Cloud-Architektur – eine gute Softwarearchitektur setzt klare Ziele voraus
Keine Kommentare

Gute Softwarearchitektur setzt klare Ziele voraus – logisch, oder? Rainer Stropek aber weiß aus eigener Erfahrung, dass Teams wichtige Hausaufgaben oft nicht machen – und hat zehn Aspekte gesammelt, die in keinem Fall vernachlässigt werden sollten.

Softwarearchitekturen für Cloud-Lösungen zu entwickeln, ist seit Jahren fester Bestandteil meiner Arbeit. Ich werde von Firmen eingeladen, mit ihnen Architekturen für Cloud-basierende SaaS-Produkte zu entwickeln. Dabei stelle ich oft fest, dass Teams wichtige Hausaufgaben vernachlässigen.

Die Projektziele und -rahmenbedingungen sind nicht klar formuliert. Man erwartet, dass Cloud-Anbieter wie Microsoft oder Berater wie ich eine allgemeingültige Cloud-Architektur aus dem Ärmel zaubern, die unabhängig vom Geschäftsmodell und der fachlichen Domäne funktionieren. Diese Vorgehensweise ist gefährlich. Sie führt zu unnötig komplexen oder unpassenden Architekturen. Es wäre, als würde man sein Haus planen, ohne vorher festgelegt zu haben, ob man einen Keller will oder wie viele Autos in der Garage Platz haben sollen. In dieser Ausgabe meiner Kolumne möchte ich eine Liste von zehn Hausaufgaben zusammenfassen, die ich Teams vor einem Cloud-Architekturworkshop mitgebe. Die Antworten sind die Basis, auf der eine solide Architekturentwicklung aufbauen kann.

1. Vision

Beginnen Sie mit einer Zusammenfassung der zentralen Vision, die hinter der Cloud-basierenden SaaS-Lösung steckt. Halten Sie sich dabei bewusst kurz. Idealerweise gibt es für das Projekt bereits ein Visionsdokument, auf das Sie verweisen können.

Eine Vision, die nur in den Köpfen der Projektbeteiligten existiert, ist zu wenig. Schreiben Sie sie nieder. Die Vision in prägnante Worte oder Schaubilder zu fassen, hilft, Inkonsistenzen und Unklarheiten aufzudecken.

Beschreiben Sie die Einordnung des Projekts in die Gesamtstrategie Ihrer Organisation. Ein Werkzeug, das ich in diesem Bereich gerne verwende, ist die Strategy Map. Sie erklärt die primären strategischen Ziele und ihre Zusammenhänge. Stellen Sie für das SaaS-Projekt dar, wie es die Zielerreichung unterstützt.

2. Scope

Welchen Scope hat das Projekt, für das die Softwarearchitektur entwickelt werden soll? Was ist Teil der Aufgabenstellung für das vorliegende Projekt und was wird im Moment bewusst ausgeklammert? Wie ist das aktuelle Projekt in eine längerfristige Produkt-Roadmap eingegliedert?

3. Innovation

Damit der Fokus im Projekt richtig gesetzt werden kann, muss klar sein, was das Innovative am zu entwickelnden SaaS-Produkt ist. Ich empfehle, die Innovation aus zwei Perspektiven heraus zu beschreiben:

  • Externe Perspektive: Was sind aus Kundensicht die wichtigsten funktionalen und nichtfunktionalen Anforderungen, durch deren Lösung sich das SaaS-Angebot von existierenden Produkten abheben wird? Ein Werkzeug, das ich persönlich in diesem Bereich gerne einsetze, ist die Blue-Ocean-Strategie.
  • Interne Perspektive: Welche internen Aspekte des Unternehmens werden sich durch das SaaS-Angebot fundamental verändern? Betroffen sein könnten beispielsweise interne Geschäftsprozesse, die Aufbauorganisation oder die Unternehmensfinanzierung. Wie verändert das neue SaaS-Angebot die Wertschöpfungskette der Firma? Ich nutze bei dieser Frage gerne den Business Model Canvas als Hilfsmittel.

Hilfreich für die Qualität der Antwort auf diese Frage ist meiner Erfahrung nach, eine Beschränkung auf jeweils maximal fünf Schlüsselinnovationen. Dadurch ist man gezwungen, sich auf das Wesentliche zu beschränken und zu priorisieren.

4. Zielumgebung

Ich habe in meinen Kolumnen schon oft darüber geschrieben, dass ein Produkt, das nur in der Cloud, vielleicht sogar nur in einer bestimmten läuft, per se nichts Schlechtes ist. Man verliert vielleicht einige Kunden, die auf jeden Fall eine On-Premises-Lösung suchen. Man begibt sich auch in eine gewisse Abhängigkeit zum jeweiligen Cloud-Anbieter. Auf der anderen Seite profitiert man aber von qualitativ hochwertigen, günstigen PaaS- und Serverless-Diensten.

Die Architektur einer Cloud-Lösung wird massiv davon beeinflusst, ob man eine Cloud-native-Lösung entwickeln will und auf welche Cloud-Zielumgebung man sich konzentriert. Daher müssen vor der Architekturentwicklung insbesondere folgende Fragen geklärt werden:

  • Muss es möglich sein, die Software in Kunden- oder Partnerrechenzentren (On Premises) zu installieren? Wenn ja, welche Anforderungen an das Zielrechenzentrum sind realistisch? Vermeiden Sie bei der Beantwortung dieser Frage technische Details (z. B. „ein Kubernetes-Cluster wird vorausgesetzt“), da dies Architekturentscheidungen schon vorwegnehmen könnte. Beschreiben Sie stattdessen den beim Kunden vorausgesetzten Reifegrad seiner IT-Infrastruktur (z. B. tiefgehende DevOps-Kenntnisse vs. kein eigenes Team mit fundiertem IT-Wissen).
  • Falls es eine Cloud-native-Lösung wird, ist ein Fokus auf einen gewissen Cloud-Anbieter gewünscht? Erklären Sie die Gründe für die Fokussierung (z. B. existierende, strategische Partnerschaft). Beschreiben Sie allgemein den Unternehmensstandpunkt hinsichtlich Cloud Vendor Lock-in.
  • Gibt es Einschränkungen (z. B. Region, ISO-Zertifizierungen, garantierte Verfügbarkeiten) für die Cloud-Zielumgebung, die sich aus internen oder externen Richtlinien (z. B. Konzernvorgaben, rechtliche Bestimmungen) ergeben?

5. Zielgruppe

Beschreiben Sie die Kundenzielgruppe für die SaaS-Lösung. Gehen Sie dabei insbesondere auf folgende Dinge ein:

  • Beschreiben Sie die Kunden, die sie ansprechen wollen, möglichst konkret. Meiner Erfahrung nach hilft es, wenn man konkrete Personas für Kunden (bei B2B-Projekten wären das Stakeholder, die den SaaS-Dienst nutzen oder über seine Nutzung entscheiden) entwickelt und beschreibt. Bei B2B-Lösungen gehen Sie auf Merkmale typischer Kundengruppen ein (z. B. Branche, Größe, Region) und bringen Sie konkrete Beispiele für potenzielle Kunden.
  • Beschreiben Sie die wichtigsten Anwendungsfälle je Persona. Ich empfehle, dass Sie sich ein Limit von fünf Fällen setzen, damit Sie gezwungen sind, zu priorisieren.
  • Fügen Sie quantitative Kundenmerkmale hinzu (z. B. Anzahl Benutzer pro Kunde, Anzahl Transaktionen pro Kunde pro Zeiteinheit, Dauer der Nutzung der SaaS-Lösung je Benutzer pro Monat etc.).
  • Erwähnen Sie eventuell wichtige technische Einschränkungen bei den Kunden (z. B. schlechte/keine Internetverbindung).

6. Skalierung

Legen Sie das Mengengerüst fest, an dem sich die Softwarearchitektur orientieren muss. Diese Frage ist speziell für Start-ups schwierig zu beantworten, da sich der Markterfolg nur schwer prognostizieren lässt. Dieser Aspekt beeinflusst die Architektur aber stark und daher ist eine Festlegung wichtig. Hier einige Aspekte, die bei der Beantwortung der Frage helfen können:

  • Geben Sie Bandbreiten für die Anzahl an Kunden und Benutzer an. Es spricht nichts gegen mehrere Szenarien (z. B. optimistisch, realistisch, pessimistisch). Bei der Entwicklung der Architektur können Varianten erarbeitet werden, die unterschiedlich gut skalieren. Die endgültige Entscheidung kann dann durch Gegenüberstellung der erwarteten Kosten je Architekturvariante und Eintrittswahrscheinlichkeit des jeweiligen Szenarios getroffen werden.
  • Strukturieren Sie das Mengengerüst nach Preisplänen (z. B. Kundenanzahl im Freemium-, Standard- und Premiumplan).
  • Schätzen Sie den zeitlichen Verlauf des Mengengerüsts durch Schätzungen für Neukunden- und Abwanderungsquoten (Churn Rate) ab.
  • Gehen Sie auf Besonderheiten im Nutzungsverhalten der Kunden ein (z. B. besonders hohe Last am Monatsende, fast keine Nutzung an Wochenenden, relative stabile Nutzung tagsüber).
  • Schätzen Sie die Transaktionszahlen für die wichtigsten Geschäftsprozesse ab. Konzentrieren Sie sich auf die wichtigsten fünf, um sich nicht von Randthemen ablenken zu lassen.
  • Wenn Sie das Mengengerüst nicht wirklich abschätzen können, nennen Sie zumindest Ober- und Untergrenzen (z. B. sicher nicht mehr als … Transaktionen pro Benutzer und Tag).

Beachten Sie, dass keine Aussage über das Mengengerüst keine Option ist. Irgendjemand muss eine Annahme treffen. Eine bewusste unternehmerische Entscheidung ist besser als eine implizite Festlegung durch Annahmen, die das Umsetzungsteam trifft.

7. Daten

Datenhaltung ist ein wichtiger Bestandteil einer Softwarearchitektur. Während es vor einigen Jahren fast immer auf eine relationale Datenbank hinauslief, gibt es heute in der Cloud eine Vielzahl an Speicherdiensten mit spezifischen Eigenschaften. Als Basis für die Wahl der richtigen Speichertechnologie sollten Sie insbesondere die folgenden Aspekte der Datenhaltung beschreiben:

  • Mengengerüst für die wichtigsten Entitäten gegliedert nach Kundentyp.
  • Logisches Datenmodell aus fachlicher Sicht für die wichtigsten Entitäten. Vermeiden Sie dabei technische Details, da diese Architekturentscheidungen vorwegnehmen würden.
  • Gehen Sie auf besondere, nichtfunktionale Anforderungen ein (z. B. garantierte, maximale Zugriffszeit bei gewissen Abfragen, Verfügbarkeitsgarantien, Datenwiederherstellung).

8. Geschäftsmodell

Ich bin in früheren Ausgaben dieser Kolumne schon darauf eingegangen, wie wichtig der Design-to-cost-Ansatz für Cloud-basierende SaaS-Lösungen ist. Ausgangsbasis dafür sind Preis- und Kostenvorgaben, die für das jeweilige Projekt gelten. Erarbeiten Sie insbesondere folgende Punkte:

  • Beschreiben Sie das Preismodell (z. B. Preispläne, Mengenrabatte, Free- und Freemium-Angebote).
  • Beschreiben Sie Zusatzprodukte- und Dienstleistungen rund um das SaaS-Angebot sowie deren Umsätze und Kosten (z. B. kostenpflichtiger Support, Einführungsprojekte, Self-Service Portale).
  • Geben Sie Kostengrenzen für Entwicklung und Betrieb des SaaS-Produkts fest (TCO, nicht nur Infrastrukturkosten), die sich aus dem Projektbudget oder der Start-up-Finanzierung ergeben.
  • Wie beim Mengengerüst sollten Sie zumindest Ober- und Untergrenzen festlegen (z. B. Wir werden nicht mehr verrechnen als …, der Standard-Preisplan wird mindestens … kosten).

9. Vorhandenen Ressourcen

In der heutigen Zeit sind die vorhandenen personellen Ressourcen genauso wichtig wie die finanziellen. Manchmal ist es sogar leichter, Geld aufzutreiben als Personal. Darauf muss in der Architekturentwicklung Rücksicht genommen werden. Sind die Ressourcen knapp, wird die Fertigungstiefe gering sein müssen und man greift mehr auf vorhandene Services und Komponenten zurück. Hat man ausreichend Leute, kann man es sich erlauben, mehr selbst herzustellen und dadurch auf individuelle Besonderheiten einzugehen oder Alleinstellungsmerkmale zu entwickeln.

Beschreiben Sie quantitative (Anzahl) und qualitative (vorhandenes Wissen) Aspekte des Personals, das für das Projekt zur Verfügung stehen wird.

10. Bestehende Komponenten

Beschreiben Sie, welche bestehenden Komponenten (z. B. existierende Codebasis, vorhandene Services) in der SaaS-Lösung weiterverwendet werden müssen. Gehen Sie auch auf Schnittstellen ein, die die SaaS-Lösung haben muss (z. B. System Context Diagram ). Vermeiden Sie, wie auch bei den zuvor genannten Punkten, technische Details. Es geht darum, die großen Zusammenhänge aufzuzeigen. Verweise auf externe Dokumente, in denen Details zu den vorhandenen Komponenten und notwendigen Schnittstellen zu finden sind, sind aber keineswegs von Nachteil.

Fazit

Eine allgemeine Softwarearchitektur, die nicht für ein spezifisches Problem entwickelt wird, ist selten besonders nützlich. Je klarer die Vorstellungen über die zu erreichenden Ziele sind, desto zielführender kann in der Architekturentwicklung gearbeitet werden. Ich hoffe, die oben genannten zehn Punkte helfen, Ihr nächstes SaaS-Projekt erfolgreich zu starten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -