Software-Architektur im Spannungsfeld zwischen Business und Entwicklung

18. April 2024

|

Matthias

Software-Architektur hat viele wichtige Facetten und Zielstellungen: Als Bauplan eines Systems, als Mittel der Risikominimierung, als Instrument zur Kommunikation und viele mehr. Der Begriff Software-Architektur steht sowohl für die Architektur von Systemen die schon existieren als auch von Systemen, die gerade erst in der Planung sind. Und zusätzlich wird er auch noch für alle Engineering-Aktivitäten rund um Software-Architektur verwendet. Es ist also immer wichtig, klar herauszustellen, um was es gerade geht bei Software-Architektur.

In diesem Artikel möchte ich einen bestimmten Aspekt in den Fokus nehmen: nämlich die Arbeit rund um Software-Architektur, die sich aus der Einbettung von Software-Architektur zwischen Business und Anforderungen auf der einen Seite und Entwicklung und Betrieb auf der anderen Seite ergibt. Dazu möchte ich auch Hinweise auf sehenswerte Vorträge geben, die tiefere Einblicke in das Thema geben.

In der Software-Entwicklung, gerade wenn es um große Entwicklungsorganisationen geht, gibt es viele einzelne Rollen und Aufgabebereiche. Und oft entstehen Probleme dadurch, dass in den einzelnen Bereichen zu viel auf die eigenen Themen und Aufgaben geschaut wird und nicht auf das Big Picture. Und zwar sowohl auf das Big Picture der entstehenden Software als auch auf das Big Picture der entwickelnden Organisation und ihrer Prozesse.

Software-Architektur in vermittelnder Mission

Software-Architektur als Disziplin hat sich an zentraler Stelle entwickelt, um Herausforderungen rund ums Big Picture zu begegnen. So vermittelt Software-Architektur zwischen Anforderungen und Umsetzung, indem ein übergreifendes Lösungskonzept, vor allem für Qualitätsanforderungen und querschnittliche Aspekte, für ein System erstellt wird. Software-Architektur stellt aber auch die Verbindung zwischen Subsystemen oder Komponenten eines Systems dar und damit im Sinne von Conway’s Law auch noch die Verbindung zwischen Teams oder Organisationseinheiten. Außerdem verbindet Software-Architektur die Entwicklung eines Systems mit dem Betrieb des Systems, unabhängig davon wie die konkrete Ausgestaltung aussieht.

Dazu kommt, dass Software-Architektur nicht einfach nur Anforderungen in Lösungen übersetzen kann, sondern dass dies ganz häufig mit Risiken und Abwägungen einhergeht, die bei der Anforderungsklärung noch gar nicht diskutiert werden konnten. Somit führt Architekturarbeit häufig auch zu Nachschärfungen und Verhandlungen mit den Verantwortlichen für das Gesamt-Business, um die Konsequenzen von bestimmten Entscheidungen für bestimmte Anforderungen und Lösungen zu diskutieren.

Aus dieser zentralen und vermittelnden Rolle von Software-Architektur als Disziplin ergeben sich Herausforderungen und Anforderungen an die Kompetenzen der Menschen, die in der Disziplin und Rolle arbeiten. Und dies völlig unabhängig davon, in welcher Rollenkonstellation Architekturarbeit stattfindet (dezidierte Architekten, Architektenrolle in Teams, verteilte Verantwortlichkeiten, …).

Zentrale Skills und Eigenschaften für die Arbeit an Software-Architektur liegen deshalb rund um Kommunikation. Nur so kann das Spannungsfeld kontrolliert beackert und das Big Picture zusammengehalten werden. Das bedeutet nicht nur Rhetorik, sondern vor allem auch eine Zielgruppen-spezifische Kommunikation, mündlich wie schriftlich. Das Top-Management eines Unternehmens hat andere Ziele und Prioritäten als eine Entwicklungsabteilung. Und andere Ansprüche an Kommunikation. Deshalb muss Kommunikation immer durch Software-Architektur fundiert sein, aber sehr spezifisch für die Zielgruppe aufbereitet sein. Das betrifft sowohl den Abstraktions- und Detailgrad als auch die Darstellung. Und vor allem müssen sich Architekten Glaubwürdigkeit erarbeiten, damit sie mit ihren Anliegen ernst genommen werden und durchdringen.

Sehr empfehlenswerte Vorträge zum Thema

Ein Vortrag der dieses Thema toll zusammenfasst ist von Gregor Hohpe :

„The Architect Elevator: Connecting Penthouse and Engine“

Der Vortrag packt dieses Spannungsfeld sprichwörtlich in ein Hochhaus, wo das Business im Penthouse sitzt und die Entwicklung im Maschinenraum. Und Architekten fahren im Aufzug zwischen allen Stockwerken. Der Vortrag ist voller Tiefe, Anekdoten und Humor.

Ein weiterer Vortrag, den ich hier empfehlen möchte, ist von Jochem Schulenklopper .

„Why they just don’t get it: Communicating Architecture to Business Stakeholders“

Dieser Vortrag ist zwar schon fast 10 Jahre alt, blieb mir aber über die ganze Zeit in bester Erinnerung. Jochem bringt toll auf den Punkt, warum es mit der Kommunikation von Architekten öfters mal nicht so gut funktioniert … und oft liegt es eben daran, dass Architekten nicht Zielgruppen-spezifisch kommunizieren, vor allem nicht für das Management. Da werden zum Beispiel ungefiltert Diagramme aus Architekturtools kopiert und lieblos in Powerpoint kopiert und man wundert sich, warum das niemanden interessiert und es keiner versteht. Jochem hält ein Plädoyer dafür, dass Kommunikation eine so essentielle Aufgabe von Architekten ist, dass man den Aufwand nicht scheuen darf, für einzelne Zielgruppen und Vorträge individuell angepasste Darstellungen zu erarbeiten.

Fazit

Die beiden Vorträge vertiefen sehr spannende Themen rund um das Spannungsfeld zwischen Business und Entwicklung und bringen zahlreiche Tipps mit, wie die Architektenrolle zur Auflösung beitragen kann.

Trotz allem sollten wir die folgenden Blickwinkel aber nicht vergessen:

  1. Die Verantwortung liegt nicht nur bei der Software-Architektur: Es wäre zu bequem für alle anderen Rollen und Disziplinen, wenn der verbindende Charakter hauptsächlich durch die Software-Architektur zu erbringen wäre. Diese Aufgabenteilung skaliert nicht gut und ist auch sehr abhängig von einzelnen Personen. Trotzdem ist es in der Praxis häufig notwendig, dass aus der Architektur-Rolle alle Fäden zusammengehalten werden, weil es sonst gar nicht passiert.
  2. Die Rolle nicht zu sehr überladen, sonst kann sie fast niemand ausfüllen: Natürlich ist es schön, wenn es Menschen gibt, die alles zusammenhalten, den Überblick haben, alle passend einbinden und perfekt kommunizieren. Das kann und darf aber nicht der Anspruch an die Architektenrolle im Allgemeinen sein. Sonst finden sich einfach zu wenige Menschen, die das überhaupt ausfüllen können, um alle Software-Projekte zu versorgen. Als Zielbild der persönlichen Entwicklung bietet diese Vision aber viel Entfaltungsspielraum und Entwicklungsspielraum für Menschen, die sich für diese Art der Arbeit begeistern.

Wie seht und erlebt ihr dieses Spannungsfeld? Lasst uns gerne einen Kommentar da oder meldet euch auch gerne direkt bei uns.

Matthias

Bitte teilen

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert