Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

CloudLand 2023

Resilienz

Softwarearchitektur

Resilient Software Design - The Past, the Present and the Future

Nur ein Gedanke …Vor ein paar Tagen habe ich das folgende Zitat gelesen:<blockquote>„Perfektion entsteht offensichtlich nicht dann, wenn man nichts mehr hinzuzufügen hat, sondern wenn man nichts mehr wegnehmen kann.“ (A. Saint-Exupéry)</blockquote>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:<ul><li>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.</li><li>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.</li><li>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.</li><li>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.</li><li>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“.</li><li>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.</li><li>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.</li></ul>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:<ul><li>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.</li><li>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.</li><li>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.</li><li>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.</li></ul>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:<blockquote>„Weniger ist mehr!“ (Mies v.d. Rohe)</blockquote>Wie ich bereits eingangs geschrieben habe: Nur ein Gedanke …

Perfektion in der IT – oder „weniger ist mehr“

Welche Geschichte hört man typischerweise über Agilität? Genau, meistens klingt es in etwa folgendermaßen: Agilität wurde von einigen frustrierten Entwicklern erfunden, die die Nase von nicht funktionierenden Prozessen voll hatten und von Dutzenden an Artefakten, die nicht die Bohne zum finalen Produkt beigetragen haben. Sie bekämpften all die schrecklichen V-Modelle, RUPs und wie auch immer diese schwerfälligen und überladenen Prozess-Monster hießen, indem sie einige schöne leichtgewichtige und agile Prinzipien erfanden, die sie dann Scrum, XP und so weiter nannten. Und seitdem haben sie nicht von ihrem heroischen Kampf abgelassen, die Entwickler von ihrer tonnenschweren Prozesslast zu befreien und die Agilität in diese Zentren der Rückständigkeit zu tragen, d.h. in das Management und die Fachbereiche, mit dem Ziel, eines Entwicklers Leben wieder lebenswert zu machen. Das ist doch die Geschichte, die wir so kennen, oder? Nun, hier bei codecentric kennen wir eine ganz andere Geschichte. Indem wir bereits seit längerer Zeit agil Software entwickeln, hatten wir schon einige Male die Gelegenheit, Teil des ersten agilen Projekts zu sein, das die jeweiligen Kunden umgesetzt haben. Meistens mussten die Kunden eine harte Terminvorgabe einhalten oder etwas ähnliches, das mit ihren normalen Prozessen nicht funktioniert hätte und sie hatten etwas über die Produktivitätserhöhung durch Agilität gehört. Nun, um die Geschichte abzukürzen: Zu irgendeinem Zeitpunkt waren wir dann mit dabei, um das entsprechende Projekt auf eine agile Art und Weise umzusetzen. Aber während der Umsetzung dieser Projekte machten wir dann Erfahrungen, die häufig ganz anders waren als die, die man auf Basis der „bekannten Geschichte“ erwartet hätte:Die Fachbereiche *liebten* die Agilität! Sie waren superglücklich über die kurzen Feedback-Zyklen und dass sie jemand hatten, der bereit war, wirklich mit ihnen zu kommunizieren, anstatt sie bei jedem Problem oder Anforderung immer nur aufzufordern, ein weiteres formales Dokument zu schreiben. Sie liebten es, wenn sie sehen konnten, wie ihre Vision in kurzen Iterationen heranwuchs und sie die Möglichkeit hatten, ihre eigenen Ideen dabei nachzujustieren. Sie fanden es sogar klasse, wenn sie bemerkten, dass sie mit ihren ursprünglichen Ideen auf dem Holzpfad waren, da sie die Möglichkeit hatten, diese Fehler einfach zu korrigieren und so das finale Produkt massiv verbessern konnten. Sie waren schlicht und ergreifend glücklich und hätten sie die Wahl gehabt, hätten sie nie wieder ein nicht-agiles Projekt gemacht.Das Management mochte Agilität auch recht gerne. Das Management der Fachseite mochte es, weil seine Fachbereiche es liebten und das IT-Management mochte es, weil sich das Management der Fachseite nicht mehr über zu späte Liefertermine, zu hohe Belastung für ihre Leute oder ähnliches beschwerte. Okay, es war nicht immer Liebe auf den ersten Blick beim IT-Management. Oftmals waren sie schon recht misstrauisch gegenüber dem ganzen agilen Kram, weil sie keine Ahnung hatten, was auf sie zukommen würde, wenn das ein richtig dicker Erfolg werden sollte. Manchmal wünschten sich diese Manager hinter vorgehaltener Hand, dass das Projekt scheitern würde, denn dann hätten sie den ganzen Fachbereichs-Leute gezeigt, dass dieser agile Kram auch nicht funktioniert und man deshalb bei dem altbekannten und etablierten Vorgehen bleiben kann.Und dann waren da noch die Entwickler, diese Leute aus den IT-Abteilungen des Kunden, die nach all den Jahren überglücklich sein sollten, dass sie endlich agil arbeiten durften, nicht wahr? Überraschenderweise waren die meisten von ihnen überhaupt nicht glücklich! Sie liebten ihre Prozesse und Artefakte sehr und die meiste Zeit drängten sie auf „mehr Formalismus“. Sie fühlten sich sicher in der Welt, die sie sich über die Jahre geschaffen hatten. Wann immer in den vergangenen Jahren etwas schiefgegangen ist, haben sie ein weiteres Stück Formalismus hinzugefügt, einen weiteren Prozessschritt, ein weiteres Artefakt. Sie hatten sich ihre eigene, sehr komfortable Welt innerhalb der Grenzen ihrer Prozesse geschaffen. Alles hatte seinen Platz und seine Ordnung. Alles war in ihren Prozessen beschrieben und Dinge, die nicht in den Prozessen beschrieben waren, waren schlicht und ergreifend verboten. Und das Beste daran: Niemand musste wirklich Verantwortung für irgendeinen Fehler übernehmen. Solange man sich an die Prozesse gehalten hat, hat man alles richtig gemacht und wenn etwas schiefgegangen ist, musste es der Fehler von jemand anderen sein. Also, tue einfach brav, was immer der Prozess Dir vorschreibt und Du bist sicher! Uff, was für eine Erleichterung!Man kann sich sicherlich vorstellen, dass Agilität mit seinem Fokus auf Ergebnissen anstatt Prozessen, mit eigenverantwortlichen Teams, die Verantwortung für das Ergebnis übernehmen, mit seinem Druck, mit Fachbereichsleuten zu sprechen, um Dinge zu klären anstatt einfach eine Spezifikation zurückzuweisen, dass dieses ganze seltsame agile Ding nicht wirklich das war, auf das diese Entwickler gewartet haben. Tatsächlich hat es ihnen richtig Angst gemacht! Sie fühlten sich verdammt unwohl damit. Sie wussten nicht, wie sie damit umgehen sollten und hatten immer dieses angsteinflößende Gefühl, dass sie schuld sein könnten, falls irgendetwas schief gehen würde. Nein, sie waren überhaupt nicht glücklich!Okay, ich gebe zu, dass ich es ein wenig überspitzt dargestellt habe, um den Punkt herauszuarbeiten, aber: Das ist kein spezifisches Problem irgendeines unserer Kunden; das ist ein Phänomen, das man quer durch die ganze Branche beobachten kann. Wir hatten eine Menge Unterhaltungen und Diskussionen mit vielen anderen agilen Protagonisten, die uns unsere Beobachtungen bestätigt haben. Und es ist nicht so, dass die beschriebenen Entwickler Agilität nicht mögen, weil sie „böse“ oder „ewiggestrig“ oder was auch immer wären. Sie fühlen sich schlicht unsicher. Sie haben sich über Jahre hinweg ihre wohlorganisierte Komfortzone aufgebaut oder sind in diese Komfortzone hineingedrängt worden und sie haben einfach noch nicht gelernt, mit dieser Agilität umzugehen.Und was ist die Moral von der Geschicht‘? Ja, es bedarf einer Menge Change Management, um Agilität erfolgreich in einem Unternehmen zu etablieren, aber … *aber* ziemlich häufig sind es nicht die Fachbereiche, die wir auf die Agilität vorbereiten müssen; es sind die IT-Abteilungen, die wir auf die Agilität vorbereiten müssen. Seltsam, oder? … 😉PS: Ich rede nicht über *alle* Entwickler. Ich weiß, dass viele von Euch agil denken und es lieben, in einer agilen Weise zu arbeiten. Aber auf der anderen Seite gibt es immer noch diese große Masse an Entwicklern, die nicht agil arbeiten wollen oder zumindest nicht wissen, wie sie sich dahin entwickeln sollen und ich denke, es sind diese Leute, auf die wir unsere Veränderungsbemühungen konzentrieren müssen, nicht auf die Fachbereiche.

Das Märchen vom agilen Entwickler

Mittlerweile tobt seit längerem eine hitzige Debatte über die Frage, ob Architektur und Design die gleiche Sache sind oder nicht. Die Vertreter der „Beides ist das Gleiche“-Fraktion sagen, dass Architektur eigentlich einfach nur die erste Phase des Designs ist, während die Gegner dieser These darauf beharren, dass Architektur und Design zwei vollständig verschiedene Aufgaben sind, die nur eine mehr oder minder unscharfe gemeinsame Berührungslinie teilen. Tja, wer von den beiden hat denn nun recht?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 … 😉

Was ist der Unterschied zwischen Architektur und Design?

Gestern habe ich den Agile Day auf der JAX 2009 in Mainz besucht. Es würde nicht viel Sinn machen, wenn ich irgendwelche Bewertungen zu den Vorträgen abgeben würde, da ich einer der Speaker war … 😉 … aber ich möchte hier einige persönliche Eindrücke weitergeben, die ich gesammelt habe.Als erstes war ich sehr überrascht, wie viele Besucher der Agile Day hatte. Es waren mindestens 300 Leute, die den ganzen Tag über dageblieben sind. Das hat mir auf eindrucksvolle Weise gezeigt, wie sehr die Leute derzeit an dem Thema Agilität interessiert sind. Bei einer kurzen Umfrage hat etwa die Hälfte der Teilnehmer gesagt, dass sie einige agile Praktiken nutzen, aber nicht wirklich agil sind. Von der anderen Hälfte haben die meisten Leute gesagt, dass sie derzeit gar nichts in Sachen Agilität machen, aber an dem Thema interessiert sind. Nur eine Handvoll Leute hat angegeben, dass sie wirklich agile Software-Entwicklung betreiben und die meisten von ihnen waren Speaker. Mir hat das gezeigt, dass noch eine weite Reise im Bereich Agilität vor uns liegt, aber dass sich viele Leute mittlerweile auf den Weg gemacht haben, was ein gutes Zeichen ist.Die zweite für mich interessante Sache war eine Pecha Kucha Session. Stefan Roock hatte diese Session organisiert. Es waren 6 Speaker, von denen jeder eine Präsentation mit exakt 20 Folien gezeigt hat, von denen jede genau 20 Sekunden angezeigt wurde, zusammen 6 Minuten und 40 Sekunden. So sind die Regeln für eine Pecha Kucha Präsentation. Das war für mich ziemlich interessant, eine solche Session zu besuchen. In der Vergangenheit habe ich zwar schon darüber gelesen, aber gestern habe ich das erste Mal an einer solchen Session teilgenommen. Gefallen hat mir die Dauer der Präsentationen. Sie zwingt die Vortragenden, sich auf eine oder maximal zwei Ideen zu fokussieren und hält sie davon ab, langwierig über dutzende Dinge zu reden. Auf der anderen Seite fand ich das strikte Format recht ablenkend. Meistens sind die Folien ein wenig zu lang oder zu kurz für den vorgetragenen Inhalt des Speakers angezeigt worden. So mussten sie wechselweise oft warten oder sich sehr beeilen. Zusätzlich war ich stark abgelenkt, da ich irgendwie immer darauf gewartet habe, wann die nächste Folie angezeigt wird. Zusammenfassend war es eine recht interessante Erfahrung für mich, aber ich denke, dass dieses sehr strikte Format nur in wenigen Fällen wirklich hilfreich ist. Meiner Meinung nach sind kurze Sessions – 10 Minuten oder weniger – ein gutes Format, aber sie sollten nicht so strikt sein.Meinen letzten interessanten Eindruck hatte ich bei dem Speaker Panel am Ende. Es war nicht die Panel Diskussion an sich, davon habe ich mittlerweile eine Menge gesehen. Es war vielmehr die Tatsache, dass selbst die agilen Experten, die dort gestanden haben, recht unterschiedliche Ansichten und Auffassungen zu dem Thema Agilität hatten. Okay, auf der einen Seite ist das sicherlich ziemlich normal für viele Themengebiete, aber auf der anderen Seite ist es immer wieder recht überraschend, das live in einer Panel Diskussion zu erleben. Für mich bin ich zu dem Schluss gekommen, dass Agilität insgesamt ein noch nicht sehr gut erforschtes Gebiet ist und dass sich das Thema in den nächsten Jahren noch ziemlich weiterentwickeln wird.

JAX 2009 – Agile Day

Am 27. November hat unser drittes Meet the Experts stattgefunden, dieses Mal zum Thema Architektur. Trotz einer Reihe krankheitsbedingter Absagen (der beginnende Winter fordert seinen Tribut) haben wieder über 80 Interessierte ihren Weg nach Solingen gefunden.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 <a href="http://blog.codecentric.de/2009/11/meet-the-experts-architektur-open-space-verwaltung-des-jar-chaos/">„Hilfe! Ich bin eine Jar-Schlampe! Was tun?“</a> 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 <a href="http://www.arc42.de/">arc42-Templates</a> 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 <a href="http://de.wikipedia.org/wiki/Open_Space">Open Space</a> 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.

meet the experts – architektur | 27. November 2009 – Eine Nachlese

Viele „klassische“ Projektmanager stehen Scrum sehr reserviert oder gar ablehnend gegenüber. Einer der Gründe dafür ist, dass sie sich in Scrum nicht wiederfinden. Es gibt keine Rolle „Projektmanager“ in Scrum. Im Rahmen unseres Meet the Experts – Agilität hatte ich die Gelegenheit, mich mit <a href="http://borisgloger.com/">Boris Gloger</a> ein wenig über das Thema zu unterhalten.Zuvor hatte Boris in einem OpenSpace einmal seine Sicht auf die Rolle Product Owner dargelegt. Bei dieser Darstellung ist mir klar geworden, dass die Rolle wesentlich mehr Elemente der klassischen Projektmanager-Rolle hat, als ich vorher wahrgenommen hatte. Ich hatte den Eindruck, dass die Aufgaben des klassischen Projektmanagers in gewisser Weise auf die Rollen Product Owner und Scrum Master verteilt worden sind. Mit diesem Eindruck habe ich Boris angesprochen und er hat mir diesen Eindruck bestätigt, genauer sogar noch etwas erweitert: Nach seiner Einschätzung ist die klassische Projektmanager-Rolle eigentlich überfrachtet und es gibt kaum eine Person, die diese Rolle in allen geforderten Aspekten gut ausfüllen kann. In Scrum hingegen ist die Rolle folgendermaßen aufgeteilt worden:<ul><li>Der Product Owner ist für die Richtung (die Vision), die inhaltliche Steuerung (Product Backlog) und das Budget verantwortlich. Er ist derjenige, der die Richtung vorgibt und inhaltlich treibt. Ebenso versucht er, das meiste aus dem ihm zur Verfügung stehenden Budget herauszuholen. Da – egal wie das Vorhaben im Detail aussieht – für die Features, die den höchsten Geschäftswert versprechen, im Verhältnis auch das meiste Budget zur Verfügung steht, ergibt sich durch das Streben, das meiste aus dem Budget herauszuholen, automatisch eine Priorisierung der Features nach Geschäftswert. Das klingt zwar nicht so richtig „edel und rein“, funktioniert aber in der Praxis erstaunlich gut … 😉</li><li>Das Team ist für die Planung der Umsetzung und die Einhaltung der Planung verantwortlich, d.h. den ganzen Detailplanungs- und Controlling-Anteil. Durch Sprint-Planung, Commitment auf die abgestimmten Sprint-Inhalte und Team-Verantwortung für die Umsetzung ist besser als in vielen klassisch aufgestellten Projekte gewährleistet, dass Erwartungshaltungen und Ergebnisse zueinander passen.</li><li>Der Scrum Master letztlich ist der „Kümmerer“: Er holt die Pizza, wenn es spät wird, räumt die Hindernisse aus dem Weg … ist aber auch derjenige, der dem Team über die Schulter schaut und es bei Bedarf an seine Commitments erinnert. Er stellt sicher, dass alle ihrer jeweiligen Rolle gerecht werden und sorgt für die bestmöglichen Arbeitsbedingungen.</li></ul>So verteilen sich die Aufgaben des klassischen Projektmanagers auf recht natürliche Weise auf die drei Scrum-Rollen. Wenn man nun als Projektmanager den Schritt Richtung Scrum wagen will (oder manchmal auch muss), so ist die Wahl einer Rolle eigentlich relativ einfach. Man sollte ehrlich in sich selber hereinhorchen, welchen Teil der Projektmanager-Rolle einem am besten liegt:<ul><li>Treibt man ein Projekt gerne inhaltlich und hat ein gutes Händchen für Budgets, dann sollte man die Product Owner-Rolle wählen.</li><li>Ist man hingegen eher der „Kümmerer“ und hat Spaß daran, dafür zu sorgen, dass ein Projekt rund läuft, dann sollte man am besten die Scrum Master Rolle wählen.</li><li>Wenn man aber nur Projektmanager geworden ist, weil man seinen früheren Entwicklerjob zu gut gemacht hat, darüber irgendwie in die Verantwortung hineingerutscht oder -gewachsen ist, dann sollte man am besten wieder Teil des Teams werden und Spaß daran haben, das Projekt durch seine eigene Leistung nach vorne zu bringen.</li></ul>Insgesamt macht diese Darstellung von Boris für mich viel Sinn. Vor allem glaube ich, dass durch diese Art der Rollenaufteilung die für den Erfolg eines Projektes kritischen Anteile der klassischer Projektmanager-Rolle gut auf die drei Scrum-Rollen verteilt sind und durch die Aufteilung umfassender gelebt werden können als wenn sie von nur einer Person wahrgenommen werden sollen.Einen Punkt hat Boris in seiner Darstellung allerdings nicht erwähnt: Es gibt eine häufig anzutreffende Art von klassischen Projektmanagern, die ich gerne „reine Projektmanager“ nenne. Diese zeichnen sich dadurch aus, dass sie auf rein formal Weise jede Art von Projekt managen, ohne genauere Kenntnis von den Projektinhalten zu haben. Sie beschränken sich darauf, Planungen (von wem auch immer erstellt) sowie Eskalationen zu verwalten und besitzen ausgeprägte Controlling-Kenntnisse, manchmal auch gute politische Kenntnisse. Sie machen in Anlehnung an das „Management by Spreadsheet“ (Management nur auf Basis von Kennzahlen unter Vernachlässigung der zugrundeliegenden Inhalte) ein „Project Management by Spreadsheet“ und manche dieser Projektmanager sind auch noch stolz darauf, dass sie nichts von den Inhalten verstehen, die sie verwalten („Ich kann jedes Projekt managen. Der Inhalt ist mir vollständig egal.“).Nun, für diesen Typus Projektmanager gibt es in Scrum tatsächlich keine Verwendung. Getreu des Lean-Prinzipies „Eliminate Waste!“ vermeidet Scrum nämlich jede Art von Ballast und fokussiert sich ausschließlich auf die Aspekte der Projektmanager-Rolle, die Mehrwert bieten, d.h. zum Projekterfolg beitragen. Und da echter Erfolg letztlich nur auf Basis der produzierten Inhalte beurteilt werden kann, wird eine Person, die nichts zu den Inhalten, zum eigentlich Ergebnis beitragen kann, in Scrum nicht benötigt. Es bleibt nur die Frage, ob solche Personen außerhalb von Scrum benötigt werden …

Der klassische Projektmanager in Scrum

