Software Architecture Summit 2017 in München
Der Software Architecture Summit ist das große Trainingsevent für alle Softwarearchitekten, Senior-Entwickler und IT-Projektleiter. Die Konferenz umfasste zwei Tracks, 12 halbtägige Workshops, vier Keynotes und eine Nightsession am zweiten Abend. Teilnehmer profitierten von der Praxiserfahrung der bekanntesten nationalen und internationalen Architekturexperten.
Montag
Keynote: Nicole Forsgren – The Data on DevOps: Making the case for Awesome
Den Anfang der Konferenz machte Dr. Nicole Forsgren, CEO von DORA (DevOps Research & Assessment). Sie beschäftigt sich in ihrer täglichen Arbeit mit dem Einfluss von DevOps auf die IT in Unternehmen und die Unternehmen selbst. Die Daten die ihre Forschung hervorbrachte und die Erkenntniss daraus waren das Hauptthema ihrer Keynote. Um es vor weg zu nehmen, DevOps ist super und ein Großteil von Unternehmen profitieren sehr stark davon.
Sie geht kurz darauf ein, was DevOps ist, nämlich Continous Delivery, Management nach Lean Prinzipien und eine gesunde Unternehmenskultur. Laut ihren Daten zeigt sich, dass DevOps mehr Durchsatz und mehr Stabilität liefert und führt gleichzeitig zu zufriedeneren Angestellten. Dazu führt sie Beispiele von Yahoo, Amazon und anderen namhaften Firmen an.
Besonders Innovation durch Experimente ist ein wichtiger Punkt hierbei, doch dafür muss die Unternehmenskultur stimmen und die technischen Möglichkeiten geschaffen werden.
Vormittags-Workshop: Nicole Forsgren – Building DevOps Greatness with Culture
Forsgren war nicht nur eine Keynote-Sprecherin sondern gestaltete auch zwei Workshops in denen sie die Themen aus ihrem Vortrag tiefer betrachtete. Im ersten ging sie näher auf den kulturellen Aspekt von DevOps ein und im Nachhinein betrachtet, versuchte sie auch ihren Vortrag nach diesem Gesichtspunkt zu gestalten.
Sie startete mit einer Vorstellungsrunde mit den üblichen Kriterien Name, Firma und Industriezweig, aber interessanterweise sollte jeder auch ein Tier nennen, welches er mit seiner Unternehmenskultur verbindet. Diese Frage regte zum Nachdenken an und es gab sehr viele unterschiedliche Antworten von den Teilnehmern.
Als nächstes sollten wir uns bereits zu kleinen Gruppen zusammenfinden um uns zum Thema hinzuarbeiten, die Fragestellung war was DevOps überhaupt ist und warum uns das interessiert. Sie wollte darauf heraus, welche wichtige Rolle die Unternehmenskultur für DevOps spielt und kam damit zu der bereits in ihrer Keynote angesprochenen Westrom Culture. Westrom beschreibt drei grobe Kulturen die in Unternehmen vertreten sind: Pathologisch, Bürokratisch und Generativ, wobei letzteres die sinnvollste ist. Wir wurden kurz gebeten, unser eigenes Unternehmen einzuschätzen, wobei sich die meisten schon eher als generativ bezeichneten.
Den Abschluss bildeten mehrere Gruppenarbeiten zu den Themen Werkzeuge und Automation als Treiber von DevOps und wie diese die Kultur mit gestalten.
Ihre Hauptaussage war, dass DevOps davon handelt zusammen zu teilen und zu lernen und das hat sie mit diesem Workshop sehr gut demonstriert, da durch eine gesunde Atmosphäre und Zusammenarbeit gute Ergebnisse entstanden sind.
Nachmittags-Workshop: Nicole Forsgren – Measuring DevOps Greatness with Metrics
Der zweite Workshop von Forsgren behandelte dann Metriken im Zusammenhang von DevOps. Metriken sind wichtig, da ein Ziel von DevOps im Sinne von Lean Management die kontinuierliche Verberssung von Prozessen ist. Allerdings kann man nichts verbessern, was man nicht gemessen hat.
Forsgren stellte außerdem klar, dass es gleichzeitig wichtig ist immer mehrere Dinge zu messen und außerdem nur Dinge zu messen, die einen Vorteil bringen.
Dies führte uns dann zu einer ausführlich Übung mit Libby Boxen. Libby Boxen dienen dazu, mit Stakeholdern gemeinsam sinnvolle Metriken zu finden, die auf verschiedenen Ebenen eines Unternehmens wichtig sind. Sie bestehen aus 4 Boxen, die aus den Schnittmengen von “Eingabe / Ausgabe” sowie “Konzept / Daten” entstehen.
Man beginnt in der Konzept-Ausgabe Box und überlegt, welche Effekt man erreichen will. Anschließend prüft man, welche Eingabe-Konzepte die gewünschte Ausgabe beeinflussen. Wenn diese beiden feststehen, werden mögliche Daten die diese Konzepte messen würden, betrachtet.
Libby Boxen helfen eine solche Diskussion zu fokussieren und sie sind außerdem auch verkettbar, indem die Eingaben-Konzepte die neuen Ausgabe-Konzepte eines neuen Box-Sets werden.
Abschluss Keynote: Stefan Tilkov & Gernot Starke – Architekturtransformationen in der Praxis
Der Abschluss vom ersten Tag war ein gelungener Vortrag über dass, was Konferenzbesucher am Ende erwartet, wenn man wieder in den Arbeitsalltag einsteigt und seinen Kollegen und/oder Chefs von den Neuerungen berichtet.
Tilkov und Starke beschreibten humorvoll verschiedene Stereotypen von Personen auf die man treffen kann, wie zum Beispiel den Ja-Sager, der eigentlich Nein meint und versucht die Diskussion einfach auszusitzen. Abwechselnd stellten sie die Stereotypen vor, machten aber auch klar, dass alle von ihnen ihre Gründe haben, die man verstehen sollte, aber sich nicht zu eigen machen muss.
Außerdem ist es wichtig auch seine eigenen Gründe zu hinterfragen, ob diese wirklich dem Sinne der Verbesserung dienen. Ganz schlecht ist zum Beispiel der Grund irgendetwas zu benutzen, weil es große Firmen wie Google auch benutzt ohne zu verstehen warum.
Allerdings boten die beiden auch einige Vorgehensweisen im Sinne eines alten Textadventures. Wichtig ist vor allem viel politisches Geschick und das Wissen, dass Veränderungen schwierig sind.
Dienstag
Keynote: Kevlin Henney – Old Is the New New
Der Start an diesem Konferenztag begann mit einem interessanten Vortrag von Henney. Er sprach davon, dass viele Architekturmuster und Prozessmuster schon sehr viel eher als bekannt entwickelt wurden. Scrum bspw. wurde Mitte der 90er Jahre entwickelt und war damals sehr viel Menschen- und Entwicklerfreundlicher. Dies war ein interessanter kleiner Exkurs in die Geschichte vieler bekannter Namen und am Ende blieb nur, was denn dann als neues noch übrig bliebe. Laut Henney ist die nur die Biologie, was er anhand de E.coli Bakteriums kurz demonstrierte.
Vormittagsworkshop: Stefan Toth – Architektur Kata Live
Nach der Keynote war eine Architektur Kata angesetzt. Zum Glück konnte ich hier teilnehmen, weil der Raum doch recht voll war. Es wollte mehr Leute diese Veranstaltung besuchen, als von den Veranstaltern erwartet wurde. Aber mit ein paar zusätzlichen Stühlen konnte noch ein paar mit rein.
Die Kata selbst wurde von Toth sehr gut geführt. Er sprach kurz darüber, was das eigentlich ist und worum es geht und stellte dann drei Aufgaben vor. Einmal eine Heimautomationslösung und zum anderen ein Entertainmentsystem für NFL Fantasy Ligen. Den Rest der Zeit verbrachten wir in kleinen Gruppen und entwarfen Systeme. Dies wurde immer wieder von kleinen Peer Review Runden unterbrochen, in denen wir unsere Ergebnisse anderen Gruppen vorstellten.
Nachmittagsworkshop: Kevlin Henney – Breaking Rocks
Am Nachmittag gab es eher einen Vortrag als einen richtigen Workshop. Wir standen zwar mehrmals in kleinen Gruppen herum und diskutierten diverse Fragestellungen, aber der Großteil war Frontal vom Sprecher. Nichts desto trotz war die Session recht unterhaltsam.
Mittwoch
Keynote: Gregor Hohpe – Denken wie ein(e) Architekt(in)
Die letzte Keynote dieser Konferenz beschäftigte sich mit dem Bild des Architekten selbst in der heutigen Landschaft von DevOps & Co. Leut Hohpe sind Architekten wie Gärtner, Stadtführer, Showzauberer oder auch Hofnarren.
Sie sollten ein Verbindungsglied zwischen Management und Entwicklern sein, aber auch auf allen Zwischenebenen erfolgreich kommunizieren können. Dabei ist es wichtig immer das große Ganze zu betrachten und immer auf das Verhalten zu fokussieren.
Vormittagsworkshop: Lars Röwekamp – CQRS meets REST
Röwekamp bot einen sehr guten Überblick über CQRS, aber leider blieb die REST Betrachtung ziemlich auf der Strecke und es ging mehr um eine Einführung in CQRS, was mir leider schon ausführlich bekannt ist von unseren Erfahrungen mit Rails Disco.
Nachmittagsworkshop: Uwe Friedrichsen – Resilient Software Design kompakt
Auch Friedrichsen bot nur einen Vortrag, dafür war für mich das Thema interessanter. Sein Hauptaugenmerk galt der Tatsache, dass sich Fehler besonders in verteilten Systemen nicht vermeiden lassen und es daher wichtiger ist die Recovery Zeit zu minimieren als die Zeit wie häufig Fehler auftreten. Im Abschluss entwickelte eine recht große Taxonomie zu Resilience mit allen wichtigen Begriffen.
Damit waren drei Tage Konferenz in München abgeschlossen. Nun geht es darum, die gelernten Themen auch anzuwenden und damit neue spannende Projekte zu gestalten.