Welche Rolle spielen Teams und individuelle Entwickler, wenn es darum geht, skalierbare Architekturen zu implementieren und zu warten?
Eine sehr große. Der Projektarchitekt richtet die zu implementierende Lösung von Beginn an auf Skalierbarkeit aus. Dabei betrachten wir sowohl die horizontale Skalierung von Services als auch die sinnvolle fachliche Zerteilung von Service-Endpunkten (domänen- und Use-Case-orientiert), damit Teams unabhängig entwickeln, deployen und betreiben können.

Wo begegnen Sie im Prozess der Entwicklung skalierbarer Architekturen typischerweise Widerständen oder Herausforderungen im Lernprozess?
Das Entwicklerteam hat die Zerteilung von Services und verteilte Anwendungen in der Regel gut im Griff. Herausforderungen entstehen eher bei Inbetriebnahme, Betrieb und Übergabe an IT-Rechenzentren beziehungsweise interne IT-Abteilungen – insbesondere, wenn Betriebsmodelle, Security- oder Compliance-Vorgaben oder Deployment-Prozesse noch klassisch serverorientiert gedacht sind.

Wir reduzieren diese Reibungspunkte, indem Anwendungen containerbasiert umgesetzt werden, zum Beispiel als Image. Dadurch wird die Übergabe an bestehende IT-Infrastrukturen wie Kubernetes-Cluster klarer und reproduzierbarer. Parallel setzen wir idealerweise gemeinsam mit dem Kunden ab Minute eins einen automatisierten DevOps-Prozess für das Deployment auf, etwa über CI/CD.

Können Sie ein Beispiel aus der Praxis nennen, das zeigt, wie eine Organisation erfolgreich eine skalierbare Architektur eingeführt hat?
HAWIS – Zeitmanagement-Applikation: Aufteilung in WebApp, WebAPI und App; umgesetzt auf Basis von .NET MAUI sowie Azure App Service und Azure SQL Services.

Wie nehmen Sie die Zusammenarbeit zwischen verschiedenen Abteilungen oder Teams wahr, wenn es um die Skalierung von Softwarearchitekturen geht?
Skalierung funktioniert in der Praxis nur dann wirklich gut, wenn Entwicklung, Betrieb beziehungsweise IT-Infrastruktur, Security/Datenschutz und Fachabteilungen früh gemeinsam an einem Zielbild arbeiten. Typische Reibung entsteht dort, wo Zuständigkeiten zwischen den Stühlen liegen, etwa bei Ownership für Logging und Monitoring, Deployment-Freigaben, Berechtigungsmodellen oder SLA- und SLO-Definitionen.

Bewährt haben sich klare Verantwortlichkeiten wie Service Ownership, gemeinsame Standards etwa für Observability und Security-Baselines, regelmäßige Architektur-Reviews sowie eine enge Abstimmung zwischen Dev und Ops. Je früher Betrieb und Security eingebunden sind, desto weniger wird Skalierung später zur nachträglichen Baustelle.

Welche Kompetenzen oder kulturellen Entwicklungen werden Ihrer Meinung nach in Zukunft entscheidend sein, um erfolgreich skalierbare Architekturen zu gestalten?
Entscheidend wird sein, das gemeinsame Verständnis von Softwareentwicklung und Fachabteilungen zu erhöhen, wenn wir über IT-Systeme sprechen. Begriffe wie Webserver oder Datenbankserver sind heute eher als Webservice beziehungsweise Datenbankservice zu verstehen. Für den Betrieb moderner Anwendungen müssen IT-Dienstleistungen als Cloud- oder Rechenzentrums-Services gedacht werden. Es wird weniger ein Server gekauft, sondern ein Service genutzt, der auf einer gemeinsamen Infrastruktur – on-premises oder in der Cloud – betrieben wird.