Was ist Software Architektur

Gerade habe ich den Artikel Is This Architecture? von Gregor Hohpe gelesen. Er stellt die folgende
Definition von Software Architecture vor:

Design decisions about any system that keep implementors and maintainers from exercising needless creativity

Needless Creativity klingt erstmal komisch, stimmt aber schon irgendwie. Designentscheidungen sorgen dafür,
dass man nicht immer und überall darüber nachdenken muss, wie man Software entwickelt. Sie dienen auch dazu,
dass man nicht von immer anderen Patterns überrascht wird und gleiche Dinge auch gleich umgesetzt werden.
Diese Begrenzung der Kreativität erlaubt es, sie dort einzusetzen, wo sie gebraucht wird: bei der Beurteilung
von neuen Situationen oder der Lösung von komplexen Problemen.

Deshalb hängt gute Architektur für mich nicht von guter Dokumentation ab. Gute Architektur zeichnet sich
dadurch aus, dass sie verständlich ist und dass sie in der täglichen Arbeit nachvollziehbar und umsetzbar ist.
Natürlich muss Dokumentation sein, schliesslich will auch die neue Mitarbeiterin verstehen können, wieso
ein System so aufgebaut ist, wie sie es vorfindet. Das kann man auch in Gesprächen klären, aber wenn man ein
anschauliches Diagramm aus der Dokumentation zaubern oder auf einer Seite im Wiki die Grundstruktur und die
wichtigsten Enscheidungen nachlesen kann, dann hilft das ganz entscheidend bei schneller Einarbeitung.

Hohpe macht eine wichtige Einschränkung:

Yet, to build such a house I would not want to pay an architect. To me this house is “cookie-cutter”,
meaning I don’t see any non-obvious decisions that an architect would have made. Consequently, I would
not consider this architecture.

Am Ende des Artikels gibt es dann noch ein paar Beispiele, wie solche “cookie-cutter” Entscheidungen aussehen:

Systems architecture does not have to be something terribly complicated. It must include, however,
significant decisions that are documented and are based on a clear rationale. The word “significant”
may be open to some interpretation and depend on the level of sophistication of the organization, but
“we separate front-end from back-end code”, “we use monitoring”, or “migrating systems is risky” surely
have the ring of “my door reaches the ground so people can walk in” or “I put windows in the walls so light
can enter”. Instead, when discussing architectures let’s talk about what is not obvious or something that
involved heavy trade-offs.

Was bei mir klingelt und eine sofortige Assoziation zu früheren und aktuellen Entscheidungen herstellt, ist
der Nebensatz “something that involved heavy trade-offs”. Das sind genau die Dinge, die dokumentiert werden
sollten: Es wurde eine Entscheidung für oder gegen etwas getroffen, und daraus ergeben sich weitreichende
Folgen.

Ich werde mich jetzt auch um eine Analogie aus dem Hausbau bemühen (obwohl ich überhaupt keine Ahnung vom
Hausbau habe…), z.B eine Entscheidung wie “Wir verwenden nur Haustüren ohne Schlösser,
weil …
” – diese Entscheidung hat weitreichende Folgen für die Sicherheit und ist quasi entgegengesetzt zu
allen anderen Häusern. Was hat wohl zu dieser Entscheidung geführt?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.