Kolumne: Stropek as a Service

Was gute Softwarearchitekten in der Cloud-Ära ausmacht
Kommentare

Dass sich typische Softwarearchitekturen in der Cloud von jenen im lokalen Rechenzentrum unterscheiden, hat sich mittlerweile herumgesprochen. Unzählige Artikel, Bücher und Vorträge auf Konferenzen behandeln dieses Thema. Ich möchte mich dem Themenbereich von einer anderen Seite nähern. Betrachten wir einmal Softwarearchitekten, also die Personen, die die Strukturen und das Design von Softwareprodukten entwerfen.

Die Rolle der Softwarearchitekten hat sich in der Cloud-Ära stark verändert. Bei ihrer Arbeit müssen sie das große Ganze im Blick behalten, denn Fehler, die in der Architekturentwicklung gemacht werden, sind teuer. In Extremfällen können sie bedeuten, dass große Teile eines Softwaresystems umgeschrieben oder sogar neu programmiert werden müssen. Mängel in der Architekturentwicklung haben oft noch dramatischere Konsequenzen für Softwarefirmen. Wenn sie dazu führen, dass Entwicklerinnen und Entwickler frustriert sind, weil sie ständig durch künstliche Hürden gebremst werden oder auf Basis veralteter Konzepte arbeiten müssen, steigert das die Personalfluktuation. Schließlich ist es für gute Techniker heutzutage nicht schwierig, neue Stellen zu finden.

Autonomie vs. zentrale Steuerung

Ich bin ein Befürworter von Teamautonomie. Teams sollen entsprechend dem Microservices-Gedanken eigenverantwortlich arbeiten und die Konsequenzen ihrer Entscheidungen auch selbst tragen. Das bedeutet auch, dass der Aufgabenbereich nicht mit dem Einchecken von Quellcode endet. „You build it, you run it“ ist das Motto, das speziell im Cloud- und SaaS-Umfeld meiner Ansicht nach gelten sollte.

Diese Organisationsmaxime widerspricht bis zu einem gewissen Grad dem Bild, das viele Softwarearchitekten in größeren Firmen von sich haben. Sie entwickeln zentral detaillierte Richtlinien für Softwareentwicklung, um Einheitlichkeit sicherzustellen. Einheitlich strukturierte Software soll die einzelnen Projekte schneller und günstiger machen, die Kosten für den Betrieb senken, Fehler von vornherein vermeiden etc. An sich kein schlechter Gedanke, er hat aber einige Haken. Punkte wie die folgenden führen zu Konflikten und Frustration auf allen Seiten:

  • Viele Softwarearchitekten kommen mit der Arbeit nicht nach. Manchmal werden Architekturentwicklungsprojekte auch einmalig durchgeführt und danach beendet. Richtlinien hinken daher nicht selten dem Stand der Technik und den Anforderungen der Praxis hinterher.
  • Richtlinien verstauben nach ihrer Erstellung häufig in der digitalen Ablage. Es wird zwar viel Zeit in ihre Entwicklung investiert. Auf die notwendige und zeitraubende Verbreitung des durchaus wertvollen Wissens wird dann aber verzichtet.
  • Architekturrichtlinien entstehen im sprichwörtlichen Elfenbeinturm. Diejenigen, die die Richtlinien entwickeln, verstehen ihre Auswirkungen nicht vollständig und müssen sie auch nicht ausbaden.
  • Einheitliche Richtlinien setzen voraus, dass die ausführenden Teams einheitlich sind. In der Praxis unterscheiden sich aber Anforderungen, Vorwissen, Begeisterung für gewisse Technologien etc.
  • Die Architekturrichtlinien, die ich in der Praxis sehe, sind oft sehr detailliert. Sie machen Vorgaben, die sich auf Implementierungsdetails beschränken und nicht das große Ganze behandeln.

Umfeld gestalten statt Mikromanagement

