Luca Morelli
Software Engineer und Analyst
Teamleiter
Projekt vorschlagen

Softwarearchitekt und Solution Architect: eine Rolle, die sich mit der Projektgröße verändert.

Wer entscheidet, wie eine Anwendung in der Cloud aufgebaut ist? In einem kleinen Projekt ist es der Entwickler, der sie schreibt; in einem großen Programm ist es eine Gruppe von Menschen, die nichts anderes tut. Diese Seite ist eine Einführung in das Thema: Sie fasst meine Sicht auf diese Rollen zusammen, die auf den Projekten beruht, an denen ich gearbeitet habe, und beschreibt, wie ich vorgehen würde, wenn ich sie übernehmen sollte. Sie betrifft nur einen Teil meines Werdegangs: Meine Hauptrolle bleibt die des Entwicklers.

Die Arbeit zählt mehr als der TitelDieselben Bezeichnungen stehen von Unternehmen zu Unternehmen für unterschiedliche Aufgaben: Entscheidend ist, wer die Entscheidungen trifft und dafür einsteht.
Entscheidungen, die bleibenWo die Software läuft, wer die Daten sieht, wie sie aktualisiert wird: Das nachträglich zu ändern ist teuer.

Zwei Ebenen vor dem einzelnen Projekt

Ein produktives System muss genaue Ziele erreichen: Leistung, Zuverlässigkeit, Sicherheit und Compliance, Nachvollziehbarkeit, Betriebsfähigkeit, Flexibilität, Kosten. Dafür wird auf zwei Ebenen gearbeitet, noch bevor es um die Funktionen der Anwendung geht.

Der Solution Architect legt die Architektur der Dienste fest: welche Cloud-Dienste eingesetzt und wie sie verbunden werden, um diese Ziele zu erreichen. Microsoft beschreibt ihn als jemanden, der Stakeholder berät und Geschäftsanforderungen in technische Entwürfe übersetzt, gemeinsam mit Entwicklern, Administratoren sowie Sicherheits- und Datenfachleuten.

Der Softwarearchitekt legt die gemeinsamen Softwareregeln fest, die diese Entscheidungen wirksam machen: wie jede Komponente Protokolle schreibt und die Monitoring-Werkzeuge nutzt, wie sie die Dienste verwendet, wie sie mit Fehlern und Konfiguration umgeht.

Keine der beiden Ebenen reicht ohne die andere. Das Monitoring muss in der Architektur vorgesehen sein, aber nützliche Daten entstehen nur, wenn auch die Entwicklung genauen Regeln folgt. Bei eingeschränktem Produktionszugriff wird das deutlich: Bei einer Anomalie kann man sich nur auf das verlassen, was vorher vorgesehen wurde.

Cloud-Erfahrung

Für beide Rollen sind diese Dienste und Regeln fast immer zu bewerten: Sie bilden eine Grundlage, fast ein eigenes Framework, für ein Projekt, das die Cloud-Umgebung nutzt, wachsen kann und sich überwachen lässt.

Danach geht es um das einzelne Projekt und darum, was es wirklich braucht. Der Softwarearchitekt entscheidet, welche Architektur entwickelt wird, etwa ob Clean Architecture zum Einsatz kommt, und legt die Entwicklungsregeln fest; gemeinsam werden die passenden Dienste und Cloud-Patterns gewählt. Je nach Situation beginnt man mit einem Prototyp (Proof of Concept), der die Einhaltung dieser Regeln prüft, und geht dann in die eigentliche Entwicklung.

Wie ich den Code organisiere

Auch die Anforderungen des Projekts können die Grundlage verändern: Regulierte Daten oder hohe Volumina können andere Dienste erfordern.

Das sind keine standardisierten Titel. In großen Organisationen kommt der Enterprise Architect hinzu, der an der Gesamtheit der Systeme und an der Technologiestrategie arbeitet, nicht am einzelnen Projekt.

