Softwarearchitektur – Dokumentation ist Pflicht, nicht Kür
Ich erlebe es als Consultant in verschiedensten, teilweise großen Projekten ständig, dass der Dokumentation der Architektur einer Software nicht die angemessene Aufmerksamkeit geschenkt wird. Erst zuletzt war ich wieder im Rahmen eines Beratungseinsatzes zu aktuellen Software-Technologien bei einem Kunden, der sein über 10 Jahre gewachsenes System auf eine aktuelle Basistechnologie migrieren wollte. Ich stelle dann als Erstes immer die Frage nach der Dokumentation, insbesondere was die bestehende Architektur angeht. Oft, wie auch in diesem Fall, ist dann wenig bis gar nichts vorhanden. Kein Dokument, kein Bild, nicht selten wissen selbst die zuständigen Entwickler nicht mehr, welche Ideen zu der bestehenden Architektur geführt haben.
Woran liegt das? Ich beobachte immer wieder, dass die Architektur fast vollständig in die Hände der implementierenden Entwickler gegeben wird, ohne dass überhaupt die Verantwortung für deren Erstellung und Dokumentation geklärt ist. Die Folge ist dann oft, dass die Architektur sowie die zu dieser führende Entscheidungen spärlich dokumentiert werden und somit zum Spezialwissen des (leitenden) Entwicklers werden, was wiederum dazu führt, dass die Kosten für Wartung und Weiterentwicklung extrem steigen, nachdem dieser verantwortliche Mitarbeiter für das Projekt nicht mehr zur Verfügung steht. Davon, dass das Gesamtkonzept der Architektur dann oft ebenfalls nicht stimmig ist, sehe ich hier mal ab.
Aus Sicht des Projektmanagements ist es natürlich sehr bequem, da durch den (oft unbewussten) Verzicht auf Teile der Planung und Dokumentation früher mit der Umsetzung begonnen werden kann. Kurzfristig gesehen werden unter Umständen auch Kosten eingespart. Der Preis ist allerdings eine mangelhafte Dokumentation der Lösung bzgl. der Erfüllung insbesondere der nichtfunktionalen Anforderungen. Diese fehlt sowohl als Diskussionsgrundlage für Entscheidungen über eventuelle Erweiterungen sowie als technische Dokumentation für künftige Entwicklergenerationen. Hier heißt die einzige Lösung meist „Reverse Engineering“ – für Softwareentwickler mit Neigung zur Forensik zwar bisweilen sehr interessant, in der Regel aber enorm kostspielig.
Wie lässt sich das vermeiden? Natürlich durch eine professionelle Architekturdokumentation: International anerkannte Standards und sogar Dokumentvorlagen gibt es zur Genüge, nur machen muss es auch jemand. Hierfür ist im Projekt eine klare Besetzung der Architektenrolle nötig, bzw. des Verantwortlichen für deren Dokumentation, und zuallererst natürlich die Erkenntnis, dass gerade in unserem heutigen, dynamischen (man könnte auch schreiben: agilen) Umfeld nur eine Software mit einer sauberen Architekturdokumentation auch über einen längeren Wartungszeitraum erfolgreich sein kann, ohne zum finanziellen Fass ohne Boden zu werden.
Fazit:
Über die Architektur einer Software sollte nicht nur nachgedacht werden, sondern diese muss auch möglichst gut dokumentiert werden. Es ist aber allemal besser wenig und unkonventionell zu dokumentieren, als gar nicht. Solange der am Entstehungsprozess unbeteiligte, wenn nötig, die Grundidee erkennen kann.
Weiterführende Links zu dem Thema:
IEEE 1016 Software Design Description – Internationaler Standard zur Dokumentation von Softwarearchitektur des Institute of Electrical and Electronics Engineers (Wikipedia)
Softwarearchitektur im V-Modell XT – und deren Dokumentation
Tagged Dokumentation, Entwicklungsprozess, Nichtfunktionale Anforderungen, Projektmanagement, Software-Engineering, Softwarearchitektur
