The post Keynote: Revolutionizing Java-Based Cloud Deployments with GraalVM appeared first on JAX.

Was ist eine Wardley Map?

Wir betrachten ein beispielhaftes Szenario, das sich an einen realen Anwendungsfall anlehnt. In diesem Szenario bietet ein Unternehmen seinen Kunden eine Übersicht über Verträge und Leistungen über ein webbasiertes Kundenportal an. Das Kundenportal greift auf ein cloudbasiertes CRM-System und auf ein internes System zur Vertragsführung zu. Letzteres ist an eine Standardlösung von SAP angebunden, um Ein- und Auszahlungsvorgänge abzuwickeln. Kundenportal, Vertragsführung und SAP werden inhouse im eigenen Rechenzentrum betrieben, das CRM wird als Software-as-a-Service-Angebot genutzt. Zusätzlich entwickelt das Unternehmen eine Kunden-App, die über ein Backend an das Kundenportal angebunden ist. Die App soll dessen Funktionen auch zur mobilen Nutzung anbieten. Die Entwicklung von App und Backend hat gerade erst begonnen.

_{Abb. 1: Eine Landkarte des Beispielszenarios}

Abbildung 1 zeigt eine Wardley Map unseres Szenarios, bestehend aus einem Bezugspunkt (Anchor) und miteinander verbundenen bedeutsamen Dingen (Components). Der Bezugspunkt ist der Nordpfeil unserer Landkarte, Positionen werden relativ zu diesem Bezugspunkt in der Karte vermerkt. Auf unserer Karte ist der Kunde der Bezugspunkt, alle Components werden also bezogen auf den Kunden ausgerichtet. Direkt verknüpft mit dem Bezugspunkt sind Components, die Bedarfe (Needs) repräsentieren. In unserem Fall drückt die Map aus, dass der Kunde mit den Components „App“ und „Kundenportal“ interagiert.

Components repräsentieren alle Dinge von Bedeutung im Kontext unserer strategischen Betrachtung. Es handelt sich um Abstraktionen, maximale Vereinfachungen komplexer Zusammenhänge. Softwaresysteme können ebenso in einer Map als Component vorkommen wie Dienstleistungen, Wissen oder physikalische Kräfte. Daumenregel: Ist es strategisch bedeutsam, wird es als Component Teil der Map.

Die Ausrichtung der Components erfolgt entlang der vertikalen Achse (Value), abhängig von der Sichtbarkeit des Werts für den Kunden (unser Bezugspunkt, Anchor). Components, mit denen der Kunde direkt interagiert, sind für ihn auch direkt wahrnehmbar und werden daher weiter oben angeordnet. Weiter unten stehende Components sind, relativ zum Bezugspunkt Kunde, weniger sichtbar – aber nicht weniger wichtig. Der Wert einer Component und seine vom Bezugspunkt aus wahrnehmbare Sichtbarkeit sind zwei voneinander zu unterscheidende Merkmale. Durch die Verbindungen zwischen den Components ergibt sich eine Wertkette (Value Chain), bei der Components aufeinander aufbauen.

