Worum geht’s?

Ich wollte nur diejenigen unter Euch, die es noch nicht wissen, kurz darauf hinweisen, dass Dana Bredemeyer seinen bekannten Software Architektur Workshop vom 13.9.2010 – 16.9.2010 bei codecentric halten wird. Dana hat seit fast 10 Jahren keinen öffentlichen Workshop in Deutschland gehalten und von allem, was ich bislang darüber gehört habe, wird das ein wirklich guter Kurs werden. Also, falls irgend jemand von Euch Interesse an dem Workshop haben sollte und dafür nicht extra in die USA reisen möchte (oder darf): Mehr Infos gibt es unter http://www.meettheexperts.de/software-architecture.

Außerdem wollte ich das “Meet the Experts” am 17.9.2010 erwähnen. Das Motto lautet dieses Mal “Herausforderungen in der Architektur heute”. Fünf bekannte Sprecher, darunter Dana Bredemeyer, Dr. Gernot Starke und Prof. Dr. Heinz Züllighoven werden ihre An- und Einsichten zu dem Thema mit Euch teilen. Und wie immer wird es jede Menge Zeit für Diskussionen, Netzwerken, Open Space für Eure Fragen, super Catering, usw. geben. Falls das für jemanden von Euch interessant klingen sollte: Mehr Infos dazu gibt es unter http://www.meettheexperts.de/meettheexperts-architektur.

Okay, das war’s schon. Mehr wollte ich gar nicht erzählen. Ich denke, dass beide Veranstaltungen echt spannend werden und werde auf jeden Fall dabei sein. Und falls jemand von Euch da sein sollte, freue ich mich schon darauf, Dich (oder Sie) kennenzulernen … und falls nicht, klappt es vielleicht ein anderes Mal mit dem Kennenlernen …

Ab heute gibt es für alle die Möglichkeit diesen Diskussionen teilweise beizuwohnen. Ab heute gibt es den codecentric competence center podcast.

Die Leiter der competence center, und ggf. auch geladene Gäste, setzen sich regelmäßig zusammen und diskutieren aktuelle Themen aus den jeweiligen Bereichen. Initial haben wir uns einen 2-wöchigen Rhythmus vorgenommen. Der erste Podcast behandelt die Themen “Story Points” und “Benennung von Java Klassen”. Langweilig? Ganz im Gegenteil! Wir hatten sehr viel Spaß bei der Diskussion der Themen.

Ich würde mich über Feedback über Inhalt, Gestaltung, Qualität, Länge, etc. im Kommentarbereich des Podcasts freuen. Wer möchte, kann den Podcast auch auf  iTunes abonnieren und bewerten.

Vor ein paar Tagen habe ich das folgende Zitat gelesen:

“Perfektion entsteht offensichtlich nicht dann, wenn man nichts mehr hinzuzufügen hat, sondern wenn man nichts mehr wegnehmen kann.” (A. Saint-Exupéry)

Ich habe ein wenig darüber nachgedacht und bin für mich zu dem Schluss gekommen, dass eine Menge Wahrheit und Weisheit in diesem kurzen Satz steckt. Aber dann fing ich an, über die IT nachzudenken …

Man sollte denken, dass wir in Zeiten, in denen wir mit mehr und mehr Komplexität konfrontiert werden, nach dieser Art von Perfektion streben sollten, indem wir alles entfernen, das wir nicht unbedingt zur Erreichung unseres Ziels benötigen. Zumindest denke ich das. Schaue ich mich aber um, dann sehe ich die meiste Zeit das genaue Gegenteil davon. Wir stapeln mehr und mehr Komplexität um uns herum auf, egal ob wir sie benötigen oder nicht. Um einfach einmal ein paar Beispiele zu nennen:

• Um Dinge lückenloser gestalten zu können, erfinden wir jeden Tag ausgefeilte Templates für alle und jedes, beginnend mit superpräzisen Anforderungs-Templates und endend mit Support Prozessen, deren Beschreibung schon hunderte oder gar tausende Seiten dick ist … Templates und Regeln, die zu verstehen schon Wochen in Anspruch nimmt und die sicherstellen, dass der eigentliche Inhalt wesentlich schwerer zu verstehen ist als er es vorher war … zumindest für die “normalen” Menschen.
• Um Unklarheiten zu vermeiden, erstellen wir Modelle, die eine ganze Wand benötigen um sie darzustellen. Kein Mensch versteht sie mehr in ihrer Gesamtheit, aber wir erstellen sie trotzdem. Und sollte das noch nicht ausreichen, erstellen wir zusätzlich Metamodelle und Meta-Metamodelle und stellen so sicher, dass wir die letzten paar Leute abhängen, die noch eine ungefähre Idee von dem Modell hatten.
• Wir versuchen, Dinge einfacher erledigt zu bekommen, indem wir Produkte einsetzen, die so viele Features haben, dass wir höchstwahrscheinlich niemals mehr als 3% davon nutzen werden … und wir integrieren solche Produkte auch noch in unsere Anwendungslandschaften.
• Um ein paar Tastendrücke zu sparen, packen wir so viel Zeug in unsere IDEs, dass niemand mehr weiß, was da alles im Hintergrund passiert und wir von der ganzen geschehenden “Magie” regelmäßig ausgetrickst werden.
• Und ebenfalls in unserer niemals endenden Suche nach einfacherer Erledigung von Aufgaben erzeugen und nutzen wir so viele Frameworks, wie wir irgendwie in eine Anwendung gepackt bekommen. Als Ergebnis sind wir ununterbrochen damit beschäftigt, die ganze Technologie zu verstehen und die daraus entstehenden Integrationsprobleme zu lösen und haben überhaupt keine Zeit mehr, uns mit der eigentlichen Aufgabenstellung der Anwendung auseinanderzusetzen – Ihr wisst, dieses “Fachzeugs”.
• Mit all diesen Tools erzeugen wir dann Anwendung einer solchen Komplexität, dass niemand mehr wirklich versteht, was die Anwendung genau tut, weder die Anwender noch die armen Entwickler, die versuchen, irgendein ein neues Feature innerhalb dieses Code-Alptraums zu realisieren, ohne die ganze Anwendung kaputt zu machen.
• Und nur, weil wir es können und irgendjemand aus dem Fachbereich denkt, das könnte irgendwann einmal nützlich sein, verbinden wir alles und jedes in unserer Anwendungslandschaft miteinander, egal ob es irgendeinen Geschäftsnutzen hat oder nicht und erzeugen so ein Netz aus Abhängigkeiten, das keiner mehr so recht versteht.

Ich könnte noch stundenlang weitermachen, aber ich denke, Ihr wisst, was ich meine und Ihr könntet bestimmt wie aus der Pistole geschossen weitere Beispiele ergänzen. Wir schaffen es sehr oft, etwas eigentlich Einfaches in etwas Kompliziertes zu verwandeln, indem wir mehr und mehr Dinge hinzufügen, egal ob es dem Ziel dient oder nicht, bis es irgendwann komplexes Verhalten entwickelt, d.h. bis es unverständlich und unvorhersehbar in seinem Verhalten wird.

Bei unseren Versuchen, mit den Grenzen unserer Gehirne umzugehen oder manchmal auch nur aufgrund unserer Faulheit oder Angst vor Entscheidungen wählen wir sehr oft die schlechteste Alternative: Wir fügen Komplexität hinzu anstatt sie zu entfernen.

Wenn ich mir diesen Trend in der IT ansehe, dass alles immer komplexer und komplexer wird, denke ich mir, dass es an der Zeit ist, das Ruder herumzureißen. Anstatt über die wachsende Komplexität um uns herum zu jammern sollten wir versuchen, sie zu vermeiden, wo immer wir können. Um auch hier ein paar Beispiele zu nennen:

• Niemand zwingt uns, Dinge so formal wie Maschinen zu machen. Wir sind Menschen und wir sollten wie Menschen interagieren. Ja, wir machen Fehler (das ist Teil unserer Natur), aber wir machen insgesamt nicht weniger Fehler, wenn wir versuchen, uns wie Maschinen zu verhalten und so zu kommunizieren, d.h. immer formaler und formaler.
• Niemand braucht Modelle, die keiner versteht. Zuallererst dient ein Modell der Kommunikation, der Weitergabe von Wissen; und wenn niemand das Modell versteht, gibt es nichts weiterzugeben. Im Zweifelsfall bevorzuge ich ein einfaches Modell, das ich jedem problemlos erklären kann, anstatt ein komplexes Modell zu benutzen, das ich niemandem nahebringen kann, egal wie akkurat es ist.
• Niemand zwingt uns, jedes verfügbare Plugin in unserer IDE und jedes verfügbare Framework in unserer Anwendung zu verwenden. Vor vielen Jahren, als Design Patterns gerade “in” waren, hatte ich einmal einen Kollegen, der uns eines Tages ganz stolz erzählte, dass er es geschafft hätte, alle Design Pattern des “Gang of Four”-Buches in seinen Code zu integrieren. Davon alarmiert hat sich der Rest des Teams seinen Code angeschaut. Das Ende vom Lied war, dass wir uns dazu entschlossen hatten, den gesamten Code wegzuwerfen, den der Kollege jemals für das Projekt geschrieben hatte und alles von Grund auf neu zu schreiben, weil der Code extrem fragil, voll von Fehlern und komplett unwartbar war. Das Gleiche gilt in der Regel für IDEs und Source Code, in denen zu viele Plugins, Frameworks oder was auch immer stecken.
• Und müssen wir wirklich unbesehen jede einzelne Anforderung umsetzen, die irgendein Fachbereichsmitarbeiter formuliert? Ja, es ist das ganz spezielle Recht eines Fachbereichs, beliebige Dinge anzufordern, ohne sich Gedanken über die möglichen technischen Konsequenzen zu machen. Es ist nicht ihre Aufgabe, sich darüber Gedanken zu machen und meisten verfügen sie dafür auch nicht über das benötigte Wissen. Aber es ist unsere Aufgabe, mit ihnen darüber zu reden, ihnen die Konsequenzen aufzuzeigen (bitte in einer nicht-technischen Sprache), ihnen Alternativen aufzuzeigen und ihnen zu helfen, die bestmögliche Entscheidung zu treffen, indem man ihnen hilft, das ganze Bild zu sehen. Meistens werden sie dann die beste Alternative wählen, und sehr oft ist das eine Alternative, die wesentlich weniger komplex ist als die initiale Anforderung.

Nun denn, dies ist keine “Schwarz oder Weiß”-Geschichte. Es gibt nicht “die” Lösung für unser Problem und Vereinfachung bis zur Unbrauchbarkeit hilft auch nicht weiter. Aber ich denke, dass es an der Zeit ist, Komplexität zu vermeiden, wo immer wir sie nicht unbedingt benötigen, dass wir versuchen, uns zurück auf den Komplexitätslevel zu bewegen, den unsere Gehirne noch verarbeiten können. Oder, um dies mit einem weiteren Zitat zu beenden, das ich sehr mag:

“Weniger ist mehr!” (Mies v.d. Rohe)

Wie ich bereits eingangs geschrieben habe: Nur ein Gedanke …

Dr. Ingo Schrewe von der incowia GmbH und ich haben einen Artikel darüber geschrieben, wie einem Agilität helfen kann, die Risiken einer EAM-Einführung zu reduzieren und die Ergebnisse zu optimieren. Der Artikel ist im Rahmen eines EAM-Onlinespecials von SIGS-DATACOM erschienen und kann unter der folgenden URL heruntergeladen werden: http://www.sigs.de/publications/os/2010/EAM/friedrichsen_schrewe_OS_EAM_10.pdf

Ingo Schrewe und ich haben vor, den Artikel um weitere Artikel zu erweitern, in denen wir praktische Empfehlungen, Tipps und Beispiele für ein agiles EAM geben … wann auch immer wir die Zeit dafür finden, die Artikel zu schreiben …

Ich bin der Meinung, dass es sehr schwer ist herauszufinden, wer recht oder unrecht hat … tatsächlich glaube ich, dass das weitestgehend unmöglich ist. Sogar in unserer kleinen Firma finden wir keinen gemeinsamen Konsens darüber, was genau Architektur und was Design ist. Und wenn es schon nicht möglich ist, einen Konsens unter so wenigen Leuten zu erzeugen (selbst wenn einige davon recht starke Persönlichkeiten sind … ), wie soll es dann möglich sein, einen Konsens in der gesamten IT Community zu erzeugen? Das ist höchstwahrscheinlich unmöglich.

Deshalb versuche ich erst gar nicht, eine präzise Antwort auf die Frage zu finden. Stattdessen werde ich versuchen, das Thema von einem anderen Standpunkt aus zu betrachten. Zunächst: Warum ist es so schwer, die Frage zu beantworten? Ich denke, ein großer Teil des Problems liegt darin, dass es keine zufriedenstellende Definition für die beiden Ausdrücke gibt, weder für Architektur noch für Design. Wann immer sie mit einer anderen Person über Architektur oder Design reden, können Sie sich deshalb schon nahezu sicher sein, dass die andere Person über etwas anderes spricht als Sie.

Es gibt *jede Menge* Definitionen, aber die meisten davon sind meines Erachtens entweder so spezifisch, dass sie das Thema nicht wirklich erfassen oder sie sind so vage, dass sie einem überhaupt nicht weiter helfen. Nur ein Beispiel: Robert Martin (der nebenbei gesagt eine Menge sehr schlauer Dinge gesagt und geschrieben hat) hat einmal gesagt “Bei Architektur geht es um die wichtigen Dinge; was auch immer das ist.”. Nun, das sagt alles und nichts. Bedeutet das, dass es bei Design um die unwichtigen Dinge geht? Wahrscheinlich nicht. Und, wenn Kaffee für die Entwickler ein sehr wichtiges Thema ist (was es fast immer ist), bedeutet das, dass es bei Architektur um Kaffee geht? Wahrscheinlich nicht. Wie Sie sehen können, bringt uns diese Definition nicht weiter.

Ich verzichte darauf, andere Definitionen näher zu betrachten, weil ich denke, dass das nirgendwohin führt. Es wird nicht möglich sein, eine Definition für Architektur und Design zu finden, der alle zustimmen *und* die uns hilft, den Unterschied zwischen Architektur und Design herauszufinden. Insbesondere glaube ich, dass es nicht möglich sein wird, eine klare Trennlinie zwischen Architektur und Design zu finden, wo das eine endet und das andere beginnt. Jeder zieht die Linie an einer anderen Stelle und viele Leute haben wahrscheinlich eher eine Art unscharfer Wolke als eine klare Linie in ihrem Kopf. “Irgendwo innerhalb dieser Wolke endet Architektur und beginnt Design” werden sie sagen.

