“Endlich fertig!” Das waren meine ersten Gedanken, als ich das letzte Kapitel dieses Buches gelesen hatte. Schon vor dem Kauf hätte mir klar sein können, dass es hier detailliert zugeht: 600 Seiten zum Thema Architektur ist für die Art von Projekten, die ich aktuell bearbeite, evtl. doch etwas hochgegriffen. Aber vermutlich waren die guten Amazon-Reviews und die Tatsache, dass es bei Addison-Wesley erschienen ist, Grund genug mich bei der Suche nach Büchern zum Thema Architektur für dieses Buch zu entscheiden.

Der Untertitel lautet “Working with Stakeholders Using Viewpoints and Perspectives”. Das Buch gliedert sich in fünf Teile: Die ersten beiden Teile liefern einen Überblick über das Thema Softwarearchitektur, Teil 3 und 4 haben eher etwas von meinem Nachschlagewerk. In Teil 3 geht es um die Viewpoints, Teil 4 beschäftigt sich mit den Perspectives. Teil 5 führt das Buch dann zu einem schnellen Ende und enthält für verschiedene prototypische Projekte Verweise zu den jeweils wichtigsten Kapiteln für die jeweilige Projektart.

Ein Viewpoint definiert Muster, Vorlagen und Konventionen, um einen View zu erzeugen. Die wichtigsten Views im Buch sind: Context, Functional, Information, Concurrency, Development, Deployment und Operational. Die Perspektiven sind orthogonal dazu und behandeln die Themen Security, Performance und Skallierbarkeit, Verfügbarkeit und Resilienz, Evolution, Regulatorik, Accessibility, Internationalization , Location und Usability.

Zu jedem Viewpoint und jeder Perspektive gibt es ein Kapitel, in der dieses Thema inkl. einiger Methoden vorgestellt wird. Das ist bisweilen sehr langatmig, aber wenn man auf der Suche nach einem Buch ist, in dem mal alles steht, dann wird man hier fündig. Das ist auch mein größter Kritikpunkt an dem Buch, es ist langatmig und liest sich nicht gut. Da scheint mir immer wieder der Versuch zu sein (aus wissenschaftlichem Antrieb?), Begriffe sauber zu definieren, die in der IT einfach nicht 100% eindeutig definiert sind. Im Ergebnis habe ich dann die 101. Definition, aber nichts neues gelernt. Genau so geht es mir mit dem häufigen Verweis auf UML als Form der Dokumentation. Auf der einen Seite ist UML natürlich genau, aber wenn fast keiner UML fließend kann, dann hilft es mir auch nix, wenn ich dort einen Kreis an eine Relation gemalt habe, der bedeutet, dass etwas ein Data-Sink ist, dieser Kreis aber von 99 % der Leser entweder übersehen oder nicht verstanden wird.

Nützlich fand ich in dem Teil des Buches zumeist das Kapitel “Problems and Pitfalls”, weil hier kompakt die Themen beschrieben wurden, auf die es in der Praxis meistens ankommt. Aus meiner Sicht eignet sich das Buch als Nachschlagewerk oder in Vorbereitung auf große Projekte. Dafür macht es eventuell auch Sinn, einzelne Kapitel zu lesen, wenn man einzelne Perspektiven bearbeitet.