Eine Reihe interessanter bis erschreckender Erfahrungen in meiner beruflichen Laufbahn im Zusammenhang mit dem Messen bzw. Nichtmesssen von „Qualität“ hatte mich dazu bewogen, einen Vorschlag für eine entsprechende Session bei der <a href="http://www.sea-con.de/">SEACON 2010</a> einzureichen, in der ich über meine Erfahrungen mit dem Thema sprechen wollte. Der Vorschlag wurde zu meiner Freude angenommen und in der Folge ging ans Vorbereiten der Session.Da die Veranstalter und der Fachbeirat der SEACON aktiv zu Formaten jenseits des klassischen Vortrags ermutigen, insbesondere zu interaktiven Formaten, die auch das Publikum einbeziehen, habe ich mich zu einem „Experiment“ entschlossen: Anstatt einen klassischen Folienvortrag vorzubereiten, wollte ich versuchen, zusammen mit dem Publikum ein „moderiertes Streitgespräch“ zu führen. So weit, so einfach, aber wie setzt man so etwas um? Gar nicht so einfach. Also überlegte ich hin und her, entwarf und variierte einige Ideen und landete schließlich bei einem relativ elaborierten Konzept mit Gruppenarbeit, abwechselndem Entwurf und Kurzdiskussion von Argumenten für die Pro- bzw. Contra-Position, gefolgt von einer Bewertung über das gesamte Publikum und Festhalten eines „Punktstandes“ am Ende der Session.Mit dem Konzept im Gepäck bin ich dann zur SEACON gefahren. Nun, das Ganze wäre wahrscheinlich fürchterlich in die Hose gegangen, wenn ich nicht glücklicherweise am Vortag schon eine Fishbowl zum Thema „Selbstorganisation von Teams“ moderiert hätte. Während der Fishbowl ist mir nämlich wieder aufgefallen, wie kurz 45 Minuten für eine Diskussion sind, gerade wenn es sich um ein potentiell kontroverses Diskussionsthema handelt. Mein ursprüngliches Konzept ging also gar nicht, war viel zu aufwändig, massive Vereinfachung war angesagt. Also zurück zum Zeichenbrett und neu nachgedacht! Das Ergebnis der Überlegungen war ein radikal vereinfachtes Konzept:<ul><li>Es gibt zwei Flipcharts, eines für Argumente, warum Qualität messbar ist und das andere für Argumente, warum nicht.</li><li>Ich biete eine „Reibungsfläche“ zum Entzünden der Diskussion, indem ich mich massiv auf einer der beiden Seiten positioniere und das mit einer Reihe von Argumente für diese Seite unterlege.</li><li>Danach geht es direkt in eine von mir moderierte Diskussion mit allen Teilnehmern und ich halte die wichtigsten Argumente auf den beiden Flipcharts fest.</li></ul>Mit diesem Minimalkonzept bin ich dann in die Session gestartet: Kurz in das Thema eingeführt, das Format erklärt und dann ging es auch schon zur „Reibungsfläche“. Ich habe mich auf die Seite „Qualität ist nicht messbar“ geschlagen und dafür die folgenden Argumente angeführt:<ul><li>Sobald man etwas misst, geht es um Zahlen und Mengen, d.h. um Quantität und nicht mehr um Qualität.</li><li>Qualität dient der Erfüllung von Bedürfnissen von Stakeholdern. Diese sind immer subjektiv und emotional und können nicht à priori auf objektiv messbare Zahlen heruntergebrochen werden. Oder anders herum ausgedrückt: Die Erfüllung à priori vereinbarter Messgrößen bedeutet noch lange nicht, dass ein Stakeholder dem fertigen System eine gute Qualität bescheinigt.</li><li>Das Problem der „metrischen Verzerrung“, basierend auf Arbeiten des Harvard-Professors Robert Austin: In Kurzform stellt jede Metrik in der Regel eine extreme Vereinfachung der eigentlich zu beobachtenden Größe dar, d.h. es werden jede Menge Informationen eliminiert, die diese Größe charakterisieren. Das Problem, das sich daraus ergibt ist, dass man nur noch die (stark trivialisierende) Messgröße optimiert und nicht mehr die (komplexe) zugrundliegende Größe, in diesem Fall „Qualität“.</li><li>Ein sich daraus ergebendes Risiko ist, dass man sich durch die Metriken in falscher Sicherheit wiegt und im schlimmsten Fall komplett falsche Impulse liefert, d.h. das System in die komplett falsche Richtung „optimiert“, weil man nur die vereinfachte Messgröße beobachtet und nicht mehr die eigentlich zu optimierende, komplexe Größe.</li><li>Letztlich bergen Metriken das Risiko, zum Selbstzweck zu verkommen, insbesondere bei Personen, die nicht genügend Fachwissen über das Messobjekt haben, um die Messgröße inhaltlich hinterfragen zu können. Wer hat noch nicht erlebt, dass ausgehend von einer guten Idee irgendwann nur noch Reports und Excelsheets „optimiert“ wurden anstatt das zugrundliegende Produkt?</li></ul>Nach der Präsentation der bewusst sehr einseitig gehalten „Reibungsfläche“ habe ich sicherheitshalber einmal nachgefragt, wie die Verteilung der „Befürworter“ und „Gegner“ von Qualitätsmessungen im Publikum ist. Wären nämlich fast alle oder womöglich sogar alle Teilnehmer einer Meinung gewesen, hätte die Diskussion ziemlich langweilig werden können. Glücklicherweise war die Verteilung sehr ausgewogen und die Diskussion konnte beginnen. Einige Teilnehmer wollten meine Argumente erfreulicherweise nicht einfach unkommentiert im Raum stehen lassen und so entspann sich eine angeregte Diskussion. Dabei habe ich versucht, die wichtigsten Argumente für die beiden Standpunkte an den beiden Flipcharts festzuhalten (siehe die beiden Bilder).<div><a href="https://media.graphassets.com/cuEN26GDSDePRRmkytnA"><img title="29062010370" src="https://media.graphassets.com/cuEN26GDSDePRRmkytnA" alt="Flipchart: Qualitaet ist nicht messbar, weil ..." width="300" height="225" /></a> Flipchart: Qualitaet ist nicht messbar, weil ...</div><div><a href="https://media.graphassets.com/Cqff8rFSR8q9wzvhV8gv"><img loading="lazy" title="29062010368" src="https://media.graphassets.com/Cqff8rFSR8q9wzvhV8gv" alt="Flipchart: Qualitaet ist messbar, weil ..." width="300" height="225" /></a> Flipchart: Qualitaet ist nicht messbar, weil ...</div>Nicht jeder Diskussionsbeitrag führte zu einem Punkt am Flipchart:<ul><li>Einige Teilnehmer hatten bereits genannte Argumente weiter untermauert und bestärkt.</li><li>Einige Teilnehmer wollten sich nicht auf eine der beiden Positionen limitieren, sondern haben eine Position „in der Mitte“ eingenommen.</li><li>Einige Teilnehmer warfen außerdem einen Blick über die Grenzen der Fragestellung hinaus.</li></ul>So wurde zum Beispiel die Frage gestellt, wie man Qualität überhaupt definiert, weil dies die Diskussion über die Messbarkeit maßgeblich beeinflussen würde. Andere Teilnehmer haben die Frage gestellt, wie man denn Qualität sicherstellen könne, wenn man sie nicht misst. Dazu gab es die sehr interessante Aussage, dass man Qualität gut „fühlen“ könne. Man müsse Qualität gar nicht messen, weil man über das Feedback der Stakeholder sehr schnell und wesentlich besser eine Rückmeldung über die Qualität des betroffenen Systems bekäme und in einem konkreten Projekt hätte das auch sehr gut funktioniert.Nach diesem letzten Beitrag musste ich die Diskussion dann leider abbrechen, weil wir die vorgesehene Zeit bereits um fünf Minuten überzogen hatten. Es gab noch eine Menge Wortmeldungen, die ich sehr zu meinem Bedauern nicht mehr berücksichtigen konnte und ich denke, wir hätten noch locker eine halbe Stunde oder Stunde weiter diskutieren können. Ein klares Fazit gab es erwartungsgemäß nicht, auch kein Patentrezept für den Umgang mit Metriken im Zusammenhang mit Qualität. Aber es gab eine Menge guter Ideen und interessanter Sichtweisen und Anregungen, die dem ein oder anderen vielleicht einen neuen Denkanstoß zu diesem nicht einfachen Thema gegeben hat … und das ist schon eine ganze Menge für die kurze Zeit.Trotzdem hier ein Versuch, die Sichtweisen der 45 Minuten zusammenzufassen:<ul><li>Es ist möglich, aber sehr schwer, geeignete Kriterien zu finden, die einen unterstützen, Qualität zu beurteilen.</li><li>Es ist nicht möglich, allgemeingültig „richtige“ Kriterien festzulegen. Man muss dies immer situativ bezogen auf die Aufgabenstellung und das Ziel tun.</li><li>Man muss sich stets der „metrischen Verzerrung“ bewusst sein und der Tatsache, dass jede Metrik auch eine „Schattenseite“ besitzt.</li><li>Entsprechend muss man die gemessenen Zahlen immer kritisch interpretieren und darauf achten, dass sie nicht zum Selbstzweck werden.</li><li>Insbesondere darf man sich durch die Metriken nicht in falscher Sicherheit wiegen. Man muss sich stets der Tatsache bewusst sein, dass Metriken immer nur einen (häufig kleinen und teilweise auch verzerrten) Teil des Gesamtbildes darstellen.</li><li>Selbst wenn einem Metriken vielleicht nicht helfen, Qualität zweifelsfrei nachzuweisen, so können sie doch zumindest sehr gut helfen, das Fehlen von Qualität festzustellen.</li><li>Gar nichts tun ist auch keine Lösung. Man muss sich auf jeden Fall explizit um Qualität kümmern, ob nun mit Hilfe von Metriken oder mit Hilfe anderer Mittel.</li></ul>Wie man sieht, hat sich trotz des bewusst polarisierenden Konzepts des Workshops ein recht differenziertes Gesamtbild ergeben, was ganz klar ein Verdienst der hohen (nicht gemessenen 😉 ) Qualität der Teilnehmerbeiträge war. Apropos „Teilnehmer“: In Summe hat mir die Session sehr gut gefallen. Für mich war das Format ja ein gewisses Risiko, da ich mich auf die Mitarbeit der Teilnehmer verlassen musste und die Qualität (oder Nichtqualität) der Session nicht mehr selbst in der Hand hatte. Die Teilnehmer sind auf das Diskussionsangebot aber hervorragend eingegangen, besser als ich es mir je erhofft hätte. Dafür auch an dieser Stelle noch einmal ein herzliches Dankeschön von mir an alle Teilnehmer, insbesondere auch an die, die aufgrund der Menge der Beiträge in der Kürze der Zeit nicht zu Wort gekommen sind. Mit so einem tollen Publikum mache ich gerne noch einmal eine solche Session!Ein kurzer Disclaimer zum Schluss: Ich habe versucht, die Session und die darin getätigten Aussagen nach bestem Wissen zusammenzufassen. Da das aber aus dem Kopf heraus passiert ist, ist es natürlich möglich, dass ich hier etwas falsch wiedergegeben haben. Das ist dann keine böse Absicht von mir und ich bitte die Teilnehmer, das zu korrigieren, z.B. in Form eines Kommentars. Danke!

Ist Qualität messbar? – Ein „moderiertes Streitgespräch“ auf der SEACON 2010

Inline-Kommentare im Code sind „böse“ und jeder, der heutzutage noch immer Inline-Kommentare verwendet, ist ein sehr, sehr schlechter Entwickler und man sollte ihm dringend seine Lizenz entziehen. Das ist es, was allgemeiner Konsens in der Entwicklergemeinde zu sein scheint … oder zumindest innerhalb des Teils der Entwicklergemeinde, der sich „Up to Date“ wähnt.Schön, aber ich behaupte, dass wir mehr Inline-Kommentare benötigen. Ja, was ist denn los mit mir? Habe ich jetzt endgültig den Verstand verloren?Nun, während die Beantwortung der letzten Frage eine durchaus diffizile Aufgabe sein könnte … 😉 … meine Gedanken bzgl. der Inline-Kommentare sind relativ einfach:Wenn Du irgendeine Art von Lösung verstehen willst, etwa wenn Du ein neues Feature in einer bestehenden, Dir bislang aber noch unbekannten Code-Basis implementierten sollst, dann musst Du mindestens die Antworten zu den folgenden drei essentiellen Fragen kennen:<ul><li>Was?</li><li>Wie?</li><li>Warum</li></ul>Wie bekommt man diese drei Fragen beantwortet, wenn der ursprüngliche Entwickler nicht mehr verfügbar ist?<ul><li>Das „Wie“ ist einfach. Das ist der Code an sich. Aus diesem Grund macht es auch definitiv Sinn, Code so verständlich wie möglich zu schreiben, damit jeder andere das „Wie“ so einfach wie möglich verstehen kann.</li><li>Das „Was“ ist normalerweise die Domäne der Klassen-/Methoden-/Funktions-/… Header. Der Kommentar-Header beschreibt, „Was“ das folgende Stück Software tun soll. In Java ist das die Domäne von Javadoc, andere Programmiersprachen haben ihre eigenen Mittel oder Konventionen dafür.</li><li>Aber wo bleibt das „Warum“? Der Code an sich kann diese Frage aus naheliegenden Gründen nicht beantworten und Javadoc, etc. sind auch nicht dafür gedacht. Diese sollten sich auf das „Was“ fokussieren. Man könnte das „Warum“ jetzt in ein separates Artefakt packen, ein Extradokument wie etwa ein Design-Dokument. Das ist aber recht umständlich. Außerdem ist die Wahrscheinlichkeit sehr hoch, dass irgendwelche Änderungen, Refactorings, etc. im Code nicht ihren Weg in das Dokument finden würden, so dass es sehr schnell veralten würde. Deshalb ist es eine wesentlich bessere Idee, die Antworten zu den „Warum“-Fragen genau an die Stelle zu setzen, an der Du den Effekt der zugehörigen Entscheidung unmittelbar sehen kannst, nämlich direkt neben den Code, der einem zeigt, „Wie“ die Entscheidung der „Warum“-Frage implementiert worden ist.</li></ul>Dafür kommen einem Inline-Kommentare gerade zupass. sie bieten ein perfektes Mittel, um die Begründung für bestimmte Entscheidungen zu liefern, die man im Code findet. Wann immer Du denkst „Warum um Himmels Willen hat er oder sie dieses Stück Code auf diese Weise implementiert?“, wäre es doch wunderbar, einen Inline-Kommentar direkt neben dem Stück Code zu finden, der einem diese Frage beantwortet, oder? Heutzutage sucht man aber leider meist vergeblich nach diesen Antworten. Stattdessen muss man versuchen, den ursprünglichen Entwickler zu fragen, sollte er noch greifbar sein und sich auch noch an diese Entscheidung erinnern oder das Wissen ist verloren und man muss den Grund erraten.Aus diesen Gründen ist die Domäne von Inline-Kommentaren für mich die Beantwortung von „Warum“-Fragen und aus meiner Erfahrung ist das Verstehen des „Warum“ aus einer Wartbarkeits- und Änderbarkeitsperspektive (hier kommt der Architekt in mir wieder durch … 😉 ) wesentlich wichtiger als das Verstehen des „Was“ … und das „Wie“ steht sowieso im Source Code.Darum sage ich, dass wir mehr Inline-Kommentare benötigen<ul><li>nicht, um das „Was“ zu erklären, das ist die Domäne der Header-Kommentare</li><li>nicht, um das „Wie“ zu erklären, das sollte der Code an sich beantworten</li><li>sondern um diese „Warum“-Fragen zu beantworten, um die Begründungen für Design- und Implementierungsentscheidungen zu liefern, die man meistens vergeblich sucht.</li></ul>Und deshalb ist meine abschließende Empfehlung:Schmeißt die Regel<blockquote>„Du darfst keine Inline-Kommentare verwenden“</blockquote>aus Euren Coding Standards und ersetzt sie durch<blockquote>„Du sollst Inline-Kommentare ausschließlich verwenden, (nicht-offensichtliche) Design- und Implementierungsentscheidungen zu erklären („Warum“-Fragen) … und vergiss nicht, sie dafür auch zu verwenden!“</blockquote>

Wir brauchen mehr Inline-Kommentare!

Auf der <a href="http://jax.de/wjax2010/">WJAX 2010</a> habe ich einen Vortrag mit dem Titel „Der agile Machiavelli oder wie kippe ich ein agiles Projekt?“ gehalten. Da meine Folien sehr minimalistisch waren und man auch nach fast 10 Jahren agilem Manifest noch überraschend viele „Worst Practices“ in agilen Projekten beobachten kann, hatte ich den Zuhörern versprochen, dass ich das Thema hier im codecentric-Blog noch einmal aufnehmen wollte.Okay, es hat etwas länger gedauert, bis ich jetzt endlich dazu gekommen bin, damit zu beginnen und anstatt mich mit dem Schnee oder dem Weihnachtsstress herauszureden, gibt es dafür erst einmal ein dickes „Sorry!“ von mir an alle, die schon länger darauf gewartet haben und vielleicht bereits mehrfach hier vorbeigeschaut haben.In dem Vortrag ging es um „Agile Worst Practices“. Eine Worst Practice ist das Gegenteil einer Best Practice, d.h. es geht um Praktiken, die sich im agilen Umfeld als schlecht erwiesen haben. Das reicht von Praktiken, die die Produktivität ungünstig beeinflussen bis hin zu absoluten „Killern“, die eine sinnvolle agile Arbeit komplett unmöglich machen.Eine solche Worst Practice kann man jetzt unter verschiedenen Gesichtspunkten betrachten und verwenden. Man kann sie einfach zu verstehen versuchen und aufpassen, dass man sie nicht in seinen eigenen Projekten verwendet. Bei einigen dieser Practices ist es nämlich so, dass sie gar nicht so offensichtlich schlecht sind, sondern dass sich ihr destruktives Potential erst bei genauerem Hinsehen offenbart.Eine andere Verwendungsweise ist – wie ironisch im Untertitel geschrieben – die Anwendung der Practices mit dem Ziel, das jeweilige Projekt zu kippen. Um jetzt evtl. Missverständnissen vorzubeugen: Das mag zwar aus persönlichen oder machtpolitischen Gründen in bestimmten Situationen opportun erscheinen, aber trotz des gewählten Untertitels war der Vortrag natürlich kein Aufruf zu solch einem aus rein egoistischen Motiven getriebenen Vorgehen.Umgekehrt kann man sich aber auch überlegen, was man gegen eine solche Practice unternimmt, wenn man mit ihr in einem Projekt konfrontiert wird, d.h. wie man sie „unschädlich“ macht.Diese verschiedenen Betrachtungs- und Verwendungsweisen spiegeln sich in der Beschreibung der einzelnen Worst Practices wider. Zunächst einmal werde ich die Practice möglichst einprägsam benennen und ihre Funktionsweise beschreiben. Danach werde ich die Konsequenzen darstellen, d.h. welche Wirkung hat die Practice. Abgeschlossen wird die Beschreibung von möglichen Maßnahmen, um der Practice entgegenzuwirken.Alle Practices entstammen übrigens realen Projekterfahrungen. Ich hatte unter meinen Kollegen – allesamt mit reichlich agiler Projekterfahrung ausgestattet – einmal herumgefragt, welche Worst Practices ihnen denn im Laufe ihrer vielfältigen Projekte begegnet seien und es sprudelte nur so. Auf diese Weise entstand eine Liste von ca. 80 Worst Practices und auch nach Bereinigung der Redundanzen blieb eine beindruckende Sammlung übrig. Das zeigt aus meiner Sicht, wie wichtig und praxisnah das Thema immer noch ist.Natürlich ist diese Sammlung nicht vollständig oder deckt das gesamte Themenspektrum gleichmäßig ab, aber das ist auch gar nicht mein Ziel. Mein Ziel ist es, eine Menge lebensnahe, dem realen Projektgeschäft entstammende Worst Practices vorzustellen und so dafür zu sensibilisieren. Es gibt auch weitere Quellen, die sich dieses Themas annehmen. Ein paar Referenzen werde ich noch am Ende der Blog-Serie nennen.Um die ganzen hier beschriebenen Practices ein wenig zu strukturieren, sind sie – soweit möglich – nach Rollen geordnet. Primär werden hier die Scrum Rollen verwendet, d.h. Product Owner, Scrum Master und Team, aber auch eine Reihe umgebender Rollen wie Kunde, Manager, User sowie der Agilitäts-Berater bzw. Coach.So, und damit das jetzt nicht nur ein „Teaser Post“ wird, hier noch die erste Worst Practice. Ich freue mich auf Eure Kommentare, Anmerkungen und Ergänzungen, aber auch über Eure eigenen Erfahrungen.Beginnen wir mit den Team Practices: Bevor wir mit dem ausgestreckten Finger auf andere Leute zeigen, ist es zunächst sicherlich sinnvoll zu schauen, welche Worst Practices uns als Team-Mitgliedern zur Verfügung stehen. Viele dieser Practices sind dabei nicht exklusiv auf das Team beschränkt, sondern können auch von anderen Personen angewendet werden.Team Worst Practice #1: Mein Wissen gehört mirBeschreibung: Anstatt mein Wissen mit anderen Team-Mitgliedern zu teilen, halte ich es sorgfältig unter Verschluss. Wenn es Aufgaben auf meinem Spezialgebiet gibt, schnappe ich sie mir sofort und passe dabei auf, dass kein anderer versteht, wie ich das gelöst habe. Meine Position im Unternehmen festige ich weiter, indem ich geeignete neue Themen annektiere, bei denen sich noch niemand auskennt und so weitere Wissensmonopole auf mir vereine. Bei all dem Konkurrenzdruck im Unternehmen und der Gefahr durch Outsourcing/Offshoring muss ich ja sehen, wo ich bleibe und meinen Arbeitsplatz sichern.Konsequenz: Es entsteht eine Wissensinsel. Eine vernünftige Selbstorganisation ist nicht mehr möglich und auch die freie Priorisierung von Tasks ist nicht mehr möglich. Alles muss rund um die „kritische Ressource“ organisiert werden und ist der Mitarbeiter mal nicht da, ist häufig gleich die ganze Iteration gefährdet. Typischerweise ist der Mitarbeiter chronisch überbucht und wird aufgrund seines Spezialwissens zwischen mehreren Projekten aufgeteilt, was eine vernünftige Team-Arbeit in den einzelnen Projekten deutlich erschwert.Maßnahmen: Wissensinseln sind schwer zu bekämpfen, weil sie zunächst einmal für alle bequem sind. Man hat sowieso mehr als genug zu tun und ist froh, dass da jemand ist, der sich um Aufgabe X kümmern kann und man sich selber nicht auch noch um das (neue) Thema kümmern muss. Die damit verbundenen Probleme versteht man meistens erst, wenn es zu spät ist.Deshalb ist es wichtig, die Probleme mit Wissensinseln frühzeitig zu erklären (Verständnis für das Problem schaffen). Hier ist insbesondere der Scrum Master gefragt, für Transparenz zu sorgen und die möglichen Konsequenzen aufzuzeigen. Neben der Transparenz sollte er auch noch darauf hinwirken, dass Maßnahmen ergriffen werden, die solchen Wissensinseln entgegenwirken. Solche Maßnahmen könnten z.B. sein:<ul><li>Aufstellen einer Team-Regel, dass jedes Thema von mindestens 2, besser 3 Personen verstanden sein muss.</li><li>Pair Programming für kritische Themen zur Regel machen.</li><li>Wenn der Scrum Master eine Wissensinsel bemerkt, auf die das Team nicht reagiert, kann er von den Team-Mitgliedern Maßnahmen einfordern, wie sie einen evtl. Ausfall von dem Mitarbeiter kompensieren wollen. Dabei kann er sie auf ihr Sprint Commitment erinnern (klingt erst einmal nicht nett, hilft aber sehr gut, die inhärente „Es wird schon gutgehen“-Attitüde zu durchbrechen).</li></ul>Das einfach mal als ein paar Ideen. Wissensinseln sind ein sehr schwieriges Thema, auch in traditionellen Projekten und es gibt keine echten Patentrezepte. Hat man sie aber erst einmal als Problem erkannt und dies für alle Beteiligten transparent gemacht, ist der erste wichtige Schritt getan.So, dieses war der erste Streich … den nächsten Post in dieser Serie findet Ihr <a href="http://blog.codecentric.de/2011/01/agile-worst-practices-2/">hier</a> .PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind immer herzlich willkommen!

Agile Worst Practices – Teil 1