So weit, so gut. Aber es muss doch etwas geben, das uns weiterhilft. Oder zumindest sollte es etwas geben …

Vielleicht hilft es, die Frage für einen Moment beiseite zu schieben. Im Laufe der Zeit habe ich herausgefunden, dass es zwei grundsätzliche Aufgaben gibt, aus denen diese ganze “Architektur-und-Design-Sache” besteht (ohne zu versuchen, eine Trennlinie zu finden). Insgesamt geht es bei der Sache darum, alle existierenden Anforderungen in eine Lösung zu transformieren. (Und sollte jemand fragen, wo dabei die Codierung geblieben ist, möchte ich es demjenigen überlassen, die Trennlinie zwischen Design und Codierung zu finden; ich denke, dass ist eine ähnliche Fragestellung … ).

Im ersten Teil dieser Transformation geht es darum, die ganzen Anforderungen zu verstehen (nicht nur die Anforderungen der Fachbereiche und Anwender, sondern auch die Anforderungen des Managements, der Projektleitung, des Entwicklungs-Teams, des Betriebs, der Systemplanung, der Sicherheitsabteilung, der Tester, und so weiter), die Anforderungen wirklich zu verstehen, sie auszubalancieren (es gibt immer widersprüchliche und inkonsistente Anforderungen über die verschiedenen Domänen und Stakeholder hinweg, mit denen man umgehen muss) und eine geeignete Lösungsidee für all diese ausbalancierten Anforderungen zu finden. Ich pflege diesen Teil der Arbeit “Alignment” oder auch “Einklang” zu nennen.

Der zweite Teil der Transformation in eine funktionierende Lösung besteht daraus, die Lösungsidee in eine geeignete Struktur zu bringen, die Wartbarkeit und Änderbarkeit unterstützt und diese Struktur weiter und weiter bis herunter auf Code-Ebene zu verfeinern, ohne die zuvor beschriebenen Eigenschaften zu verlieren. Diesen Teil der Arbeit pflege ich “Strukturierung” oder einfach nur “Struktur” zu nennen.

Nun, ist es wichtig, diese beiden Aufgaben zu unterscheiden? Ich denke, ja! Der Grund dafür ist, dass ich bemerkt habe, dass diese beiden Aufgaben sehr unterschiedliche Skills erfordern. Während Einklang viel mit Kommunikations- und Konflikt-Management-Skills zu tun hat, erfordert Struktur eher formale Stärken. Einklang erfordert auch ein recht breites Wissen über all die verschiedenen Anforderungsdomänen, während Struktur ein eher tiefes Wissen in der Lösungsdomäne erfordert. Als eine Konsequenz daraus findet man nur relativ wenige Personen, die beide Aufgaben mit der gleichen Stärke wahrnehmen können (oder wollen), und wenn man eine der beiden Aufgaben vernachlässigt, erhält man höchstwahrscheinlich kein befriedigendes Ergebnis.

Okay, kommen wir zurück zu initialen Fragestellung. Helfen uns Einklang und Struktur, eine Trennlinie zu finden. Nun, ich denke, in gewisser Weise …

Aus meiner Sicht ist Einklang auf jeden Fall Teil einer guten Architektur und Struktur ist auf jeden Fall Teil eines guten Designs. Man kann kein guter Architekt sein, ohne viel an Einklang zu arbeiten und man kann kein guter Designer sein, ohne viel an Struktur zu arbeiten. Wie viel Struktur zusätzlich in Architektur benötigt wird und wie viel Einklang in Design – ich denke, das ist gewissermaßen eine Geschmacksfrage und darauf wird es keine endgültige Antwort geben.

Zusammenfassend kann ich auch nicht “die” Antwort auf die initiale Fragestellung bieten. Aber ich weiß, wenn jemand über Architektur redet, ohne über Einklang zu reden, macht er etwas falsch und wenn jemand über Design redet, ohne über Struktur zu reden, macht er auch etwas falsch. Und das ist das Wichtigste aus meiner Sicht …

PS: Ein dickes “Sorry” an Robert Martin, weil ich ausgerechnet auf seiner Architektur-Definition herumgehackt habe. Wie ich bereits zuvor geschrieben habe, hat er eine Menge sehr schlauer Dinge gesagt und geschrieben, auch wenn ich nicht allen davon zustimme. Wenn Sie also die Gelegenheit haben sollten, etwas von ihm zu lesen oder einen Vortrag von ihm zu hören, dann tun Sie es! So, das sollte genug der Wiedergutmachung sein …

Angelehnt an die IT-Landkarte und den damit verbundenen Reisezielen von Gernot Starke (vergleiche Dr. Gernot Starke- Publikationen) kann ich festhalten, dass meine Tagesausflüge nach Architektionien oder Analytistan sehr viele positive Erfahrungen und Eindrücke hinterlassen haben.

