Geben und Nehmen: Die 9 Stakeholder des Systemarchitekten

Eine wichtige Aufgabe des Systemarchitekten ist die Kommunikation. Um ein komplexes System zu entwickeln, ist die Zusammenarbeit mit vielen Stakeholdern erforderlich.

Doch warum sollten die Stakeholder mit dem Systemarchitekten kooperieren? Schließlich kostet das Zeit und Mühe. Daher müssen wir, um erfolgreich zu sein, verstehen, was wir diesen Stakeholdern bieten können. Wir müssen auch präzise formulieren, was wir von den Stakeholdern erwarten, damit wir weder deren Zeit noch unsere verschwenden.

Kurz: Es ist ein Geben und Nehmen. Worum es da genau geht, und wer diese Stakeholder eigentlich sind, erfahren Sie im Folgenden.

Diese Liste stammt übrigens aus dem hervorragenden Buch Model-Based System Architecture (Rezension). Für jede Rolle wird im Folgenden aufgeführt, was diese gibt und dafür vom Systemarchitekten bekommt.

Requirements Engineering

Der Umgang mit Anforderungen hat einen hohen Stellenwert im Systems Engineering.

• Gibt: Eine Erklärung/Erläuterung der Anforderungen
• Bekommt: Das Versprechen, dass die Anforderungen weiter verarbeitet und berücksichtigt werden;
• Bekommt: Eine Erläuterung der Architektur, die beim Ableiten weiterer Anforderungen hilft

Verifikation

Es wird häufig unterschätzt, wie wertvoll eine frühzeitige Zusammenarbeit mit dem V&V-Team ist: Allein schon das frühzeitige Formulieren von Tests kann die Systembeschreibung schärfen und viele Risiken reduzieren, die erst in einer späteren Phase auftauchen würden.

• Gibt: Vertrauen in die Erfahrung des Architekten bezüglich des zu entwickelnden Systems
• Gibt: Expertise bezüglich den geplanten Ansätzen für die Verifikation des Systems
• Bekommt: Ein System, dass die Verifikation beim Design bereits berücksichtigt
• Bekommt: Informationen über die geplante Lösung, die in die Verifikationsaktivitäten einfließen können.
• Bekommt: Eine Basis für Regressionstests, basierend auf solidem Änderungsmanagement

Konfigurationsmanagement

Auch bei der Konfiguration kann eine frühzeitige Absprache viele Risiken entschärfen, die erst später auftauchen würden.

• Gibt: Erläuterung der Konfigurationsmanagement-Strategie
• Gibt: Überblick über die geplanten Systemkonfigurationen
• Bekommt: Versionierte Beschreibung der Systemarchitektur
• Bekommt: Eine Übersicht der Konfigurationselemente des Systems und deren Kompaibilität

Ingenieursdisziplinen

Die angrenzenden Ingenieursdisziplinen werden üblicherweise über Abteilungsleiter, Subsystemarchitekten oder direkt die Entwickler angesprochen. Eine solide Kommunikation ist hier sehr wichtig.

• Gibt: Expertise der Domäne
• Gibt: Das Eingeständnis, das Design eines Subsystems zu verändern, um das Gesamtsystem zu verbessern
• Gibt: Das Vertrauen, dass der Architekt die Kompetenz des entsprechenden Teams respektiert
• Bekommt: Den Respekt eines Stakeholders, insbesondere bezüglich Schnittstellen
• Bekommt: Die Berücksichtigung derer Interessen
• Bekommt: Das Zugeständnis, als kompetenter Domänenexperte respektiert zu werden

Projekt- und Produktmanagement

Die Aufgaben des Architekten werden oft beim Projekt/Produktmanagement angesiedelt. Es macht aber durchaus Sinn, die Rollen zu trennen. Wenn das der Fall ist, ergibt sich die folgende Dynamik:

• Gibt: Die Ressourcen für einen effektiven Dialog zwischen Engineering und Architektur
• Gibt: Das Vertrauen, dass eine gute Architektur einen positiven Return on Investment (ROI) generieren wird
• Bekommt: Übersicht und Klarheit über die Ergebnisse und Lieferungen des Projekts
• Bekommt: Vorhersagbarkeit Bezüglich Kosten und Leistung
• Bekommt: Frühzeitige Warnung bezüglich Risiken
• Bekommt: Bessere Produkte

Planung der Roadmap

Wenn am aktuellen Produkt gearbeitet wird, sind oft schon die nächsten Generationen in der Form einer Roadmap in der Planung.

• Gibt: Transparenz bezüglich der Roadmap und deren Änderungen
• Gibt: Bereitschaft, Kenntnisse der Architektur bei der Roadmapplannung zu berücksichtigen
• Bekommt: Realistischere Roadmaps

Lieferanten

Es wird immer mehr Arbeit an Zulieferer vergeben. Dass hier eine Zusammenarbeit extrem effektiv ist, sollte eigentlich klar sein. Und die Vorteile sind symmetrisch:

• Gibt: Technisches Wissen des Zulieferers, das dem Hersteller hilft, gute Schnittstellendefinitionen zu schaffen
• Bekommt: Technisches Wissen des Herstellers, das dem Zulieferer hilft, gute Schnittstellendefinitionen zu schaffen

Marketing

Hier geht es primär um das Produkt-Marketing, welches sich oft von anderen Marketingaktivitäten abgrenzt.

• Gibt: Bereitschaft, sich auf einen technischen Dialog einzulassen
• Bekommt: Eine Systemarchitektur, welche strategisch unterstützt, anstatt nur ein weiteres Produkt auf der Roadmap darzustellen

Management

Und zuletzt: Selbstverständlich müssen wir das Management davon überzeugen, dass unsere Aktivität zum Geschäftserfolg beiträgt.

• Gibt: Vertrauen, dass die Investition in eine gute Architektur einen positiven Return on Investment (RoI) generiert
• Bekommt: Vorhersagbare Projekte
• Bekommt: Bessere Produkte
• Bekommt: Bessere Kommunikation zwischen den Ingenieursdomänen

Stakeholder des Systemarchitekten

Eigentlich ist das hier gesagte nicht neu. Dennoch ist es erstaunlich, wie lang diese Liste ist. Es ist leicht, einen wichtigen Stakeholder zu vergessen.

Im Systems Engineering geht es zum großen Teil um die Kommunikation. Diese Liste hilft sicherzustellen, dass wir mit allen Stakeholdern kommunizieren.

Photo by Cytonn Photography on Unsplash