Die Rolle ist nicht mit der Cloud entstanden, doch heute treffen beide Themen fast immer zusammen. In der Cloud kauft man Infrastruktur nicht einmalig: Man wählt aus vielen Diensten, beschreibt sie in versionierten Dateien und zahlt jeden Monat. Eine Architekturentscheidung wird damit auch zu einer Entscheidung über Kosten, Risiken und die Abhängigkeit von einem Anbieter.

Vier unterschiedliche Situationen

01

Kleine Projekte: Architektur gehört zur Entwicklung

In einem kleinen Projekt gibt es keine eigene Rolle: Die Architekturentscheidungen trifft, wer entwickelt, während der Entwicklung.

Die Entscheidungen gibt es trotzdem: wo die Anwendung gehostet wird, wie ihre Teile getrennt werden, welche Dienste hinzukommen. Es genügt eine erfahrene Person, die sie trifft und dafür einsteht; eine eigene Rolle würde mehr kosten, als sie einbringt.

Was es braucht

  • Eine Person, die entscheidet und dafür einsteht
  • Wenige schriftliche Entscheidungen, mit Begründung
  • Eine Struktur, die später wachsen kann

Meine Rolle

Hier habe ich die Entscheidungen selbst getroffen, in direkter Zusammenarbeit mit dem Kunden.

Ein Beispiel

02

Komplexere Projekte: die Lösung festlegen und den Boden bereiten

Wenn es mehrere Systeme und viele Entwickler gibt, wird die Architektur zu einer anspruchsvollen Aufgabe für sich.

Es reicht nicht, zu entscheiden, wie die Lösung aussehen soll: Vorzubereiten ist auch, was dem Team die Arbeit ermöglicht. Gemeinsame Regeln im Code, etwa zu Protokollen, Monitoring und Nutzung der Dienste; getrennte Umgebungen für Entwicklung, Test und Produktion, beschrieben mit Infrastructure as Code; Pipelines, die kompilieren, prüfen und ausliefern; Regeln dazu, wer worauf zugreift; ein kontrollierter Weg für Datenbankänderungen. All das muss dann gepflegt werden, weil es sich mit dem Projekt verändert.

In dieser Größenordnung legt oft dieselbe Person oder eine kleine Gruppe fest und baut zugleich. Wächst das Projekt, geht die Pflege an DevOps- oder Plattformspezialisten über, und der Architekt gibt die Richtung vor.

Was es braucht

  • Wiederholbare Infrastruktur und Releases, die nicht vom Gedächtnis Einzelner abhängen
  • Eine Möglichkeit, jede Änderung ohne die Cloud zu prüfen
  • Eigene Zeit: Das ist keine Nebenaufgabe der Entwicklung

Meine Rolle

Die Lösungen dieser Art, an denen ich gearbeitet habe, waren bereits in Betrieb. Ich habe als Teil des Teams daran gearbeitet, betrachte sie aber nicht als mein eigenes Werk.

03

Große Programme: eigene Rollen, oft ein ganzes Team

In sehr großen Programmen tun Softwarearchitekten und Solution Architects nichts anderes, und oft reicht eine Person nicht aus.

Microsoft unterscheidet Plattformteams, die die gemeinsame Grundlage aufbauen, von Teams für Regeln und Sicherheit und von denen, die die Anwendungen entwickeln. SAFe, ein Framework für agiles Arbeiten im großen Maßstab, sieht auf jeder Ebene einen Architekten vor, von der Gruppe von Teams bis zum Portfolio, und merkt an, dass die Rolle oft einem kleinen Team übertragen wird.

Eigene Rollen heißt nicht getrennt. Martin Fowler erinnert daran, dass Architektur eng mit der Programmierung verwoben ist: Entfernt sich, wer entscheidet, vom Code, verlieren die Entscheidungen den Kontakt zu dem, was tatsächlich geschieht.

Meine Rolle

In Programmen dieser Größe habe ich als Entwickler und Teamleiter gearbeitet, nicht als Architekt. Ich habe von anderen festgelegte Architekturen angewendet, ihre Folgen aus der Nähe gesehen und an Systemen im laufenden Betrieb gearbeitet.

Cloud-Erfahrung

04

Die Cloud-Migration eines Unternehmens

Dazu kommt eine Aufgabe, die über die Entwicklung hinausgeht: die Tätigkeiten und Ressourcen eines Unternehmens in die Cloud zu bringen.

Am Anfang steht die Analyse der Ausgangslage: Anwendungen, Server, Daten, Verträge, Menschen und der Grund, warum sich der Umzug lohnt. Nicht alles wird gleich behandelt: AWS nennt sieben Strategien, darunter stilllegen, was nicht mehr gebraucht wird, belassen, was noch nicht bereit ist, und durch ein vorhandenes Produkt ersetzen. Microsoft ordnet die Migration in einen größeren Weg ein: Strategie, Plan, Vorbereitung der gemeinsamen Grundlage, Einführung, Governance, Sicherheit und Betrieb.

Auf diesem Weg übersetzt der Solution Architect die Ziele in Architekturen und leitet den technischen Teil. Die Entscheidungen bleiben beim Unternehmen, das auch Finanzen, Sicherheit und Compliance einbezieht.

Meine Rolle

Damit habe ich mich nicht befasst; ich erwähne es, weil es eine weitere Bedeutung des Begriffs ist. Meine Migrationsarbeit betrifft einzelne Anwendungen.

Wie ich sie migriere

Die Fragen, auf die es für ein Unternehmen ankommt

Wenn ich diese Rolle übernehmen sollte, würde ich mit diesen Fragen beginnen. Es sind nur die wichtigsten: Jede Antwort kann weitere aufwerfen, und Analyse und Entscheidungen hängen immer vom Kontext und vom Projekt ab.

Wo läuft die Software?

Azure bietet Dienste für Webanwendungen, für Software in Containern, für ereignisgesteuerte Funktionen sowie Kubernetes. Kubernetes gibt die größte Kontrolle und erfordert mehr Betriebsaufwand: Es sollte wegen eines konkreten Bedarfs gewählt werden, nicht aus Gewohnheit.

Wie lange darf das System ausfallen, und wie viele Daten dürfen verloren gehen?

Ohne diese Zahlen sowie die erwarteten Nutzer und das Budget lässt sich nichts dimensionieren. Mehr Zuverlässigkeit kostet mehr.

Wer darf die Produktionsdaten sehen?

Wer die Software kompiliert, darf deshalb noch nicht die Kundendaten lesen. Auch indirekte Wege zählen: Protokolle, Backups, Exporte, Diagnosewerkzeuge.

Lässt sich eine Änderung ohne die Cloud prüfen?

Wenn jeder Test ein Release erfordert, wird das Team langsamer und die Kosten steigen. Die Software ist so zu organisieren, dass sie sich auf dem Rechner der Entwickler testen lässt; manches, wie Netzwerk und Identität, wird trotzdem in der Cloud geprüft.

Wer erstellt die Ressourcen, und wer liefert die Software aus?

Das sind getrennte Aufgaben, keine Alternativen. Die Pipeline kompiliert, prüft und liefert die Software aus; Terraform oder Bicep beschreiben die Ressourcen und werden in der Regel von derselben Pipeline ausgeführt. Sie lohnen sich schon für ein einzelnes Projekt und werden unverzichtbar, wenn die Lösung in mehreren Kopien installiert werden soll. War ein Vorgang erfolgreich, gibt es die Ressourcen: Das heißt nicht, dass der Dienst funktioniert.

Von wo aus arbeiten die Entwickler?

