Agile Architektur in "großen" Systemen

Am Dienstag, den 12. Dezember, hatten wir eine Open Space-Wissenssitzung und einer der Open Spaces, die wir hatten, handelte von der agilen Architektur in "großen Systemen". Die Frage war, wie man mit der Architektur umgeht: Sollte es am Anfang eine geben oder sollte sie sich "entwickeln"? Die Antwort, zu der wir gekommen sind, ist nicht sehr überraschend, sie lautet, dass eine Basisarchitektur benötigt wird, aber die Größe variabel ist und die Architektur nicht statisch sein, sondern sich entwickeln sollte. Die Art und Weise, wie wir zu diesem Schluss gekommen sind, ist jedoch interessant. Während der Diskussion, in der viele Meinungen geäußert wurden, haben wir eine Liste mit den guten alten, viel verwendeten Wörtern erstellt, bei denen sich alle einig waren, dass sie gebraucht werden. Auf der Grundlage dieser Wörter kamen wir zu der oben genannten Schlussfolgerung. In diesem Blog werden die Wörter aufgelistet, auf die wir unsere Schlussfolgerung stützten, und es wird erklärt, wie wir zu dieser Schlussfolgerung kamen.

Zu Beginn der Diskussion sprachen wir über die Bedeutung des Wortes Architektur und kamen zu dem Schluss, dass es viele verschiedene Ebenen der Architektur gibt: Unternehmen, Domäne, System, Anwendung und wahrscheinlich noch mehr. Wir haben versucht, in unserer Diskussion so allgemein wie möglich zu sein und alle Wörter, die uns einfielen, allen Architekturebenen zuzuordnen, an die wir dachten. Die Wörter: (nicht in der Reihenfolge ihrer Bedeutung, sondern in der Reihenfolge, in der sie in der Diskussion auftauchten)

• • Konzeptionelle Integrität Eine Architektur sollte immer konzeptionelle Integrität aufweisen. Das macht alles in Ihrer Architektur verständlich und wartbar. Aber um konzeptionelle Integrität zu haben, sollten Sie zumindest darüber gesprochen haben, was der "Standard" für welchen Teil sein wird, basierend auf der Architekturschicht. Für die Anwendungsarchitektur könnte das bedeuten, dass Sie eine Art und Weise festlegen, wie der Code zu formatieren ist, welche Schichten (Web, Service, Daten) verwendet werden und so weiter. Vor diesem Hintergrund ist eine gewisse Architektur erforderlich, bevor ein Projekt beginnt. Es könnte auch einfach heißen: Wir verwenden das, was beim ersten Projekt herauskommt, solange jedem auf dieser speziellen Architekturebene klar ist, wie die Dinge ablaufen.

• • Vision Ein Visionär wird auf allen Ebenen der Architektur benötigt. Diese Visionäre sind dazu da, die Vision zu vermitteln und dafür zu sorgen, dass die Vision nicht veraltet ist. Die Welt ist nicht altbacken, also sollte auch die Vision nicht altbacken sein. Neue Erkenntnisse sollten in die Vision aufgenommen werden. Dies ist nicht dasselbe wie eine Referenzarchitektur. Diese sind in der Regel sehr strikt in der Ausführung der Dinge. Dies ist (basierend auf der Architekturebene) eher jemand, der das große Ganze im Blick hat, weiß, wie alles zusammenpasst und sicherstellen kann, dass das große Ganze nicht zum "heiligen Blabla" wird (etwas Großes und Unverständliches). Das bedeutet, dass die Vision von Anfang an notwendig ist, aber sie kann klein sein (die Welt ist dann klein). Diese Vision muss sich weiterentwickeln und wachsen, wenn die Welt um sie herum ebenfalls wächst.

• • Spike / POC Architekturideen sollten immer getestet werden, bevor man sie einsetzt. Eine Möglichkeit, dies zu tun, ist ein Spike (in der XP-Praxis eine Art halbtägiger Proof of Concept, bei dem nur ein Problem behandelt wird). Spikes liefern Feedback, das zur Weiterentwicklung der Architektur beiträgt.

• • Halten Sie sich Optionen offen Das ist einfach, wird aber auch leicht vergessen: Treffen Sie die "schweren" Architekturentscheidungen so spät wie möglich. Wenn Sie das tun, haben Sie mehrere Optionen und sind nicht fest an eine Lösung gebunden. Das bedeutet, dass Sie "agil" sind und darauf reagieren können, wenn sich die Anforderungen, die Vision oder etwas anderes ändert, das die Architektur beeinflusst. Das bedeutet im Grunde genommen: Entscheiden Sie so spät wie möglich, aber nicht später! (ein spezieller Blogbeitrag, der auf diese Aussage eingeht, folgt später)

• • Gerade genug Besonders in der Java-Welt neigen wir dazu, die Architektur zu übertreiben und die Dinge unnötig komplex zu machen. In der Diskussion sind wir auf die Aussage "gerade genug" gekommen, um dem entgegenzuwirken. Dies entspricht auch dem Prinzip "Lean eliminiert Verschwendung". Das bedeutet, dass die Architektur immer gerade genug sein sollte, nicht nur zu Beginn des Projekts, sondern auch währenddessen.

• • Modularität Wenn die Architektur modular ist, kann jedes Modul unabhängig voneinander geändert werden, ohne dass dies schwerwiegende Auswirkungen auf andere Teile der Architektur hat. Die Module müssen nicht zu Beginn des Projekts festgelegt werden, sondern können sich im Laufe des Lebenszyklus eines Systems oder Projekts weiterentwickeln. Die "Vision" sollte sich diesen Architekturentscheidungen anpassen oder sie leiten.

• • Anpassen Eine Gemeinsamkeit, die in den oben beschriebenen Worten bereits in irgendeiner Form erwähnt wird, ist die Anpassung. Um agil zu sein, müssen Sie in der Lage sein, sich anzupassen, also muss auch die Architektur anpassungsfähig sein. Viele der hier behandelten Wörter sind dazu gedacht, genau dies zu tun, aber es muss trotzdem getan werden. Das ist der Grund, warum dieses Wort in unserer Diskussion auch definiert wird.

• Technologie Technologieentscheidungen können einen großen Einfluss auf die Architektur haben. Wenn man sich für eine bestimmte Technologie entscheidet, muss diese den Anforderungen entsprechen und die Wahl sollte beibehalten werden. Denn sobald Sie sich für eine Technologie entschieden haben und mit ihr arbeiten, wird es immer schwieriger, sie zu migrieren. Ein Wechsel der Technologie könnte bedeuten, dass Sie alles, was Sie bisher gemacht haben, neu machen müssen. Dies erfordert die bereits getroffene Aussage "Optionen offen halten". Dies gilt auch für Technologieentscheidungen und stellen Sie sicher, dass Sie, wie bereits erwähnt, "Spikes" durchführen, um sicher zu sein, dass Sie die richtige Technologie wählen. Wenn Sie Technologieentscheidungen auf der untersten Architekturebene treffen, wo sie möglich sind, können Sie sicherer sein, dass die richtige Wahl getroffen wird, denn die Leute, die mit der Technologie arbeiten, können den Spike durchführen, sie pflegen und wissen, ob etwas die Anforderungen erfüllen kann oder nicht.

Ausgehend von den Anforderungen der "konzeptionellen Integrität" und der "Vision" benötigen wir zu Beginn des Projekts auf allen Architekturebenen eine "gerade noch ausreichende" Architektur, die sich im Laufe des Projekts und des Lebenszyklus der Software weiterentwickeln sollte.

Ich hoffe, Sie sind inspiriert oder freuen sich, dass wir bestätigt haben, was Sie bereits dachten... ;-) Kommentare sind willkommen.