Moderne Softwarearchitekturteams sollten sich als Servant Leaders verstehen. Sie setzen ihre Vorstellungen nicht durch Ausübung von Positionsmacht durch, sondern sind koordinierende Dienstleister für die autonomen Entwicklungsteams. Softwarearchitekten legen den Rahmen fest, in dem sich die Teams bewegen können, und reduzieren die dazu gemachten Vorgaben auf das notwendige Minimum. Der Fokus liegt auf folgenden Themen:

  • Entwicklung von Architekturprinzipien als generelle Leitlinie für die gesamte Softwareentwicklung im Unternehmen (Beispiel: eine Sammlung von zwölf Prinzipien für SaaS-Entwicklung).
  • Festlegung von feststehenden Grenzen und Vorgaben, an die sich Teams z. B. aus rechtlichen Gründen unbedingt zu halten haben. Ein Beispiel dafür wäre das bewusste Ausschließen gewisser Cloud Services, weil diese die notwendigen Datenschutzrichtlinien nicht erfüllen oder in der gewünschten Region nicht angeboten werden.
  • Sammlung von Patterns und Practices, die als Startpunkt für die Lösung von Herausforderungen in konkreten Projekten dienen können. Diese können plattformunabhängig (z. B. Microsoft REST API Guidelines) oder plattformabhängig (z. B. .NET Foundation C# Developer Guidelines) sein.

Während die ersten beiden Punkte verpflichtenden Charakter haben, ist der dritte Punkt eine Sammlung von Vorschlägen. Durchgesetzt werden sie nicht durch organisatorische Weisung, sondern indem anhand konkreter Beispiele gezeigt wird, dass sie funktionieren.

Programmierende Architekturteams

Moderne Architekturteams arbeiten nicht im Elfenbeinturm. Ganz im Gegenteil, sie arbeiten in Entwicklungsteams mit und spüren so am eigenen Leib die Auswirkungen ihrer Patterns und Practices. Eine gute Möglichkeit, Wissen zu verbreiten, sind Leuchtturmprojekte. Solche Vorzeigeprojekte setzen die Architekturideen möglichst optimal um. Architekten arbeiten Hand in Hand mit Profientwicklerinnen und Profientwicklern, um den Gedankenaustausch zu fördern. Die Erfahrungen und der Code der Leuchtturmprojekte illustrieren die positiven Effekte der Architekturvorschläge.

 

Wildwuchs? Nein, Vielfalt!

In Zeiten vor Cloud und DevOps wäre so große Freiheit für Programmierteams schon alleine daran gescheitert, dass die Administratoren sich geweigert hätten, die Vielzahl an Plattformen, Datenbanken, Betriebssystemen etc. zu betreuen. In Großunternehmen ist es heute noch üblich, dass Technologien, die gut zu einem vorliegenden Problem passen würden, ausgeschlossen werden, weil sie nicht auf der (ziemlich kurzen) Wird-offiziell-unterstützt-Liste stehen. Eine Vielfalt an Technologien wird als „Wildwuchs“ oder „Flickenteppich“ abgetan.

Meiner Ansicht nach werden die Vorteile übersehen, die sich daraus ergeben, das jeweils beste Tool für das jeweilige Problem auswählen zu können. Wechselt ein Unternehmen in die Public Cloud, fallen viele dieser Probleme weg. Es ist keine Erfahrung auf dem Gebiet des professionellen Betriebs von z. B. MySQL vorhanden? Kein Problem, in der Public Cloud gibt es ein fertiges PaaS-Angebot dafür. Bisher läuft alles auf .NET und niemand weiß, wie man hochverfügbar und sicher Node.js-Serveranwendungen betreibt? Kein Problem, ein Service in der Cloud übernimmt diese Aufgabe.

Eines der größten Probleme für IT-Abteilungen ist heutzutage das Finden von Programmierexpertinnen und -experten. Ein Unternehmen, das per Definition alle seine Cloud-Lösungen z. B. mit .NET entwickelt, lässt viele Talente, die Know-how auf einer anderen Plattform mitbringen oder deren Passion bei einer anderen Technologie liegt, links liegen. Eine größere Vielfalt an Plattformen und Tools bedeutet für ein Unternehmen, dass der Pool an potenziellen Mitarbeiterinnen und Mitarbeitern größer wird.

Selbst wenn man sich auf eine Plattform einigt, führen im Lauf der Zeit unterschiedliche Versionen zu einer gemischten Softwarelandschaft. Man denke nur an Entscheidungen wie .NET-Full-Framework vs. .NET Core oder AngularJS vs. Angular. Ich habe in meiner Beratungsarbeit mit Softwarefirmen häufig Architekturrichtlinien gefunden, in denen eine bestimmte Version von .NET festgeschrieben ist. Für einen Wechsel auf eine neue Major-Version gilt das Alles-oder-nichts-Prinzip. Kein Team darf vor einer Entscheidung eines übergeordneten Architekturgremiums selbstständig eine neue Version nutzen. Meiner Ansicht nach ist diese Strategie in der Cloud-basierten SaaS-Entwicklung überholt.

Innerbetriebliche Beratungsteams

Entwicklungsteams haben die Aufgabe, die vorliegenden Anforderungen effizient, stabil, sicher und wartungsfreundlich umzusetzen. Ihr Blick ist daher naturgemäß auf Details gerichtet. Ich weiß aus eigener Erfahrung, dass es nicht einfach ist, parallel zur Implementierung das große Ganze im Blick zu behalten.

Modernen Softwarearchitekten kommt daher auch die Rolle von Beraterinnen und Beratern für die Entwicklungsteams zu. Sie weisen auf wichtige, nichtfunktionale Anforderungen hin, helfen bei der Auswahl der richtigen Cloud-Dienste, unterstützen bei Make-or-buy-Entscheidungen u. v. m.

Architekten sollten meiner Ansicht nach bei dieser Beratungsarbeit Strukturen nicht verkomplizieren. Sie sollten ihren Spieltrieb und den ihrer Kolleginnen und Kollegen eindämmen und Software nach dem KISS-Prinizip (Keep it simple and stupid) gestalten. Nicht selten sehe ich in der Praxis Cloud-Architekturen, die gebaut werden, als müsste man sich auf Millionen Benutzer vorbereiten. Die tatsächlich angestrebten und realistischen Benutzerzahlen liegen aber in den Tausenden. Auch solche Überlegungen bringen Architekturteams in Projekte ein.

Organisatorische Änderungen als Erfolgsfaktor

Firmen und Architekturteams müssen beim Wechseln in Richtung Cloud und SaaS lernen, Verantwortung an die Produktteams abzugeben. Die zentrale Steuerung ist nicht obsolet, sie wird aber auf das notwendige Minimum reduziert. Softwarefirmen, die bisher eine streng hierarchische Organisation hatten, müssen über generelle organisatorische Änderungen nachdenken, wenn sie diesen Weg gehen wollen. Architekten, deren Selbstbild darin besteht, dass sie Einheitlichkeit im Softwaredesign durch die Durchsetzung mit Zwang von oben nach unten sicherstellen, müssen umdenken. Nicht die Entwicklungsteams sind ihre Kunden, es ist genau umgekehrt. Die Einbindung der Architekten in Projekte steigt, und viele werden wieder mehr Code schreiben, als sie es früher vielleicht getan haben.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -