Stefan Zörner
01.09.2009
Java Magazin, Kolumne "Architekturen dokumentieren", Folge 12
Ran ans Whiteboard, und erklärt! Als Softwarearchitekt kommunizieren Sie Ihre Konzepte und Endscheidungen im Entwicklungsteam. Für die meisten von uns stellt dies keine große Hürde dar. Denn Architekten sollten zuvor selbst lange als Entwickler oder Spezialist in Projekten gearbeitet haben. Oft nehmen sie ohnehin eine Doppelrolle wahr. Erfahrungshorizont und Sprache der Beteiligten liegen nahe beieinander. Was nicht heißen soll, dass es hier nicht zu Konflikten kommen kann. Aber zumindest die Wellenlänge stimmt meist überein.
Nun sind Entwickler aber nicht die einzigen, mit denen sich Architekten über das gemeinsame Vorhaben austauschen. Die Projektleitung ist an Ressourcenverbrauch und Risiken interessiert, auch Kunden und Auftraggeber wollen über den Projektfortschritt auf dem Laufenden gehalten werden, und ab und an was vorgeführt bekommen. Kommunikationsfähigkeiten sind zentrale Erfolgsfaktoren für einen Architekten [1]. Insbesondere muss er seine Ideen zielgruppenorientiert vermitteln können; er hat es mit sehr unterschiedlichen Empfängern zu tun. Zu den Kommunikationspartnern zählen regelmäßig auch Personen aus dem Management, sei es auf Seiten der Kunden und Auftraggeber, oder auch in Form eigener Vorgesetzter. Diese Leute entscheiden mitunter über die Zukunft Ihres Projektes. Effektiv auch mit dieser Zielgruppe kommunizieren zu können ist entscheidend!
„Wo sind denn auf dem Bild unsere Kunden?“ – Haben Sie schon einmal Entscheidern anhand bestehender Dokumentation die Architektur Ihres Systems erklärt? Versuch einer Antwort: „Kunden greifen vom PC per Browser auf unser System zu, die sind hier nicht mit drauf. Nur unsere Webserver sind drauf.“ Worauf hin der Entscheider denkt: „Tolle Bilder malen die, nicht mal unsere Kunden sind drauf.“ und Sie fragen sich vielleicht: „Weiß der überhaupt, was ein Browser ist?“ [2]. Entscheider lesen nicht das Java Magazin, sondern die Computerwoche („7 Spartipps fürs Rechenzentrum“). Sie operieren auf einem völlig anderen Abstraktionsniveau als wir. Entscheider versuchen vor allem betriebswirtschaftliche Anforderungen zu erfüllen. Dabei geht es um ein vernetztes Denken in den Zusammenhängen der ganzen Firma oder sogar eines Konzerns. Entscheider entwickeln Visionen und Strategien für die Zukunft. Sie verstehen nicht unmittelbar, warum OSGi eine tolle Sache ist. Stattdessen rechnen sie gerade, die gesamte IT mit Hilfe von SAP zu harmonisieren, oder die Individualentwicklung nach Tschechien auszulagern.
Konsequenterweise sind meisten in dieser Kolumne vorgestellten Arbeitsergebnisse der Architekturdokumentation, insbesondere die unterschiedlichen Sichten notiert in UML, nicht entscheiderkompatibel. Nicht notwendiger Weise deshalb, weil sie nicht verstanden werden (was zwar meist der Fall ist), sondern weil die Implikationen auf die betriebswirtschaftlichen Aspekte nicht zu erkennen sind.
Was nicht heißt, dass man für diese Zielgruppe nicht auch mit Abbildungen arbeiten kann, um zu vermitteln, was auf neudeutsch so schön „The Big Picture“ heißt. Nur muss die Argumentation anders ansetzen. Und ein (lediglich unterstützendes) managementtaugliches Bild sieht ebenfalls anders aus: Informelle Notation, viel Symbolik, sinnvoll eingesetzte Farben. Ansprechend im wahrsten Sinne des Wortes. Eine gemeinsame „Big Picture“-Abbildung eignet sich darüber hinaus, früh ein einheitliches Bild vom System im Team zu etablieren. Es besteht hier allerdings die Gefahr, dass es das einzige Bild bleibt, keine Architektursichten erstellt werden, und immer mehr Aspekte in der Abbildung vermischt werden. Trennen Sie es daher klar von Bausteinsicht, Kontextsicht, Laufzeitsicht usw. Es ist im Grunde eine weitere Sicht. Nennen Sie sie z.B. „Architekturüberblick“. Anders als bei den anderen Sichten ist die UML hier keine geeignete Notation. Es spricht nichts dagegen, einen Architekturüberblick frei von Hand zu zeichnen, wie das Beispiel von Scott Ambler in Abbildung 1 zeigt (Quelle: [3]). PowerPoint oder Visio sprechen Entscheider in der Regel mehr an, und es ist bei elektronischen Diagrammen leichter eine Änderung oder Ergänzung möglich. Da das Abstraktionsniveau eines Architekturüberblicks sehr hoch ist, sollte dies jedoch selten nötig sein. Es ist daher kein Drama, die Abbildung nicht in einem Modell mit den übrigen Artefakten zu halten. Nichts desto trotz sollte der Überblick natürlich konsistent zu den anderen Sichten sein. Ansonsten stiftet er schnell Verwirrung, oder wird im Entwicklerteam nicht ernst genommen.
Der Architekturüberblick unterstützt bei der Kommunikation ähnlich wie Produktkarton und Systemidee [4]. Gut gemacht ist er exzellent geeignet, neue Teammitglieder ins Boot zu holen, Sponsoren zu informieren, oder Bedenkenträger zu überzeugen. Oder auch einem Manager einen groben Überblick darüber geben, was für ein System Ihr Team gerade baut. Der Architekturüberblick ist ein wichtiger Baustein des Projektmarketings, er wird in jedem mit dem Vorhaben verbundenen Powerpoint-Foliensatz auftauchen.
Zurück in den Lenkungsausschuss. Folie zur Ist-Situation. „Oh, da sind ja unsere Kunden. Und da ist der Host. Die Host-Wartungsverträge laufen aus. Eine Verlängerung bindet uns weitere 5 Jahre …“. Dem Entscheider gelingt eine Einordnung Ihres Vorhabens in seinen Kontext. Hier können Sie anknüpfen: „In der Zeit gehen 8 der 13 Host-Entwickler in Rente. Der Markt gibt keine neuen Arbeitskräfte für diese alte Technologie her. Obwohl die Wartungskosten derzeit für das Host-System extrem niedrig sind, gilt es jetzt die Weichen neu zu stellen, damit dies in 3 Jahren auch noch der Fall ist. Ich schlage daher folgende Migrationsstrategie vor, …“. Nächste Folie. Ihr neuer Architekturüberblick. Sie haben Vertrauen gewonnen, und vielleicht auch Unterstützer.
[1] U. Vigenschow, Björn Schneider, „Soft Skills für Software-Entwickler<“, Dpunkt 2007
[2] “Browser – Was sind denn jetzt noch mal Browser?”, https://netzpolitik.org/2007/kinderreporter-fragen-politiker-nach-dem-internet/
[3] S. Ambler, „Agile Modeling“, http://www.agilemodeling.com
[4] S. Zörner, “Out of the box. Produktkartons”, Java Magazin 7/2009
Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
“The Big Picture – Mit Entscheidern kommunizieren”, Java Magazin, 09/2009, 2 Seiten, S. 78
(mit freundlicher Genehmigung)