So, nach einer kleinen Pause über die Feiertage und den Jahreswechsel begrüße ich Euch zum nächsten Post aus der Serie Agile Worst Practices, die ich mit <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">diesem Post</a> begonnen hatte. Wir bleiben bei den Worst Practices für das Team:Team Worst Practice #2: Wer zu spät kommt, gewinntBeschreibung: Und noch ein Meeting. Und das jeden Tag! Als wenn ich nicht etwas Besseres zu tun hätte! Na gut, ich komme dann halt, auch wenn es nichts bringt, aber dadurch lasse ich mich nicht bei den wichtigeren Dingen, wie z.B. dem Entwickeln stören. Und wenn ich dann erst fünf Minuten später komme, dann ist das halt so. Und Zeit für eine neue Tasse Kaffee vorher muss sowieso sein, egal ob es dem Scrum Master nun passt oder nicht.Konsequenz: Das Daily Scrum ist, wie es der Namen schon sagt, ein Meeting, das jeden Tag stattfindet und die Akzeptanz eines täglich stattfindenden Meetings steht und fällt extrem mit der Dauer des Meetings. Dabei kommt es auf Minuten an. 10-15 Minuten werden in der Regel problemlos akzeptiert, 20 Minuten werden schon kritisch und spätestens bei einer durchschnittlichen Dauer von 30 Minuten ist es mit der Akzeptanz ganz schnell vorbei.Wenn die pünktlichen Teilnehmer durch das regelmäßige Warten auf einen chronischen Zuspätkommer dann immer erst 5-10 Minuten warten müssen, bevor das Meeting anfängt, dann dauert das Meeting für sie entsprechend länger, d.h. in der Regel zu lang. Zusätzlich ist ein tagtägliches Warten sehr entnervend, allein schon unter dem Gesichtspunkt, dass – wenn nicht dagegen gesteuert wird – die pünktlichen Team-Mitglieder durch das erzwungene Warten „bestraft“ werden, während der Zuspätkommer in seiner Handlungsweise bestätigt wird, da er als einziger nicht warten muss.Die Konsequenz ist eine wachsende Unzufriedenheit bei den anderen Team-Mitgliedern für das Daily Scrum, die sich zur Unlust oder im Extremfall bis zur vollständigen Ablehnung auswachsen kann.Maßnahmen: Wie bereits geschrieben ist ein regelmäßiges Zuspätkommen beim Daily Scrum absolut keine Option. Entsprechend ist es Aufgabe des Scrum Masters, da aktiv gegenzusteuern. Er muss auf einen pünktlichen Beginn bestehen und regelmäßige Zuspätkommer entsprechend verwarnen. Auch das Team darf den Zuspätkommer in die Pflicht nehmen, schließlich ist es auch ein Zeichen mangelnden (positiven) Respekts gegenüber den Kollegen, wenn man sie regelmäßig warten lässt.Eine weitere wichtige Maßnahme ist, pünktlich zu beginnen, zum einen, um der sinkenden Akzeptanz des Meetings entgegenzuwirken, zum anderen aber auch rein psychologisch, denn so werden die Pünktlichen für ihre Pünktlichkeit „belohnt“, während die Zuspätkommer das Nachsehen haben.Sollte der Zuspätkommer überhaupt kein Einsehen zeigen, dann empfiehlt sich als Ultima Ratio darüber nachzudenken, die Person aus dem Team zu entfernen, da sie in dem Fall nüchtern betrachtet für ein agiles Team eigentlich nicht tragbar ist … aber so pathologische Fälle sollten hoffentlich nur selten vorkommen.Zum Abschluss des Posts noch ein wenig Verlinkung:<ul><li>Den Link zum ersten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">hier</a> .</li><li>Den Link zum nächsten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2011/02/agile-worst-practices-3/">hier</a> .</li></ul>PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

Agile Worst Practices – Teil 2

Willkommen zum nächsten Post aus der Serie Agile Worst Practices, die ich mit <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">diesem Post</a> begonnen hatte. Wir bleiben bei den Worst Practices für das Team und greifen ein häufiges Missverständnis im agilen Umfeld auf:Team Worst Practice #3: Alles ist selbstorganisiertBeschreibung: Wir als Team sind ja selbstorganisiert. Uns hat keiner etwas vorzuschreiben und wir wissen selber am besten, was für uns gut ist. Feste Regeln gelten für uns nicht, sondern wir klären basisdemokratisch, was wir unter agilem Vorgehen verstehen und wie wir das machen wollen. Auch Scrum ist ja eher so eine Art Empfehlung als eine Methode und wir diskutieren ausführlich in jedem Sprint, wie wir das machen wollen. Schließlich sind die Retrospektiven doch dafür da, dass wir unsere Methode nach jedem Sprint (und bei Bedarf auch während des Sprints) ändern können, oder?Konsequenz: Das Konzept der Selbstorganisation ist vielfach falsch verstanden worden und wird leider auch bis heute noch vielfach falsch vermittelt. Zunächst einmal bedeutet Selbstorganisation nicht komplette Anarchie und Team Empowerment bedeutet auch nicht Basisdemokratie. Es gibt sehr wohl feste Regeln und Ziele, die von außen vorgegeben werden und die ein Team erfüllen muss. Die Selbstorganisation findet innerhalb dieser Regeln und Ziele statt. Die Regeln und Ziele hingegen sind fest und können vom Team nicht nach Belieben umdefiniert werden.Ein einmal gewähltes Vorgehen wie z.B. Scrum gehört zu den festen Regeln und kann (und sollte auch) nicht nach Belieben geändert werden. Es ist Aufgabe des Scrum Masters, dafür zu sorgen, dass die entsprechenden Regeln eingehalten werden. Tut man das nicht, hat man das große Problem, dass die initiale Lernphase fehlt, in der man versteht, welche Wirkungen die verschiedenen Regeln von Scrum haben. Nicht ad hoc offensichtliche Auswirkungen von Regeln werden nicht verstanden, sie werden mangels Verständnis in der Regel frühzeitig verworfen und es werden typischerweise bequemere, aber auch suboptimale Alternativen eingesetzt.In Summe führt das Vorgehen typischerweise zu geringerer Produktivität, einmal weil viel Zeit und Energie für die Diskussionen über das Vorgehen verbraucht werden und andererseits, weil das Vorgehen weniger gut ist. Zusätzlich birgt das Vorgehen die Gefahr, dass sich das Verfahren nicht stabilisiert, sondern zu einem dauerhaften Ausprobieren führt.Maßnahmen: Hier ist insbesondere der Scrum Master gefragt. Er muss die nicht diskutierbaren Anteile des Vorgehens klar kommunizieren und die Einhaltung forcieren. Bei den ergänzenden Anteilen (z.B. das verwendete Schätzverfahren) muss er auch dafür sorgen, dass sich zunächst auf ein Verfahren geeinigt wird und das auch eine Zeitlang ohne Diskussion gelebt wird. Zusätzlich sollte er das Team auf eine Lernphase ohne Diskussion der Vorgehensweise einschwören.Für ein erstes Scrum-Projekt sind dafür mindestens 6 Sprints, eher noch einige Sprints mehr zu empfehlen. Nach dieser Lernphase hat das Team dann genug Erfahrung mit der Methode sammeln können, um qualifiziert beurteilen zu können, an welchen Stellen Optimierungen möglich und sinnvoll sind. Aber auch dann noch muss der Scrum Master darauf achten, dass keine von außen vorgegebenen Regeln und Ziele angefasst werden, denn diese sind wie bereits geschrieben fest bzw. müssen in Fällen von Problemen in Form von Impediments angegangen werden und können nicht einfach eigenmächtig vom Team angepasst werden.Zum Abschluss des Posts wie immer noch ein wenig Verlinkung:<ul><li>Den Link zum ersten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">hier</a> .</li><li>Den Link zum nächsten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2011/02/agile-worst-practices-4/">hier</a> .</li></ul>PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

Agile Worst Practices – Teil 3

Willkommen zum vierten Post aus der Serie Agile Worst Practices, die ich mit <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">diesem Post</a> begonnen hatte. Wir bleiben bei den Worst Practices für das Team und greifen ein Problem auf, das es auch außerhalb der agilen Welt gibt, im agilen Kontext aber noch größeres Schadenspotential entwickelt:Team Worst Practice #4: Bloß keinen KundenkontaktBeschreibung: Diese Worst Practice gibt es in verschiedenen Ausprägungen. Allen gleich ist die Grundeinstellung: „Ich weiß eh am besten, was der Kunde braucht“. Entsprechend ist es ja nicht notwendig, mit dem Kunden, dem Anwender oder auch nur dem Product Owner zu sprechen – alles vertane Zeit, in der man ja schon etwas programmieren könnte. Mehrwert produzieren ist doch die goldene Regel der Agilität, oder?Und da lenken Kunden und ähnliche Nicht-Experten einfach nur ab. Nicht nur, dass sie die Dinge einfach nicht vernünftig formulieren können, sie wissen doch gar nicht, was sie wollen. Da muss doch einfach mal ein Experte ran und denen zeigen, was sie brauchen.Gleiches gilt auch für Fachkonzepte und ähnlichen Ballast (im Lean-Jargon auch gerne „Waste“ genannt oder von den ganz hippen Agilisten „Muda“ – japanisch für sinnlose Verschwendung). Wozu sollte ich meine Zeit damit verschwenden, womöglich auch noch vor einer Schätzung? Ich weiß es eh besser!Konsequenz: Man muss kein Hellseher sein, um vorauszusagen, dass das Ergebnis bei einem solchen Verhalten mit hoher Wahrscheinlichkeit nicht den Erwartungen des Kunden entsprechen wird. Auch wenn der Kunde bzw. Anwender sich in der Tat manchmal schwertun, ihre Vorstellungen „auf den Punkt“ zu bringen und sie (aus verschiedenen, meist nachvollziehbaren Gründen) während der Entstehung einer Funktionalität auch einmal ihre Meinung ändern, so sind sie letzten Endes dennoch die einzigen, die sagen können, was sie benötigen, um ihre Aufgabe zu erfüllen.Bezieht man sie bei der Umsetzung nicht in die Lösungsfindung mit ein, so wird man normalerweise eine suboptimale Lösung realisieren, die dem Kunden/Anwender nicht oder nur eingeschränkt hilft, seine Aufgaben möglichst effizient und effektiv zu erfüllen.Häufig führt ein solches Vorgehen auch zu geringerer Qualität des Ergebnisses, weil benötigten Qualitätsanforderungen nicht wahrgenommen und damit auch nicht umgesetzt werden. Oder um es einfach zu formulieren: Das Ergebnis ist technisch vielleicht top, aber fachlich ein „Flop“.Maßnahmen: Häufig ist der Grund für eine solche Einstellung nicht Arroganz, wie man zunächst vermuten könnte, sondern eher Unsicherheit. Es besteht eine große (gefühlte) Distanz zwischen dem Kunden/Anwender und dem Entwickler im Team. Und da viele Leute sich schwertun, eine solche Distanz von sich aus abzubauen, sollte man da unterstützen.Eine gute Maßnahme ist z.B. ein gemeinsames Kick-Off, möglichst in einem nicht zu formalen Rahmen, damit die Leute Zeit haben, sich gegenseitig ein wenig kennenzulernen. Auch ein gemeinsames Projekt-Event nicht zu spät während des Projektes wirkt oftmals echte Wunder.Eine etwas kleinere Maßnahme ist, das Team zu den Sprint-Demos mitzunehmen und es die Demo selber durchführen zu lassen, inklusive der Diskussionen, die sich häufig bei der Demo ergeben. Nebenbei ist das sowieso meistens eine gute Idee, wird nur häufig nicht gemacht, weil sich die Kosten dafür über die Sprints hinweg summieren, vor allem, wenn der Kunde nicht um die Ecke sitzt. Diese Kosten werden dann gerne eingespart und nur der Scrum Master oder der Product Owner, ggf. mit einem weiteren Senior machen die Demo. Lässt man das Team die Demo machen, so fungieren Scrum Master bzw. Product Owner nur als Moderator.Und sollten diese Maßnahmen nicht fruchten und die Distanz wird vom Team oder einzelnen Personen daraus aufrecht erhalten, kann man ggf. auch noch ein fachliches Design einfordern, um die betreffenden Personen mehr oder minder dazu zu zwingen, sich mit der Fachlichkeit und den Anforderungen auseinanderzusetzen. Natürlich muss in dem Fall auch sichergestellt sein, dass jemand zur Verfügung steht, der dieses Design auch validieren kann.Zum Abschluss des Posts wie immer noch ein wenig Verlinkung:<ul><li>Den Link zum ersten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">hier</a> .</li><li>Den Link zum nächsten Post dieser Serie findet Ihr hoffentlich in Bälde hier … 😉</li></ul>PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

Agile Worst Practices – Teil 4

Ich lese immer wieder Aussagen wie „wirklich neu ist Cloud nicht“ oder härter formuliert „das ist doch nur alter Wein in neuen Schläuchen“.Ja, das kann man so sehen, aber ich tue mich etwas schwer mit diesen Aussagen. Warum?Disruptive Innovationen (also Innovationen, die wirklich etwas verändern) benötigen keine grundlegend neue Ideen. Tatsächlich bestanden die wenigsten Innovationen, die wirklich etwas verändert haben, aus komplett neuen Ideen.Egal, ob Ford T, der PC, das viel geliebte und gehasste MS Windows oder die Smartphones … alles keine neuen Ideen, sondern eine Rekombination bekannter Ideen zum richtigen Zeitpunkt, d.h. der Markt war reif dafür, sowohl von der Bedarfsseite als auch von der Fähigkeit, das „neue“ Produkt in hinreichender Qualität zu liefern. Als Gegenbeispiel war z.B. der Apple Newton sicherlich ein tolles Gerät, aber der Markt war noch nicht reif dafür.Das „revolutionäre“ an der Cloud sind also nicht die Bestandteile, sondern deren Kombination und der Zeitpunkt.Für mich ist das wirklich innovative an der Cloud diese Kombination aus Elastizität, flexiblen Preismodellen (bis hin zum häufig genutzten Pay-per-Use), Customer self service und Instant delivery. Ja, jede einzelne Idee gab es früher schon, aber in dieser Kombination ist es neu, eine echte Innovation mit disruptivem Potential.Das ist ein wenig so wie mit einem hervorragenden Essen: Die Zutaten sind alle altbekannt, kann sich jeder auf dem Markt oder im Supermarkt seines Vertrauens besorgen, aber ihre Kombination und die Zubereitung machen es zu etwas Außergewöhnlichem. Ich weiß, der Vergleich hinkt ein wenig, weil ein hervorragendes Essen nicht wirklich einen geeigneten Zeitpunkt benötigt. Da wären wir dann eher beim Fast-Food, was zu seiner Zeit eine disruptive Innovation war … nur, ob das viel mit hervorragendem Essen zu tun hat? … 😉Aus den genannten Gründen tue ich mich mit den eingangs genannten Aussagen etwas schwer. Der Innovationscharakter einer Idee hängt nicht von der Innovativität der Bestandteile, sondern von ihrer Kombination ab … und natürlich stark vom Zeitpunkt.So gesehen erfüllt die Cloud für mich die Voraussetzungen für eine echt disruptive Innovation. Ob sie es letztlich auch sein wird, werden wir sehen, wenn sich der sie umgebende Hype-Nebel ein wenig gelichtet haben wird …

Ist die Cloud innovativ oder alter Wein in neuen Schläuchen?

Es sind die Weihnachtsfeiertage und wie viele andere Leute nutze ich die Zeit, um ein wenig abzuschalten – keine großen Verwandschaftsbesuche, keine große Urlaubsreise, nur ein wenig zu Hause abhängen und dabei darauf achten, nur nicht zu viel zu tun. Aber wie viele andere Leute beginne ich nach den ersten Tagen, seltsame Dinge zu machen, konkret hier und da Dinge aufzuräumen, die die ganze Zeit liegengeblieben sind. So habe ich heute morgen Zeit damit verbracht, mein Büro zu Hause ein wenig auszumisten.Dabei bin ich über einige Notizen gestolpert, die ich mir 2008 bei der <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference in London</a> gemacht habe. Auch wenn es eine großartige Konferenz gewesen war, habe ich entschieden, dass ich die meisten der Notizen nicht mehr benötige und sie in den Müll geworfen. Aber ein Satz auf einer der Seiten ließ mich für eine Zeitlang innehalten. Ich glaube, es war ein Satz aus einer Keynote, die David Robertson, ein Professor aus der Schweiz gehalten hat. Der Satz erschien mir damals offenbar so wichtig, dass ich ihn mir notiert habe (Ich bin kein großer Notizen-Schreiber, deshalb muss mir der Satz wichtig erschienen sein).Der Satz lautete: „Architektur ist ein Kompass, kein Blueprint“. In Klammern hatte ich noch „Überdenken!“ dazugeschrieben, als ein Hinweis für mich, noch einmal über diesen Satz nachzudenken. Nun hat es letztlich mehr als 3 Jahre gedauert, bevor ich dazu gekommen bin, über den Satz noch einmal nachzudenken und aus heutiger Sicht bin ich der Meinung, dass der Satz wirklich wichtig ist – einer dieser zeitlos wahren Sätzen.Aus meiner heutigen Wahrnehmung beschreibt der Satz perfekt, was Architektur sein sollte und was nicht. Architektur sollte eine Orientierungshilfe in Richtung der richtigen Lösung sein, in einer fürchterlich komplexen Umgebung, in der bereits „richtig“ eine extrem komplexe Sache ist, die alles andere als offensichtlich und nur schwer zu bestimmen ist. Daher sollten wir die Umgebung von Zeit zu Zeit von verschiedenen weiter entfernten (d.h. abstrakteren) Standpunkten betrachten, einzig und allein mit dem Ziel, danach zurückzukommen und zu sagen „Basierend auf dem, was ich da drüben gesehen habe, denke ich, dass es eine gute Idee ist, diesem Pfad da eine Weile zu folgen“.Danach machen wir dann die nächsten Schritte und dann schauen wir wieder, um über die nächsten Schritte zu entscheiden und so weiter: Architektur als ein Kompass. Wir können in der Regel zu Beginn keine vollständige Karte (d.h. einen Blueprint) von unserer Umgebung erstellen. Die Umgebung ist dafür viel zu komplex. Und üblicherweise benötigt man diese große, umfassende Karte auch überhaupt nicht. Üblicherweise reicht es, sich ein paaer Aufzeichnungen über die grundlegenden Wahrnehmungen von den verschiedenen, weiter entfernten Standpunkten zu machen (Überblicksbilder und High-level Konzepte) plus Begründungen für die wichtigsten Entscheidungen – für den Fall, dass man einmal zu der Stelle zurückkommt und nachvollziehen möchte, warum man sich damals so entschieden hat.Architektur als Kompass hat auch noch eine zweite Bedeutung: Architektur ist dynamisch, nicht statisch. Architektur ist kein Ziel oder Ergebnis, sie ist Teil eines Wegs. Sie verändert sich über die Zeit. Sie entwickelt sich. Sie verändert sich, wenn sich die Umgebung verändert, sie verändert sich, wenn Du etwas aus Deinen vorherigen Schritten dazugelernt hast. Während eine veraltete Karte keinerlei Nutzen mehr hat, bleibt ein Kompass immer hilfreich – aber natürlich nur, wenn man akzeptiert, dass er keine Lösung ist, sondern nur ein wertvolles Hilfsmittel, um den richtigen Weg auf einer Reise durch unbekanntes, komplexes Terrain zu finden.Ich denke, wir könnten auch einige dieser ermüdenden Diskussionen über Architektur beenden – insbesondere im Zusammenhang mit Agilität – wenn wir alle diesen einen Satz akzeptieren würden: „Architektur ist ein Kompass, kein Blueprint“. Architektur ist keine Karte zur Lösung, sie ist ein Hilfsmittel, um den richtigen Weg zu finden.Es gäbe sicherlich noch eine Menge mehr über diesen Satz zu schreiben, aber es sind die Weihnachtsfeiertage und ich wollte nicht zu viel tun … 😉

Architektur ist ein Kompass, kein Blueprint

Ihr fragt Euch vielleicht, was emergente Architektur mit Skalierbarkeit und Fehlertoleranz zu tun haben. Nun, um ehrlich zu sein: Gar nichts. Mit diesem kurzen Blog Post möchte ich nur kurz auf ein paar meiner kürzlich gehaltenen Vorträge hinweisen, die ich jetzt endlich auf Slideshare hochgeladen habe.Da ist zunächst eine neue Präsentation über Muster für fehlertolerante Systeme im Kontext von Scale-Out-Lösungen: <div> <a href="http://www.slideshare.net/ufried/no-crash-allowed-fault-tolerance-patterns" target="_blank">No crash allowed – Fault tolerance patterns</a> <div><div><div>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.<a href="#">Inhalt laden</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>Vor einigen Tagen habe ich außerdem eine verwandte Präsentation über Muster für hochskalierbare Systeme hochgeladen:<div> <a href="http://www.slideshare.net/ufried/scalability-patterns" target="_blank">Scalability patterns</a> <div><div><div>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.<a href="#">Inhalt laden</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>Und letztlich möchte ich noch eine Präsentation über die Möglichkeiten und Grenzen emergenter Architektur erwähnen, die ich ebenfalls vor einigen Tagen hochgeladen habe:<div> <a href="http://www.slideshare.net/ufried/emergent-architecture-12620741" target="_blank">Emergent architecture</a> <div><div><div>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.<a href="#">Inhalt laden</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>Wie immer fehlt die „Tonspur“, aber ich habe versucht, die Folien auf eine Art und Weise zu gestalten, dass sie ohne den begleitenden Text nicht komplett nutzlos sind.Und ebenfalls wie immer bin ich an Eurer Meinung und Feedback interessiert. Solltet Ihr also irgendwelche Kommentare zu den Folien haben – immer her damit …

Skalierbarkeit, Fehlertoleranz und emergente Architektur

