Eines der Probleme beim Entwerfen von Software ist es, eine gute Architektur für das gegebene Problem zu finden, damit die Lösung, also das lauffähige System, „gut“ wird.
Doch was heißt „gut“? Wann ist ein Entwurf „gut“?
Wenn ich mit Softwarearchitekten spreche, kommen häufig ähnliche Antworten wie diese hier. Das ist eine Liste der Antworten, die ich höre, nicht eine Liste von Antworten, hinter denen ich selbst auch stehe:
- Wenn der Erfolg im Auge des Betrachters liegt, sollte eine „gute“ Architektur uns ermöglichen, solchen Erfolg billiger, schneller und leichter zu erreichen.
- Eine gute Architektur ist in der Lage, mit sich ändernden Anforderungen und Prozessen des Kunden umzugehen. Bei einer guten Architektur muss bei äußeren Änderungen nicht auch innen „alles“ geändert werden, sondern nur die „entsprechende“ Stelle im System.
- Es gibt keine „absolut“ gute Architektur, sondern nur eine, die dem Kontext angemessen ist oder nicht.
- Man kann Architekturen immer nur im Nachhinein beurteilen, wenn sie umgesetzt sind, nicht im Vorhinein.
- Man kann die vorgeschlagene Architektur der Lösung (also Bausteine, Schnittstellen, Abläufe, usw.) vergleichen mit der Architektur des Problems (also des geschäftlichen Kontextes, den man betrachtet). Bei dem Vergleich kann man prüfen, wie gut die wichtigen Aspekte des Kontextes durch die Lösung abgedeckt werden. Damit bekommt wenigstens eine Aussage, ob eine Architektur zu dem Zeitpunkt einmal gut war. Jedoch sagt das noch nichts darüber, ob die Architektur auch gut bleiben wird.
- Eine gute Architektur berücksichtigt auch alle Fehlerfälle.
- Ein Entwurf ist gut, wenn er die aktuellen Bedürfnisse abdeckt und trotzdem flexibel für zukünftige Verbesserungen ist. Ein großartiger Entwurf ist darüber hinaus einer, der das so einfach erklärt, damit dies auch für die möglich ist, die übrig bleiben, um das System zu warten.
- Man kann erst wissen, was „gut“ ist, wenn man vordefinierte Metriken dafür hat. Die Frage „Was ist gut?“ sollte man besser formulieren als Frage „Was sind angemessene, aussagekräftige Metriken?“. Und wenn wir dabei sind, müssen wir auch klären: Was sind notwendige Attribute, also was sollen diese Metriken eigentlich messen?
- Eine gute Architektur hat ein visionäres Element, bleibt dabei aber immer konsistent und deployment-fähig.
- Ein Entwurf ist dann gut, wenn das Team sagt „Ja, jetzt wissen wir, was wir tun müssen“ und wenn die Stakeholder sagen „Ja, dieses System würde uns helfen, unsere geschäftlichen Ziele zu erreichen!“.
- Ein Entwurf ist gut, wenn er die Qualitätsmerkmale („-ilities“ oder „-barkeiten“) einhält und der Entwicklungsorganisation eine kurze time to market ermöglicht.
Es gibt noch viele, viele solche Antworten. Auch ich hätte die eine oder andere dazu.
Mich würde aber viel mehr interessieren: Was sind Ihre Antworten? Und Ihre noch offenen Punkte dazu?
Kommentieren Sie doch einfach diesen Blog-Artikel (weiter unten sind Felder dafür). Ich bin gespannt.