Im Unterschied zu anderen Konferenzen, wie z. B. der Jax, fokussiert die OOP für mich viel stärker die “Business Aspekte” im Zusammenhang mit IT. Die Veranstaltungen bieten Erfahrungen und Modelle, um die gefühlte, als auch erlebte meine „Grenze“ zwischen der Business-Welt und der IT-Welt besser zu verstehen, sowie Ideen, Tendenzen, Lösungen und Entwicklungen um die Beziehungen dieser beiden „Welten“ zu verbessern.

In meiner bisherigen Tätigkeit in der IT, erst als Entwickler und mittlerweile als Architekt, habe ich die technischen Aspekte beim Design und der Entwicklung fokussiert. Diese sind nicht nur interessant und spannend, sondern haben einen großen Coolness-Faktor (vergleiche die Keynote „Nachbars Garten – Wo Architekten lernen„ von Gernot Starke). Nun arbeite ich „auf einmal“ viel enger und intensiver mit fachlichen Domänenexperten, Projektleitern oder Businessanalysten, mit jeweils individuellen Anforderungen, unterschiedlichen Interessen und eigentümlichen Sprachen. Ich muss feststellen, dass „coole Technik“ nicht ausreicht um als Architekt im Grenzgebiet zu „überleben“. Aus diesem Grund habe ich eine Veranstaltung gesucht die mir neue Ideen, sowie Impulse für meine Arbeit bietet.

Nachdem ich das Programm zum ersten Mal überflogen habe, war meine Neugier sofort geweckt. Einige bekannte Namen wie z. B. Philippe Kruchten oder Eric Evans kündigten interessante Vorträge und Tutorials an. Letzt endlich sind mir unter anderem die Veranstaltungen dieser beiden Sprecher nachhaltig in Erinnerung geblieben.

Veranstaltungen dieser Art und der spezielle Architektur Tag (Donnerstag den 28.01.2010), organsiert von Peter Hruschka und Gernot Starke (zwei weiteren bekannten Personen im Umfeld Architektur), bestärken mich, das Architektur wesentlich mehr ist als z. B. Design. Zu den Themen Architektur oder der Beziehung von IT zur (Fach) Domäne, habe ich eine Menge Ideen, sowie Erfahrungsberichte von den dortigen Bewohnern und anderen Reisenden mitgenommen. Vor allem der direkte Kontakt während der Vorträge, der anschließenden Q&A Runden, sowie den Diskussionen und Gesprächen mit den Sprechern und anderen Teilnehmern im Nachgang, z. B. beim Mittagessen, hinterlassen einen positiven Eindruck. Diese sind nicht nur interessant, sondern haben mir gezeigt, dass sich viele der „Herausforderungen“ denen ich in meinem täglichen Leben und auf meinen Reisen im “Grenzgebiet” begegne, sich dabei sehr ähneln. Das Lachen kam dabei auch nicht zu kurz.

Unter dem Slogan “Software meets Business” und dem Motto “Productivity: People, Process, and Technology” bietet meines Erachtens die OOP eine Möglichkeit, Architektur (neben anderen Schwerpunkten) von verschiedenen Standpunkten und Sichtweisen zu betrachten. Wer mehr über die Facetten von Architektur erfahren und diskutieren möchte, dem empfehle ich einen Besuch dieser Konferenz.

Besonders hervorheben möchte ich die folgenden Veranstaltungen, meine persönlichen Top 3:

• Tutorial mit Philippe Kruchten: “Software Architecture Knowledge Management – Theory and Practice, Methods and Tools”
• Keynote mit Gernot Starke: “Nachbars Garten – Wo Architekten lernen“
• Tutorial mit Eric Evans, Hans Dockter: „Domain-Driven Design: The Basics / Strategy”

Die Ideen und Impulse für das Überleben als Architekt, die ich in meinen vielen Tagesausflügen gesammelt habe, werde ich sicherlich in meiner Arbeit im „Grenzgebiet“ weiterverfolgen. Somit sind sicherlich nicht nur meine “Top 3″, sondern auch die Erfahrungen und Erlebnisse weitere Blogeinträge wert. To be continued …

Das Motto war “Architektur in Zeiten von Agilität” und die vier Speaker Dr. Gernot Starke, Stefan Zörner, Martin Lippert und Uwe Friedrichsen haben das Motto jeweils von einem bestimmten Standpunkt aus beleuchtet.

Uwe Friedrichsen hat in dem ersten Vortrag des Tages auf die Wichtigkeit von Wartbarkeit und Weiterentwicklung als Architekturziel hingewiesen – insbesondere im Rahmen agiler Entwicklung.

Martin Lippert hat in seinem folgenden Vortrag Modulsysteme betrachtet, welche wertvollen Beiträge sie zu flexiblen Systemen liefern können und welche Lehren wir daraus für unsere tägliche Architektur- und Designarbeit ziehen können.