Vom 5.11.2012 bis zum 9.11.2012 öffnete wie bereits seit mehreren Jahren die W-JAX in München ihre Pforten – fünf Tage randvoll mit Vorträgen, Tutorien, Diskussionen, Ausstellung und Neuigkeiten rund um Java-basierte Enterprise- und Web-Anwendungen im weitesten Sinne.Ich hatte dort die Gelegenheit, mehrere Vorträge zu halten, von denen 3 aufgenommen worden sind und die demnächst online gestellt werden. Die Links dazu werde ich nachreichen.Außerdem hat Mirko Schrempp, seines Zeichens Chef-Redakteur des BusinessTechnology Magazins, ein Interview zu den Themen agile Architektur und den Konsequenzen des Wirtschaftsdarwinismus auf die Software-Entwicklung mit mir geführt. Das Ergebnis findet Ihr <a href="http://it-republik.de/jaxenter/news/Hektische-Zeiten-fuer-Architekten-065578.html" target="_blank">hier</a> . Zwischen meinen Vorträgen und vielen spannenden Unterhaltungen und Diskussionen mit vielen interessanten Personen hatte ich noch die Gelegenheit, mir den ein oder anderen Vortrag anzuschauen. Sehr erfreulich fand ich dabei, dass kein einziger Totalausfall bei den Vorträgen dabei war. Ich war durchweg positiv von der Qualität der Vorträge angetan. Natürlich hätte ich mir bei dem ein oder anderen Vortrag noch etwas mehr Tiefe gewünscht, aber bei durchschnittlich 60 Minuten pro Vortrag ist häufig einfach nicht mehr möglich.Meine persönlichen, garantiert komplett subjektiven Highlights waren:<ul><li>Manuel Küblböck und Doreen Timm von it-agile erzählten im Rahmen des Agile Day von ihren Erfahrungen mit einem Start-Up-Experiment, in dem versucht wurde, ein neues Produkt nach den Ideen von Lean Startup zu entwickeln. Der Vortrag bestand aus einer gut balancierten Mischung aus „Theorie“, sprich einer Vermittlung diverser Lean-Startup-Konzepte und „Praxis“, d.h. Erfahrungen, die sie in ihrem Selbstversuch gesammelt haben.</li><li>Stefan Tilkov (innoQ) und Gernot Starke haben einige Nicht-Mainstream-Sprachen, nämlich Prolog, Clojure, Erlang und Node.js (Java-Script auf einer speziellen Server-Engine) vorgestellt und dabei versucht zu vermitteln, was man aus diesen Sprachen und den damit verbundenen Laufzeitumgebungen für den Mainstream mitnehmen kann. Nun, 4 Sprachen in 60 Minuten waren eh schon eine Herausforderung. Dazu kam dann noch die Begeisterung, die die beiden Vortragenden ganz offensichtlich für die genannten Sprachen hegten, so dass sie die 60 Minuten locker gerissen haben … was ihnen aber niemand übel genommen hat. Die Begeisterung war ansteckend und außerdem konnte jeder die ein oder andere neue Idee für sich mitnehmen. Ich als alter Lisp-Liebhaber habe mir mal wieder auf meinen Merkzettel geschrieben, mir jetzt endlich mal Clojure in Ruhe anzuschauen. Seit gut eineinhalb Jahren nehme ich es mir immer wieder vor, aber immer kommt mir irgendwas dazwischen … aber nach dem Vortrag: Jetzt aber wirklich … 😉</li><li>Und noch einmal Stefan Tilkov, der über fortgeschrittene REST-Konzepte erzählt hat. Primär ging es in dem Vortrag um das HATEOAS-Konzept (Hypermedia As The Engine Of Application State). Ich spare mir jetzt, das genauer zu erläutern (Google hilft da besser als ich es jemals könnte), aber der Vortrag hat mir noch einige Anregungen gegeben, wie ich die derzeitige <a href="https://www.centerdevice.de/" target="_blank">CenterDevice</a> -REST-API in eine selbsterklärende, HATEOAS-konforme API transformieren könnte. Nebenbei könnte ich so auch das enervierende Pflegen der API-Dokumentation loswerden, indem alle Dokumentation letztlich in den Code wandert, mit dem netten Nebeneffekten, dass zum einen die Dokumentation genau beim Code steht und zum anderen, dass die Kollegen der CenterDevice-Entwicklung eher einmal bereit sind, die Dokumentation mit nachzupflegen, weil es dann auch möglich ist, ohne die geliebte IDE zu verlassen … mal sehen, was die Kollegen dazu meinen, wenn ich ihnen meine Ideen erzähle … 🙂</li><li>Am Mittwoch gab es gleich zwei interessante Keynotes. Zuerst hat Wolfgang Henseler über Natural User Interfaces (NUI) erzählt, die Art von Benutzerschnittstellen, die sich mit Smartphones und Tablets etablieren. Seiner Meinung nach wird der Übergang von GUI zu NUI ähnlich weitreichende Auswirkungen für die Mensch-Maschine-Schnittstelle und die Art, wie Menschen mit Programmen interagieren, haben wie seinerzeit der Übergang von der Kommandozeile zum GUI. Auch ich denke, dass da noch einiges an Umlernen bzw. Dazulernen (bzw. Verlernen der jahrelang antrainierten GUI-Best-Practices) gefordert ist, damit wir richtig gute NUIs entwickeln werden. Die zweite Keynote war übrigens von Dierk König und Gerrit Grunwald (bei Canoo), die in einer Neuauflage eines Formats, das sie bereits auf der JAX verwendet haben, zwei ihrer persönlichen IT-bezogenen Steckenpferde vorgestellt haben – jede Menge Spaß inklusive.</li><li>Last, but not least gab es am Donnerstag noch eine Keynote über Git Culture von Matthew McCullough. Auch wenn Matthew in seinem ungezügelten Redefluss ganz offensichtlich vergessen hatte, dass er vor einem non-native-Publikum gesprochen hat und damit sicherlich den ein oder anderen Zuhörer überfordert hat, so hat er doch einige interessante Konzepte von GitHub erzählt, das praktisch ohne Management geführt wird. Mir hat sich da die Frage gestellt, wie weit man das auf andere Unternehmen übertragen kann und ob es dafür bestimmte Voraussetzungen bei den Mitarbeitern gibt. Von der organisatorischen Seite her sind aus meiner Sicht auf jeden Fall die vollständige Transparenz (inklusiver aller Finanzdaten) und die volle kommerzielle Verantwortung bei allen Mitarbeitern kritische Schlüsselfaktoren. Ohne vollständige Informationen und volle Verantwortung bei allen Mitarbeitern kann es nicht funktionieren – nach dem Motto: „Bei uns ist jeder CEO“. Wie geschrieben, bin ich mir ehrlich gesagt nicht sicher, inwiefern ein solcher Ansatz auf eine beliebige Personengruppierung übertragbar ist, aber spannend finde ich den Gedanken allemal.</li></ul>Das waren meine persönlichen Highlights. Das heißt jetzt nicht, dass die Vorträge, die ich nicht erwähnt habe, schlechter gewesen wären … so eine Liste ist halt immer sehr subjektiv … spannend waren die ganzen Tage, ob mit oder ohne Vorträge.

W-JAX Nachlese …

Derzeit sind drei Megatrends auszumachen, die die IT zu einem dramatischen Wechsel zwingen:<ul><li>Wirtschaftsdarwinismus</li><li>Digitalisierung</li><li>Disruptive Technologien</li></ul>Alle drei sind außerordentlich wichtig und Firmen, die diese Trends ignorieren, werden früher oder später hinter ihren Konkurrenten zurückbleiben (zumindest solange diese Firmen in einem effizienten Markt leben – nichteffiziente Märkte sind eine andere Geschichte).<h2>Märkte im Wandel</h2>Kommen wir zum ersten Trend und beginnen mit einer kurzen Erläuterung: „Darwinismus“ bedeutet kurz gesagt „Nur die Besten überleben“ (Survival of the fittest) – der „Beste“ ist nicht der Stärkste, sondern derjenige, der sich schnell genug an die Anforderungen der Umgebung anpassen kann.<div><a href="https://media.graphassets.com/exFeyoUVT2CIMk8PkPbZ"><img src="https://media.graphassets.com/exFeyoUVT2CIMk8PkPbZ" alt="Wirtschaftsdarwinismus, Digitalisierung und disruptive Technologien setzen die IT unter Druck" width="250" height="188" /></a> Mega-Trends setzen die IT unter Druck und erzwingen damit einen fundamentalen Wandel</div>Das gilt auch für Firmen: Nur die Firmen, die sich schnell genug an die sich ändernden Ansprüche und Forderungen ihrer Kunden anpassen können, werden auf lange (oder auch nur kurze) Sicht überleben.Nun könnten Sie fragen: „Hey, was ist daran neu? Das ist doch schon immer so in der Wirtschaft.“ Und Sie hätten recht.Entscheidend ist, dass die Märkte, in denen die meisten Firmen agieren, vor einigen Jahren einen drastischen Wandel erfahren haben. Fast ein Jahrhundert lang waren die meisten Märkte weit, nahezu unbeschränkt und träge: Die Nachfrage war immer größer als das Angebot und die größte Herausforderung für die Firmen in diesen Märkten war es, die Produktion ihrer Waren möglichst kosteneffizient zu skalieren.Das änderte sich in den 1980ern: Langsam aber sicher wurde ein Markt nach dem anderen immer enger. Globalisierung, Marktsättigung und das Internet haben zu stark konkurrierenden und dynamischen Märkten geführt. (Tatsächlich gab es noch mehr Triebkräfte für den Wandel im Markt, doch das würde den Rahmen dieses Blogposts sprengen.) Die Märkte wurden stark bedarfsgesteuert und die neue größte Herausforderung der Firmen war, sich an die veränderten Bedürfnisse der Kunden schnell genug anzupassen. Die entscheidende Triebkraft wechselte von „kosteneffiziente Skalierung“ zu „Reaktionsfähigkeit“.<h2>Veränderte Rolle der IT</h2>Nun könnten Sie sagen: „Gut, das weiß ich alles. Doch was hat das mit IT zu tun?“Die Sache ist die, dass Business und IT heutzutage eng miteinander verflochten sind. Man kann sie nicht mehr unabhängig voneinander betrachten, selbst wenn alles ganz anders begann:Wenn Sie an die Beziehung zwischen Business und IT in den 1950ern und 1960ern denken, unterstützte die IT winzige Bruchteile der Geschäftsfunktionen – einen kleinen Bericht hier, eine kleine Analyse da. Das geschah ziemlich selektiv, da die damalige Rechenleistung der Mainframes recht beschränkt war (jedes moderne Mobiltelefon hat um Größenordnungen mehr Rechenleistung als die Computer in den 1960ern).Dennoch war es für die Geschäftsabteilungen ziemlich angenehm, die Berichte und Analysen nicht mehr per Hand erstellen zu müssen. Und sie wollten mehr davon haben – was schließlich zur Softwarekrise führte: Der Bedarf an Software überstieg deutlich das Angebot.Die Reaktion auf die Softwarekrise war die Erfindung des Software-Engineering: eine Ingenieurs-Disziplin mit dem Ziel, die Produktion von Software kosteneffizient zu skalieren. Klingt vertraut, nicht wahr? Die Industrialisierung stand Anfang des 20ten Jahrhunderts vor einem sehr ähnlichen Problem und der damalige Lösungsansatz war Taylorismus in seinen verschiedenen Varianten. Es dürfte also nicht überraschen, dass das Software-Engineering viele tayloristische Konzepte und Praktiken aufgegriffen und auf die Softwareentwicklung übertragen hat.Und damals war das auch vollkommen in Ordnung. Doch mit der Zeit hat sich die Rolle der IT essentiell gewandelt. In den 1980ern begann der Siegeszug des PC und Netzwerke gewannen an Bedeutung. Das mooresche Gesetz wirkte weiter, Computer wurden immer leistungsfähiger. Letztlich unterstützte die IT nicht mehr nur ausgewählte Geschäftsfunktionen, sondern zunehmend die Geschäftsprozesse im Ganzen. Sie rutschte immer näher an das Business mit all seiner Komplexität.Diese Entwicklung ging weiter, das Internet begann seinen Siegeszug in den 1990ern und mittlerweile ist die IT das Nervensystem jeder nichttrivialen Firma: Das gesamte Businesswissen ist in IT codiert, IT-Ausfälle von nur wenigen Stunden gelten für viele Firmen als existenzbedrohend. Das bedeutet aber auch, dass Sie Ihr Business nicht mehr ändern können – weder neue Produkte noch neue Features oder Prozessänderungen –, ohne die IT anzufassen.<h2>The Need for Speed</h2>Wenn man die oben beschriebenen Beobachtungen zusammenfasst, zeigt sich, dass die IT zu einem entscheidenden Erfolgsfaktor für jede Firma geworden ist, um im Wirtschaftsdarwinismus bestehen zu können. Egal wie gut Sie die die Bedürfnisse und Forderungen Ihrer Kunden kennen, wenn Ihre IT nicht schnell genug liefern kann, werden Sie das Nachsehen haben.Dennoch klammern sich die meisten Firmen an die Ideen des herkömmlichen Software-Engineering, wo es das primäre Ziel ist, die Produktion von Software kosteneffizient zu skalieren. Das Problem ist, dass Skalierung der Softwareproduktion und IT-Kosteneffizienz nicht mehr die entscheidendsten Treiber sind (tatsächlich schreiben wir heutzutage viel zu viel Software, es dauert nur zu lange und sehr oft ergibt sich nur ein Bruchteil des erwarteten Mehrwerts).Der entscheidendste Treiber für die heutige IT sind Durchlaufzeiten – wie lange es dauert, um eine Idee zum Kunden zu bringen. Es geht also um die erforderliche Zeit, um die gesamte IT-Wertschöpfungskette zu durchlaufen, beginnend beim Aufnehmen der Anforderungen bis die Lösung live in der Produktion läuft.Je kürzer diese Durchlaufzeiten sind, desto besser kann man sich an den sich ständig verändernden Bedarf der hochdynamischen Märkte anpassen. Wir brauchen „Speed“!<h2>Verschärfte Bedingungen</h2>Wenn wir uns den zweiten Megatrend – die Digitalisierung – ansehen, wird es noch etwas schwieriger: Mit Digitalisierung wird die IT das Business nicht mehr nur unterstützen, sondern selbst zum Business. Wir erzeugen neue Businessprodukte, die teilweise oder gänzlich aus IT bestehen. Auf der einen Seite verlangt das nach Innovation, da wir gerade erst verschwommene Ideen entwickeln, welche zukünftigen Geschäftsmodelle Trends wie z.B. das Internet der Dinge (Internet of Things, IoT) ermöglichen werden. Andererseits bedeutet das, dass unsere IT noch robuster als zuvor sein muss, da auch unsere Kunden ständig damit in Berührung kommen.Der dritte Megatrend sind disruptive Technologien wie Cloud-Computing, Mobile Services, Big Data und IoT. Diese Technologien eröffnen ganz andere Möglichkeiten, um Geschäftsanforderungen umzusetzen, bis hin zu einer Ebene, wo sie vollständig neuartige Geschäftsmodelle ermöglichen. Da wir aber gerade erst begreifen, was wir mit diesen Technologien anstellen können, verschärfen sie die oben beschriebenen Bedingungen:Wir müssen verstehen und lernen, wir müssen Innovation treiben, wir müssen uns an die sich ständig ändernden Märkte anpassen und das Ganze muss schnell geschehen, wobei wir die neuen Möglichkeiten disruptiver Technologien berücksichtigen müssen. Und wir werden nicht erfolgreich sein, wenn wir uns dabei an Ideen klammern, die vor vielen Jahren in einer gänzlich anderen Geschäfts- und IT-Ära entwickelt wurden.Wir müssen IT neu denken!<h2>IT neu denken</h2>Dies war die Kurzversion der langen Geschichte, warum Durchlaufzeiten zum wichtigsten Treiber für die heutige IT geworden ist, warum wir IT neu denken müssen.Doch wenn das alte Wissen, auf der wir immer noch die meisten unserer IT-Prozesse und Arbeitsabläufe aufbauen, nicht geeignet ist, um IT neu zu denken, was ist es dann?<div><a href="https://media.graphassets.com/k50qhCrQR1aorXMqAVab"><img loading="lazy" src="https://media.graphassets.com/k50qhCrQR1aorXMqAVab" alt="DevOps, Continuous Delivery, Microservices und Cloud-basierte Infrastruktur als Kernbausteine einer neuen IT" width="250" height="188" /></a> Kernbausteine einer neuen IT, die auf die veränderten Treiber reagiert</div>Das ist eine durchaus berechtigte Frage. Ein guter Ausgangspunkt sind üblicherweise Organisation und Prozesse: Die Organisations- und die Systemtheorie haben gezeigt, dass sich dezentrale Organisationen mit vorwiegend autonomen Einheiten viel besser und deutlich schneller an die sich ständig ändernden Anforderungen anpassen können als hierarchische Organisationen, die auf tayloristischen Prinzipien beruhen. Außerdem sind dezentrale Organisationen typischerweise ein ganzes Stück robuster gegenüber unerwarteten Anforderungen.Wenn wir uns einen Moment lang umsehen, werden wir schnell erkennen, dass es bei DevOps genau um diesen Punkt geht: Wir schaffen vorwiegend autonome Teams, die ganzheitlich Verantwortung für dedizierte Geschäftsfähigkeiten übernehmen und wir lassen sie auf alle Änderungsforderungen in ihrem Kompetenzbereich reagieren. Tatsächlich gehört noch viel mehr zu DevOps, wie zum Beispiel ganzheitliche Optimierung von Durchlaufzeiten, Verstärkung von Feedback-Schleifen, um gegebenenfalls erforderliches Wissen bereitzustellen, und eine Kultur des beständigen Lernens. Dies sind ebenfalls sehr wichtige Eigenschaften von DevOps, die genau in die Richtung der Treiber zeigen, die wir oben gesehen haben.Doch DevOps allein genügt nicht. Wir müssen sicherstellen, dass Teamautonomie nicht durch Software und Systeme verletzt wird, an denen die Teams arbeiten. Wenn zum Beispiel viele Teams an einem großen Monolithen arbeiten (der leider die Tendenz hat, im Laufe der Zeit zu einem großen Brocken Spaghetticode zu verkommen), werden die Teams normalerweise jede einzelne Änderung koordinieren müssen und die Autonomie ist dahin. Wenn wir Software nur in großen Alles-oder-nichts-Releases freigeben können, wenn wir mit einem Laufzeit-Megamonolithen konfrontiert sind, müssen die Teams sämtliche Änderungen koordinieren und sich auf ein Release-Datum verständigen – und die Autonomie ist ebenfalls dahin.Wir brauchen also ein Architekturmuster, das Autonomie in Bezug auf Entwicklung und Bereitstellung von Software unterstützt. Microservices sind ein solches Architekturmuster. Deren Eigenständigkeit („Self-containment“) und problemlose Erfassbarkeit für den Einzelnen („Fits in one brain“) unterstützen Teamautonomie sehr gut. Zudem erlauben sie schnelle Änderungen und kurze Durchlaufzeiten. Faktisch sind Microservices nicht der einzige Stil, der den gegebenen Anforderungen entspricht, und zugegebenermaßen ist es recht einfach, sie zu verpfuschen und am Ende vor einem großen verteilten Kuddelmuddel zu stehen (auch bekannt als „verteilte Hölle“). Doch richtig gemacht unterstützen sie Autonomie und schnelle Anpassung sehr schön.Autonome DevOps-Teams, die auf die sich ständig ändernden Forderungen reagieren, müssen ihre Software auch freigeben („deployen“) können, wann immer sie wollen. Und wenn sie ihre Software mehrmals pro Tag freigeben müssen, darf das keine Probleme machen. Software unabhängig nach Bedarf freizugeben verlangt normalerweise nach Automatisierung. Manuelles Erstellen, Testen und Freigeben ist viel zu teuer und fehleranfällig, wenn dies häufig geschehen muss. Dies ist die Domäne von Continuous Delivery, das ja gerade das konsequente Automatisieren von Erstellen, Testen und Freigeben von Software zum Ziel hat.Der letzte Teil des Bilds ist die Infrastruktur, auf der die Software läuft, da sie ebenfalls sehr flexibel sein muss. Wenn es Tage, Wochen oder Monate dauert, um die erforderliche Infrastruktur für Entwicklung, Bauen, Testen oder Freigeben zu bekommen, ist jede Teamautonomie und Reaktionsfähigkeit dahin. Die Teams müssen in eigener Regie auf die erforderliche Infrastruktur zugreifen können („Self-service access“), wann immer sie sie brauchen, und sie müssen sie auch wieder abstoßen können, sobald sie sie nicht mehr brauchen. Genau diesen Anforderungen entspricht das Cloud-Bereitstellungsmodell. Darüber hinaus ermöglicht der API-basierte Ansatz elastisches Skalieren zur Laufzeit sowie bessere Automatisierung des Build-, Test- und Freigabeprozesses.<h2>Weitere Überlegungen</h2>Wir haben gesehen, dass DevOps, Microservices, Continuous Delivery und Cloud-Computing Kernbausteine einer neuen IT sind. Doch reicht das aus für unsere neue IT oder fehlen noch irgendwelche Teile?<div><a href="https://media.graphassets.com/V8XbLBliRLmtcDbuC4Rg"><img loading="lazy" src="https://media.graphassets.com/V8XbLBliRLmtcDbuC4Rg" alt="Beyond Budgeting, EAM neu gedacht und Craftsmanship als ergänzende Bausteine" width="250" height="188" /></a> Bausteine einer neuen IT, einschließlich unterstützender Elemente</div>Tatsächlich fehlen einige unterstützende Teile. Das erste ist das Unternehmensarchitektur-Management (Enterprise Architecture Management, EAM), doch nicht auf die Weise, wie man es kennt. Es hat keinen Mehrwert, Unmengen von Bildern im Voraus zu zeichnen und zentral zu versuchen, die gesamte IT-Landschaft im Detail unmittelbar vom Elfenbeinturm aus vorauszuplanen und zu beschreiben. Dies wird standardmäßig ein Flaschenhals sein und ist ziemlich genau das Gegenteil von dem, worum es bei DevOps geht.Dennoch gibt es einige wichtige Aufgaben in einer DevOps-Organisation, wo EAM eine Menge Mehrwert erzeugen kann: Selbst wenn die Teams möglichst unabhängig und autonom sein sollten, müssen sie trotzdem noch an einem gemeinsamen Ziel arbeiten. Hier bietet sich EAM an, um die gemeinsame Vision zu verbreiten und den Teams zu helfen, das große Ganze im Blick zu behalten.Zweitens ist totale Teamautonomie nicht möglich, da alle Teams auf ein gemeinsames Ziel hin arbeiten und die von ihnen produzierte Software zusammenspielen muss. Das heißt Koordination. Die Teams müssen sich wechselseitig abstimmen, wie ihre Software mit der jeweils anderen zusammenarbeitet. Das kann recht umständlich und ineffizient sein, wenn über jede einzelne Interaktion von Grund auf neu abgestimmt werden muss. Deshalb ist es sinnvoll, sich über bestimmte Interaktionsstandards über alle Teams hinweg zu verständigen. Diese Minimalmenge an Standards zu ermitteln und zu pflegen, ist ebenfalls eine gute Aufgabe für EAM.Eine andere Definition ist, dass sich EAM um das große Ganze und den Raum zwischen den Verantwortlichkeiten der Teams kümmert. Eine letzte Anmerkung zu EAM: Normalerweise ist dies kein Vollzeitjob und es sollte kein Elfenbeinturmteam damit betraut werden. Stattdessen sollte das EAM-Team aus Abgesandten der DevOps-Teams bestehen, die sich gelegentlich oder einfach nur bei konkretem Bedarf treffen.Der zweite große unterstützende Baustein ist das Führungsmodell („Governance“). Wir müssen immer noch sicherstellen, dass die Visionen des Top-Level-Managements und die Arbeit der Teams zueinander passen. Wichtig ist Transparenz – was geschieht in den Teams? Und ebenso wichtig ist, dass das Top-Level-Management den Teams Richtungsänderungen effizient vermitteln kann.Die herkömmlichen Führungsmodelle von hierarchischen Organisationen sind nicht geeignet für eine DevOps-Organisation, die Durchlaufzeiten und Marktreaktivität optimiert. Wir brauchen ein anderes Führungsmodell. Das gute daran ist, dass diese Führungsmodelle schon eine ganze Zeit bekannt sind und von diversen großen Firmen, die sie übernommen haben, erfolgreich in der Praxis erprobt wurden. Diese Modelle sind unter dem Namen „Beyond Budgeting“ oder „Beta-Kodex“ (eine Weiterentwicklung von „Beyond Budgeting“) bekannt.Als dritter großer unterstützender Baustein ist Craftsmanship zu nennen. Ja, es geht um Menschen (leider vergessen wir das allzu oft)! Wir müssen allen beteiligten Personen helfen, ein verändertes Verständnis bzgl. der Art und Weise zu entwickeln, wie sie arbeiten.Auf der einen Seite ist es wichtig, den Leuten dabei zu helfen, ständig die Art und Weise zu verbessern, wie sie ihre Arbeit erledigen und mit ihren Kollegen zusammenarbeiten. Man bezeichnet dies auch als „Meisterschaft“ („Mastery“). Eine Haltung der Art „alles wird sich finden“ ist nicht mehr ausreichend. Dies ist die Kernidee von Craftsmanship.Auf der anderen Seite brauchen die Menschen kein stabiles Arbeitsmodell mehr, sondern vielmehr ein robustes Veränderungsmodell. Menschen brauchen Orientierung – einige Regeln und Ankerpunkte, an denen sie sich orientieren können. In der Vergangenheit wurde den Leuten ein Modell vorgesetzt, wie sie ihre Arbeit zu erledigen haben, entweder mithilfe detaillierter Prozessbeschreibungen oder über weniger förmliche Richtlinien.Das Problem bei diesem Ansatz ist, dass sich die Arbeitsweise ständig ändert, da sich Firmen fortwährend an die sich ständig ändernden Bedürfnisse und Forderungen ihrer Kunden anpassen müssen. Demzufolge ist es nicht möglich, ein Arbeitsmodell bereitzustellen, das über einen längeren Zeitraum stabil ist. Deshalb ist es notwendig, den Leuten ein Modell an die Hand zu geben, mit dem sie leichter verstehen können, wann eine Veränderung notwendig ist und warum. Wir gehen also eine Stufe nach oben vom Bereitstellen eines stabilen Arbeitsmodells zum Bereitstellen eines robusten Veränderungsmodells. Selbst wenn dies kein zentraler Aspekt von Craftsmanship ist, gehört er zweifellos in diesen Bereich.<h2>Fazit</h2>Wir müssen IT neu denken – die Märkte, in denen die Firmen agieren, haben sich geändert, die IT selbst hat sich geändert. Die Rahmenbedingungen, unter denen unsere traditionellen IT-Modelle entwickelt wurden, existieren nicht mehr. Unser primärer IT-Treiber ist nicht mehr die kosteneffiziente Skalierung der Softwareproduktion, vielmehr geht es darum, die Durchlaufzeiten zu minimieren, um die Reaktionsgeschwindigkeit des Unternehmens zu maximieren.Die Kernbausteine für diese neue IT sind DevOps, Microservices, Continuous Delivery und Cloud-Computing, die durch einige zusätzliche Elemente wie EAM (ebenfalls neu gedacht!), Beyond Budgeting und Craftsmanship ergänzt werden müssen.Immerhin ist dies lediglich das „große Bild“, eine Draufsicht aus 10.000 Metern Höhe. Es gibt viele Schattierungen, die ich zugunsten der Kürze weggelassen habe – und dennoch ist es ziemlich lang geworden. Außerdem besteht jeder hier erwähnte Baustein aus vielen weiteren Details auf verschiedenen Ebenen. Und es sind jede Menge Details zu berücksichtigen, um nicht alles am Ende zu verpfuschen. Doch das sind andere Geschichten …

The Need for Speed – eine Geschichte über DevOps, Microservices, Continuous Delivery und Cloud-Computing

Wenn wir eine Definition für einen Begriff suchen oder Erklärungen zu einem Thema, wo schauen wir dann nach? Richtig, in <a href="http://de.wikipedia.org/wiki/Hauptseite " target="_blank">Wikipedia</a> ! Und wir wissen, dass die gesammelten Informationen nach dem Prinzip der offenen Community zusammengetragen worden sind, dass also jeder, der Ahnung von einem Thema hat, alle Experten dieser Welt ihr Wissen dort verewigen können und so dem nicht ganz so wissenden Rest der Welt zur Verfügung stellen können.Wir verlassen uns mittlerweile so sehr auf die Informationen in Wikipedia, dass wir uns häufig gar nicht mehr die Mühe machen, alternative Quellen zu prüfen. Und wenn irgendwo eine Definition aus Wikipedia zitiert wird, nehmen wir sie als richtig hin.Dazu das folgende Erlebnis, das ich dieses Jahr auf der <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference</a> in London hatte:Auf besagter Konferenz hat John Zachman in einer Keynote die neue Version seines Frameworks vorgestellt. Dazu hat er an jeden Keynote-Teilnehmer ein Blatt ausgeteilt, das eine schön aufbereitete Darstellung seines Frameworks zeigte. Bevor er aber begann, die Neuerungen seines Frameworks zu erklären, hat er uns Teilnehmer auf zwei kurze Artikel aufmerksam gemacht, die auf der Rückseite des Blattes abgedruckt waren.Er erzählte dazu sinngemäß übersetzt: „Diese beiden Artikel erläutern in Kürze mein Framework. Der Grund, warum ich sie hier habe abdrucken lassen, ist Wikipedia. Ich hatte vor einiger Zeit aus Neugierde nachgelesen, was in Wikipedia über mein Framework geschrieben steht. Dabei ist mir aufgefallen, dass der Artikel in Wikipedia einige falsche Aussagen enthielt. Also habe ich die fehlerhaften Aussagen in dem Artikel korrigiert. Dank des offenen Konzepts von Wikipedia ist das ja kein Problem. Kurze Zeit später erhielt ich die Rückmeldung von Wikipedia, dass meine Änderungen gelöscht worden seien, da sie nicht korrekt wären. Ich schrieb sinngemäß zurück: ‚Hallo, ich bin John Zachman. Wenn ich nicht wissen soll, was im Kontext meines Frameworks richtig ist, wer dann?‘ Aber es hat nichts geholfen. Wikipedia hat darauf bestanden, dass meine Aussagen zu meinem Framework falsch seien. Aus diesem Grund sah ich mich gezwungen, diese beiden Artikel zu schreiben, in denen dargestellt ist, wie ich mir mein Framework vorstelle, wenn ich das schon nicht in Wikipedia machen kann.“Natürlich hatte John Zachman mit dieser Anekdote die Lacher auf seiner Seite und da er die gute Ausgangsstimmung in seiner Keynote aufrecht halten konnte, war es auch für alle Anwesenden eine tolle Keynote, bei der wir übrigens auch eine Menge über die neue Version seines Frameworks und die dahinterliegenden Ideen und Konzepte gelernt haben.Was sagt einem diese Geschichte aber in Bezug auf Wikipedia? Ich weiß nicht, was da im Detail passiert ist, wer genau die Änderungen von John Zachman in Wikipedia rückgängig gemacht hat und habe auch nicht weiter nachgefragt. Was einem die Anekdote von John Zachman aber gut vor Augen führt ist, dass auch Wikipedia nicht unfehlbar ist. Auch hinter Wikipedia stehen Menschen, und Menschen haben Schwächen und machen Fehler – Fehler, die sich letztlich auch in den Inhalten von Wikipedia wiederfinden.Für mich war es ganz hilfreich, mit dieser Geschichte mal wieder daran erinnert zu werden, dass auch Wikipedia nicht unfehlbar ist. Natürlich wissen wir das eigentlich auch alle, nur vergessen wir es zwischendurch immer mal wieder.Wikipedia ist eine hervorragende Informationsquelle und es ist aus meiner Sicht nach wie vor beeindruckend, wie über das offene Konzept von Wikipedia über so kurze Zeit so viel qualitativ hochwertiges Wissen zusammengetragen werden konnten. Dennoch sollten wir Wikipedia nicht mit der „Wahrheit an sich“ verwechseln, sondern es wie mit jeder anderen guten Informationsquelle auch halten: Wir können Wikipedia als erste Quelle für eine Informationsrecherche nutzen; dann sollten wir aber wie bei jeder guten Recherche mehrere weitere Quellen zur Gegenprüfung heranziehen, um das Fehlerrisiko zu minimieren und die Belastbarkeit unserer Informationen sicherzustellen.Denn: Wikipedia hat eben nur fast immer recht.

Wikipedia hat immer recht

Letzte Woche habe ich die SET 2009 in Zürich besucht. Die von <a href="http://www.sigs-datacom.de/">SIGS DATACOM</a> organisierte Konferenz ist nicht so groß wie ihre große Konferenz, die OOP. Die SET hatte etwa 160 Besucher, dauerte zwei Tage und hatte ein gutes Programm, das in drei parallelen Tracks organisiert war.Auf der Konferenz habe ich einen Vortrag über die Probleme der Wiederverwendungs-Diskussion und die Potentiale eines Design for Maintenance gehalten, aber darüber möchte ich hier nicht schreiben.In der restlichen Zeit habe ich die Gelegenheit genutzt, einige andere Sessions zu besuchen und mich mit anderen Konferenzteilnehmern zu unterhalten und ich möchte hier über zwei interessante Ideen schreiben, die ich in dem Kontext aufgeschnappt habe. Als erstes habe ich einen Erfahrungsbericht bzgl. eines virtuellen Entwicklungsteams besucht, den Stephan Wald gehalten hat. An einer Stelle  in seinem Vortrag hat er festgehalten, dass die Entwicklung in virtuellen Teams nur mit einem bestimmten Typus Entwickler funktioniert. Er sagte, dass diese Art der Zusammenarbeit Entwickler braucht, die bereit sind, sich regelmäßig auszutauschen, ihre Ergebnisse zu teilen, zu dokumentieren, was sie getan haben, und so weiter. Oder um es andersherum auszudrücken: „IT Superhelden“ oder „einsame Cowboys“ (gemäß ihrer Selbstwahrnehmung), die immer alles allein machen und nichts teilen, insbesondere nicht ihren Code, passen nicht zu dieser Art von Projekten, selbst wenn sie extrem schnell Ergebnisse produzieren. Der virtuelle Ansatz funktioniert schlicht nicht mit dieser Art von Entwicklern.Ich fand diese Beobachtung sehr interessant, weil ich schon immer ein wenig ambivalente Gefühle gegenüber diesen “Shared nothing”-Leuten gehegt habe. Auf der einen Seite waren diese Leute häufig exzellente Entwickler, die in der Lage waren, ein in Schieflage geratenes Projekt an einem Wochenende zu retten (weshalb sie bei Managern häufig sehr beliebt sind). Auf der anderen Seite erzeugten sie immer eine Art schwarzes Loch in ihrer Umgebung, mit dem sie sich unersetzlich machten – ebenfalls innerhalb eines Wochenendes.Als ich beim Mittagessen mit in paar anderen Leuten darüber gesprochen habe, sagte ein anderer Speaker, dass er denkt, dass „IT Superhelden“ immer ein Problem sind, in jeder Art von Projekt. Virtuelle, verteilte Teams würden es nur sehr schnell sichtbar machen. Die anderen Leute am Tisch stimmten dem zu und ich glaube auch, dass er recht hat. Für meinen Teil denke ich mir, dass die Ära der „IT Superhelden“, dieser „einsamen Cowboys“ zu Ende gehen sollte oder anderenfalls werden die Projekte, an denen sie beteiligt sind, zu Ende gehen – und zwar früher als erwartet.Die zweite interessante Sache, über die ich hier schreiben möchte, ist der Vortrag, den Peter Sommerlad gehalten hat, einer der Autoren des <a href="http://www.amazon.de/System-Patterns-Pattern-Oriented-Software-Architecture/dp/0471958697/">ersten POSA Buchs</a> und mittlerweile Professor am <a href="http://ifs.hsr.ch/">Institute for Software</a> in Rapperswil. Peter hat einen sehr interessanten Vortrag über „Decremental Development“ gehalten. Die Idee ist, alle unnötige Komplexität aus dem Code zu entfernen und den Code so auf einen Bruchteil seiner ursprünglichen Größe zu schrumpfen, wodurch er leichter zu verstehen und wartbarer wird.Diesen Vortrag fand ich sehr interessant, weil er ebenfalls die Wichtigkeit wartbarer Software betont hat, unabhängig davon, ob auf Architekturebene, worüber ich in meinem Vortrag gesprochen habe oder auf Design- und Codeebene, worüber Peter gesprochen hat. Für meinen Teil denke ich, dass die Leute zumindest auf den Konferenzen beginnen zu verstehen, dass wartungsfreundliches Design und wartungsfreundlicher Code die wirklich kritischen Punkte sind, die dringend angegangen werden müssen, um die Gesamtkosten (TCO) von Software unter Kontrolle zu halten.Es geht nicht darum, immer die billigste Implementierungsvariante zu wählen und damit punktuell einen gut aussehenden Business Case zu erzeugen, bei dem die Folgekosten, die diese billigste Lösung hervorruft, komplett ignoriert werden. Stattdessen geht es darum, die Gesamtkosten einer Anwendung unter Berücksichtigung ihres gesamten Lebenszyklus zu optimieren – und die Wartungsphase ist die mit Abstand größte Phase des Lebenszyklus einer IT Anwendung.Ich denke, wenn die Leute beginnen, sich dieser Tatsache auf Konferenzen bewusst zu werden, dann mag es immer noch eine Weile dauern, bis es in der Breite der IT-Schaffenden ankommt, aber es ist definitiv ein Schritt in die richtige Richtung.Das waren die zwei Ideen, über die ich schreiben wollte. Ein letzter Tipp: Sollten Sie einmal die SET besuchen, benutzen Sie die <a href="http://www.zvv.ch/zvv/de/home.html">öffentlichen Verkehrsmittel</a> . Wenn Sie – wie ich – die üblichen Verspätungen der Deutschen Bahn gewohnt sind, ist es einfach großartig, öffentliche Verkehrsmittel zu benutzen, die so pünktlich und zuverlässig sind, dass man seine Uhr danach stellen kann. Deshalb: Benutzen Sie die öffentlichen Verkehrsmittel, lehnen Sie sich einfach zurück und genießen Sie es … 😉

Eindrücke von der SET 2009 in Zürich

Das erste meet the experts – performance im Juni war für alle Beteiligten ein erlebnisreicher Tag. Auch das zweite meet the experts – agilität am 4. September war ein interessanter Tag mit vielen spannenden Vorträgen und Diskussionen. Daher freue ich mich, bereits jetzt den nächsten Termin in dieser Reihe ankündigen zu können.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:<img title="Dr. Gernot Starke" src="https://media.graphassets.com/0kF9LvOaRBeuGmvtc2xo" alt="Dr. Gernot Starke" width="272" height="280" /><a href="http://www.gernotstarke.de/">Dr. Gernot Starke</a> 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.<img loading="lazy" title="Martin Lippert" src="https://media.graphassets.com/RcB1MDOCRbO3dDGQqboE" alt="Martin Lippert" width="272" height="280" /><a href="http://www.it-agile.de/">Martin Lippert</a> 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.<img loading="lazy" title="Stefan Zörner" src="https://media.graphassets.com/m2TGDROPTwq9mdffErtA" alt="Stefan Zörner" width="272" height="280" /><a href="http://www.oose.de/">Stefan Zörner</a> 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.<img loading="lazy" title="Uwe Friedrichsen" src="https://media.graphassets.com/cSeYjtQQQWGOK0yg3p9g" alt="Uwe Friedrichsen" width="272" height="280" /><a href="https://www.codecentric.de/">Uwe Friedrichsen</a> 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 PraxisDie 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 ArchitekturenIm 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:<ul><li>Wie verändern sich Architektur-Vorstellungen, wenn eine starke Modularisierung und Komponentisierung des Systems eine wichtige Rolle spielt?</li><li>Wie helfen mir Modulsysteme, große Systeme über einen langen Zeitraum hinweg flexibel weiterzuentwickeln?</li><li>Wie kann eine flache Aufwandskurve auch über Jahre hinweg erhalten bleiben?</li></ul>Eine spannende und kontroverse Diskussion ist garantiert.3. Stefan Zörner: Steht alles im Wiki? Architekturen effektiv dokumentieren und kommunizierenDokumentieren 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-ExampleWie 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 <a href="http://www.meettheexperts.de/">meet the experts</a> 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.

meet the experts – architektur | 27. November 2009

Just a thought …A few days I read the following citation:<blockquote>“Perfection is reached not when there is no longer anything to add, but when there is no longer anything to take away.” (A. Saint-Exupéry)</blockquote>I thought about it for a while and from my perspective there is a lot of truth and wisdom in this short sentence. But then I started thinking about IT … One should think that confronted with more and more complexity we should strive for that kind of perfection by getting rid of anything that we do not absolutely need to accomplish our goal. At least that is what I would expect. But when looking around most of the time I see exactly the opposite. We pile up more and more complexity around us no matter if we need it or not. Just to name a few examples:<ul><li>To make things more comprehensive we invent new elaborated templates for everything and anything every day, starting with more than detailed requirements templates and ending in support processes that take several hundred or thousand pages of description … templates and rules that take weeks and months to understand and that make sure that the content is way much harder to understand than it was before … at least for the “normal” people.</li><li>To avoid ambiguity we create models that would take up whole walls to show them. No one will ever understand them altogether, but still we create them. And if is not enough we start creating meta models and meta-meta models to make sure that we lose the last people who had an idea of the model.</li><li>By trying to get things done easier we use products that have so many features that we will probably never use more than 3% of them … and we also integrate those products in our application landscapes.</li><li>To save a few keystrokes we plug so much stuff into our IDEs that no one knows anymore what is going on “backstage” and we are lost in all the “magic” that is going to happen.</li><li>Again in our never ending search to get things done easier we create so many frameworks and we are so keen about using as many as possible in one application that we are completely lost in understanding the technology and resolving all the resulting integration issues and do not have any time left to deal with the applications purpose – you know, that “business stuff”.</li><li>With all those tools we create applications of such a complexity that no one really understands anymore what is going on inside the application, neither the users nor the poor developers who try to implement a new feature within those code nightmares without breaking the whole system.</li><li>And just because we can and some business department guy or lady thinks this might possibly become useful some day we interconnect everything in our application landscape no matter if it provides real business value or not, this way creating a web of dependencies that no one really understands anymore.</li></ul>I could probably go on for hours, but I think you got the point, and I am sure that you could instantaneously add some more examples. We regularly succeed in turning something simple into something complicated by adding more and more stuff to it no matter if it serves the goal or not, until it develops complex behavior, i.e. that it becomes incomprehensible and unpredictable.By trying to deal with the limits of our brains or sometimes just because of our laziness or our fear of decisions we pick the worst alternative very often: We add complexity instead of removing it.When I look at this trend within the IT that everything becomes more and more complex I think it is urgently about time to change course. Instead of complaining about more and more complexity around us we should try to avoid it wherever we can. Again, just to provide a few examples:<ul><li>No one requires us to do things as formal as machines. We are humans and we should interact like humans. Yes, we make mistakes because we are human (it’s part of our nature) but altogether we do not make less mistakes if we try to behave and communicate like machines, i.e. more and more formal.</li><li>Nobody needs models that no one understands. A model serves communication in the first place, the sharing of knowledge; and if nobody understands it there is nothing to share. I would rather have a simple model that I can share with everybody than a complex model that cannot be shared, no matter how precise it is.</li><li>Nobody urges us to use every plug-in for our IDE and every framework for our application that is around. I had a colleague a lot of years ago when design patterns were “all the rage”. He proudly told us one day that he managed to implement each design pattern of the “gang of four” book within his code. Alerted by this statement the rest of the team took a look into his code. After doing this we decided to throw away all the code that colleague ever wrote for the project and to rewrite it from scratch because it was brittle, error prone and not maintainable at all. The same thing usually is true for your IDE and your source code if you use too many plug-ins or frameworks or whatever.</li><li>And do we really need to implement each and every requirement some business guy or lady postulates without questioning it? I mean it is the very own right of the business departments to ask for everything and anything without thinking about the consequences it might have on the technical side. It is not their job to think about the technical consequences and usually they do not have the required knowledge to do that. But it is our job to talk to them, to show them the consequences (in a non-technical language, please), to show them alternatives, to help them to make the best decision by showing them the whole picture. And quite often they will pick the best alternative then, one that is quite often less complex than the initial one.</li></ul>However, this is not a black or white story. There is not “the” solution to our dilemma and simplification beyond recognition does not help either. But I think it is about time for all of us to avoid complexity wherever we do not need it, that we try to push back to the amount of complexity our brains are capable to deal with. Or, to close this with another citation I like a lot:<blockquote>“Less is more!” (Mies v.d. Rohe)</blockquote>As I said at the beginning: Just a thought …

Perfection in the IT – or “less is more”

What is the common story that you usually hear about agility? Yes, most of the times it is something like this: Agility was invented by a bunch of frustrated developers who had enough of big, big processes that did not work out and dozens of artefacts that did not deliver to the final product at all. They fought all those evil V-models, RUPs and however those cumbersome process monsters were named by inventing some nice, lean and agile principles they called Scrum, XP and so on. And since then they kept on with their heroic fight to free the developers from their 800 pound process burden and to carry agility into those centres of backwardness, i.e. the management and the business departments to make the developers lives worth living again. That’s sort of the story you know, isn’t it? Now, here at codecentric we know a quite different story. Practicing agility for quite a while we had the opportunity to be part of the first agile projects that some of our customers implemented. Most of the times those customers had a tough deadline to meet or something similar that would not work with their standard processes and they had heard about the speed of agility. And, to make a long story short: At some point in time we were there to implement the project in an agile fashion. But throughout the implementation of those projects our observations were often quite different than you would expect it from the “common story”:The business departments simply *loved* agility! They were happy that they had fast feedback cycles and somebody who was going to have a real communication with them, not just urging them to write another formal document whenever they had a problem or a requirement. They loved to see their vision growing in short iterations and having the opportunity to fine-tune their own ideas. They even loved to figure out where they were wrong with their initial ideas because they had the opportunity to change it easily and to improve the final product a lot that way. They were simply happy and they never wanted to do a non-agile project again if they had the choice.The management also was quite fond of agility. The business management liked it because their departments loved it and the IT management liked it because the business management stopped complaining, about delivering too slow, putting too much workload on their folks, and so on. Okay, with the IT management it wasn’t always love on first sight. They often were quite suspicious about that agile stuff because they had no idea what it would mean for them if that would really become a big success. Sometimes those managers secret hope was that this agile project would fail. Then they would have shown to the business folks that all this agile stuff does not work out either and that they can stick to the way they did it before. On the other hand, when the agile project turned out to be successful they liked the part that the business people were quite happy.And then there were the developers, those guys from the customers IT department who should be lucky that finally they are allowed to work agile, after all those years, shouldn’t they? Surprisingly, most of them weren’t lucky at all! They liked their processes and artefacts very much and most of the time they were pushing towards “more formalism”. They felt save in the world that they built up throughout the last years. Whenever something went wrong in the former years they added another piece of formalism, another process step, another artefact. They had built their own comfortable world within the bounds of their processes. Everything had its place and its order. Everything was defined in their processes and things that were not described in their processes simply were not allowed. And the best part of it: No one had to take over real responsibility for any failure. As long as you comply with the processes you have done everything right and if something goes wrong it must be the fault of someone else. So, simply do whatever the process tells you and you are safe! Whew, what a relief!You can imagine that agility with its focus on the product instead of the process, with self empowered teams who take over responsibility for the result, with its enforcement to communicate with business people to clarify things instead of simply rejecting specifications, this whole strange agile thing wasn’t exactly the thing those developers were looking for. It actually scared the shit out of them! It made them feel really uncomfortable. They did not know how to deal with this and they always had that creepy feeling that they could be responsible if something would go wrong. No, they weren’t lucky at all!Yes, I exaggerated it a bit to make the point plain, but: That is not a problem of some particular customers of ours. That is something that you can find throughout the whole industry and we had a lot of talk and discussions with many other agile protagonists who approved that observation we made. And it is not that those developers don’t like agility because they are “evil” or “backward” or whatever. They are simply insecure. They built their well organised comfort zone for many years or they were forced into that comfort zone and they simply haven’t learned yet how to deal with this agile way.And what is the moral of the story? Yes, it takes a lot of change management efforts to introduce agility successfully into a company, but … *but* quite often it is not the business departments that we have to prepare for agility; it is the IT departments that we have to prepare for agility. Strange, isn’t it? … 😉A short “disclaimer”: I am not talking about *all* developers. I know many of you have an agile mindset and really love to work the agile way. But on the other hand there is still that huge mass of developers around who do not want to become agile or at least do not know how to change, and I think it is those people we have to focus our change efforts on, not on the business folks.

The fairy tale of the agile developer

Meanwhile, there is a debate for a long time whether architecture and design are the same thing or not. The advocates of the “both are the same” thesis say that architecture is basically the first stage of design, while the opponents of this thesis claim that architecture and design are completely different tasks that just share some more or less fuzzy line of contact. So, who the heck is right?I think it is really hard to find out who is right or wrong … actually I think it is sort of impossible. Even within our small company we are not able to get a common agreement about what exactly architecture is and what design is. And if it is not possible to get to an agreement within a few people (even if some of them are strong characters … 🙂 ), how should we come to an agreement within the whole IT community? It is probably impossible.Thus, I will not try to find a precise answer for that question. Instead I will try to approach the topic from a different angle. First, why is it so hard to answer the question? I think a big part of the problem is that there is no satisfying definition for both terms available, neither for architecture nor for design. So, whenever you talk with another person about architecture or design you can almost be sure that he or she will talk about something different than you do.I mean there are *lots* of definitions available but most of them are so specific that they do not capture the topic sufficiently or they are so vague that they do not help at all. Just for instance, Robert Martin (who said and wrote a lot of very smart things, btw) once stated “Architecture is about the important stuff. Whatever that is.”. Now, this means everything and nothing. Does it mean that design is about the unimpotant stuff? Probably not. And, if coffee is really important for the developers (which it usually is), does it mean, that architecture is about coffee? Probably not. As you can see this definition does not really help.I will not go into detail for other definitions because I think it will not lead anywhere. It won’t be possible to find a definition for architecture and design that everybody will agree upon *and* that will help us to figure out the difference between architecture and design. Especially I think it won’t be possible to find a clear separating line between architecture and design, where the one thing ends and the other thing starts. Everybody draws his line somewhere else and many people probably rather have some kind of fuzzy cloud in mind instead of a sharp line. “Somewhere within that cloud architecture stops and design starts” they will say.Okay, but there must be something that might help us. At least there should be something …Maybe it does help to step away from that question for a moment. From my experience I figured out that there are two basic tasks that make up that whole architecture and design thing (without trying to find the separating line). The whole thing is about transforming all the requirements that are around into a result. (Btw: If you would ask where the coding is in there, I think I would leave it up to you to find the separating line between design and coding; I think it is a similar question … 😉 )The first part of that transformation task is to understand all the requirements (not just the business and user requirements, but also the requirements of the mangement, the project management, the development team, operations, system planning, the security department, the testers, and so on), really understand them, to balance them (there are always conflicting and inconsistent requirements across the different domains and stakeholders to deal with) and to find an appropriate solution idea for all those balanced requirements. I usually call this part of the work “alignment”.The second part of the transformation into a working solution consists of turning the solution idea into an appropriate structure that supports maintainability and changeability, and refine the structure over and over again until you are down at the code level without losing the properties described before. I usually call this part of the work “structuring”.Now, is it important to distinguish those two tasks? I think, yes! The reason for this is that I figured out that those two tasks require very different skills. While alignment has much to do with communication and conflict management skills, structuring requires more formal strengths. Also alignment requires kind of a broad knowledge about all the different requirement domains while structuring requires more of a deep knowledge about the solution domain. As a consequence, you will find quite few persons who are capable (or willing) of doing both tasks with the same strength, and if you neglect one of the two tasks you will most likely get an unsatisfying result.Okay, getting back to the initial question. Will alignment and structuring help us to find a separating line. I think, sort of …From my perspective, alignment is definitely part of any good architecture while structuring is definitely part of any good design. You cannot be a good architect without doing a lot of alignment and you also cannot be a good designer without doing a lot of structuring. How much of structuring is required in architecture and how much of alignment is required in design, I think that is mostly a matter of taste and there won’t be a definite answer to this.So, I also cannot provide you with “the” answer to the initial question. But I know, if somebody talks about architecture without talking about alignment he does something wrong and if somebody talks about design without talking about structuring he also does something wrong. And that is the most important thing from my point of view …PS: My apologies to Robert Martin for picking on his definition of architecture. As I wrote before he said and wrote a lot of really smart things, even though I do not agree with all of them. So, if you have the opportunity to read some of his stuff or listen to a presentation of him, just do it! Now, that should be enough of indemnification … 😉

Is there a difference between architecture and design?

Yesterday I attended the Agile Day on the JAX 2009 in Mainz. I do not want to rate the talks in any way. Since was one of the speakers, it just wouldn’t make much sense … 😉 … but I want to share a few personal impressions I had.First I was surprised how many people attended the agile day. There were at least 300 persons, throughout the whole day. This showed me in a very impressive way that people are really interested in agility these days. In a short poll about half the people said they are using a few agile practices but they are not really agile. Most people of the other half said they are not doing any agility at all at the moment but they are interested in the topic. And just a few people stated they are doing real agile software development and most of them were speakers. For me that showed that there is still a long road to travel in the area of agility but many people started moving which is good.The second interesting impression was a Pecha Kucha session. Stefan Roock organized that session. There were 6 speakers doing a presentation, each with exactly 20 slides, which are shown exactly 20 seconds each, 6 minutes and 40 seconds altogether. These are the rules of a Pecha Kucha presentation. For me it was really interesting to attend such a session. I have read about it before but I haven’t attended a Pecha Kucha session up to yesterday. I liked the short duration of the presentations. It urges the presenters to focus on one or maximum two ideas and keeps them from lengthily talking about dozens of things. On the other hand the strict format was quite distracting for me. Most of the time the slides were shown a bit too long or too short for the things the speakers had to say about the slide. So quite often they had either to wait or to hurry up. And I always was distracted somehow waiting for the next slide to show up. In summary it was an interesting experience for me but I don’t think that this very strict format is very helpful in most cases. I think short sessions – i.e. 10 minutes or less – are a good format but they shouldn’t be that strict.The last interesting impression for me was the speaker panel at the end. It wasn’t the panel discussion in itself. Those I have seen many times. It was the fact that even the agile experts that stood there still had quite different viewpoints on the topic agility. I mean on the one hand that is quite normal for many topics but on the other hand it is always quite surprising to experience that live within a panel discussion. I think it shows that agility is still not a too well explored area that yet has a lot of evolution to go through.

This is a reflection of the meet the experts – architecture that took place at codecentric in Solingen at November-27-2009.Since the whole event including all talks was held completly in german an english version of this reflection would probably not be very expedient. Thus I decided not to translate this announcement.You can read the full version of the reflection if you switch the language to german (by clicking on the german flag in the upper left corner of this page).Beyond that we will – of course – carry on providing an english version of our blog entries.

meet the experts – architecture | November-27-2009 – a reflection

Many “conventional” project manager are quite offish about Scrum or they even reject it completely. One of the reasons for this behaviour is that they cannot identify with Scrum since there isn’t a role “project manager” in Scrum. Throughout our Meet the Experts – Agility had the opportunity to talk a bit about this topic with <a href="http://borisgloger.com/">Boris Gloger</a> .Before, within an open space session Boris had presented his point of view on the role Product Owner. Throughout this presentation I realised that this role has a lot more elements of the conventional project manager role than I thought before. I got the perception that the responsibilities of the conventional project manager became distributed across the roles Product Owner and Scrum Master in a certain way. Having this picture in mind I asked Boris about it and he confirmed my perception. To be exact, he even extended it a bit: From his point of view the conventional project manager role is overloaded and there is hardly a person who is capable to fulfil all responsibilities of this role in a reasonable way. On the other hand in Scrum the role is split up the following way:<ul><li>The Product Owner is responsible for direction (the vision), control with regard to content (Product Backlog) and the budget. He is the one who sets the direction and drives development with regards to content. He also tries to make the most of the available budget. No matter how the project looks in detail – since the features that promise the highest business value are relatively also the best funded features, the pursuit of making the most of the budget automatically leads to a priorisation of the features by their business value. Now, this might not sound “noble and pristine”, but in practise this works surprisingly well … 😉</li><li>The team is responsible for planning the implementation and sticking to its plan, i.e. the whole detail planning and controlling tasks. Using concepts as sprint planning, commitment on the negotiated sprint contents and team responsibility for the implementation, it is much better guaranteed that expectations and results fit together than in conventional projects.</li><li>Finally the Scrum Master is the “care taker”: He takes care of the pizza if it becomes late and he smoothes the impediments out … but he is also the guy who looks over the teams shoulder and reminds it of its commitments if necessary. He makes sure that everybody fulfils his individual role and he cares for the best working conditions possible.</li></ul>This way the responsibilities of a conventional project mangager are split across the three Scrum roles in a quite straightforward fashion. Thus, if a project manager wants (or sometimes is urged) to move into Scrum it is quite easy for him to select the appropriate role. He should figure out for himself honestly which part of the project manager role he likes the best:<ul><li>If he likes most to drive a project with regard to contents and has a way with budgets, he should take the Product Owner role.</li><li>If he is more of a “care taker” and loves to make sure that a project is running smoothly, he should take the Scrum Master role.</li><li>If he became project manager in the first place because he was simply too good in his former developer role and somehow slipped or grew into the responsibility this way, he should become part of the team best and enjoy to push the project along with his own effort.</li></ul>Alltogether Boris point of view makes a lot of sense to me. Especially I think that this way the critical responsibilites for project success of the conventional project manager role are split up well across the three Scrum roles. Also I think that these responsibilities are handled much better by three persons than by one person.Anyway, one point Boris left out in his presentation: There is a kind of conventional project managers that can be met quite often. I like to call them “pure project managers”. They manage projects in a pure formal fashion without having a deeper insight of the project contents. They limit themselves to manage plans (whoever created them) as well as escalations. They posess distinct controlling knowledge, sometimes also good political skills. Following the “management by spreadsheet” metaphor (management on the basis of key figures only neglecting the underlying business contents) they do a “project management by spreadsheet” and some of them are even proud of the fact that they don’t know anything about the contents they manage (“I can manage any project no matter what it is about.”).Now, for this kind of project managers Scrum actually has no usage. Following the lean principle “Eliminate waste!” Scrum avoids any kind of dead freight and focuses solely on those aspects of the project manager role that provide added value, i.e. add directly to project success. And since real success can be judged finally on the basis of the produced results only, a person that cannot contribute to the project contents, to the actual result is not needed in Scrum. The only question left is, if such a person is needed outside of Scrum …

The conventional project manager in Scrum

Inline comments within code are “evil” and everybody who still uses inline comments today is a really, really bad developer and should get his license revoked. That’s what seems to be consensus throughout the developer community … or at least throughout the “up to date” community.Okay, but I say that we need more inline comments. So, what’s wrong with me? Have I gone completely nuts?Now, while answering the last two questions might be a difficult task … 😉 … my idea about inline comments is quite straightforward:If you want to understand any kind of solution, i.e. whenever you need to implement some new feature within an existing, yet unknown code base, you need at least three essential questions to be answered:<ul><li>Why?</li><li>What?</li><li>How?</li></ul>So, how will you get these questions answered without having the original developer at hand?<ul><li>The “How” is simple. That is the code in itself. Thus, it definitely makes sense to write the code as understandable as possible that everybody else will understand the “How” as easy as possible.</li><li>The “What” is usually the domain of the class/method/function/… header. The comment header describes “What” the piece of code down below is meant to do. In Java that is the domain of the Javadoc, other programming languages have their own means or conventions for that.</li><li>But where is the “Why”? The code itself cannot answer the question for obvious reasons and the Javadoc, etc. is not meant for this. It has to focus on the “What”. You could put the “Why” part to a separate artifact, an extra document, i.e. a design document or whatever. But that is quite cumbersome. Also there is a high probability that any changes, refactorings, etc. in the code wouldn’t find their way into that document so that it becomes obsolete quite fast. Hence, it would be better to place the answers to the “Why” questions right at the place where you can see the effect of the corresponding decision, right next to the code that shows “How” the decision of the “Why” question was implemented.</li></ul>That’s where inline comments come in handy. They provide a perfect means to describe rationale for certain decisions that you find within the code. Whenever you think “Why the heck did he or she implement that piece of code this way?” it would be just perfect to find an inline comment right next to the piece of code that answers that question, wouldn’t it? But today most of the time you will look in vain for those answers. Instead you might have to ask the original developer if he or she is still around and remembers that decision or that knowledge is gone for good and you have to guess the rationale.Thus, for me the domain of inline comments is answering “Why” questions and from my experience from a maintainability and changeability perspective (that’s where the architect inside kicks in 😉 ) understanding the “Why” is often a lot more important than understanding the “What” … and the “How” is laid out in the source code anyway.That’s the reason why I say that we need more inline comments<ul><li>not for explaining the “What”, that’s the domain of the header comments</li><li>not for explaining the “How”, the code should answer that by itself</li><li>but for answering those “Why” questions, to provide the rationale for design and implementation decisions that are missing most of the time</li></ul>Therefore here’s my concluding tip for you:Kick that rule off your coding standard that says<blockquote>“You are not allowed to use inline comments”</blockquote>and replace it with<blockquote>“You should use inline comments only to explain (non-obvious) design and implementation decisions (“Why” questions) … and don’t forget to use them for this purpose!”</blockquote>

We need more inline comments!

I read statements like “the cloud isn’t actually new”, or a bit harder “it’s just old wine in new skins” over and over again.Yes, you can think about it that way but I have my difficulties with those statements. Why?Disruptive innovations (those innovations, that really change something) don’t need fundamentally new ideas. Actually the fewest innovations, that really changed something, entirely consisted of all new ideas.No matter, if the Ford T, the PC, the passionately loved and hated MS Windows or the smart phones … all of them weren’t new ideas but a recombination of known ideas at the right time, i.e. the market was ready for them, both form a market demand point of view and from a delivery capability point of view (the capability to deliver the “new” product in an appropriate quality). As a counter example the Apple Newton certainly was a great product, but the market wasn’t ready for it.Thus, the “revolutionary” thing about the cloud isn’t its parts, but their combination and the timing.So, for me the actual innovation about the cloud is that combination of elasticity, flexible pricing models (to the point of the often used pay per use model), customer self service and instant delivery. Yes, each of those ideas is around for quite a while, but this combination is new, a real innovation with disruptive potential.It’s a bit as with an extraordinary meal: The ingredients are well known, you can get them on the market or in your favorite store, but their combination and the preparation turn them into somthing extraordinary. I know, this comparison isn’t working too well since an extraordinary meal doesn’t depend on an appropriate timing. That would rather lead us to fast food, which was a disruptive innovation in its time … but if that still has to do with extraordinary meals? … 😉For those reason I have some difficulties with the statements I mentioned in the beginning. The innovation nature of an idea does not depend on the innovation nature of its parts, but on their combination … and of course on the timing.Given this, for me the cloud fulfils the prerequisites of an actual disruptive innovation. If it really will become one we will see, when the hype mist that covers the cloud at the moment is going to clear up …

Cloud: An innovation or just old wine in new skins?

It’s christmas holidays and as many other people I use that time to goof off a bit – no big visits of relatives, no big vacation trips, just hanging around at home and making sure not to do too much at all. But as many other people after the first few days I start doing odd things, namely cleaning up things here and there. So, this morning I spent some time sorting out things in my office at home I don’t need anymore.In doing so I found some notes I took 2008 at the <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference in London</a> . Even though it was a great conference I decided that I don’t need most of the notes anymore and threw them away. But there was one sentence on one of the pages that made me pause for a while. It seems that it was a sentence from a keynote that David Robertson, a professor from the Switzerland held. The sentence seemed to be so important to me at that time that I noted it down (I’m not a big note-taker, so it must have been important to me).The sentence was: “Architecture is a compass, not a blueprint”. In brackets, I added a “Rethink that!” as a reminder for me to come back to that sentence. Okay, it seems that it took me more than 3 years to come back to that sentence and from todays perspective I think, it actually is an important sentence – one of those timeless sentences.From my todays perspective it perfectly describes what architecture should be and what it shouldn’t. Architecture should be a guidance towards the right solution in a terribly complex environment where even “right” is an extremely complex thing that isn’t obvious and hard to find. Therefore, we need to watch the environment once in a while from several distant (i.e. more abstract) points of view, just with the goal to come back then and to say “From what I saw over there I think it’s a good idea to follow that path for a while”.After that we take the next steps and then we observe again to decide about the next steps and so on: architecture as a compass. We usually cannot draw a complete map (i.e. a blueprint) from our territory upfront. It is just way too complex. And usually you don’t need that big, thorough map at all. Usually it is enough to take a few notes about the basic perceptions you had at the distant points of views (overview pictures and high-level concepts) and the rationale for the most important decisions – just in case you come back to that point and you want to comprehend why you did it then the way it is done.Architecture as a compass also has a second meaning: Architecture is dynamic, not static. Architecture is not a goal, it is part of a journey. It changes over time. It evolves. It changes if the terrain changes, it changes if you learn something from your former steps. While an outdated map doen’t help you anymore at all a compass will always stay useful – but only if you accept that it is not a solution in itself but just a valuable aid to find the right direction on your journey through uncharted complex territory.I think we also could get rid of many of these annoying discussion about architecture – especially in conjunction with agility – if we all would accept this one sentence: “Architecture is a compass, not a blueprint”. Architecture is not a map to the solution, it is a means to find the right way.There is for sure a lot more to write about this sentence but it’s christmas holidays and I don’t want to do too much at all … 😉

Architecture is a compass, not a blueprint

You might ask yourself how emergent architecture is related to scalability and fault tolerance. To be honest: Not at all. With this short blog post I just want to give you a pointer to a few recent presentations I finally managed to upload to Slideshare.First of all there is a new presentation about fault tolerance patterns in the context of scale-out solutions: <div> <a href="http://www.slideshare.net/ufried/no-crash-allowed-fault-tolerance-patterns" target="_blank">No crash allowed – Fault tolerance patterns</a> <div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>A few days ago I also uploaded a related presentation about high-scalability patterns:<div> <a href="http://www.slideshare.net/ufried/scalability-patterns" target="_blank">Scalability patterns</a> <div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>And finally I would like to mention a presentation about the opportunities and limitations of emergent architecture, I also uploaded a few days ago:<div> <a href="http://www.slideshare.net/ufried/emergent-architecture-12620741" target="_blank">Emergent architecture</a> <div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>As always, the “audio track” is missing but I tried to design the slides in such a way that they are not completely useless without the audio.And also as always, I am interested in your opinion and feedback. Thus, if you have any comment about the slides, just let me know …

Scalability, fault tolerance and emergent architecture

