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