Je weiter oben sich eine Component befindet, umso erkennbarer ist ihr Wert für den Kunden, je weiter rechts sie sich befindet, desto höher und reifer ist sie entwickelt. Die horizontale Achse beschreibt den Grad der Entwicklung (Evolution). Dieser sagt etwas über den Charakter der jeweiligen Component aus: Stellen wir ein Softwaresystem als Component am linken Rand der Map dar, sagen wir damit aus, dass das System sich am Anfang seiner evolutionären Entwicklung befindet. Gleiches gilt für Components, die Wissen oder Methoden repräsentieren. Steht eine Component weit links, kann das beispielsweise bedeuten, dass Technologien oder Konzepte eingesetzt wurden, zu denen bisher im Unternehmen wenig Wissen verfügbar ist. Dadurch erhält die Component im betrachteten Kontext experimentellen Charakter. Das birgt Chancen für neuartige Ideen und somit künftiges Potenzial sowohl für Wettbewerbsvorteile als auch für Risiken. Am linken Rand der Evolutionsachse sind die Unwägbarkeiten hoch. Je weiter eine Component sich entlang der Achse bewegt, umso reifer wird sie, d. h. umso geringer die Unwägbarkeit, und umso besser lassen sich Chancen und Risiken erkennen und bewerten. Die Einteilung der Achse in vier Segmente verdeutlicht das: Im ersten Segment (Genesis) findet die „Werdung“ statt. Der Fokus liegt auf der Erforschung und Erkundung und der ursprünglichen Entstehung von etwas Neuem. Im zweiten Segment handelt es sich um spezifische, maßgeschneiderte (Custom-Built-)Lösungen. Im dritten Segment erhält eine Component hinsichtlich ihrer Entwicklung und Reife die Eigenschaften eines Produkts. Components im vierten Segment sind so weit entwickelt, dass sie allgegenwärtig und einfach verfügbar sind (Commodity + Utility), vergleichbar mit Elektrizität, Radioempfang oder, dank Cloud Computing, Rechenleistung. Nicht alle Components erreichen auch die höchste Entwicklungsstufe, aber sie entwickeln sich entlang der Achse in diese Richtung – freilich in unterschiedlicher Geschwindigkeit.

Nun haben wir alle Bausteine kennengelernt, um eine Karte einer bestimmten Landschaft zu zeichnen: Wir haben einen Bezugspunkt (Anchor) und können strategisch relevante Elemente (Component) relativ dazu positionieren (Value). Entfernungen zwischen den Elementen sind für uns unterscheidbar und bedeutsam (Evolution). Diese Karte können wir anderen zeigen, um über die Landschaft zu diskutieren. Der beste Weg, eine Map zu erstellen, ist, dies direkt in einer Gruppe zu tun, gemeinsam mit den jeweiligen Experten. Dabei ergeben sich wertvolle Diskussionen: „Warum ist das so weit unten?“, „Warum wird X weiter als Y entwickelt dargestellt?“, „Ist A wirklich Teil der Landschaft? Warum ist B nicht abgebildet? Wo ist C?“. Durch kritische Auseinandersetzung werden Annahmen hinterfragt und Erkenntnisse geteilt – ein gemeinsames Verständnis wird aufgebaut und weiter gefördert. Wer dabei an Domain-driven Design (DDD) und die Ubiquitous Language denkt, liegt genau richtig. Sobald wir ein gemeinsames Verständnis der Landschaft haben, können wir uns den Umgebungsbedingungen (Climate) widmen und diese ebenfalls in unsere Map übertragen.

Klimatische Einflüsse

Bodenwetterkarten enthalten neben der geografischen Abbildung der Landschaft weitere Informationen, etwa über Hoch- und Tiefdruckgebiete, Windverhältnisse, Niederschläge und Temperaturen. Die klimatischen Verhältnisse wirken auf die Landschaft ein und beeinflussen die geltenden Bedingungen. Je mehr relevante Details unsere Karte enthält, umso besser erkennen wir, dass der beste Weg von A nach B nicht zwangsläufig eine Gerade ist. Ein steiler Aufstieg an einer auf der Karte verzeichneten Felswand (Landscape) ist, je nach klimatischen Verhältnissen, anstrengend aber machbar, oder eben ein lebensgefährliches Wagnis. Dieser Informationsvorsprung ist entscheidend und stellt laut Simon Wardley den Unterscheid zwischen Maps und klassischen Methoden der Strategieplanung (siehe Kasten „Über die Methode“) dar.

Um eine erfolgreiche Strategie zu entwickeln, müssen wir uns explizit und ganz bewusst mit den Dingen beschäftigen, auf die wir keinen Einfluss haben. Während wir uns die Gegebenheiten der Landschaft zu Nutze machen und sie auch ein Stück weit verändern können, entziehen sich klimatische Einflüsse unserem Willen: Wir können sie nicht steuern, aber wir können sie entdecken und auch diese Erkenntnisse für uns vorteilhaft nutzen. Bewegungen an Märkten, strategische Entscheidungen von Wettbewerbern, technologischer oder gesellschaftlicher Wandel sind klimatische Einflüsse, die wir auf unseren Karten abbilden können und wollen.