Let me start this post with a bit of ranting: I am so tired to hear or read the same nonsense over and over again usually emitted by people obviously hardly knowing what they are talking about.What am I ranting about? It is about this stupid argument that Agile does not need an architect because Scrum does not know about this role. Aaaaaaaarrrrgh, could scream about that nonsense!Do not get me wrong: I do not think that you always need an explicit architect — not at all. There might be reasons to have an architect on your project, there might be reasons not to have one. That is not the point.It is the mindless argumentation usually used that annoys me. It goes like this: “Scrum does not define a role Architect and therefore an architect is not needed in an agile IT project. Case closed. Period.”I hoped we left this mindless argumentation behind us several years ago but I still hear this crap over and over again — usually either by some blindfold agile disciples trying to justify their point of view this way or by some agile deniers trying to start a rant right after this claim.I just read it a few days ago again in a session abstract of a big, well-known German conference. And it was not meant as a joke. The author meant it absolutely serious. Aaaaaaaarrrrgh again!Okay, I guess most of you know already what is wrong about this argumentation. For those of you who are not completely sure, let us step back and think about Scrum a bit:First of all Scrum is not an equivalent for Agile but just a tiny process framework with lots of gaps and missing bits and pieces (at least if Scrum is all you have to run an IT project). There is a lot more to Agile than just Scrum. Thus, even if Scrum does not provide for an architect it does not mean at all that Agile does not need an architect. But that is not the most important point.The most important point is: Scrum is IT-agnostic!Scrum does not know anything about IT!Or as Jeff Sutherland once told us in my original Scrum Master training several years ago: “You can use Scrum to organize your weekend.” And even though you partner is not provided as an explicit Scrum role you should better not exclude her or him from our weekend organization if you care about your relation … 😉Actually, Scrum was not developed in the IT domain at all. Scrum’s <a href="http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG" target="_blank">origins</a> are the design and development of consumer goods. Much later it became generalized and rolled out to other domains, as the IT domain.And if you look really carefully, you will figure out that Scrum also does not define roles as Requirements Engineer or Tester. Scrum even does not define a role Developer!There is just a Team and all Scrum tells us about that team is that you better make sure all skills you need to get the job done should be available in the team.Utilizing the mindless argumentation from the beginning I am really curious how anyone will get an IT project done without developers. Maybe Chuck Norris can do, but not the rest of us … 😉Conclusion: The fact that Scrum does not mention an architect role does not give any evidence if this role is needed or not in an IT project. Scrum does not mention any IT-specific role because it is IT-agnostic.Thus, please let us stop using this stupid argumentation for good. And if you should ever see someone using this argumentation again please tell him or her that he or she is talking crap. Let us all get rid of that nonsense for good.Again, there might be good reasons why you need or do not need an architect in your project but that is a different story … a much more interesting story!

Agile, Scrum and the nonsense about architects

Currently we can observe three mega-drivers that force IT into a dramatic change:<ul><li>Economic darwinism</li><li>Digitization</li><li>Disruptive technology</li></ul>All of them are extremely important and the companies that ignore these drivers will sooner or later fall short of their competitors (at least as long as the companies live in an efficient market – non-efficient markets are a different story).<h2>Changing markets</h2>Let’s begin with the first driver and start with a quick explanation: “Darwinism” in short means “Survival of the fittest” – and the “fittest” is not the strongest but whoever can adapt quickly enough to the changing demands of the surrounding environment.<div><a href="https://media.graphassets.com/exFeyoUVT2CIMk8PkPbZ"><img src="https://media.graphassets.com/exFeyoUVT2CIMk8PkPbZ" alt="Economic darwinism, digitization and disruptive technologies create pressure on IT" width="300" height="225" /></a> Mega-drivers create pressure on IT, forcing it into fundamental change</div>This is also true for companies: Only the companies that adapt quickly enough to the changing needs and demands of their customers will survive in the long (or even short) run.You might say: “Hey, where are the news? This is true since the beginning of economy.” And you are right.The key part is that the markets most companies live in changed dramatically some years ago. For almost a century most markets were broad, almost unlimited and sluggish: There was always a larger demand than supply and the biggest challenge for companies in those markets was to scale the production of their goods in a cost-efficient way.This started to change back in the 80ies: Slowly but surely one market after the other became narrower. Globalization, market saturation and the internet led to highly competitive and dynamic markets (Actually there were more drivers for the market change but that is outside the scope of this post). The markets became highly demand-driven and the new biggest challenge of the companies was to adapt to the changing demands of the customers quickly enough. The key driver changed from “cost-efficient scaling” to “responsiveness”.<h2>Changing role of IT</h2>You might say: “Yeah, I know all this. But what has it got to do with IT?”The point is that business and IT are tightly interwoven these days. You cannot consider them independently anymore even if it started quite differently:If you think about the relation between business and IT, back in the 50ies and 60ies it started with IT supporting tiny fractions of business functions – a little report here, a small analysis there. It was very selective because the computing power of the mainframes back then was quite limited (every cell phone today has orders of magnitude more computing power than the computers back in the 60ies).Yet, it was so cool for the business departments that they did not have to create their reports and analyses manually anymore that they wanted more of that – which eventually led to the software crisis: Demand for software became a lot higher than supply.The reaction to the software crisis was the invention of software engineering: An engineering practice to scale the production of software in a cost-efficient manner. Sounds familiar, doesn’t it: Industrialization had a very similar problem in the beginning of the 20th century and the solution approach back then was Taylorism and its variants. Thus, it is not surprising that software engineering picked up many tayloristic concepts and practices and adopted them to software development.And that was perfectly fine back then. But over time the role of IT changed essentially. Sometime back in the 80ies the PC started its triumphant success and networking became widespread. Also Moore’s law did its job and computers became more powerful all the time. As a result IT did no longer only support selective business functions, it started to support whole business processes. It moved closer and closer to the business with all its complexity.This development continued, the internet started its success story in the 90ies and eventually IT became the nervous system of each non-trivial company: The whole business domain coded into IT, IT outages of just a few hours considered existence-threatening by many companies. And this also implies that you cannot change your business anymore – no new products, features or process changes – without touching IT.<h2>The need for speed</h2>Combining the two observations described before, we can conclude that IT has become a critical success factor for any company to hold its ground in the economic darwinism. No matter how good you understand the needs and demands of your customers, if your IT cannot deliver fast enough you will go away empty-handed.Yet, most companies still stick to the ideas of traditional software engineering where the primary goal is scaling the production of software in a cost-efficient manner. The problem is that scaling software production and IT cost-efficiency are not the most crucial drivers anymore (we actually write way too much software these days, it just takes too long and very often just delivers a fraction of the value expected).The most crucial driver for IT today are cycle times, the time needed to bring an idea to the customer. This means the time needed to traverse the whole IT value chain beginning in picking up the requirement until it is live in production.The shorter these cycle times are, the better we can adapt to the ever-changing demands of the highly dynamic markets. We need “speed”!<h2>Tightened conditions</h2>If we look at digitization, the second mega-driver, we get an additional twist: With digitization IT no longer just supports the business, it becomes the business. We create new business products which consist partly or completely of IT. On the one hand this means the need for innovation as we just start to develop vague ideas what future business models trends like Internet-of-Things (IoT) will enable. On the other hand this means that our IT needs to be even more robust than before as it becomes continuously exposed to our customers.The third mega-driver are disruptive technologies like cloud, mobile, big data and IoT. These technologies provide very different ways to implement business needs up to a level where they enable completely innovative business models. As we are still just at the beginning of understanding what we can do with those technologies, they tighten the conditions described before:We need to understand and learn, we need to innovate, we need to adapt to ever-changing markets and we need to do it fast incorporating the new possibilities provided by disruptive technologies. And we will not succeed if we try to accomplish all this clinging to ideas developed many years ago in a very different business and IT era.We need to re-think IT!<h2>Re-thinking IT</h2>This was the short version of the much longer story why cycle times became the most important driver for IT today, why we need to re-think IT.But, if the old wisdom we still base most of our IT processes and operation on is not appropriate for re-thinking IT, what is appropriate instead?<div><a href="https://media.graphassets.com/k50qhCrQR1aorXMqAVab"><img loading="lazy" src="https://media.graphassets.com/k50qhCrQR1aorXMqAVab" alt="DevOps, microservices, continuous delivery and cloud-based infrastructure as core building blocks of a new IT" width="300" height="225" /></a> Core building blocks of a new IT, responding to the change drivers</div>This is a very valid question. A good starting point usually are organization and processes: Organizational and system theory showed that decentralized organizations with mostly autonomous units can adapt much better and a lot quicker to ever-changing demands than hierarchical organizations based on tayloristic principles. Also the decentralized organizations tend to be a lot more robust against unexpected demands.If we look around for a moment we will quickly realize that DevOps is exactly about this issue: We create mostly autonomous teams that take over end-to-end responsibility for dedicated business capabilities and we let them respond to all change demands in their capability area. Actually there is a lot more to DevOps like holistic optimization of cycle times, amplifying feedback loops in order to provide knowledge where it is needed and a culture of continuous learning. These are also very important traits of DevOps which exactly point in the direction of the drivers we have seen before.But DevOps alone is not enough. We need to make sure that team autonomy will not be compromised by the software and systems the teams are working on. For example, if we have many teams all working on a big monolith (which unfortunately has the tendency to eventually degenerate into a big lump of spaghetti code), the teams will usually need to coordinate every single change and the autonomy is gone. If we can release software only in big all-or-nothing releases, if we are confronted with a runtime mega-monolith, the teams need to coordinate all their changes and agree on a release date and the autonomy is also gone.This means we need an architectural style which support autonomy in terms of development and deployment of software. Microservices are such an architectural style. Their self-containment and fits-in-one-brain properties support team autonomy very well. They also support quick changes and short cycle times. Actually microservices are not the only style that supports the given needs and admittedly it is quite easy to screw them up and end up with a distributed ball of mud (a.k.a. “distributed hell”) but if done right, they support autonomy and quick adaption very nicely.Autonomous DevOps teams that respond to ever-changing demands also need to release their software frequently, whenever it suits their needs. And if they need to release their software multiple times per day, it must not be a problem. Deploying software independently on demand that often requires automation. A manual build, test and deployment is way too expensive and error prone to execute it frequently. This is the domain of continuous delivery which is exactly about consequently automating build, test and deployment.The last part of the picture is the infrastructure the software runs on as it also needs to be very flexible. If it takes days, weeks or months to get the required infrastructure for development, build, test or deployment, any team autonomy and responsiveness is toast. The teams need self-service access to the required infrastructure whenever they need it and they also need to get rid of it as soon as they don’t need it anymore. The cloud provisioning model exactly meets those demands. Additionally the API-based approach enables elastic scaling at runtime as well as better automation of the build, test and deployment process.<h2>Some more re-thoughts</h2>We have seen that DevOps, microservices, continuous delivery and cloud computing are core building blocks of a new IT. But is that all we need for our new way of IT or are there missing pieces?<div><a href="https://media.graphassets.com/V8XbLBliRLmtcDbuC4Rg"><img loading="lazy" src="https://media.graphassets.com/V8XbLBliRLmtcDbuC4Rg" alt="Beyond budgeting, EAM re-thought and craftsmanship as supporting topics of a new IT" width="300" height="225" /></a> Building blocks of a new IT, including supporting topics</div>Actually some supporting pieces are missing. The first one is Enterprise Architecture Management (EAM), but not the way we know it. There is not any value in drawing lots of pictures ahead and centrally trying to pre-plan and prescribe the overall IT landscape in detail right from the ivory tower. This will be a bottleneck by default and is quite the opposite of what DevOps is about.Yet, there are some important tasks in a DevOps organization where EAM can create a lot of value: Even though the teams should be as independent and autonomous as possible they still need to work towards a common goal. EAM can help to spread the common goal and help the teams not to lose track of the big picture.Secondly, total team autonomy is not possible as all team work towards a common goal and the software they produce need to work together. This means coordination. The teams need to agree mutually upon how their software interacts with each other. This can become quite cumbersome and inefficient if every single interaction is agreed upon from scratch. Thus, it makes sense to agree upon some interaction standards across all teams. Finding and maintaining this minimal set of standards is also a good task for EAM.A different definition is that EAM takes care about the big picture and the space between the responsibilities of the teams. One last remark about EAM: Usually this is not a full-time job and there should not be an ivory tower EAM team in charge. Instead the EAM team should consist of agents from the DevOps teams that meet once in a while or whenever needed.The second big supporting topic is which governance model to use. We still need to make sure that the top level management’s vision and the work of the teams is in sync. It is important that we have transparence what is going on in the teams and it is also important that top level management can transport changes in direction in an efficient way to the teams.The traditional governance models of hierarchical organizations are not suitable for a DevOps organization which optimizes for cycle times and market responsiveness. This means we need a different governance model. The good news are that those governance models are known for quite a while and that they are successfully battle-tested by some big companies which adopted them. Those models are known under the name “Beyond Budgeting” or “Beta codex” (which is a further development of “Beyond Budgeting”).The third big supporting topic is Craftsmanship. Yes, it is about people (unfortunately we forget that way too often)! We need to help all the affected persons to develop a different understanding of the way they need to work.On the one hand it is important to help people becoming continuously better in the way they do their work and collaborate with their peers. This is also know as “mastery”. An “everything will be all right” attitude is just not sufficient anymore. This is the core idea of Craftsmanship.On the other hand people do not need a robust work model anymore, they need a robust change model. People need orientation – some rules and anchors they can use for orientation. In the past people were provided with a model how to do their work, either using detailed process descriptions or less formal guidelines.The problem with that approach is that the way work is done changes continuously as companies continuously need to adapt to the ever-changing needs and demands of their customers. Therefore it is not possible to provide a working model that is robust over a longer period of time. Therefore, it is necessary to provide people with a model that makes it easier for them to understand when change is needed and why. So, we go one level up from providing a robust work model to providing a robust change model. Even though this is not a core aspect of Craftsmanship it definitely belongs in that area.<h2>Wrap-Up</h2>We need to re-think IT – the markets the companies live in have changed, IT itself has changed. The conditions in which our traditional IT models were developed do not exist anymore. Our main IT driver is not cost-efficient scaling of software production anymore, it is minimizing cycle times in order to maximize the company’s responsiveness.The core building blocks for this new IT are DevOps, microservices, continuous delivery and cloud computing which need to be augmented by some additional topics like EAM (also re-thought!), Beyond Budgeting and Craftsmanship.After all, this is just the “big picture”, a 30.000ft point of view. There are many shades of grey I have left out for the sake of keeping it short – and yet it became quite lengthy. Also each building block I mentioned consists of many, many more details on different granularity levels. And there are quite a lot of details that need to be considered for not screwing up everything badly. But those are different stories …

The need for speed – A story about DevOps, microservices, continuous delivery and cloud computing

Re-use is the holy grail of IT: whenever a new architectural paradigm comes to IT town, “re-use” is one of the core arguments why to go for that paradigm. The business sales pitch typically goes like this: “Switching to <insert new paradigm here> will cost some money upfront but due to the re-use it enables it will soon pay back”.I do not know about your experiences but I have never really seen it working the promised way. No matter if you look at Object-orientation, CORBA, Component-based architectures, EJB, SOA, you name it: re-use was accomplished to a lot smaller degree than promised, which meant that the promised business case never got realized. Additionally, very often brittle and tightly coupled systems emerged after a while that were very hard to change and operate, i.e., the business case started to turn into its opposite. But fortunately, at this point in time usually the next holy-grail paradigm showed up and the cycle started over again.In short words: re-use based on any architectural paradigm never worked as promised, the promise was always broken.And today? Currently, microservices are the paradigm de jour, and – of course again – re-use is the business case promise that accompanies it regularly. Will it work this time? Have we finally found the long promised silver bullet?I do not know your opinion about it, but I am convinced that if we push for re-use in our microservice approaches, we will – once again – end up with a completely messed up architecture, including a very poor business case.This leads to the question: Why is the promise of re-use broken?There are several reasons why the re-use promise is broken. Here are my – probably incomplete – observations:First of all, good reusability is expensive. Fred Brooks many years ago coined the “Rule of 9” for a re-usable component (where “component” here solely means the basic building block of re-use, no additional semantics attached to it). Based on his observations it took about three times the effort to design a component that can be re-used properly compared to a component that was just designed for simple use. This has a lot to do with the fact that it is very hard to isolate the right responsibility in a component and then to design a good API to offer the functionality to others. It takes a lot of brain-power and trial and error to come up with such a component.Brooks also made the observation that it takes another factor of three to make the component ready for re-use, i.e., the required testing, hardening and documentation. Finally he stated that these two factors are independent, i.e., they do not sum up, they multiply. This 3 times 3 lead to the “Rule of 9”.You might say that Fred Brooks was way too pessimistic with his statements and that we cannot compare software development in the early 70ies (when he made his statements) to software development today. And you may be right. Things have changed and might have become better (even though I have not seen any evidence for that). So, maybe a factor of 9 is too high today, maybe it is just 5 times the effort to turn a simple project result into a re-usable component, i.e., the additional struggling for the right responsibility encapsulation, good APIs, additional testing, documentation and hardening.This means that you need a re-use of at least 5 times for a component that was made re-usable in order to amortize the investment, and you would need a lot higher re-use factor to justify the typical re-use business case, which claims that you do not only amortize your investment but save a lot of money over time.But if you look into the rarely published re-use numbers of SOA initiatives (Fun fact: If you search the web, you will find tons of pages that talk about, how important re-use is for SOA and how important it is to measure your re-use, but you will hardly find any page that shows real re-use numbers realized by SOA initiatives), you will realize that typical average usage factor for a service is one point something (1.x). In other words: Most services were used only one time, a few services (usually less than 20%) were used more than once. Let us recap: services, that are five times as expensive to create in order to be re-usable, in average used a bit more than one time. There goes the business case …Understanding that the business case is broken is one thing. But it is more important to realize that there is a lot less re-use than expected and thus re-use is a lot less important argument for any architectural paradigm than always claimed.After that statement you regularly find the black-and-white folks who cry out immediately “So, you are telling us that we should not do *any* re-use *at all* and *everybody* should start to write their own string library again!” – which would be nonsense of course. But polemically perverting a statement into its absolute extreme, which – as all extremes – does not make sense, is no proof that the statement itself does not make sense.The point about re-use is that mostly everything that would be re-used often enough that it makes sense to invest the effort to make it re-usable has been implemented already. These are the libraries which are usually part of a programming language ecosystem, be it that they are part of the language itself or are available as 3rd party libraries. Higher level re-usable components, especially company-specific business components are rarely worth the effort in terms of investment costs vs. re-use ratio.And even if you might have IT assets that are worth encapsulating in re-usable components, you do not need a new architectural paradigm for it: Every programming language, every communication protocol provides the means to define an interface. That’s all you need to implement encapsulation which is the basic building block for re-use. It’s all there, it’s been there all the time – nothing new needed.But we face a dilemma: we wanted to get our hands on that new, shiny silver-bullet architectural paradigm that is all the rage and thus made the re-use promise – and now we have to deliver. How is that typically implemented? First of all, we promised re-use as part of our business case. Therefore we design our whole application landscape with re-use in mind. Re-use becomes the driver of design and components must re-use each other, no matter if it makes sense or not. We promised re-use. Thus, there has to be re-use, no matter what it costs.Implementing this, we usually end up in a mess of tightly coupled components which (re-)use each other in strange ways. We especially did not take the time to understand how to design the components best, which boundaries and APIs emerge over time, which ideas work and which do not work. As we promised re-use will make things less expensive, components need to be cheap and re-usable right away without taking the efforts, Fred Brooks described, to make them really re-usable.Besides other bad effects, this leads to a very nasty kind of premature optimization: We try to guess in which way a component might be re-used and as we usually have no real idea about it at the time of the initial design, we just take our first guess and throw it at the world. And because we don’t know anything about our potential users, we just create a “generic” component which offers its internal concepts at its API. This way we end up with basically the exact opposite of a re-usable component.Why do we end up with the opposite of a re-usable component? There are at least two reasons for that: First, as we do not have the knowledge which variability points the component needs to offer in order to satisfy the actual needs of its clients, we usually implement way too many variability points and thus increase the accidental complexity of the component and its interface protocol a lot. In other words: The component becomes harder to use than required, it will be harder to understand and the overall system complexity will be higher than needed.Secondly, “generic”, provider-driven APIs tend to create tight couplings between the provider and its clients because – as you do not have any experience about usage patterns and client needs at design time – you just externalize everything that your component offers via the API. This way, the API is implementation-driven and not client-driven which adds two bad effects:First, the clients are tightly coupled to the implementation of the component (which is externalized via the API due to missing alternatives at design time), usually requiring a much more fine-grained protocol for component access than the client would have needed. Secondly, it becomes very hard to change the implementation of the component after a client started to use it because the implementation was externalized via the API.This, way we end up with a overly complex, tightly coupled, brittle and hard to change system landscape – the opposite of what we wanted to achieve. Even if we would eventually figure out better responsibility encapsulations and access protocols based on actual client needs, we would have a hard time to change the overly complex and highly dependent system we created in the first place. And all this just because we started with a re-use based business case to get a hand on the new shiny paradigm.This is not just theory. Basically, every single system I have seen over the years that was built with re-use in mind exactly looked the way I just described. Sometimes (especially in SOA initiatives), it was even worse because the designers went for a “layered architecture”.The layered architecture pattern is broken often enough within a component, but across components, which are meant to be loosely coupled by definition (and thus btw. need to be as self-dependent as possible), it is quite close to the worst design imaginable: extremely tight coupled components, overly long call-chains (often across process boundaries), very high structural complexity, fragile at runtime due to many components involved for every single request, extremely hard to change – in short words: From an architectural perspective and the goals we wanted to achieve close to a nightmare.After all this: What can we learn from this?<ul><li>First of all: Never base an architectural decision on re-use. It will never work and you usually end up at quite the opposite place of where you wanted to go.</li><li>You don’t need any special architectural paradigm for re-use. Everything that is needed for re-use is already in place – batteries included.</li><li>Re-use emerges. Don’t plan for it. It takes a lot of work, trial and error and actual experience with real clients to design a good re-usable component which encapsulates the right responsibility and provides it via a good client-driven and easy-to-understand API.</li><li>Re-use is expensive. It takes a lot of effort to make a component re-usable. As a rule of thumb, it costs about 5 times as much as it costs to make a component usable. Thus, make sure, it is worth the effort, i.e., the component is used often enough before you make it re-usable.</li><li>And last of all: Don’t go for cheap re-use by building trivial components or layered components. You will end up in a hell where you never, ever wanted to be.</li></ul>How can we make it better?As so often, I do not have a perfect plan to offer (and probably there is no perfect plan at all). My recommendation is to go for replaceability instead of re-use. Replaceability leads in the right direction: you think about how to separate responsibilities in order to make them replaceable, which gives you loose coupling. You think about separating clients from the implementation in order to keep it replaceable, which gives you client-driven APIs.And, if you might realize after a while, that a component tends to be used several times, you go the extra mile to make it really re-usable in terms of additional testing, documentation and hardening. Therefore I would like to add one more line to the learnings:<ul><li>Strive for replaceability, not re-use. It will lead you the right way.</li></ul>Any final words? Um, yes: do not get me wrong. Re-use is not bad per se. Re-use can be extremely useful. For example, I am absolutely grateful that I do not have to build my own String libraries from scratch in every new project as I had to do in the early 90ies with C and C++. It is also great that today it is virtually a no-brainer in most programming languages to create a HTTP client or server. This are just two of probably a million examples where re-use does a great job.Just do not justify your new architectural toy with re-use. It will not work. Never. Why? Re-use this post to figure out … 😉

