Documenting Software Architectures: Views and Beyond (2nd Edition) [Kindle Edition]

Warning up front: This book is not about teaching hands-on, direct-to-use techniques for documenting software architectures. It is a lengthy, sometimes academically long-winding discussion about what a good documenation is and what techniques might be employed. It is a book to make the reader think, it is not a shop from which you can lift pracical recipes without reading the small print first. But the book does fulfill its promise: It makes you think about the problem. Pretty hard, actually. So read on if this is what you want.

Very few books on software architecture tackle the difficult problem of how a software architecture should be presented. This is a surprising omission given the commonly accepted dictum that architecture is, to a large extent, about communication. The omission may indicate that despite attempts at formalizing software specification (e.g UML, BPMN or various attempts at specifiying templates for architectural documents) no single technique of describing an architecture is sufficient in practice. From my own experience, I think this is not really surprising. Unlike specifications for physical machinery, software is prone to demand a plethora of different views. These range from the creation of the contextual language for a specific software (e.g. the formalisation of measurement in medicine as first step towards building a diagnostic system) over the various clasical views on an architecture all the way to a business perspective whithout which no budget may be available to the project. What makes software architecture documents particularly difficult is the interrelation between various views and the importance of dynamic aspects (which are among the more difficult aspects to capture in documentation). But to my mind, one of the hardest challenges of all, and usually mentioned at best in passing, is the problem of creating the right sort of contextual language up front.

The present book is a laudable attempt at discussing various methods of formally describing a software architecture. That the requiste material is all there can be glimpsed from the table of contents. I wish to make the following remarks: The authors make no attempt at finding a general formal solution to the title-problem of documenting a software architecture. Instead, they discuss the standard persepctives but remain aware throughout that there is no single solution. They take the reader through the various persepctives that need to be serviced by an architect. The authors challange their readers to think further by providing numerous exercises which help show the diversity inherent in the discussion. They do not limit themselves to one technique of documentation but, through their own example, make it plain that documenting an architecture requires different tools and, above all!, a sure command of language. It is this latter distinguishing feature, which is not explicitly mentioned in the book but implicit in the author's own way of presenting their thinking, that should be one of the main conclusions of the book. However, and this is where I have not been quite so happy, they stop short of showing how formal representations tie in with the way we first create the language in which we talk about the problem to be cast in software.

The book is not a book of recipes. It is a book that gets you thinking about the complex problem of writing up an architecture. The focus remains on documenting technical architectures and only implicity touches on the larger problem of how an architecture is, in writing, related to the problem domain it is intended for. I find it a useful restriction that templates for use in projects are not provided - these tend to limit inexperienced architects to given perspectives and in practice may lead you to omitting what may be particular and specific about your architecture. An excellent push in the right direction. Be pushed and then push on.

Eine gute SW-Architekturdokumentation umfasst verschiedene Aspekte, von der logischen Struktur bis hin zu Konfigurations- und Hardware-spezifischen Sichten. In dem Buch "Documenting Software Architectures" beschreiben die Autoren verschiedene Sichten ("Views"), die sie in 3 Gruppen einteilen: Module Views, Component&Connector Views, und Allocation Views. Bei Bedarf können weitere Views definiert werden, z.B. in spezielle Domänen oder innerhalb von Firmen.
Ihr systematischer Ansatz erlaubt es, alle relevanten Aspekte zu beschreiben. Im Buch werden Vergleiche z.B. zu IEEE 1471 und UML gezogen, wobei sie detailiert Möglichkeiten und Einschränkungen von UML 1.x im Rahmen von Architekturdokumentationen aufzeigen. UML2.0, das besser zur SW-Architektur-Dokumentation geeignet ist, wird nicht behandelt.

Das momentan immer noch einzige Buch zum Thema "Architekturdokumentation" - mit vielen hilfreichen Tipps für gute Dokumentation. Clements motiviert das (wichtige!) Thema "Architektur aus unterschiedlichen Sichten" sehr gut und ausführlich.

Aber: In der Praxis möchte ich NICHT zuerst mal über die geeigneten Viewpoints und Perspectives forschen, sondern meine konkrete Architektur dokumentieren. Clements versäumt es, mir DAFÜR konkrete Hilfestellung zu geben, leider! Ich möchte auch nicht jedes Mal wieder über mögliche Notationen und Strukturen diskutieren - auch dafür gibt Clements nur sehr ausweichend Hilfestellung...

Den Beispielen merkt man den akademisch/militärischen Hintergrund an - ich fand sie nicht besonders hilfreich. Clements hätte besser daran getan, "einfachere" aber aussagekräftigere Beispiele zu verwenden.

Fazit: Wer sich mit "methodischer Dokumentation von IT-Architekturen" beschäftigt, sollte dieses Buch lesen. Wer allerdings für konkrete Aufgeben direkt anwendbare Hilfe sucht, dem hilft das Buch nicht (dafür gibt es aber frei verfügbare Doku-Templates inklusive Erläuterungen als Abhilfe!)

Wegen der Praxisferne gibt's nur drei Sterne.

Alternative Literaturempfehlung: Dokumentation ist in den Büchern über Software-Architektur ein ungeliebtes Thema - meist wird es ignoriert...