Nach der Mittagspause übernahm Stefan Zörner den undankbarsten Slot des Tages, bei dem die Teilnehmer gut gesättigt vom Mittagessen zuhören und stets latent einschlafgefährdet sind … . Stefan hat die Herausforderung aber souverän gemeistert und launig über den Sinn und Zweck von Architekturdokumentation erzählt und wieviel man davon in der Praxis benötigt.

Er hat mit “Jar-Schlampe” auch den Ausdruck des Tages geprägt (Umschreibung für eine Person, die sich bei der Nutzung vieler Frameworks und Bibliotheken gerne einmal einschleichenden Jar-Abhängigkeiten nicht mehr im Griff hat). Der Ausdruck hat neben spontanem Applaus so viel Eindruck hinterlassen, dass er zu einer gut besuchten Open Space Session am Abend mit dem Arbeitstitel “Hilfe! Ich bin eine Jar-Schlampe! Was tun?” geführt hat …

Abgeschlossen wurde der Vortragsteil des Meet the Experts von Dr. Gernot Starke, der auf Basis eines realen Beispiels erläutert hat, wie man Architekturentscheidungen in der Praxis trifft und – aufbauend auf dem Vortrag von Stefan Zörner – wie man diese geeignet festhalten kann. Er hat das auf Basis des arc42-Templates getan, was nicht wirklich verwunderlich ist, da er das Template ja maßgeblich selbst entwickelt hat …

Nach den Vorträgen ging es dann mit den Open Space Sessions weiter. Als Neuerung gegenüber den früheren Meet the Experts wurde das Open Space Konzept schon direkt am Morgen vorgestellt und die Teilnehmer hatten den ganzen Tag Zeit, eigene Themen auf einer bereitgestellten Pinwand einzutragen. Nachdem die Möglichkeit bis zum Mittagessen noch nicht genutzt worden ist, hat die Mittagspause offenbar genügend Zeit und Raum zur Reflektion geboten, denn nach der Mittagspause füllte sich die Pinwand zusehends.

Auf Basis der Einträge wurde dann in den einzelnen Open Space Sessions wieder kräftig diskutiert, überlegt, debattiert, argumentiert und natürlich auch zugehört, bevor man den Abend langsam bei einem guten Essen und angeregter Unterhaltung ausklingen ließ – nicht zu vergessen diverse harte Kickerturniere, bei denen sich nichts geschenkt wurde und einige heiße Gitarrengefechte bei Guitar Hero an der Wii …

Das Feedback der Teilnehmer während und nach der Veranstaltung war durchweg sehr positiv und wir freuen uns schon auf das nächste Meet the Experts. Einige Impressionen von der Veranstaltung sind in der folgenden Fotogallerie zu sehen.

[Show as slideshow]

12►

• OSGi ist ein sehr gutes Modulkonzept welches leider noch nicht im Javastandard enthalten ist. Leider wird es auch noch sehr lange dauern bis sich OSGi im Enterprise Umfeld durchsetzt. Die Hauptursache dafür dürfte in der schlechten Interoperabilität von altem Code und der veränderten Laufzeitumgebung, welche primär für den Betrieb Herausforderungen darstellt, zu liegen.
• Man soll viele kleine Module für die eigene Software verwenden. Es gibt einige kleinere Vorteile, welche insgesamt die etwas erhöhten Entwicklungskosten aufwiegen.
• Es ist absolut notwendig jemanden zu haben der den Überblick über alle verwendeten externen Bibliotheken behält.
• Viele externe Bibliotheken zu haben, kann einige Probleme auslösen: Classloading, rechtliche, Dateigröße, Deployment Dauer, Arbeitspeicherverbrauch.
• Maven oder Ivy lösen das Problem nicht aber helfen bei der Bewältigung ungemein.
• Es ist empfehlenswert regelmäßig den Nutzen eingesetzter Bibliotheken auszuwerten. Kaum genutzter Code kann eventuell umgeschrieben werden um Bibliotheken zu reduzieren

Vielen Dank an alle Teilnehmer. Über 20 Teilnehmer zeigen klar, daß es wichtig ist Abhängigkeiten besser zu bewerten.

1. Neal bestätigt unser Credo bei codecentric: Der Code ist das wichtigste. Code ist design, Code ist Architektur. Alles was kein Code ist (auch Kommentare) ist nicht so wichtig, weil es nicht Teil des vom Compiler zu unserem Produkt Übersetztem ist. Die gleiche Idee findet sich in ausführbaren Spezifikationen über die Thomas vor ein paar Tagen schrieb. Neal betonte auch die Wichtigkeit einen sauberen Code zu haben und Baustellen umgehend zu beseitigen. Code solle mit der Zeit besser werden, nicht schlechter.
2. Neal verglich Architektur mit Design. So seien sie sich sehr ähnlich, aber Architektur sei beständiger während Design sich an den Geschäftsproblemen orientiert, welche sich häufig ändern.
3. Er klassifiziert Komplexität in zwei Gruppen. Es gibt inherente Komplexität eines Problems, welches die Komplexität ist um die wir uns eigentlich kümmern müssten um ein Problem zu lösen. Oft führen wir aber selbst versehentliche Komplexität ein, indem wir zu generische Lösungen skizzieren. Man kann sie zwar bekämpfen indem man versucht Entscheidungen zu verzögern bis sie notwendig werden und man ausreichend Informationen erlangt hat. Außerdem sollte man die einfachen Lösungen bevorzugen, da man komplexer eigentlich immer werden kann, einfacher hingegen eher nicht.

Es gab noch viele weitere gute Ideen in seinem Vortrag. Da Neal einen hervorragenden Präsentationsstil hat hätte ich ihm noch den ganzen Abend zuhören können

Falls Ihr auch heute Abend auf der JUG wart: Was habt ihr mitgenommen?

PS: Pac Man wird nie wieder so sein wie vorher

Das dritte meet the experts – architektur wird am 27. November 2009 stattfinden. Das Motto dieses Events ist „Architektur in Zeiten von Agilität“. Dabei geht es nicht nur um die Verbindung von Architektur und Agilität, sondern um die Anforderungen, die die aktuellen Entwicklungen in der IT an die Architektur stellt. In Zeiten knapper Budgets, immer kürzerer Entwicklungs- und immer längerer Betriebs- und Wartungszyklen reichen traditionelle Architekturansätze nicht mehr aus. In diesem Event soll beleuchtet werden, welche Herausforderungen sich aus dieser Situation für zeitgemäße Architekturen und Architekten ergeben und wie man sie meistern kann.

Mittlerweile steht der Inhalt des Events fest und auch dieses Mal haben wir es wieder geschafft, namhafte Experten zu versammeln:

Dr. Gernot Starke arbeitet seit einigen Jahren als unabhängiger Berater für Software-Architekturen, methodisches Software-Engineering sowie iterative Entwicklungsprozesse. Er besitzt mehr als 20 Jahre Erfahrung in der Gestaltung von Architekturen und Prozessen von IT-Systemen unterschiedlicher Größe. Vor seiner Selbständigkeit wirkte er einige Jahre als technischer Direktor des “Object Reality Center”, einem Joint-Venture mit Sun Microsystems sowie als Entwickler, Berater und Projektleiter bei verschiedenen Unternehmensberatungen. Er ist Mitbegründer von arc42, dem freien Portal für Software-Architekten. Aus seiner Feder stammt der praktische Leitfaden “Effektive Software-Architekturen” (3. Auflage, Hanser-Verlag 2008) sowie “Software-Architektur kompakt” (Spektrum-Verlag, 2009) und weitere Bücher zu agiler Entwicklung, Design-Patterns und SOA. Gernot hat an der RWTH Aachen Informatik studiert und in Aachen und Linz über Software-Engineering promoviert.

Martin Lippert arbeitet als Senior-IT-Berater für die it-agile GmbH in Hamburg und hilft Teams und Organisationen, agile Methoden erfolgreich einzuführen und umzusetzen. Er verfügt über 10 Jahre Erfahrung aus agilen Softwareprojekten als Projektleiter, Coach und Entwickler und ist Experte für große objektorientierte Systeme, flexible und hochgradig modularisierte Architekturen und Refactoring-Techniken. Er ist regelmäßiger Sprecher auf nationalen und internationalen Konferenzen, Autor diverser Artikel und Co-Autor von Büchern zu Extreme Programming, Refactoring und Eclipse. Darüber hinaus arbeitet Martin an der Integration von Aspect-Weaving in die Equinox-OSGi-Runtime, um die Modularisierungstechnologien OSGi und AOP nahtlos miteinander zu verknüpfen.

Stefan Zörner ist Anwendungsarchitekt, Berater, Trainer und Coach bei oose in Hamburg und leitet dort den Bereich Software-Engineering. Zu seinem Erfahrungsschatz zählen etliche Entwicklungs- und Beratungsprojekte bei Unternehmen und Organisationen im In- und Ausland – zumeist im Zusammenhang mit Java. Sein Interesse an Verzeichnisdiensten und die Arbeit an seinem LDAP-Buch lenkten Stefans Interesse auf das Directory Project der Apache Software Foundation. Sein Einsatz dort führte 2005 zur Wahl in den Kreis der Committer dieses Projektes, in dem er noch immer sehr aktiv mitarbeitet. Stefan spricht regelmäßig auf Konferenzen und ist Autor zweier Bücher und zahlreicher Fachartikel (u.a. bei IBM developerWorks). Zuletzt zeichnete er im Java Magazin für die Kolumne zum Thema “Architekturen dokumentieren” verantwortlich.

Uwe Friedrichsen ist seit vielen Jahren in der IT tätig und leitet derzeit das Competence Center Architektur bei der codecentric GmbH. Er hat langjährige Erfahrungen als Architekt, Projektleiter, Berater und Entwickler. Seine Schwerpunkte sind Software Architekturen und Unternehmensarchitekturen im Kontext agiler Konzepte. Aktuell beschäftigt er sich intensiv mit den Herausforderungen flexibler und nachhaltiger Architekturen in der Praxis. Darüber hinaus verfasst er regelmäßig Artikel und hält Vorträge in den Bereichen Architektur, Agilität und Software-Engineering.