The broken promise of re-use

If we look for a definition of a term or for an explanation of a special topic, where do we look first? Right, in <a href="http://en.wikipedia.org/wiki/Main_Page" target="_blank">Wikipedia</a> ! We know that the information in Wikipedia are collected by an open community that consists of thousands of experts all around the world, all of them publishing their knowledge so that the rest of the world can get a bit more clever with each click.Meanwhile, in many cases we count on the reliability of Wikipedia so much that we don’t bother looking up alternative sources. Also it is quite normal to believe someones thesis if it is backed by a Wikipedia excerpt.In this context I had a nice experience on the <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference</a> in London this year:In a keynote John Zachman presented the new version of his framework. Therfore every attendee got a piece of paper that contained a nicely formatted presentation of the framework. Before he started to explain the new features of the framework though, he advised us of of two short articles on the back of the paper.Basically, what he stated was: “The two articles describe the framework in a very short manner and the reason for printing them on the back of the paper is Wikipedia. Out of curiousity I read the description of my framework in Wikipedia a while ago and found out that some of the statements were wrong. So, I corrected the wrong statements in the Wikipedia article. Due to the open concept of Wikipedia that works straightforward. After a while I got feedback by Wikipedia that the changes had been deleted because they were not correct. So, I wrote back something like ‘Hi, I am John Zachman, the inventor of the framework and if I don’t know the correct description of the framework, who on earth does?’ It didn’t help. Wikipedia insisted that my statements about my framework were wrong. Thus I had to write the two articles to describe my framework as I intended it to be – as in wikipedia I wasn’t able to do it.”Of cause John scored by making everybody laugh telling us this nice anecdote. Since he kept up the good atmosphere throughout his keynote, it was a great keynote for all attendees and we also learned a lot about the new version of his framework and the ideas and concepts behind it.But what does this story tell us about Wikipedia? I don’t know what happened in detail, who exactly removed the changes that John made in Wikipedia and I didn’t ask for more details. However, this anecdote shows quite plainly that Wikipedia is not infallible. Wikipedia is built and maintained by humans and humans are making mistakes – mistakes that eventually can be found in any of the entries in Wikipedia.This was quite helpful for me to be reminded by the story that I cannot take wikipedia by their words in any case. Of course we certainly use to know that but sometimes we also tend to forget about it.Wikipedia is a very powerful information source and for me it is still very impressing, how this immense amount high-quality knowledge was brought together in such a short peroid of time due to the open concept of Wikipedia. Yet we shouldn’t consider Wikikpedia to be “the truth in itself” but rather we should handle it like any other good source of information: We can use Wikipedia as our first research source, but then – as with any good research – we should try to find other resources for crosschecking the information, in so doing minimizing the risk of errors and making sure to get proven and sustainable information.Remember: Wikipedia is just almost always right.

Wikipedia is always right

This is a small post to inform you about some new slide decks that you can view online or download if you like.I’ve been presenting at some conferences in the last months. First I talked about the developer challenges if you leave the strict consistency model of ACID transactions at <a href="http://www.oop-konferenz.de/" target="_blank">OOP</a> . The <a href="http://de.slideshare.net/ufried/how-to-survive-in-a-base-world" target="_blank">slide deck</a>  first compares ACID and BASE transactions for a second. Then a simple example using ACID transactions is presented (Java/JPA/RDBMS). Afterwards this example is ported to the NoSQL world in a naive way (seen quite often in real-life projects). The reminder of the deck then shows the challenges that arise from this naive port one by one and ways to deal with them. As with every slide deck a lot of the information is on the voice track but I think the slides on their own already offer some helpful pointers. (This last sentence is also true for the slide decks I’m going to write about in the remainder of this post. Thus, I won’t repeat it for the other slide decks.)<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>This first presentation is complemented by the presentation I gave at <a href="http://www.javaland.eu/" target="_blank">JavaLand</a> . There I talked about the different consistency models in more detail and presented two approaches in depth that I only mentioned shortly in the first presentation: quorum based read & writes which can give you strong client-side consistency and CRDTs (Conflict-free Replicated Data Types) which help to keep your data eventually consistent even under extreme availability requirements. The <a href="http://de.slideshare.net/ufried/self-healing-data" target="_blank">slide deck</a>  is exactly organized the way I just described it before, so no need to write anything more about it.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>There is another pair of correlated presentations I’d like to offer. Those presentations are located in the resilience area. The first of the two presentations I gave at <a href="http://qconlondon.com/" target="_blank">QCon London.</a>  The <a href="http://de.slideshare.net/ufried/implementing-fault-tolerance" target="_blank">slide deck</a>  first gives a quick motivation why resilience and fault-tolerant software design is an important topic for developers today. The reminder of the deck is organized the following way: First a case study is shown that explains the consequences of non-resilient applications. Then some patterns are shown that help to mitigate the problems shown in the case study – including code examples that show how to implement those patterns. The idea of this talk was not to give an introduction or overview to resilient software design, but to demonstrate that at least for some resilience patterns it is surprisingly easy to get them implemented in your application – which is a lot better than not having any of them in place.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>The complementing presentation is the one I gave at the <a href="http://bed-con.org/2014/home" target="_blank">Berlin Expert Days</a> . There I gave an introduction to Hystrix, a resilience library developed by Netflix. Hystrix implements downstream isolation utilizing timeouts, circuit breakers and load shedder which are some of the patterns I presented in the other talk. The <a href="http://de.slideshare.net/ufried/resilience-with-hystrix" target="_blank">slide deck</a>  again starts with a quick motivation why resilience is important. Then Hystrix is introduced – first a quick overview, then some basics features. Afterwards some principles of Hystrix are explained in more detail, followed by some resilience patterns that can be implemented using Hystrix – including lots of code examples. A short glance at some advanced Hystrix features and extensions that were not mentioned before close the presentation.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>Those were the slide decks related to distributed and scalable systems which is one of my current focus areas. My second focus area I usually describe with “IT organizations in a post-agile world”. If you want to know a bit more in detail what I mean with that flamboyant phrase you might want to have a quick look at my <a href="http://de.slideshare.net/ufried/dr-hectic-and-mr-hype-surviving-the-economic-darwinism" target="_blank">slide deck</a> about surviving the economic darwinism which explains the core ideas. Within the scope of this focus area I am going to talk about “DevOps for Developers” at <a href="http://rome2016.codemotionworld.com" target="_blank">Codemotion</a> . The core idea of this <a href="http://de.slideshare.net/ufried/devops-for-developers-28043923" target="_blank">slide deck</a> is that many developers are taken in by the false assumption that DevOps is a cool idea but does not affect them in their daily development work. Therefore, first the false assumptions is presented in the slide deck. Then the needs of an operations administrator are described as they nicely describe what properties are crucial for an application in production. Those needs are then taken and the challenges for a developer are derived from them. Afterwards for each of the challenges several principles are presented that explain what a developer needs to take care of in his daily development work in order to deliver software that is really production-ready.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>Those were the slide decks I wanted to present in this post. Feel free to view them online or download them. I would be glad if they give you some helpful ideas. And feel free to contact me via Twitter, Email or some other channel if you have any questions or remarks about the slides.

New slide decks available: Resilience patterns, Hystrix, beyond ACID transactions, CRDTs and DevOps for developers

Last week I attended the SET 2009 in Zurich. The conference – organized by <a href="http://www.sigs-datacom.de/">SIGS DATACOM</a> – is not as big as their flagship conference OOP. About 160 people visited the conference, it took two days and had a nice programme organised in three parallel tracks.I was there because I gave a talk on the problems of reuse and the potentials of design for maintenance but that’s not what I want to talk about here.In the other time I took the opportunity to attend a view other sessions and talk to other people and I’d like to talk about two interesting ideas I picked up there. First I attended a talk about the experiences with a virtual development team given by Stephan Wald. At some point in his talk he claimed that development in virtual teams only works with a certain type of developer. He said that this way of working together requires developers that are willing to collaborate a lot, share their results, document what they have done, and so on. Or to say it the other way around: Those “IT superheroes” or “lonesome cowboys” (in their self-perception) who are doing everything on their own, not sharing anything and especially not their code, do not fit in those projects even if they produce results extremely fast. The virtual approach just does not work with this kind of developers.I found this observation very interesting because I always felt somehow ambivalent about this type of “shared nothing” people. On the one hand those guys often were excellent developers that were able to save a project that fell behind schedule within a weekend (which often made them kind of manager’s darling). On the other hand they always created sort of a black hole in their perimeter making themselves irreplaceable – also within a weekend.When I talked about this at lunch with some other people another speaker just stated that he thinks those “IT superheroes” are always a problem in any kind of project. The virtual, distributed team just makes it obvious very quickly. The other people on the table agreed and I also think this guy is right. So, for me I think with virtual, distributed teams the era of “IT superheroes”, those “lonesome cowboys” should come to an end or otherwise the projects they are involved with will come to an end – much earlier than expected.The second very interesting idea I’d like to share is the talk that Peter Sommerlad, one of the authors of the <a href="http://www.amazon.de/System-Patterns-Pattern-Oriented-Software-Architecture/dp/0471958697/">first POSA book</a> and meanwhile professor at the <a href="http://ifs.hsr.ch/">Institute for Software</a> in Rapperswil. Peter gave a very interesting talk about “Decremental Development”. The idea is to get rid of all unnecessary complexity in the code and to shrink it down to a fraction of its original size this way making it easier to understand and to maintain.I found this talk very interesting because it also stressed the importance of maintainable software, no matter if it is on the architecture level that I talked about in my presentation or on the design and code level that Peter talked about. For my part I think at least at the conferences people start to realise that design and code for maintenance is the real issue that needs to be addressed badly to keep the TCO (Total Cost of Ownership) of software in balance.It is not about always picking the cheapest implementation to create a nice punctual business case neglecting the follow-up costs caused by the cheapest solution. Instead it is about optimising the total costs of an application regarding the whole lifecycle of the application – and maintenance is the by far biggest part of an IT applications lifecycle.I think when people start to become aware about this at those conferences it might still take a while until it becomes common understanding but it is definitely a step in the right direction.Those were the two ideas I wanted to share. One last tip: If you should ever go to the SET use <a href="http://www.zvv.ch/zvv/en/home.html">public transport</a> . If you are – as I am – used to the common delays of the Deutsche Bahn it is simply great using public transport that is so punctual and reliable that use can set your clock to its schedule. Hence, use public transport, relax and enjoy it … 😉

Impressions from the SET 2009 in Zurich

Enterprise Architecture Management (EAM) is an important issue for most enterprises, not only the big ones. But its implementation still bears a lot of risks and the results are often way beyond the initial expectations.Dr. Ingo Schrewe from <a href="http://www.incowia.com/">incowia GmbH</a> and I wrote an article how agility can help to reduce risk and optimise the results when implementing an EAM. The article was published within the scope of an EAM online special by SIGS-DATACOM and can be downloaded here: http://www.sigs.de/publications/os/2010/EAM/friedrichsen_schrewe_OS_EAM_10.pdf (available in german language only)Ingo Schrewe and I plan to continue this article by writing some more articles that provide practical guidelines, hints and examples how to establish an agile EAM … whenever we will find the time to write those articles … 😉

Agility and EAM

All right, now I’m trying to write the probably shortest post ever published in the codecentric blog … 😉So, what’s it about?I just wanted to point out for those who do not know yet that <a href="http://www.bredemeyer.com/">Dana Bredemeyer</a> will conduct his well-known Software Architecture Workshop at codecentric from Sep-13-2010 to Sep-16-2010. Dana haven’t had an open enrollment for this workshop in Germany for almost 10 years and from all I’ve heard about it this will be a great course. So, if you are interested in that workshop and do not want to travel to the United States for that you might want to take a look at <a href="https://www.codecentric.de/wissen/schulungen/">http://www.meettheexperts.de/software-architecture</a> .Also, I wanted to mention our “Meet the Experts” on Sep-17-2010. “New challenges in architecture today” will be the topic. Five well-known speakers, including Dana Bredemeyer, Dr. Gernot Starke and Prof. Dr. Heinz Züllighoven will share their ideas in insights with you. And, as always there will be a lot of time for discussions, networking, open space for your questions, great catering, and so on. So, if that sounds interesting for you, just have a look at http://www.meettheexperts.de/meettheexperts-architektur.Okay, that’s all I wanted to talk about. I think those sessions will be great stuff, I will be there for sure. And if you will be there too, I’ll be glad to meet you … and if not, maybe we’ll meet some other time …

Software Architecture Workshop with Dana Bredemeyer and Meet the Experts

Meanwhile I know <a href="http://www.opengroup.org/togaf/" target="_blank">TOGAF</a> for several years but I never found the opportunity to use it in its whole breadth in a customer project. For any actual project situation TOGAF with all its phases and result artifacts always seemed to be just too much to use it straightforward. I always was sort of afraid to frighten off my customers if I would talk about more than a dozen phases and sub phases and lots of result artifacts to be produced. So I usually tended to use a more “lightweight” architecture lifecycle framework consisting of only a few phases and artifacts that fitted the requirements of my customers pretty well.Then a few weeks ago I had the opportunity to attend the Open Group Conference in Munich, one of the largest gatherings of TOGAF experts worldwide. So I was very curious to talk to these experts, what their experiences were. Did I just have the wrong projects for TOGAF in the past? Did I miss an important point? Or would they share the same experiences I had?So, when attending the case studies and talking to other people at the conference I always got the same answer: No one of them used TOGAF “pure”. All of them tailored TOGAF according to their specific customer requirements which usually meant simplification: Phases were pooled together, dropped or renamed. The result artifacts were also simplified, dropped or renamed. In one case they compressed the framework down to four phases and did not mention the term “TOGAF” at all, just to avoid discussions about the architectural framework complexity with the customer.On the other hand everybody agreed that TOGAF is a really good framework which is very well suited to get a grasp of what is important to architecture lifecycle management and to start any non-trivial architectural effort. In the context of an actual project though, the framework usually has to be customized or simplified to suit the projects constraints – even radically if required.This feedback was very interesting for me since it somehow confirmed my former approach: Do not customize the customer to suit the needs of the framework but select and customize the framework to suit the needs of the customer. And a framework of the size of TOGAF is usually just about a magnitude too large for most customers and projects. Hence most of the time you have to simplify the framework to suit the needs of the customer. Of course there are also projects that require the complete TOGAF in its whole and unlimited beauty. But due to the size of these projects they are quite rare.By the way this is an experience I had for most non-trivial methods and frameworks – also in different areas: Most of them give you a good idea of what areas you should look at when dealing with the topic they cover but you use them quite rarely in their pure form. Most of the time you have to customize, i.e. simplify and modify them to work with your specific customer and project.Remember: The goal is to create business value, not establishing methods and frameworks – those are just a means to an end.

TOGAF applied

Michael Nygard is a well-known software engineer and architect. He designed and delivered some large-scale systems in his career and distilled some of his insights in his book Release It! [1]. He is also a renowned expert in the area of microservices. This month, he is visiting Germany to give his workshop “Monolith to Microservices” in Solingen and Munich. We had the opportunity to interview him.Uwe Friedrichsen: Microservices are no longer a hype. They have become reality in many companies. Even more companies have just started picking them up. And some companies with special requirements like Segment already <a href="https://segment.com/blog/goodbye-microservices/" target="_blank">stopped using them</a> [2]. What is your opinion regarding microservices? Are they the long-searched-for panacea as some say? Or are they Pandora’s Box as others say? How do you experience microservices?Michael Nygard: As the saying goes, there’s no silver bullet. Microservices are a technological solution to an organizational problem. That problem is, “How do I scale my development team without paralyzing development flow?”I also think microservices are the result of failures in our operating systems, languages, and frameworks. Basically, the goal is fault isolation and independent deployment. We want each team to deploy on their own schedule without causing downtime to other teams. We also want to prevent bad code in one service from harming others. This is only partly achieved with microservices today. Third, we want to isolate the OS level namespaces—IP addresses, TCP ports, file names, directory contents, etc.—from each other. Finally, we want to enforce architectural boundaries between the services. Do these really require us to run thousands of containers, each with their own operating system image?Uwe: You already touched upon it in your previous answer, but just to get to the heart of it: when do you think, using microservices is a good idea?Michael: They’re a good idea when you need independent deployment across multiple teams.<blockquote>The reality is that adopting this architectural style means constant redesign and evolution.</blockquote>Uwe: While I feel I already know your answer, let me ask you nonetheless: when should you better refrain from using microservices?Michael: If you are a small team working cohesively, like in a single room, then you are better off avoiding the operational complexity of microservices.Uwe: If you look at your customers, what are – based on your experience – their biggest challenges when picking up microservices? What do they really struggle with?Michael: There are two big hurdles. First, many people pick up microservices but don’t do enough design of the APIs between the services. As a result, they build a distributed ball of mud, where every service can call every other service. That results in rigidity at a higher level, since nobody is free to change their APIs.Second, a lot of groups that pick up microservices think they’re just going to design things once, build a set of microservices, and then be done with it. The reality is that adopting this architectural style means constant redesign and evolution. You may delete a service that you just created last month, and you have to be willing to accept that. It can be uncomfortable, because we’re used to thinking of code as a long-lived asset.Uwe: Facing those challenges: what are your recommendations? What are the most important topics people and companies should be aware of if they decide to adopt microservices?Michael: First, they need to be aware of the nature of distributed systems development. Developers should be comfortable drawing Lamport diagrams and talking about idempotent messages versus “exactly once” delivery infrastructure. That’s already a prominent part of system design and it will only become more important. I extend this all the way to the front-end as well, by the way. Modern front-ends are applications in a distributed system with all the uncertainty and asynchrony that implies.Second, I think developers have gotten plenty of discussion about the virtues and perils of microservices, but most have little experience designing the services and evolving their APIs. What I mean by that is, you can find hundreds of tutorials about setting up Kubernetes or how to use Docker to deliver your code to production. But there isn’t as much about how to design a good service, let alone how to build a whole system out of such services. Developers must avoid falling into the trap of making their microservices act like distributed objects or entity services. That was a big part of the motivation behind my “Monolith to Microservices” workshop. In that class, developers build real services and we talk extensively about making usable, evolvable APIs.<blockquote>You can find hundreds of tutorials about setting up Kubernetes or how to use Docker to deliver your code to production. But there isn’t as much about how to design a good service.</blockquote>Uwe: Okay, that is quite a bit to ponder regarding the adoption of microservices. Let us finish with a look into the crystal ball: Do you think microservices will still be relevant in five years? Or will they be replaced by a new paradigm? Or will we be so absorbed with totally different challenges that we simply won’t care?Michael: I’m going to predict what I think should happen, in the hopes that I can simply wish it into being true. Our languages and platforms today don’t help developers express the design of a distributed system. We’ve got languages for writing code that runs inside a process on one machine. Then we try to assemble that code together with functions-as-a-service, a pile of infrastructure-as-a-service using some other languages and tools. Then we somehow expect that the assembly respects the wire protocols, preconditions, and invariants that we planned for our system. Yet there’s no way to assist the humans in making the whole assembly correct.By that I mean that we have things like unit tests, type checkers, linters, and so on that help us get the code right that runs inside a single process. But when it comes to coordinating processes across a network, we don’t have tools to assist the developer or designer. So what I’d like to see in five years is something like this: We have a true distributed operating system, in the same sense as a server operating system. It provides an abstraction over hardware, resource management, an API, visibility, operational tools, etc. We have a language that lets us describe the connections between processes in terms of their data formats and invariants, and we use the same language—or something very similar—to describe the code inside the processes. When we hand a system written in that way to the operating system, it will be the job of the OS to make everything run with the right network rules, security protections, isolation, and so on.I think we can see the beginnings of such a world right now. But each installation is a unique combination of off-the-shelf parts. So you might have Kubernetes, Helm, and Istio, running on AWS with Lambda, etc. I might be using Terraform, Consul, Vault, with applications in Clojure with Clojure.spec. It would be like if every server ran its own hand-crafted version of Unix.Uwe: Thanks a lot for the interview, Michael!A German translation of the interview was previously published on <a href="https://www.heise.de/developer/artikel/Microservices-sind-keine-Patentloesung-Ein-Interview-mit-Michael-Nygard-4142196.html" target="_blank">heise Developer</a> .<img width="250" height="347" src="https://media.graphassets.com/JYtmYUvnTenFShtDHyRw" alt="Michael Nygard on Microservices" />Michael Nygard has been a professional programmer and architect for more than 15 years. He has delivered running systems to the U.S. government and to the banking, finance, agriculture, and retail industries. Michael is a popular speaker at technical conferences, and has written and co-authored several books, including Release It! [1] and 97 Things Every Software Architect Should Know [3].<h2>References</h2>[1] Michael Nygard, Release It!, 2nd edition, Pragmatic Programmers, 2018[2] Segment Blog, Alexandra Noonan, Goodbye Microservices: From 100s of problem children to 1 superstar, see <a href="https://segment.com/blog/goodbye-microservices/" target="_blank">https://segment.com/blog/goodbye-microservices/</a> [3] Richard Monson-Haefel (Ed.), 97 Things Every Software Architect Should Know, O’Reilly, 2009

Microservices all the way down – An interview with Michael Nygard

Weitere Infos

Details

Sprich mich gern an

Komm zu unserer Konferenz, ich freue mich auf den Austausch mit dir! Hast du vorher schon Fragen?

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Ich habe die \nDatenschutzbestimmungen\n und die Einwilligung in die Datenverarbeitung gelesen und stimme diesen zu.*

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Kontakt

Absenden

Resilient Software Design - The Past, the Present and the Future

CloudLand 2023

Weitere Infos

Details

Sprich mich gern an

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten