Agilität und Performance – ein Livebericht von der JAX 2010

Impressionen, Erstaunliches und Erfahrungen direkt aus Mainz von der JAX 2010, der grössten Konferenz für Enterprise-Technologien und -Strategien.

Heute hat die 10. Ausgabe der JAX begonnen. Die drei Buchstaben JAX stehen eigentlich für Java, Apache und XML – Technologien welche vor zehn Jahren die Softwareentwicklung revolutionierten. Heute müsste die Konferenz wohl JAXEASHGR, Java, Apache, XML, Eclipse, Agile, Spring, Hibernate, Groovy/Grails, Ruby/Rails heissen, aber ich finde JAX doch viel cooler. Also, let’s get jaxed!

Am ersten (Pre-)Konferenztag, findet neben diversen Power Workshops auch der Agile Day statt. Von diesem Tag erwarte ich einerseits Erfahrungsberichte, andererseits aber auch Meinungen zu Chancen, Risiken und Grenzen von agiler Softwareentwicklung.

Architektur in Zeiten der Agilität

Ich bin selber Software-Architekt und wenn ich ehrlich bin, läuft man immer Gefahr, dass man Architektur zum Selbstzweck betreibt. Irgendwo gibt es doch ein Gefühl der Sicherheit, wenn etwas komplex aufgebaut ist. Ein Statement von Uwe Friedrichsen, dem ersten Referenten am heutigen Agile Day regt zur Selbstkritik an: “Architektur hilft den Menschen, nicht den Maschinen.”

Agilität soll also nie auf Kosten einer sauberen Architektur umgesetzt werden. Ich bin froh, dass ein Quick Fix auch in einer agilen Welt nur eine Notlösung ist. Aber wie geht’s denn nun richtig?

Ganz interessant finde ich den Ansatz, Architektur als integralen Bestandteil des Entwicklungsprozesses zu sehen. “Ich muss erst das hundertseitige Architekturdokument fertigstellen bevor ihr mit der Entwicklung starten dürft” ist ein Satz, der dafür sorgt, dass garantiert keine vernünftige Architektur ins System einfliesst. Welcher Entwickler liest schon gern 100 Seiten die ihm vorschreiben wie er etwas machen soll und was er sicher nicht tun darf? Architekturtasks sollen während der Iteration neben den Entwicklungstasks geführt werden. Bei Scrum nehmen wir also in jedem Sprint auch Architekturaufgaben mit aufs Scrum-Board. Der Software-Architekt wird so zum vollwertigen Teammitglied.

Was ist denn nun das Besondere an einem guten, agilen Architekten? Er ist die Kommunikationsschnittstelle zur Anforderungsdomäne. In grossen Projekten, kann kein Entwickler alles kennen. Hier muss der Architekt ein System so strukturieren, dass es die Anforderungen erfüllt und gleichzeitig für alle verständlich bleibt. Wichtig ist also, dass die Konzepte in einer Form dokumentiert werden, dass sie für die Entwicklung einen Mehrwert bringen. Der Architekt soll auch ein guter Zuhörer sein und sich interessieren wenn bei der Realisierung technische Hürden entstehen. Diese Erkenntnisse lässt er wieder in seine Arbeit einfliessen um die Architektur weiter zu verfeinern.

Aha, der Architekt ist also ein Dienstleister für sein Team. Er bereitet Anforderungen so auf, dass das Team sie dem Stand des Projektes entsprechend effizient umsetzen kann.

Zusammenfassend habe ich das Zitat von Ludwig Mies van der Rohe behalten: “Weniger ist mehr!”. Als Architekt in der Bauhaus-Epoche hat er einfache Gebäude ohne Schnörkel, dafür aber mit klaren Linien gebaut. Seine Werke gelten als funktional und trotzdem auch als modern und ästhetisch. So sollte es doch auch in der agilen Softwareentwicklung sein.

The Secret Art of Agile Performance Management

Weiter geht es mit einem Vortrag zum nächsten Lieblingsthema des Architekten: der Performance.

Klassischerweise werden Lasttests für Systeme am Schluss bei der Abnahme durchgeführt. Sie sind oft aufwändig und dauern Ihre Zeit. Erkenntnisse fliessen so erst bei der Entwicklung eines nächsten Releases wieder in die Entwicklung ein. Im schlechtesten Fall hat sich die Ausgangslage dann soweit verändert, dass die Tests nicht mehr aussagekräftig sind.

Interessant finde ich hier den Ansatz aus der testgetriebenen Softwareentwicklung, Perfomance-Tests während der Entwicklung aufzubauen und diese möglichst automatisiert immer wieder laufen zu lassen. So erhalten die Entwickler schnelle Aussagen darüber, wie gut ihr Code ist. Zusätzlich erhalten sie auch eine Historisierung des Performance-Verhaltens. Klar ist es eine sinnvolle Strategie, dort anzusetzen, wo die grössten Geschwindigskeitseinbussen entstehen. Noch besser ist es aber, zu erkennen, wo die Performance schlechter wurde, da in diesem Fall nachweislich schon mal eine bessere Lösung vorlag.

Feuerwehrübungen sind nicht agil, sondern Notlösungen, die darauf abzielen die Performance-Anforderungen knapp zu erfüllen. Um Agile Software performant zu halten, müssen die entsprechenden Anforderungen ständig aufgenommen und aktualisiert werden (z.B. Minimalvorgaben für Durchsatz, Antwortzeiten und Speicherverbrauch). Die Einhaltung dieser Anforderungen, sollte analog den funktionalen Anforderungen ständig überwacht werden. Resultate der Überwachung führen zu Massnahmen, welche die Performance des Systems verbessern. So wird das Performance Management ebenfalls zum integralen Bestandteil des Entwicklungsprozesses.

Ich würde sagen, der Auftakt der 2010er Ausgabe der JAX ist geglückt und ich freue mich riesig auf die nächsten spannenden Tage.

Kommentare sind geschlossen.