Diese vier Experten beleuchten das gegebene Motto jeweils von ihrem Standpunkt aus und bieten Ihnen so ein breites Spektrum an Ansichten und Einsichten zu dem Thema an. Konkret sieht die Agenda für das meet the experts – architektur folgendermaßen aus:

1. Uwe Friedrichsen: “Design for Maintenance” in der Praxis

Die IT-Budgets werden immer knapper, die Entwicklungszyklen immer kürzerer und die Betriebs- und Wartungsphase von Software immer länger. Agile Ansätze treiben diese Entwicklung auf die Spitze, da die Software praktisch mit Ende der ersten Iteration in die Betriebs- und Wartungsphase übergeht. Traditionelle Architekturansätze reichen häufig nicht mehr aus, um diesen Herausforderungen gerecht zu werden.
“Design for Maintenance” geht auf diese Herausforderungen ein, indem es zum Ziel hat, die Architektur einer Software so zu gestalten, dass sie möglichst gut auf die Anforderungen von Wartung, Weiterentwicklung und Betrieb vorbereitet ist und so die Einsparpotentiale dieser im Lebenszyklus einer Software dominanten Phasen zu erschließen. Die Frage ist nur: Wie geht das in der Praxis?
Dieser Vortrag erläutert die Prinzipien und Potentiale von “Design for Maintenance” und gibt dann eine Reihe allgemeiner und konkreter Empfehlungen zur Umsetzung in der Praxis, veranschaulicht mit Hilfe einer Reihe von praktischen Beispielen.

2. Martin Lippert: Modulsysteme und ihr Einfluss auf Architekturen

Im Java-Umfeld wird derzeit viel über ein zukünftiges Modulsystem für die Sprache diskutiert. OSGi wird dabei als ein möglicher Kandidat betrachtet, der sich in den letzten Jahren als ein tragfähiges dynamisches Modulsystem für Java-basierte Systeme etabliert hat. In Rahmen dieses Vortrags betrachten wir die elementaren Eigenschaften solcher Modulsysteme und diskutieren, welchen Einfluss sie auf die Gestaltung und Umsetzung von flexiblen Architekturen für große Business-Anwendungen haben.
Wir widmen uns Fragen wie beispielsweise:

• Wie verändern sich Architektur-Vorstellungen, wenn eine starke Modularisierung und Komponentisierung des Systems eine wichtige Rolle spielt?
• Wie helfen mir Modulsysteme, große Systeme über einen langen Zeitraum hinweg flexibel weiterzuentwickeln?
• Wie kann eine flache Aufwandskurve auch über Jahre hinweg erhalten bleiben?

Eine spannende und kontroverse Diskussion ist garantiert.

3. Stefan Zörner: Steht alles im Wiki? Architekturen effektiv dokumentieren und kommunizieren

Dokumentieren zählt nicht zu den Lieblingsbeschäftigungen in Entwicklungsprojekten. Gerade Architektur und Entwurf einer Softwarelösung werden in vielen Fällen gar nicht oder zumindest nicht angemessen dokumentiert. Wenn dann später Umbaumaßnahmen am Softwaresystem anstehen oder Neue ins Team kommen, wird klar: Ziele, Entscheidungen und Strukturen sind nicht mehr nachvollziehbar, die Lösung ist (Zitat aller) “historisch gewachsen”.
Dieser Vortrag stellt einige bewährte und praxiserprobte Arbeitsergebnisse vor, mit denen Sie Softwarearchitektur frei von unnötigem Ballast festhalten können. Sie unterstützen Sie dabei, Ihre Konzepte im Team zu kommunizieren, anstatt sie zu vergessen.

4. Dr. Gernot Starke: Software-Architecture-by-Example

Wie entstehen eigentlich “gute” Architekturen? Wie treffen Software-Architekten auf Basis unklarer und widersprüchlicher Anforderungen denn Entscheidungen, die Basis für flexible und robuste Systeme darstellen?
Anhand realer Beispiele erfahren Sie, wie das in der Praxis funktioniert und wie Sie selbst solche Entscheidungen systematisch angehen. Außerdem erfahren Sie eine Menge über die Kommunikation zwischen Software-Architekten und den anderen Projektbeteiligten.

Trotz teilweiser englischer Titel sind die Vorträge selbst natürlich alle auf Deutsch. Das meet the experts wird in bewährter Weise durchgeführt, erstklassige Rahmenbedingungen, Vorträge und ein “Open Space”, um auch Themen platzieren zu können, die den Teilnehmern am Herzen liegen, sich aber nicht in den Vorträgen wiederfinden.

Die Anmeldung zum Event ist freigeschaltet und ich würde mich freuen, Sie am 27. November beim meet the experts – architektur begrüßen zu dürfen.