_{Abb. 2: Wardley Maps mit klimatischen Einflüssen}

In Abbildung 2 werden klimatische Gegebenheiten genutzt, um eine Strategie zu entwerfen. App und zugehöriges Backend werden parallel vom gleichen Team entwickelt. Der gemeinsame Kontext wird durch die Umrandung sichtbar gemacht, da er für die strategische Entwicklung eine Rolle spielt. Beide Systeme sind noch in einem frühen experimentellen Status und nicht produktionsreif. Es müssen das UI optimiert und Performanceprobleme ausgeräumt werden, um eine positive Kundenerfahrung und somit Akzeptanz am Markt zu ermöglichen. Der rote Pfeil drückt die angestrebte Bewegung (Movement) entlang der Evolutionsachse aus. Die Software soll ihren experimentellen Charakter mit der Zeit verlieren und die Eigenschaften eines reifen Produkts erhalten. Die strategische Entscheidung wird zusammen mit der dafür zu nehmenden Hürde abgebildet: In unserem Fall mangelt es an Wissen und Kapazität, was als schwarzer Balken dargestellt wird. Der Balken beschreibt Inertia, die zu überwindende „Massenträgheit“. Nur wenn diese Hürde überwunden werden kann, ist der Weg frei für die Evolution von einer Eigenentwicklung (Custom Built) zu einem reifen und konkurrenzfähigen System mit Produktcharakter.

Cloud Computing ermöglicht nicht nur die Nutzung von SaaS, sondern auch alternative Betriebskonzepte für Eigenentwicklungen, was Einfluss auf die Bereitstellung hat. Der rote Pfeil beschreibt den Schritt weg vom rechenzentrumsbasierten Betrieb standardisierter VMs (Product) hin zu Container as a Service in einer Public Cloud (Commodity). Dieser Schritt ist jedoch nicht ohne Weiteres gangbar, denn auch hier existiert Inertia, also Widerstand durch eigene Trägheit. Das Know-how muss aufgebaut werden, Deployment und Betrieb erfordern neue infrastrukturelle Maßnahmen, die physische Anbindung zwischen Cloud und dem eigenen Haus muss ggf. neu dimensioniert werden. Sind diese Herausforderungen bewältigt, ergeben sich neue Möglichkeiten für andere Components auf der Map, sie können sich weiterentwickeln. Das Backend profitiert von der Umstellung auf containerbasierte Bereitstellung und kann cloudbasiert betrieben werden, sobald dieses Betriebsmodell zu einem späteren Zeitpunkt bereit ist. Die rote Linie beschreibt diese Verbindung der Components in der Zukunft. Dazu lohnt es sich, das Konzept der Evolution noch einmal genauer zu betrachten.

Evolution

Die Evolution beginnt mit dem Auftreten einer Component am linken Rand, der sogenannten Uncharted Domain (Abb. 3). Ihre Charakteristiken sind geprägt von Begriffen wie „experimentell“, „chaotisch“, „unzureichend verstanden“. Wir können schwer oder gar nicht vorhersehen, wie Dinge in der Uncharted Domain sich entwickeln werden. Daraus ergibt sich zum einen ihr hohes Potenzial in der Zukunft, aber auch ihr hohes Risiko durch eben diese Unsicherheit.

_{Abb. 3: Evolution von der Uncharted zur Industrialised Domain}

Je weiter eine Component sich entwickelt, umso mehr weicht die Unsicherheit der Gewissheit und es wird möglich, im industriellen Maßstab zu denken. Aus den ersten Laborversuchen mit transistorbasierten CPUs werden spezialisierte Kleinserien gefertigt, die später Produktreife erlangen und schließlich kostengünstig in Massenfertigungsprozessen in ausreichender Stückzahl produziert und für jeden erhältlich angeboten werden können. Je weiter wir uns auf der Map an den rechten Rand bewegen, umso mehr gelangen wir in die Industrialised Domain. Die Differenzierbarkeit zwischen verschiedenen Produkten nimmt ab, dafür sind diese wohl verstanden und lassen sich effizient her- und bereitstellen. Die Verfügbarkeit steigt rapide an, die Kosten pro Stück fallen. Je weiter entwickelt eine Component ist, umso eher kann sie die Ausgangsbasis für neue Entwicklungen sein, die dann ihrerseits wieder in der Uncharted Domain einsetzen. Aus kostengünstig in hoher Stückzahl gefertigten CPUs wurden Serverfarmen und wurde schließlich Cloud Computing, bei dem die Rechenleistung (nicht die Hardware) allgegenwärtig verfügbar ist. In unserem Beispiel ist die Evolution des Betriebsmodells vom eigenen Inhouse-Rechenzentrum hin zu cloudbasierten Containerdiensten die Basis für die technologische Weiterentwicklung des Backends. Das App-Experiment entwickelt sich zu einem reifen Produkt, je weiter es in die Industrialised Domain vorstößt.

Strategische Entscheidungen treffen

Bislang wurden die rein visuellen Eigenschaften von Wardley Maps besprochen. Mit Kenntnis der Landschaft und der Kräfte, die auf diese einwirken, können wir uns nun den strategischen Entscheidungsprozessen widmen. Kennen wir die Landschaft und die klimatischen Einflüsse, können wir individuelle Handlungen ableiten und universelle Prinzipien, die in jedem Kontext zutreffen, anwenden. Muster helfen uns dabei, diese zu erkennen und anzuwenden. Simon Wardley beschreibt dies mit den fortgeschrittenen Konzepten Doctrine und Leadership und gibt dem interessierten Leser Patternkataloge und Strategeme an die Hand, um eigene Strategien basierend auf Maps effektiver entwickeln zu können. Diese Konzepte sprengen den Rahmen dieses Artikels, sollen aber nicht gänzlich unerwähnt bleiben. Zusammen mit dem Konzept des Strategy Cycles bilden sie den wahren Kern des strategischen Mappings.

Um das zu verdeutlichen, wenden wir das gesammelte Wissen an und greifen das Pattern „No Single Method fits all“ heraus. Es besagt, dass es keine Methode gibt, die sich sinnvoll universell auf alle Components einer Map anwenden lässt. Beziehen wir das auf die unterschiedlichen Ansätze zur Softwareentwicklung und übertragen sie in das Konzept von Uncharted und Industrialised Domain, ergibt sich das Bild aus Abbildung 4.

_{Abb. 4: Verschiedene Methoden eignen sich je nach Evolutionsgrad besser}

Sowohl App als auch Backend befinden sich in der Uncharted Domain. Das bedeutet, dass mit häufigen Änderungen zu rechnen ist, sozusagen „by Design“. Dies ist eine wesentliche Eigenschaft von Components in der Genesis-Phase der Evolution und somit der Uncharted Domain. In diesem Fall bietet es sich an, mit agilen Methoden auf den steten Wandel zu reagieren, um die dadurch anfallenden Kosten unter Kontrolle zu behalten. Elemente am rechten Rand der Skala unterliegen diesem Wandel weniger stark. Ihre Charakteristiken sind wohl bekannt und somit kalkulierbar. Für Eigenentwicklungen, die es bis zu diesem Stadium schaffen, könnte (nicht muss!) Outsourcing eine Option sein. Das CRM ist beispielsweise von Anfang an als SaaS im Einsatz und keine individuelle Eigenentwicklung.

Fazit, Anwendungsmöglichkeiten und Ausblick

Wir haben die auffälligsten Merkmale von Wardley Maps angesprochen und anhand einfacher Beispiele verdeutlicht. Für fortgeschrittene Themen wie Doctrine, Gameplay und die Patternkataloge wird auf das frei verfügbare, unter CC-BY-SA lizensierte, Werk von Simon Wardley verwiesen, da dieser Artikel dafür nicht ausreichend Raum bieten kann [1], [2].

Die Entwicklung einer Map im Team kann im Rahmen eines Workshops stattfinden. Das Ergebnis kann leicht eine ganze Wand füllen. Entscheidend ist hier der nächste Schritt: Die Reduktion auf das Wesentliche, z. B. durch Aufspaltung einer Map in mehrere. Auf diesem Weg werden immer wieder neue Erkenntnisse über bestehende Annahmen gesammelt.

Im Kontext von DDD lassen sich Wardley Maps nutzen, um strategische Entscheidungen über Bounded Contexts zu treffen. Welche Veränderungen zeichnen sich ab? Welches Team und welche Methode eignen sich für welche Region der Karte? In welchen Bounded Context (nicht in welches System!) lohnen sich Investitionen, um neue Chancen nutzbar zu machen? Wardley Maps sind ein weiteres Werkzeug in unserer Designtoolbox, auf das wir im Bedarfsfall zugreifen können.

Auch wenn Wardley Maps ursprünglich für strategische Entscheidungen auf CEO-Level entwickelt wurden, können wir sie überall dort anwenden, wo wir uns ein Bild von komplexen Situationen verschaffen wollen, um fundierte Entscheidungen zu treffen. Das gilt für das strategische Architekturmanagement des Enterprise-Architekten ebenso wie für Projektleiter und System Owner, die eine vorausschauende (eben strategische) Planung betreiben wollen.

Abschließend lässt sich noch die Frage aufgreifen, ob es möglich ist, mit Wardley Maps komplexe Sachverhalte der realen Welt wirklich treffend darzustellen. Auch dazu gibt es ein mehr als treffendes Zitat von Simon Wardley: „All models are wrong but some are useful.“

Links & Literatur

[1] Ebook von Simon Wardley, frei verfügbar als Serie von Blogposts: https://medium.com/wardleymaps
[2] Projektseite mit Referenz und Artikeln für den Einstieg: https://learnwardleymapping.com/

The post Domain-driven Design: Strategisches Mapping mit Wardley Maps appeared first on JAX.

Kevin Goldsmith, CTO bei Avvo, gab mit seiner Keynote den offiziellen Startschuss für die JAX. Unter dem Titel „Fail Safe, Fail Smart, Succeed!“ gab er dem Auditorium mit in die Konferenzwoche, dass Innovationen Fehlschläge brauchen. Denn wer sich nicht traut, zu scheitern, traut sich auch nicht, Neues auszuprobieren. Deswegen ist für den Softwareentwickler, in dessen Lebenslauf so klangvolle Namen wie Adobe, Microsoft und Spotify stehen, eine Arbeitsumgebung wichtig, die „fail-safe“ ist.

Für ihn bedeutet fail-safe aber nicht, dass Fehler nicht vorkommen, sondern, dass es sicher ist, zu scheitern. Es darf nicht darum gehen, Fehler unter den Teppich zu kehren oder einen Sündenbock zu finden.

„Nehmt den schnellsten und günstigsten Weg zum Lernen“, war ein weiterer seiner Tipps. Dann bleiben das Risiko und die Kosten von Fehlschlägen überschaubar. Als Gegenbeispiel nannte er den grandios gescheiterten Assistenten von Microsoft Karl Klammer. Er entstand im stillen Kämmerlein ohne jegliches Nutzerfeedback, und auch wenn die Idee dahinter gut war, fanden die Anwender den Assistenten einfach nur nervtötend.

Im Anschluss an seine Keynote haben wir Kevin zum Interview gebeten. Im Gespräch mit Sebastian Meyen geht er auf die Notwendigkeit ein, eine Experimentalkultur im Unternehmen zu etablieren, die Innovation fördert. Wie kann ein Unternehmen es schaffen, Fehler zuzulassen und sie als Gelegenheit zu begreifen, zu lernen? Wie lassen sich Systeme bauen, die, anstatt nur auf Fehlervermeidung ausgelegt zu sein, Fehler antizipieren und diese verarbeiten?

2. Mehrsprachigkeit macht glücklich

Keine Angst vor der polyglotten Programmierung war die Botschaft der Session von Mario-Leander Reimer, Cheftechnologe bei QAware. Er zeigte seine Idealvorstellung einer Anwendungsentwicklung, samt Tools und Sprachen. Unter anderem brach er eine Lanze für Kotlin. Die Sprache treffe genau „den Sweet Spot zwischen Java und Scala“. Er ermutigte seine Zuhörer, mit Sprachen zu experimentieren. Man müsse nicht jede Sprache so gut beherrschen wie die Muttersprache Java. Oft reiche ein Grundverständis aus, um „langweiliges Zeug“ beispielsweise in Groovy mit Skripten wegzuautomatisieren.

Interview zu Sinn und Grenzen des polyglotten Programmierens mit @LeanderReimer https://t.co/8bnh8II7S5

— JAXenter (@JAXenter) May 12, 2017

3. Sein oder Nichtsein: Java 9 und die Debatte um Jigsaw

Punktgenau zur Eröffnung der JAX 2017 ließ das Exekutivkomitee des Java Community Process (JCP) die Bombe platzen: Das Java-Kerngremium hatte sich in einer Abstimmung gegen den Entwurf des Java-9-Modulsystems (aka Jigsaw) entschieden. Lange Gesichter bei Oracle. Ergebnis dieses negativen Votums: Die Jigsaw-Spezifikation muss nochmals überarbeitet werden. Und, wie sich dann herausstellte, wurde dadurch auch eine erneute Verschiebung des gesamten Java-9-Release notwendig.

Das Thema wurde auf der JAX natürlich ausführlich diskutiert. Da prominente Vertreter aus dem Java-Kernteam vor Ort waren, haben wir die Gelegenheit für Interviews genutzt. Rémi Forax aus der Jigsaw-Expertengruppe machte deutlich, dass an dem Modulsystem an sich kein Weg mehr vorbei führt.

Die Weichen für Jigsaw sind längst gestellt: Bereits seit Java 8 ist ein Modulkonzept Teil des JDK, viele der geplanten Features für Java 10 bauen auf Jigsaw auf. Nicht zuletzt hängt die Strategie, neue Java-Versionen zukünftig häufiger und agiler zu veröffentlichen, von Jigsaw ab. Fazit: Das Modulsystem wird kommen – daran führt kein Weg vorbei!

4. Modularisierung – aber bitte mit Fokus auf die Fachlichkeit!

Entspannt sieht übrigens Java-Champion Adam Bien die Jigsaw-Debatte: „Ich warte schon seit 2007 auf Jigsaw“, hat er uns im Interview verraten. Kommt es da also wirklich auf weitere acht Wochen Verschiebung an? Aber Adam äußerte auch Bedenken: Mit Jigsaw sollte man nicht in die Falle tappen, sich mehr mit der Modularisierung als mit der eigentlichen Fachlichkeit auseinanderzusetzen!

Denn um genau diese Fachlichkeit ging es Adam in seiner Session „Bare Metal Design“. Ausgangspunkt war hier die Idee der Microservices, die Adam auf das Prinzip der Shared-Nothing-Architekturen zurückführt. Wenn wir es mit voneinander unabhängigen Komponenten zu tun haben, von deren interner Organisation die anderen nichts wissen, so lässt sich das Design des Quellcodes extrem optimieren. Viel Boilerplate, den gerade Java mit sich bringt, kann entfallen. Vorhang auf für das Bare Metal Design!

Starten sollte man aber nicht gleich mit einer verteilten Microservices-Architektur. Für Adam ist es sinnvoller, zunächst mit einem schlanken Monolithen zu beginnen – den er auch Thinlith oder Minilith nannte –, um dann Anforderungen aus den Fachabteilungen zu sammeln. Erst durch dieses Domänenwissen lassen sich kohärente Microservices schneiden, die auch abgeschlossene Einheiten in der realen Welt abbilden.

Das Take-away hier: Modularisierung und Microservices sind kein Selbstzweck. Nur wenn die Fachlichkeit es hergibt, sollte man diesen Ansatz wählen. Microservices zahlen sich aber dann aus, wenn eine Software aus unterschiedlichen Teilen besteht, die unabhängig voneinander ausgetauscht werden müssen oder wenn verschiedene Entwicklerteams autonom an bestimmten Komponenten arbeiten wollen.

5. Öfter mal Nein sagen

Wieder und wieder werden agile Teams, aber auch Stakeholder und Scrum Master, mit Anforderungen konfrontiert, die so nicht erfüllbar sind: ein fixer Abgabetermin bei festem Budget und Scope, die sehr dringende Anforderung an der Kaffeemaschine, am besten gestern. Viele Entwicklerteams kennen solche Schwierigkeiten.

Die Speaker des Agile Days der JAX 2017 waren sich in dieser Sache einig: Ein „Nein“ ist an der richtigen Stelle gar nicht schlimm. Volker Schmidt, Agile-Coach bei Cegeka Deutschland, verwies bereits in seinem Talk darauf, dass man sich als Entwickler kaum Sorgen darum machen muss, seinen Job zu verlieren. Und, wie im Abschlusspanel zur Sprache kam, erst Recht nicht dann, wenn man Recht hat. Agile funktioniert nämlich nur dann, egal ob auf Team- oder auf Organisationsebene, wenn eine ehrliche Kommunikation stattfindet und nicht zu bewältigende Anforderungen offen benannt werden. Die 59. Idee des Stakeholders sollte man also lieber ablehnen, falls man eh nicht vor hat, sie jemals anzugehen. Das ist besser für den gesamten Prozess und alle Beteiligten.

Zum Abschluss des #agile days der #jaxcon – das alljährliche Expertenpanel. #agility pic.twitter.com/nAQ4VZauE4

— JAXenter (@JAXenter) May 8, 2017

6. Diversität ist Trumpf

Was bedeutet Diversität für dich? Sind diverse Communitys effizienter oder innovativer? Im BoF-Panel haben wir darüber gesprochen, warum wir Diversität in unseren Unternehmen und Teams dringend brauchen. Jeder Teilnehmer hatte die Chance zu erläutern, was Diversität für ihn bedeutet und ob seine Firma versucht, Diversität nahtlos in die Unternehmenskultur zu integrieren.

Wir sprachen über die Teilnahme der Männer in der Diskussion und kamen zu dem Schluss, dass sie ihre Kolleginnen unterstützen und dabei helfen müssen, die Mauern des sogenannten Männerclubs einzureißen. Unser Panel war der lebende Beweis dafür, dass Männer Teil der Diskussion sein wollen. Denn es gab mehr männliche als weibliche Teilnehmer und sie äußerten deutlich, dass Diversität nicht nur zu einer besseren Arbeitsumgebung, sondern auch zu besserer Performance und Innovationen führt.

Unser Fazit war, dass wir die Unterhaltung weiter führen müssen, um Diversität wirklich nicht nur auf einem Makrolevel (Unternehmen), sondern auch auf einem Mikrolevel (Teams) zu implementieren.

Mit der JAX-Keynoterin Tracy Miranda haben wir uns über die Rolle von Diversität in der modernen Gesellschaft unterhalten. Auch die Fragen, was man tun kann, um die Dinge wirklich zu verändern und wie man Inklusion, Diversität und Gleichheit vorantreiben kann, werden besprochen.

7. Omen auf der JAX: Die Roboter-Challenge

Auch in diesem Jahr war der einzigartige Bernhard Löwenstein mit seiner LEGO MINDSTORMS Challenge ein substanzieller Teil der JAX in Mainz. Seit vielen Jahren begeistert er mit diesem festen Segment der JAX die Besucher, für viele ist der Workshop das Highlight unserer Konferenz.

Nachdem bei der W-JAX im vergangenen November die Roboter gegeneinander im Ring angetreten sind und sich gegenseitig herausschubsen mussten, ging es in Mainz diesmal friedlicher zu: Gleich zwei Herausforderungen galt es für die LEGO-Roboter zu meistern, zum einen die sichere Fahrt entlang einer vorgelegten Strecke, zum anderen die korrekte Auslieferung eines Java-9-Startpakets in Form einer Streichholzschachtel.

Treffenderweise konnten nur wenige Pakete abgeliefert werden – war das etwa ein Omen für die nahende Verschiebung von Java 9? Möglich wäre es. Dennoch waren die Einfälle wieder einmal grandios und die Teams kombinierten ihr Fachwissen um die Programmierung auf höchst professionelle Weise mit kreativen Konstruktionsideen. Fast jedes Team hatte eine individuelle und kreative Idee dafür parat, wo die Sensoren in den Roboter eingebaut und wie die Transportproblematik gelöst werden sollte. Die Gewinner konnten sich am Ende über ein kostenloses Tutorial aus unserem entwickler.tutorials-Angebot und eine Tasse mit dem Schriftzug I Java freuen.

8. Ohne Feedback kein Big Data

Früher entschied der Chef, und er hatte entweder ein gutes Gespür oder es ging eben schief. Heutzutage fallen immer mehr Entscheidungen auf der Grundlage von gesammelten Daten, wie Hendrik Saly, Senior IT Consultant bei codecentric, in seinem Talk zum Datengoldschürfen erklärte.

Aber damit wirklich aus Daten Gold wird, setzt er auf den OODA-Loop. OODA steht für „observe“, „orient“, „decide“ und „act“. Das Konzept beschreibt eine Feedbackschleife, die aufgrund von neuen Ereignisse immer wieder durchlaufen wird. Entscheidungen und Änderungen, die zu Taten führen, die dann aber nicht erneut gemessen werden, sind nur der halbe Weg. „Big Data ohne Feedbackzyklus lohnt nicht“, war sein knappes Statement.

9. Container drinnen und draußen

Das reichhaltige Aufgebot an Containerschiffen, die während der JAX aus der Rheingoldhalle beobachtet werden konnten, war ziemlich auffällig. Es kam einem fast so vor, als seien sie ganz speziell von den Reedereien in dieser Woche auf die Reise geschickt worden, um die Besucher der Konferenz in die richtige Stimmung zu versetzen.

Aber um Container ging es auch in zahlreichen Sessions, zum Beispiel in Philipp Garbes Talk. Er sprach über Continuous Delivery von Docker-Containern mit Amazon ECS. Im Interview mit JAXenter erläuterte er dann auch, dass sich ECS vor allem durch die gute Weboberfläche und das ECS CLI auszeichnet. Gerade Letzteres sorgt für angenehmes Arbeiten, da man mit einem Befehl ganze Cluster erzeugen und deployen kann.

10. Serverless heißt nicht less Server

Längst werden Anwendungen und Microservices zu einem großen Teil in der Cloud erstellt. Seit einer Weile geht das sogar serverless, wobei das nicht bedeutet, dass gar keine Server zum Einsatz kommen. Im Vergleich zur klassischen Methode kümmert sich allerdings der Cloud-Anbieter um das gesamte Servermanagement, nicht mehr das Unternehmen oder der User selbst.

Wie man die neue Technologie einsetzen kann, hat Niko Köbler in seinem Workshop und seiner Session auf der JAX eindrucksvoll vermittelt. Für Best Practices, so verriet uns der freiberufliche Softwareentwickler, sei es allerdings noch zu früh. Daran liegt es auch, dass das Tooling der Technologie noch nicht besonders ausgereift ist. Ein paar „Lessons Learned“ gibt es aber, nämlich unter anderem, dass es wichtig ist, auf die Latenz und das Caching zu achten.

Wir sehen uns im November!

Viel los war wieder auf der JAX. Und unser kleiner Rückblick ist sicher kein umfassendes Spiegelbild von über 170 Sessions, Workshops und Keynotes. Wir sehen uns wieder in München zur W-JAX 2017. Dann hoffentlich mit Java 9 und einer ganzen Wagenladung weiterer Themen aus und von der Java-Community.

The post 10 Take-aways von der JAX 2017: Microservices, Container, Java 9 & More appeared first on JAX.