Flexible Architekturen: Mit Handwerkskunst zukunftssichere Systeme bauen

Architekturvision

Kein agiles Projekt beginnt mit der ersten Sprint-/Iterationsplanung. Es hat vorher bereits etwas stattgefunden, das sich Visionierung (Envisioning) oder auch Exploration nennt [4]. In der Visionierung werden die Ziele des Projekts, die Kundengruppen mit ihren Bedürfnissen und die groben Eigenschaften des Produkts festgelegt und z. B. in einer so genannten Produktvision beschrieben. Leider wird die Visionierung häufig zu unsystematisch oder falsch verstanden durchgeführt. Da verwundert es wenig, dass in der Visionierung Architektur und Technologien kaum bis gar nicht beachtet werden. Neben einer fachlichen Produktvision sollte die Visionierung aber auch eine Architekturvision hervorbringen. In dieser sollten genau die technischen und architekturellen Eigenschaften des Produkts beschrieben sein, die sich im weiteren Entwicklungsgeschehen gar nicht mehr oder nur sehr schwer ändern lassen. Damit kommuniziert die Architekturvision explizit und klar an den Produktverantwortlichen, welche Freiheiten er im Projektverlauf hat. Legt die Architekturvision beispielsweise fest, dass eine In-House-Webanwendung entwickelt wird, ist damit klar, dass die Umstellung auf eine iPhone-App sehr aufwändig wird. Faktisch sollte der Produktverantwortliche davon ausgehen, dass solche Änderungen die Neuentwicklung des Produkts bedeuten.

Natürlich sollten wir den Handlungsspielraum des Produktverantwortlichen nicht weiter einschränken als notwendig. In der Architekturvision sollten also nur die Aspekte festgelegt werden, die sich tatsächlich nur sehr schwer ändern lassen. Und die Entwickler sollten kontinuierlich an ihren Fähigkeiten arbeiten, flexible Produkte zu entwickeln. So müssen sie von Projekt zu Projekt immer weniger in der Architekturvision fixieren.

Folglich hängt der konkrete Umfang der Architekturvision von den Fähigkeiten des Entwicklungsteams ab. Ein agil-unerfahrenes Team muss in der Regel deutlich mehr Aspekte in der Architekturvision fixieren als ein sehr erfahrenes Team. Außerdem hängt der Umfang der Architekturvision von den verwendeten Technologien ab. In einem Cobol-Projekt muss man deutlich mehr fixieren als in einem Java-Projekt.

Festlegungen aus einer Beispielarchitekturvision:

  1. Es handelt sich um eine Internetanwendung.
  2. Als Programmiersprache wird Java verwendet und JavaScript für das Frontend.
  3. Im Backend wird Spring als Dependency-Injection-Container verwendet.
  4. Für die Persistenz wird ein relationales Datenbanksystem verwendet und Hibernate für die Anbindung an das Datenbanksystem.
  5. Als View-Framework wird Spring Web MVC mit JSPs verwendet.
  6. Quasar ist unser Architekturstil.
Nicht ausgearbeitet:

  1. Konkretes Datenbanksystem (wir beginnen mit mySQL, können aber mit wenig Aufwand wechseln).
  2. Anwendung soll später internationalisiert werden.
  3. Man erhofft sich sehr große Nutzerzahlen. Die Anwendung muss später geclustert betrieben werden können.
  4. Konkrete Architektur und die Komponenten, aus denen das System besteht.
  5. Programmierrichtlinien.

Dass diese Punkte in der Architekturvision nicht ausgearbeitet werden, bedeutet nicht, dass sie naiv ignoriert werden. Im Gegenteil hat das Team nach gewissenhafter Analyse explizit entschieden, diese Aspekte in der Architekturvision nicht auszuarbeiten. Das Team weiß, wie es die genannten Aspekte auch später noch ins System integrieren bzw. ändern kann.

Besonders interessant ist Punkt 3. Tatsächlich kann es sehr aufwändig sein, ein existierendes System so umzubauen, dass es geclustert betrieben werden kann. Auf der anderen Seite sind die notwendigen Bedingungen für den geclusterten Betrieb kein Hexenwerk, sondern relativ einfache Richtlinien, die eigentlich immer gelten sollten (z. B. Vermeidung von statischen Variablen). Das Team ist sich sicher, dass es diese Richtlinien beherrscht und daher nicht bereits jetzt ständig über alle Eventualitäten des geclusterten Betriebs nachdenken muss. Außerdem ist gar nicht sicher, dass das System jemals geclustert betrieben werden muss. Die tatsächlich erzielbaren Benutzerzahlen werden erst klar werden, wenn das System tatsächlich eingesetzt wird. Erst dann weiß man sicher, wie groß der Besucheransturm ist, und erst dann weiß man, welche Cluster-Strategie die geeignete ist: Braucht man mehrere Application-Server auf einer Datenbank, oder muss man die Datenbank auch clustern? Kann man die Abfrage live auf der Datenbank ausführen, oder braucht man eine In-Memory-Suchmaschine? Ist am Ende das relationale Datenbankschema insgesamt der Last nicht mehr gewachsen und muss eine NoSQL-Datenbank her? All das sind Fragen, über die das Team bisher nur spekulieren kann, ohne wirklich weiter zu kommen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.