Sind die Dienste nur im privaten Netz erreichbar, braucht es ein VPN, einen Zero-Trust-Zugang oder einen mit dem Netz verbundenen Cloud-PC. Kosten und Betrieb ändern sich, das Prinzip nicht: Jede Änderung muss mit eigenständigen Tests prüfbar bleiben, und im Netz zu sein gibt keinen Zugriff auf Produktionsdaten.

Wie gelangen Datenbankänderungen in die Produktion?

In der Entwicklung werden Datenbanken manchmal von Hand geändert. Solche Änderungen müssen erfasst, geprüft und versioniert werden, nie automatisch kopiert.

Was, wenn das Release schiefgeht?

Zur vorherigen Softwareversion zurückzukehren ist meist möglich; bei Daten ist das viel schwieriger. Das ist vorher zu entscheiden.

Ein Release über mehrere Systeme

Was kostet es wirklich?

Ein Budget in Azure warnt, stoppt aber den Verbrauch nicht. Ein Dienst, der sich bei Nichtnutzung abschaltet, senkt die Ausgaben nicht auf null: Daten, Netzwerk und Protokolle bleiben. Zu betrachten ist das gesamte System, einschließlich der Zeit derer, die es betreiben.

Eine Installation pro Kunde oder eine gemeinsame?

Für Anbieter von Software als Dienst erleichtert die eigene Kopie die Datentrennung und die Wiederherstellung, erhöht aber die Kosten deutlich und vervielfacht die Updates. Nötig sind ein Verzeichnis der Installationen, Updates in Wellen und Abläufe für Kunden, die hinzukommen oder gehen.

Was landet in einem KI-Modell? An das Modell gesendete Daten unterliegen denselben Grenzen wie Produktionsdaten. Die Garantien hängen vom Dienst und seiner Konfiguration ab.

KI-Sicherheit

Wie ich in dieser Rolle arbeiten würde

  1. Zuerst die Zahlen

    Verfügbarkeit, Volumen, regulierte Daten, Budget. Ohne sie ist jede Produktwahl verfrüht.

  2. Schriftliche Entscheidungen

    Was gewählt wurde, welche Alternativen es gab, warum, und wie man zurückkommt.

  3. Ein Prototyp, wenn nötig

    Eine Funktion, vom Code bis in eine reale Umgebung gebracht, mit Tests, Release und Monitoring, um vor der eigentlichen Entwicklung zu prüfen, dass das Projekt die Regeln einhält.

  4. Faire Vergleiche

    Zwei Lösungen werden am selben Fall und mit denselben Anforderungen verglichen: Kosten im Leerlauf, Release, Wiederherstellung.

  5. Ausfälle proben

    Ein Backup wird wirklich wiederhergestellt, und ein mittendrin abgebrochenes Release wird simuliert.

Das ist eine Arbeitsmethode, keine Ergebnisgarantie.

Meine Erfahrung im Überblick

Dieses Profil gilt nur für einen Teil der Projekte in meinem Lebenslauf.

  • Festgelegt habe ich Architektur und technische Entscheidungen, als einziger Entwickler, mit Direktkunden (C-06, C-07).
  • Mitgearbeitet habe ich an bereits laufenden Lösungen, als Teil des Teams: Releases über mehrere Systeme, Diagnose bei eingeschränktem Produktionszugriff, Infrastructure as Code (C-01, C-05, Cloud-Erfahrung).
  • Nicht befasst habe ich mich mit Cloud-Migrationen eines ganzen Unternehmens: Meine Migrationen betreffen einzelne Anwendungen (Migration).

Quellen zur Einordnung

Die Quellen beschreiben Rollen und Dienste. Die vier Situationen und die Arbeitsweise in dieser Rolle sind meine Einschätzung aus der Erfahrung, keine offizielle Einteilung.

Inhalt zuletzt aktualisiert am

Brauchen Sie jemanden, der diese Rolle in einem Projekt übernimmt?

Ausführlicher Lebenslauf und Referenzen auf Anfrage verfügbar.