Redaktion: Domain-driven, DevOps und Unternehmensarchitektur – das sind die drei Schlüsselworte deines Talks auf der JAX 2020. Welchen Zusammenhang gibt es aus deiner Sicht zwischen den drei Disziplinen ?

DDD und Unternehmens- architektur zeigen erst dann ihren Effekt, wenn die IT-Organisation tatsächlich etwas Nützliches an IT-Anwender abliefert.

Bernd Rederlechner: In größeren Unternehmen gibt es klassischerweise Unternehmensarchitekten, die sich als Brücke zwischen IT und Business sehen. Doch meiner Erfahrung nach fokussieren sie stark auf Standardisierung und die Auswahl von Produkten – um Einsparungen mittels eigener Plattformen und Veränderung von Infrastruktur zu erzielen.

Wegen dem fehlenden Bezug zur Software-Entwicklung hat das wohl zu einer Wahrnehmung als “Elfenbeinturm-Architekten” geführt. Wenn diese nun die strategischen Aspekte von DDD anwenden, verschiebt sich ihr Fokus hin zu den logischen, wertliefernden Strukturen der IT. Plötzlich geht es darum, mittels sinnvoller Leitlinien wie Upstream-Downstream blockierte Teams arbeitsfähig zu machen.

Umgekehrt sollte man nicht unterschätzen, dass Unternehmensarchitekten viel näher am Geschäft dran sind als IT-Techniker oder sogar Fachseiten. Sie haben Methoden wie “Capability Mapping” oder “Managed Evolution”, die DDD gut um Geschäftsaspekte ergänzen.

DDD und Unternehmensarchitektur zeigen aber erst dann ihren Effekt, wenn die IT-Organisation tatsächlich etwas Nützliches an IT-Anwender abliefert. Was nutzen die schönsten Architekturen, wenn sie erst in ferner Zukunft geerdet werden? Deshalb benötigen alle, die etwas mit IT erreichen wollen, mehr als nur Halbwissen darüber, wie man Umbauarbeiten an einer Unternehmenslandschaft so aufteilt, dass sie früh und trotzdem qualitativ hochwertig in Produktion gehen.

Taktisches DDD liefert da sicher einen kleinen Beitrag, aber DevOps bietet viel mehr. DevOps erzwingt schnelle Feedback-Zyklen und fügt der Mischung den nötigen, frühen Schuss Realität hinzu, um eine effektive Produkt- bzw. Systemlandschaft für den Unternehmenserfolg zu bauen.

Redaktion: Und was hat DevOps mit Bounded Contexts zu tun?

Bernd Rederlechner: Conways Gesetz. Klingt komisch, ergibt aber schon Sinn: Conways Gesetz sagt, dass (Unternehmens-)Software nahezu unweigerlich die Kommunikationsstrukturen der Organisation widerspiegelt.

Aus dieser Erkenntnis ist im DevOps das “umgekehrte Conway-Manöver” entstanden: Man organisiert die Teams anhand der gewählten Architektur, damit Kommunikationspfade und gewählte Systemstrukturen zusammenpassen. Ziel hierbei ist, dass die entstehenden Teams so unabhängig wie möglich von anderen Parteien agieren und unabhängige (Micro-)Services liefern können.

Aber wie sieht eine zu diesem Vorgehen passende Architektur aus? Sicherlich kein Wald von Miniatur-Services, die sich wild gegenseitig aufrufen. Da fehlt die Entkopplung.

Bounded Contexts machen deshalb den Unterschied: Sie grenzen Bereiche mit einer unterschiedlichen Sicht auf die Geschäftswelt gegeneinander ab. Innerhalb des Kontexts arbeiten alle mit einem gemeinsamen Modell, also einem gemeinsamen Verständnis von der Realität: Ein Team, dass sich mit dem Erzeugen von Rechnungen beschäftigt grenzt sich beispielsweise durch seine Weltsicht von einem Team ab, das Online-Werbung produziert. Die Vereinigung vieler solcher schnell liefernder Teams mit ihren getrennten Kontexten ist die Basis für eine hochperformante Lieferorganisation nach DevOps.

Das wirkt so stark vereinfacht wie aus einem Werbeprospekt für Manager. Im Vortrag wird es unterhaltsamer und konkreter – versprochen.

Software-Architekten als Wertbeiträger

Redaktion: IT-Architektur ist allgemein ein breit gefächertes Gebiet – ebenso unterschiedlich ist das Rollenverständnis unter IT-Architekten. Worin siehst du persönlich in deiner Position als IT-Architekt deine Hauptaufgabe? Was ist dir besonders wichtig?

Für mich hat immer dazugehört, möglichst gute IT-Strukturen dem Chaos entgegenzustellen.

Bernd Rederlechner: Tatsächlich hatte ich das Glück (oder Pech?), in allen drei Bereichen arbeiten zu dürfen. Dabei hat für mich immer dazugehört, möglichst gute IT-Strukturen dem Chaos entgegenzustellen und technische Schulden als Zukunftshypothek wo immer möglich zu vermeiden. Die Welt rundherum erwartet das implizit von einem. Man kann damit sicher seine gesamte Zeit verbringen und sich von den realen Liefer-, Produktions- und Kundenherausforderungen fernhalten.

Aber irgendwann wird der IT-Architekt feststellen, dass er so als “Verkomplizierer” von den Geschäftsbereichen wahrgenommen wird, nicht als “Wertbeiträger”. Respekt auf Geschäftsebene gewinnt der, der mit den Methoden z.B. aus DDD, DevOps oder Unternehmensarchitektur Lieferblockaden auflöst und dafür sorgt, dass Verbesserungen durch IT auch tatsächlich wirksam werden.

Mit kleinen Erfolgen und einem guten persönlichen Image ergibt sich oft irgendwann die Möglichkeit, die neuen Methoden weiter ins Unternehmen zu tragen. Zumindest bleibt aber immer die Befriedigung, jemandem tatsächlich mittels Architektur geholfen zu haben.

Redaktion: Welchen Architektur-Trend findest du momentan besonders spannend?

Bernd Rederlechner: Ich feiere natürlich das Revival von DDD. Vor allem zwei Bereiche haben meine besondere Aufmerksamkeit: Zum einem sehe ich die Rückkehr von Modellen, die sowohl Entwickler als auch Nicht-ITler lesen können. Mit graphischen Notationen sind wir da ja schon mal grandios gescheitert. Die Idee, den Code zum gemeinsamen Modell für IT und Business zu machen, halte ich für pragmatisch und vielversprechend – wenn die Entwickler mitmachen…

Zum anderen wird Event Sourcing die Architektur von großen Anwendungen und Unternehmenslandschaften fundamental verändern. Beim Event Sourcing veröffentlicht ein Bounded Context geschäftliche Ereignisse für die Nutzug durch die Allgemeinheit. Das fördert nicht nur eine Kultur der Offenheit und des Teilens in Organisationen und sorgt für Entkopplung. Konsequent zu Ende gedacht stehen Streaming Event-Architekturen: Statt nur den aktuellen Zustand z.B. eines Vertrags oder Kunden zu verwalten, bewahren so designte Systeme und Landschaften alle geschäftlichen Veränderungen als Ereignisse auf. Zustand wird nur noch aus den Ereignissen für jeden gewünschten Zeitpunkt rekonstruiert. Sie ermöglichen das Beobachten von Verhalten und öffnen ganz neue Bereiche, wo IT das Business unterstützen kann.

Redaktion: Und welches Thema im Bereich der Software-Architektur ist deiner Meinung nach im aktuellen Diskurs etwas unterbelichtet?

Bernd Rederlechner: Ich sehe immer noch, dass Entwickler und Architekten Technik um der Technik willen bauen. Das ist zwar nicht falsch, aber immer schwerer geschäftlich vertretbar. Warum benötige ich beispielsweise meine eigene Installation eines Streaming-Clusters, wenn ich einen auf Knopfdruck in der Cloud schneller und unterm Strich auch günstiger bekommen kann? Überall dort, wo man eine neue Technologie so nutzt wie alle anderen, wird man in Zukunft immer mehr gezwungen sein, fertige Services einzusetzen.

Verbündet Euch mit den Architekten und Entwicklern aus anderen Disziplinen und Fachbereichen.

Budget zum Ausprobieren cooler Sachen wird dorthin fließen, wo Eigenentwicklung mein Unternehmen am Markt differenziert. Wie also arbeiten IT-Architekten, die konsequent Teile eines Systems durch PaaS/SaaS-Services ersetzen, sobald sie Mainstream geworden sind? Wie müssen Architekturen gestaltet sein, damit sie Sollbruchstellen enthalten – nicht ganz ohne Entwicklungsaufwand, aber wenigstens für einen schmerzfreien Austausch? Wie komme ich aus einer Legacy-Welt dorthin?

Redaktion: Was ist die Kernbotschaft deiner Session, die jeder Besucher mit nach Hause nehmen sollte?

Bernd Rederlechner: DDD als lokale Optimierung innerhalb eines Projektes oder Produktes verliert viel von seiner Schlagkraft. Verbündet Euch mit den Architekten und Entwicklern aus anderen Disziplinen und Fachbereichen, kombiniert Eure Stärken und liefert mutig viele kleine Veränderungen hin zu der IT-Welt, in der Ihr gemeinsam in Zukunft leben wollt.

Redaktion: Vielen Dank für dieses Interview!
Die Fragen stellte Hartmut Schlosser.

The post DDD, DevOps, Software-Architektur: „Verbündet Euch mit Entwicklern aus anderen Disziplinen und Fachbereichen“ appeared first on JAX.

Redaktion: Hallo Christian! Ihr bringt in eurem JAX Talk die Systemtheorie nach Luhmann mit Softwareentwicklung und -architektur zusammen. Was können Entwickler von der Systemtheorie lernen?

Es gibt eine starke Analogie zwischen der Kommunikation, die in sozialen Systemen stattfindet, und der Kommunikation innerhalb von Softwaresystemen.

Dr. Christian Mennerich: Den Vortrag halte ich ja zusammen mit Freddy Meseck, der bei uns als systemischer agiler Coach arbeitet und sich von daher mit der Systemtheorie sehr gut auskennt. Bei synyx arbeiten wir in den Softwareentwicklungsprojekten u.a. nach den Prinzipien des Domain-driven Design (DDD), folglich ist eine große gemeinsame Aufgabe das Finden der relevanten abgeschlossenen Kontexte (Bounded Contexts).

Freddy und ich sind nun schon ein paar Jahre zusammen in verschiedenen Projekten und Teams unterwegs und waren uns einig, dass ein guter soziologischer Ansatz fehlt, um diese Kontexte systematisch zu finden und zu beschreiben. Die sozialen Systeme gemäß der Systemtheorie nach Luhmann, so wie wir sie interpretieren, sind unserer Meinung nach hierzu gut geeignet.

Für Entwickler*innen in einem agilen Projekt ist die Systemtheorie, insbesondere der darin enthaltene konstruktivistische Ansatz, unserer Meinung nach ein geeignetes Werkzeug um zu verstehen, warum es in Softwareprojekten immer wieder zu Missverständnissen kommen wird. Aus diesem Bewusstsein heraus lässt sich das gemeinsame Verständnis mit POs, Stakeholdern und Endanwendern erhöhen.

Die Systemtheorie liefert noch einmal eine andere Sichtweise auf iteratives Vorgehen und motiviert zu kleinen Inkrementen in einem kontinuierlichem Ausrollprozess, experimentellem Lernen, “fail fast” und anderen agilen Elementen. Weiter verändert Software ja auch die “Gesellschaft” der Anwender. Für Entwickler*innen ist das eine wichtige Erkenntnis. Es gibt eine starke Analogie zwischen der Kommunikation, die in und zwischen sozialen Systemen stattfindet, und der Kommunikation innerhalb und zwischen Softwaresystemen. Dies legt eine nachrichtengetriebene Systemarchitektur nahe, und die Kommunikation über Domänen-Events.

Die Herausforderungen, die nachrichtengetriebene verteilte Systeme mit sich bringen (wie die Fragen nach Zeiten, Reihenfolgen, Zustellhäufigkeiten usw.), erhalten so eine starke fachliche Komponente, da Kommunikation zwischen sozialen Systemen oft ebenso “unvorhersagbar” stattfindet. Für Entwickler*innnen wird es so natürlicher, diese Herausforderungen auch im Code anzugehen und gegenüber POs und Stakeholdern zu motivieren.

Redaktion: Ihr schreibt in eurem Abstract zum Talk, dass es darauf ankomme, “die Realitätskonsense der beteiligten sozialen Systeme isomorph zur Deckung zu bringen, um ein für alle zufriedenstellendes Softwareprodukt zu erhalten.“ Kannst du das einmal anhand eines Beispiels erläutern?

Dr. Christian Mennerich: Ja klar, die Systemtheorie ist als solche ja sehr abstrakt und als Universaltheorie ja nicht so ganz trivial. Unserer Meinung nach ist an dem Ansatz aber nichts Esoterisches! In unserem Vortrag bringen wir ganz konkrete Beispiele aus einem unserer Kundenprojekte, in dem es um die Digitalisierung von Prozessen an Containerterminals im Hinterland geht.

Schauen wir zum Beispiel auf das Terminalgate, den Ort, an dem LKWs, die Container bringen oder abholen, kontrolliert und eingelassen oder abgewiesen werden. Wir können das Gate als ein soziales System verstehen (einen Bounded Context), den wir in Software abbilden wollen. Die Mitarbeiter am Gate arbeiten schon seit langem zusammen, sind abgestimmt und haben einen “Konsens”, ein gemeinsames Verständnis über ihre Arbeitsweisen und -prozesse: Wie wird mit LKWs im “Normalfall” umgegangen? Wie mit welchen, die nicht angemeldet sind, die trotz Anmeldung nicht kommen usw.? In der Sprache Luhmanns spricht man hier von “anschlussfähiger Kommunikation”, von “Mustern” und “Prozessen”.

Nun soll das Gate durch eine Software unterstützt werden. Ein Requirements Engineer “verzerrt” diesen Konsens bei der Anforderungserfassung, da er das soziale System “Gate” verändert und zusätzlich seine Sichtweise unvermeidlich mit einbringt (seine “Konstruktion der Realität”). Das Ergebnis soll dann von einem Entwicklerteam umgesetzt werden. Die Entwickler sind aber auch ein soziales System, das eine eigene Konstruktion und Interpretation der Anforderungen ausbildet, sich also einen “Konsens” darüber bildet, was es umsetzen soll und was das bedeutet.

Um bei den Mitarbeitern am Terminal eine hohe Akzeptanz zu schaffen und sie bestmöglich in ihrem Prozessen zu unterstützen, sollten Mitarbeiter und Entwickler die Prozesse möglichst gleich verstehen. Das meinen wir damit, wenn wir davon sprechen, dass die Konsense zur Deckung kommen sollen. Für uns ist eine hohe Übereinstimmung der Konsense eine Art Maß dafür, dass die Software leistet, was sie soll und auch akzeptiert ist.

Software-Architektur Trends

Redaktion: Software-Architektur ist allgemein ein breit gefächertes Gebiet – ebenso unterschiedlich ist das Rollenverständnis unter Software-Architekten. Worin siehst du persönlich in deiner Position als Software-Architekt deine Hauptaufgabe? Was ist dir besonders wichtig?

Mir persönlich ist es wichtig, dass die Architektur-Entscheidungen fachlich getrieben sind.

Dr. Christian Mennerich: Mir persönlich ist es wichtig, dass die Architekturentscheidungen fachlich getrieben sind, das heißt, dass die Entwicklung Business-zentriert stattfindet, nicht technisch. Dies gilt für alle Ebenen der Softwarearchitektur, von den groben Systemschnitten bis hin zur konkreten Implementierung der einzelnen Services.

Hier achten wir verstärkt auf DDD, nachrichtenorientiertes Denken von Beginn an, das Einhalten hexagonaler Architektur-Pattern und ähnliches. Hier ist es meiner Meinung nach unerlässlich, iterativ zu arbeiten und die Teams von vorne herein mit möglichst breit gefächertem Wissen aufzustellen.

Redaktion: Welchen Architektur-Trend findest du momentan besonders spannend?

Dr. Christian Mennerich: Streng nachrichtenorientiertes Design in verteilten Systemen, vor allem den Gedanken der Domänen-Events konsequent anzuwenden, finde ich spannend. Wenn wir fachlich getrieben kleine abgeschlossene Services auch in verteilten Teams entwickeln lassen, dann bekommt auch die Kommunikation über Nachrichten und deren unterschiedliche Interpretation durch verschiedene Services eine fachliche Entsprechung. Das wirft eine gute neue Perspektive auf Diskussionen über Garantien in solchen verteilten Systemen (wie Zustell-Reihenfolgen und -zeiten, exactly-once delivery usw.).

Redaktion: Und welches Thema im Bereich der Software-Architektur ist deiner Meinung nach im aktuellen Diskurs etwas unterbelichtet?

Dr. Christian Mennerich: Was mich brennend interessiert, ist die Frage, was die neuen Architekturstile genau bedeuten und mit der Anwenderschaft machen. Wenn wir in Microservices (oder noch kleineren Einheiten) entwickeln, was bedeutet das dann beispielsweise für Bounded Contexts nach DDD und Conways Law, wie können wir diese Konzepte dann noch verstehen?

Das ist auch eine Frage, die Freddy und mich angetrieben hat, Luhmanns Systemtheorie und Softwareentwicklung zusammen zu bringen; Software und Digitalisierung machen ja etwas mit der Gesellschaft, und umgekehrt. An dieser Stelle fände ich eine breitere Diskussion spannend, wie sie beispielsweise momentan anläuft, wenn es um ML und moralische Fragestellungen geht.

Redaktion: Was ist die Kernbotschaft eurer Session, die jeder Besucher mit nach Hause nehmen sollte?

Dr. Christian Mennerich: Wir wünschen uns klar zu machen, dass eine objektive Realität keine Relevanz hat, da die Realität nicht objektiv beschrieben werden kann! Beschreibung ist immer Konstruktion des Beobachters. Um gute Software zu bauen, gilt es, gut und viel zu kommunizieren, um die richtigen Konsense zu finden. Denn alle am Softwareentwicklungsprozess beteiligten sozialen Systeme haben jeweils einen “eigenen Konsens”. Diese Konsense gilt es dann gemeinschaftlich zu harmonisieren, und da hilft nur das gemeinsame Ausprobieren kleiner Änderungen, um beweglich zu bleiben.

Redaktion: Vielen Dank für dieses Interview!

Das Interview führte Hartmut Schlosser.

The post Was Software-Architekten von der Soziologie lernen können 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.

Was macht evolutionäre Software-Architekturen aus? Wie hält man die Balance zwischen Stabilität und Flexibilität? Wie lässt sich das Prinzip des Wandels mit dem agilen Prinzip vereinbaren, Software möglichst schnell auszuliefern, die einen echten Mehrwert bietet?

Evolutionäre Prinzipien

Evolutionäre Architekturen tragen zunächst einmal der Erkenntnis Rechnung, dass Software in inkrementellen Schritten entsteht. Software-Entwicklung ist kein linearer Prozess, an dessen Anfang eine Architektur-Skizze steht, die dann stur implementiert wird. Evolutionäre Software-Architektur vollzieht sich vielmehr in Schleifen: Nach dem Release einer kleinen Einheit wird Feedback eingeholt, auf dessen Basis Entscheidungen für die Weiterentwicklung getroffen werden können.

Weiterentwicklung vollzieht sich stets auf mehreren Dimensionen. Auf technischer Ebene sind dies zum Beispiel neue Sprachen, Frameworks, Tools und Systemupdates. Auf fachlicher Ebene können Änderungen des Marktes, neue Einkommensmodelle, ein verändertes Konsumverhalten oder eine neue Wettbewerbssituation Anpassungen an die Software-Architektur verlangen.

Kuas Fazit: Software-Architektur beschäftigt sich nicht nur mit dem Problem der richtigen technischen Entscheidung. Software-Architekten sind zunehmend mit der Frage konfrontiert, wie gewisse Entscheidungen getroffen werden sollten. Es geht um die Entscheidungskultur, die Grundlage für eine evolutionäre Software-Architektur ist.

The post Evolutionäre Software-Architektur appeared first on JAX.

The post 10 Gründe, warum wir gewisse APIs mögen und uns andere APIs nerven appeared first on JAX.

Wozu eigentlich Software-Architekten?

JAXenter: Die Rolle des Software-Architekten kann verschiedentlich interpretiert werden: Technologieplaner, Change Manager, Chefentwickler, Projektkoordinator, Kommunikator, Kundenberater, etc. Worauf kommt es dir persönlich in deiner Rolle als Software-Architekt an?

Ein Software-Architekt ist ein Vermittler zwischen Techniker und Nicht-Techniker

Sandra Parsick: Aus meiner Sicht ist ein Software-Architekt ein Vermittler zwischen Techniker und Nicht-Techniker. Dabei ist es hilfreich, wenn der Software-Architekt im Team mitentwickelt. Vermehrt sehe ich den Trend, dass die Rolle des Architekten als Teamaufgabe interpretiert wird, so dass die Entwickler aktiv an der Architektur mitarbeiten und auch gleich sehen, wie die Architektur sich im Code widerspiegelt.

Hanna Prinz: Meiner Meinung nach ist es wichtig, dass Architekten möglichst nah am Team sind und einen guten Draht zu Product Ownern haben. Nur mit regelmäßigem, direktem Austausch über Fachlichkeit, Architektur und Technologien können gute technische Entscheidungen gefällt werden. Viele – wenn nicht die meisten – Architektur-Entscheidungen fällen sowieso die Entwickler im Alltag. Umso besser das Team bei Architektur-Entscheidungen involviert und informiert ist, desto besser werden diese Entscheidungen sein und desto weniger erodiert die Architektur.

Thomas Kruse: Ich denke, dass ein guter Softwarearchitekt tatsächlich von allem etwas mitbringen muss. In erster Linie muss ein Architekt das Geschäft des Kunden besser verstehen, als der Kunde selbst. Nur so lassen sich geeignete technische Loesungen auswählen, mit denen sowohl die aktuellen Anforderungen als auch vorhersehbare Änderungen umgesetzt werden können.

Dabei ist der Schritt dann nicht mehr weit, den Kunden auch dahingehend zu beraten, wie er seine Geschäftsprozesse optimiert oder sogar dank geeigneter Software völlig neue Prozesse oder Modelle anbieten kann.

In zweiter Linie finde ich es wichtig, dass man nicht ausschließlich seine Lieblingsarchitektur hat, sondern über ein breites Spektrum an Wissen und Erfahrung verfügt und unter Berücksichtigung aller Anforderungen und Rahmenbedingungen dann eine passende Auswahl treffen kann.

Markus Harrer: Mir kommt es einfach darauf an, dass sich das Entwicklungsteam bei der Technik nicht übernimmt, um noch genug Zeit zu haben, einen Mehrwert für die Kunden zu liefern. Bei meinen Beratungen zum Entwurf oder der Modernisierung von Softwaresystemen stehen daher der Abbau unnötiger Komplexitäten und Standardisierung mit Hirn im Vordergrund. Ich will nicht, dass die besten Entwickler*innen ihre wertvolle Zeit mit dem Aufbau von eigenentwickelten Infrastrukturlösungen oder dem Zurechtbiegen von Standard-Frameworks verwenden. Sie sollen ihr Gehirnschmalz in die fachlich anspruchsvollen Teile stecken und hier die inhärente Komplexität clever in einfache Softwaresysteme gießen. Das bringt den wahren Wert der Software – und letztendlich auch den Mehrwert für die Kunden.

Stephan Pirnbaum: Als Software-Architekt ist es meiner Meinung nach besonders wichtig, die verschiedenen Anforderungen der einzelnen Stakeholder sowohl von technischer als auch besonders von fachlicher Seite sinnvoll zu vereinen und auf dieser Basis zukunfts- und evolutionsfähige Entscheidungen für das Software-System zu treffen. Dabei ist Kommunikation ein essentieller Bestandteil der Tätigkeit. Dokumentation von Entscheidungen und ein aktiver Wissensaustausch gehören aber für mich ebenso selbstverständlich dazu wie das Mitentwickeln an der Software.

Franziska Dessart: Software-Architektur ist das, was entsteht, wenn Software geschaffen wird. Genauso wie etwas bei seiner Herstellung automatisch eine Gestalt (-ung, also ein Design) bekommt. Hierzu braucht es keinen Designer. Architektur entsteht immer, egal ob Entscheidungen bewusst getroffen werden oder nicht. Unabhängig davon, ob ein sogenannter “Architekt” dazu beigetragen hat oder nicht. Auch die Sandburg meiner Kinder hat sowohl eine Gestalt, als auch eine Architektur.

Idealerweise werden jedoch die meisten Entscheidungen bewusst getroffen und nicht basierend auf Vorlieben oder dem “Bauchgefühl” Einzelner. Hierzu gilt es, Vor- und Nachteile aller erdenklichen Möglichkeiten zu beleuchten und gegeneinander abzuwägen. Es gibt keine perfekten oder allgemeingültigen Entscheidungen, aber immer die unter den momentanen Bedingungen bestmögliche Variante (die das unter Umständen schon Tage, Wochen oder Monate später nicht mehr sein muss, wenn sich die Rahmenbedingungen ändern).

Dabei spreche ich von Architekturentscheidungen auf allen Ebenen. Von weitreichenden Makroarchitekturentscheidungen (wie z.B. “Datenreplikation immer per Feed”) bis hin zu extrem detaillierten Entscheidungen (etwa Variablen- und Methodennamen bzw. Anzahl und Art ihrer Parameter), sowie allen Schattierungen dazwischen. Mir ist wichtig, dass jeder, der an der Herstellung von Software beteiligt ist, sich jederzeit so gut wie möglich mit seinem Wissen und seinen Fähigkeiten in die Architekturarbeit einbringen kann und dadurch die bestmögliche Architektur entsteht. Die Vorraussetzung dafür ist, dass eine offene und sichere Kommunikationskultur herrscht, die das überhaupt erst ermöglicht.

Architektur-Trends 2019

Welchen Trend in Sachen Software-Architektur findest du momentan besonders spannend?

Sandra Parsick: Ich finde es momentan spannend zu beobachten, wie die Wahl der Cloud-/Infrastrukturtechnologie Auswirkung auf die Software-Architektur hat. Noch vor ein paar Jahren haben sich Entwickler/Architekten wenig Gedanken darüber gemacht, so zumindest meine Wahrnehmung, ob die Architektur der Software die Anforderungen aus der Infrastruktur erfüllen kann. Ich denke da an Beispiele wie: “Kommt meine Software damit zurecht, dass sie im Kubernetes-Cluster einfach mal beendet wird und wo anders wieder gestartet wird?”

Hanna Prinz: Ich habe natürlich einen Starken Bias in Richtung Cloud, Kubernetes und Service Mesh. Es fasziniert mich immer wieder, wie beliebt und erfolgreich Microservices sind, obwohl es bis vor kurzem so schwer war, sie zu betreiben, zu kontrollieren und Einblicke in das Gesamtsystem zu gewinnen. In diesem Bereich gibt es ständig neue interessante Ideen und Technologien.

Der Trend zu Containern zieht unglaublich viele Bereiche nach sich.

Thomas Kruse: Der Trend zu Containern ist in meinen Augen eine Bewegung, die Auswirkungen auf unglaublich viele Bereiche nach sich zieht. Neben etablierten Technologien stehen dabei auch Organisationsstrukturen und etablierte Verfahrensweisen zur Diskussion. Das Potential, das Kubernetes bietet, liegt dabei natürlich auf der Hand. Auf der anderen Seite sollte man auch mit Bedacht vorgehen,. Nur um bei einem Trend dabei zu sein, aber dann doch eigentlich nichts ändern zu wollen, bringt aus meiner Sicht keine Vorteile und potentiell viel Frust und vergebene Energie. Dabei ist Kubernetes in der Tat bei vielen Firmen ein Wegbereiter zur Cloud und den damit verbundenen Chancen.

Markus Harrer: In vielen Firmen sind mittlerweile eine Unmenge an Softwaresystemen mit zahlreichen Anbauten und undurchsichtigen Kommunikationsbeziehungen entstanden. Für Softwarearchitekt*innen wird es dadurch immer schwerer, den Überblick zu behalten. Meist kennen diese nur Methoden zur Analyse einzelner Systeme. Das bringt Softwarearchitekt*innen bei der Beratung des Managements zur strategischen Ausrichtung des vorhandenen Systemzoos an ihre Grenzen. Daher finde ich besonders neu aufkommende Methoden interessant, welche ganze Systemlandschaften überschaubar machen.

Hier haben es mir besonders Wardley Maps [1] angetan. Eine Wardley Map ist eine Art Strategielandkarte, auf der Softwaresysteme nach ihrem Nutzen für einen Stakeholder (meist dem zahlenden Kunden) und dem jeweils gegebenen Evolutionsstadium (Prototyp, Eigenentwicklung, Produkt oder Gebrauchsgut) eingeordnet werden. Dadurch entsteht ein sehr kontextspezifisches Situationsbewusstsein über die eigene Systemlandschaft. Dank des immer vorhandenen Bezugs zum Stakeholder-Nutzen können auch Nicht-Techniker*innen bei strategischen Überlegungen zur IT mitreden. Durch die Einordnung der Systeme gemäß ihrer Evolutionsstufe können situationsspezifische Maßnahmen wie Know-How-Aufbau, Standardisierung oder Outsourcing sachlich diskutiert werden – je nachdem, wohin sich ein Softwaresystem entwickeln soll.

Stephan Pirnbaum: Aktuell finde ich Service-Meshes sehr spannend, denn leider wird der einfache Betrieb von Anwendungen bei deren Entwicklung häufig erst zweitrangig betrachtet. Dabei stellen insbesondere dynamisch skalierende Microservice-Landschaften große Herausforderungen insbesondere bezüglich Resilienz, Security, Monitoring und Logging. Zwar gibt es zahlreiche Frameworks, um dies zu bewerkstelligen, doch fügen diese weitere Komplexität sowohl in der Entwicklung als auch im Betrieb hinzu. Service-Meshes wie Istio erachte ich durch das Sidecar-Konzept und die Control Plane daher als einen interessanten Ansatz, diese Komplexität zumindest etwas einzudämmen. Dabei ist jedoch auch zu prüfen, ob die Mächtigkeit von Service-Meshes in dem jeweiligen Projektkontext notwendig ist.

Franziska Dessart: Mob Programming – hier ist jeder im Team an jeder wichtigen Entscheidung beteiligt und gleichzeitig immer über alles informiert. Ich mache das jetzt schon mehrere Monate erfolgreich bei meinem aktuellen Kunden. Von zuhause, vom Homeoffice aus. Wir nennen das Remote Mob Programming. Wie das funktioniert, haben meine Kollegen Jochen Christ, Simon Harrer und Martin Huber auf remotemobprogramming.org aufgeschrieben. Das funktioniert auch mit Teilzeit und sonstigen Abwesenheiten (Urlaub, Konferenzen, …), ganz ohne lästige Übergaben. Der Mob fängt das auf!

Jenseits der Trends

Welches Architekturthema außerhalb der Trends liegt dir besonders am Herzen und sollte deiner Meinung nach mehr Beachtung finden?

Sandra Parsick: Ist vielleicht kein direktes Architekturthema, aber ich finde, dass sich viel zu wenig Gedanken darüber gemacht wird, wie Architekturentscheidungen die Testmöglichkeiten einer Software beeinflussen. Daher wünsche ich mir, dass bei der Entscheidungsfindung mitberücksichtigt wird, wie ich das Ganze auch getestet bekomme.

Hanna Prinz: Man kann förmlich dabei zusehen, wie Softwareentwicklung immer dynamischer wird. Es geht häufig darum, schnell handeln zu können, selbst wenn dieser Vorteil auch mit ganz offensichtlichen Nachteilen einher geht. Architektur ist aber etwas, wo diese Dynamik nicht möglich und häufig auch nicht sinnvoll ist. Eine Architektur sollte deshalb nur so viel vorgeben, wie unbedingt nötig, und genug Raum für kontinuierliche Verbesserung lassen. Entscheidungen können nur dann wirklich in Frage gestellt werden, wenn der Aufwand, sie zu ändern, beherrschbar ist. Dieses offene Reflektieren über den Ist-Zustand setzt voraus, dass Alternativen bekannt sind.

Man kann förmlich dabei zusehen, wie Software-Entwicklung immer dynamischer wird.

Im Alltag ist man aber mit den immer gleichen Tools und Ideen konfrontiert. Deshalb brauchen wir Kollaboration und Austausch mit anderen. Meetups, Podcasts, Blogs und Workshops sind ein guter Anfang. Aber längst nicht alle Unternehmen ermutigen ihre Entwickler, sich so kontinuierlich weiterzuentwickeln und auszutauschen.

Thomas Kruse: Ich sehe oft, dass klassische Muster immer wieder Anwendung finden, die durch neue Optionen wie bspw. leistungsfähigere Hardware in Frage gestellt werden sollten. Ein Klassiker ist zum Beispiel die Verwendung von Batch-Jobs, weil auf Datenmengen im Gigabyte-Bereich gearbeitet wird – also Datenmengen, die locker in aktuellen Systemen auch im Hauptspeicher gehalten und performant verarbeitet werden könnten.

Markus Harrer: Es sind zwei Themen, die mir persönlich zu kurz kommen. Das eine Thema ist die Softwaremodernisierung. Auf Konferenzen reden wir meist nur über den Neubau von Software. Aber gefühlt sind doch 80% von uns in den sogenannten Legacy-Systemen unterwegs. Meistens haben diese Systeme vor allem bei der jüngeren Generation einen eher schlechten Ruf. Das finde ich sehr schade, denn es kann geistig sehr erfüllend sein, schwerwiegende Probleme in Bestandssystemen systematisch zu lösen. Es gibt viele Methoden und Vorgehen, wie etwa die Object-Oriented Reengineering Patterns [2] oder die Architecture Improvement Method aim42 [3], um Softwaresysteme Stück für Stück zu verbessern. Es fehlt leider jedoch noch an mehr Ausbesserinnen und Ausbessern, die sich in das Licht der Konferenzsäle wagen, um über solche Techniken und die eigenen Erfahrungen zu sprechen.

Das andere Thema ist das Dokumentieren von Softwaresystemen. Ich finde hier den Ansatz Docs-As-Code [4] insbesondere in der Ausprägung Arch-As-Code sehr spannend. Dokumentation auf den Stellenwert von Code zu heben, um damit Entwickler*innen keine Ausweichmöglichkeiten mehr zu geben, nichts zu dokumentieren? Genial! Gleiche Tools, gleiche Prozesse, gleiche Regeln. Die zusätzliche Verzahnung von den dokumentierten, architekturellen Spielregeln und deren Prüfung gegenüber dem echten Code bei Arch-as-Code treibt das noch ein Stück weiter. Werkzeuge wie ArchUnit [5] oder jQAssistant [6] prüfen hier beim Test oder Bau der Software automatisiert, ob die dokumentierten Architekturregeln auch eingehalten werden. Damit gibt es zusätzlich noch eine neutrale Instanz, welche dem sonst schleichenden Verfall von Softwaresystemen entgegenwirkt.

Stephan Pirnbaum: Für mich ist das Thema „Monolith“ und deren Verbesserung sehr wichtig, obwohl es leider in der Vergangenheit aufgrund neuer Trends als nicht sehr ansprechend galt. Im Gegenteil, schaut man zurück, waren lange Zeit Microservices (zumindest gefühlt) das Nonplusultra und Monolithen alles andere als attraktiv. Ebenfalls gefühlt hat sich diese Situation aber wieder gelegt, und es geht viel stärker darum, was tatsächlich für den Use Case und die Projektzukunft notwendig und sinnvoll ist. Dies kann ich nur unterstützen und finde, dass die Diskussion um die „richtige“ Architektur (soweit es diese überhaupt gibt) noch viel stärker auf Basis geschäftlicher Anforderungen und Rahmenbedingungen geführt werden sollte, anstatt auf der Grundlage aktueller Trends zu entscheiden.

Franziska Dessart: ADRs, also Architecture Decision Records, sind ein Mittel, das auf effiziente Art und Weise die wichtigsten Architekturentscheidungen dokumentiert. Es wird sowohl die Entscheidung selbst explizit dokumentiert, als auch, wie das Team zu dieser gekommen ist. Welche Information zum Zeitpunkt der Entscheidungsfndung zur Verfügung standen und welche Alternativen möglich gewesen wären.

Das hilft dem Team selbst: Entscheidungen werden explizit gemacht, Alternativen beleuchtet, Vor- und Nachteile abgewogen. Gleichzeitig schafft man Transparenz für Stakeholder außerhalb des Teams und erleichtert das Onboarding für neue Kollegen. Das Aufschreiben fördert die strukturierte Herangehensweise an die Entscheidung und gibt allen die Möglichkeit, sich daran zu beteiligen.

Architektur-Themen der Experten

Hanna, du hältst auf der W-JAX einen Talk namens Istio & Co: Service Mesh – das Missing Piece der Microservices-Architektur. Welche Vorteile hat man beim Einsatz eines Service Mesh Tools?

Hanna Prinz: Die Automatisierungs-Werkzeuge, die wie nutzen, sind teilweise schon so unsichtbar geworden, dass wir uns ihrer gar nicht mehr bewusst sind. Erst wenn man einen Container-Orchestrierer wie Kubernetes oder das CI/CD-Tooling wegnehmen würde, würde uns deren Mehrwert auffallen. Ich denke, dass es im Bereich solcher Automatisierungswerkzeuge noch viel mehr Potential gibt. Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features wie Monitoring, Routing, Circuit Breaking und die Absicherung des Netzwerkverkehrs hinzu – und zwar ohne, dass die Anwendungsentwickler auch nur eine Zeile Code ändern müssen. Der Hype um das Thema ist also durchaus berechtigt.

Neben den vielen Vorteilen: Erkauft man sich dabei auch einige Nachteile?

Selbst die sinnvollsten Veränderungen haben immer den Nachteil, dass es Zeit und Ressourcen kostet, die Veränderung zu evaluieren, zu planen, zu kommunizieren und herbeizuführen. Das trifft auch auf die Einführung eines Service Mesh zu. Noch dazu unterscheiden sich die verfügbaren Service-Mesh-Implementierungen stark – nicht nur im Feature-Umfang und was die Kompatibilität mit anderer Infrastruktur wie Kubernetes angeht, sondern auch in der Benutzbarkeit der API für Entwickler. Der mentale Overhead ist meiner Meinung nach aktuell der größte Nachteil von Service Meshes.

Schließlich ist das auch nicht die einzige Veränderung, mit denen die Teams konfrontiert sind. Ein Service Mesh hat außerdem einen Einfluss auf die Antwortzeit einer Anwendung und auf deren Ressourcenverbrauch. Ich empfehle deshalb immer, einen Benchmark mit der individuellen Anwendung zu machen.

Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features wie Monitoring, Routing, Circuit Breaking und die Absicherung des Netzwerkverkehrs hinzu.

Sandra, du bist auf der W-JAX und dem Software Architecture Summit aktiv. Dabei geht es beides Mal ums Testen: auf der W-JAX mit dem Vortrag Testen von und mit Infrastruktur, auf dem Summit mit dem Workshop Softwarearchitektur automatisiert testen. Was bedeutet es überhaupt, eine Architektur zu testen?

Sandra Parsick: Es geht in erster Linie darum, die Frage zu beantworten, wie ich erkenne, ob meine Architektur die gewählten Qualitätsmerkmale erfüllt. Da können oft schon klassische Testtechniken helfen. Bei anderen Fällen muss ich den Begriff “Testen” eher als Qualitätssicherung interpretieren, und dann kommen auf einmal andere Methoden in Spiel, die man erstmal nicht so auf dem Schirm hatte.

Thomas, deine Session auf der W-JAX lautet Frontend-Architektur für Microservices. Dabei gehst du explizit auf Chancen ein, die sich dank des etablierten Web-Components-Standards ergeben. Welche Chancen gibt es da?

Thomas Kruse: Der Vortrag liefert ein ganzes Buffet an Optionen, wie Webfrontends für eine Microservice-Architektur umgesetzt werden können. Ziel des Vortrages ist dabei vor allem, das Spektrum aufzuzeigen und nicht einen goldenen Hammer zu vermarkten. Webcomponents spielen für mich eine besondere Rolle, wenn es darum geht, wiederverwendbare Widgets oder Teilfunktionalitaet anzubieten, die nicht an ein spezifisches Framework gekoppelt ist. Auch wenn der Tradeoff besteht, dass dann nicht unmittelbar Frameworkvorteile bei der Einbettung genutzt werden können, stellen Webcomponents einen guten Mittelweg dar, wenn Team, Projekt oder sogar unternehmensübergreifend Funktionalität wiederverwendet werden soll. Dabei ist es z.B. mit Angular Elements oder Polymer auch möglich, bei der Entwicklung der Komponenten auf ein Framework mit den entsprechenden Vorteilen zurückzugreifen.

Markus, du übernimmst auf der W-JAX den Workshop Architektur 101: Praktisch, konzentriert und ohne Hype. Dabei ist dein Spezialgebiet die datenzentrierte Analyse von Softwareprodukten. Weshalb ist diese aus deiner Sicht so wichtig?

Markus Harrer: Die Analyse von Softwaresystemen mit Hilfe von Werkzeugen aus dem Data-Science-Bereich ist für mich einer der Wege, wie Softwareentwickelnde ihre Bedenken und Schmerzen an Nicht-Techies kommunizieren können [7]. Durch nachvollziehbare Datenanalysen werden die ansonsten verborgenen Gedankengänge der Bedenkenträger*innen offengelegt. Probleme können somit Stück für Stück systematisch herausgearbeitet werden – von den Rohdaten zu den Erkenntnissen bis hin zur managementgerechten Darstellung. Dies ermöglicht eine sachliche Diskussion auch über unangenehme Probleme, deren Schwere in politisch überhitzten Projekten gerne heruntergespielt wird.

Stephan, du bist Trainer auf dem Software Architecture Summit. In deinem Workshop Lasst uns einen Monolithen (z)erlegen gehst du von einem Legacy-System aus, das schrittweise in eine Microservices-Struktur überführt wird. Welchen typischen Problemen begegnet man dabei?

Eine Anwendung ist nicht aufgrund ihrer technischen Architektur, sondern ihrer fachlichen Fähigkeiten so wichtig für den Kunden.

Stephan Pirnbaum: Ich sehe primär drei Probleme. Erstens: Die Lieferfähigkeit ist zu jeder Zeit zu erhalten. Das heißt, dass für die Umsetzung geplanter Refaktorisierungen die Lieferung neuer Features nicht gefährdet werden darf. Schließlich ist die Anwendung nicht aufgrund ihrer technischen Architektur, sondern ihrer fachlichen Fähigkeiten so wichtig für den Kunden und damit für uns. Demzufolge kann es erforderlich sein, zunächst architekturell suboptimale Lösungen zu finden, um dafür langfristig sicher zum Ziel zu kommen.

Zweitens: Fehlendes Wissen (z. B. durch Mitarbeiterfluktuation) und mangelhafte Dokumentation erschweren sowohl die Wartung und Weiterentwicklung als auch die Planung von Refaktorisierungen. Dies wird verstärkt durch über Jahre gewachsene Strukturen, unterschiedliche Entwicklungsstile und verschiedene eingesetzte Technologien.

Drittens: Die vollständige Entkopplung auf Java-Code-Ebene bringt ganz neue Herausforderungen mit sich. Dabei geht es sowohl um die Änderung von Abhängigkeitsstrukturen, zum Beispiel durch Einführung von asynchronem Messaging, aber auch um Themen wie Laufzeitverhalten, Verfügbarkeit und Resilienz gegenüber Infrastrukturproblemen. Allesamt Themen, die im Monolithen nie derart bedacht werden mussten.

Franziska, du bist auf der W-JAX ebenso im Workshop „Architektur 101: Praktisch, konzentriert und ohne Hype“ aktiv. Dabei soll auch das Handling von nichtfunktionalen Anforderungen nicht zu kurz kommen. Kannst du einmal ein Beispiel ausführen, wie man mit einer nichtfunktionalen Anforderung umgeht?

Franziska Dessart: In meinem aktuellen Projekt spielt Resilienz eine sehr große Rolle. Das System soll funktionieren, auch wenn Probleme auftreten oder umliegende System nicht so arbeiten, wie erwartet. Wir sind hier auch für den Betrieb zuständig und halten uns dieses Ziel in Diskussionen immer wieder vor Augen: “Wir wollen nachts nicht angerufen werden!” Das hilft, zu priorisieren und insgesamt bessere Entscheidungen zu treffen.

Take-aways – was haben wir nun gelernt?

Zum Schluss noch ein Take-away. Was sind eure Kernbotschaften, die die Leser – und natürlich die Teilnehmer eurer Sessions und Workshops – mitnehmen sollten?

Sandra Parsick: Die Kernbotschaft soll sein, dass, wenn ich Ziele definiere, ich mir auch darüber Gedanken machen muss, wie ich erkenne, dass ich diese Ziele erreicht habe – und das auf Dauer!

Hanna Prinz: Am besten nehmen die Teilnehmer natürlich ein Service Mesh für ihre Microservice-Anwendung mit und setzen es gleich in ihrer Microservice-Anwendung ein Aber Spaß beiseite. Es gibt viele gute Gründe für ein Service Mesh, aber auch ein paar dagegen. Meine Teilnehmer werden den Workshop mit einer Einschätzung verlassen, ob sich ein Service Mesh für ihr Projekt lohnt. Es würde mich wundern, wenn der Großteil keine überzeugenden Gründe dafür sieht. Deshalb, und weil der Markt nicht ganz einfach zu durchschauen ist, wird es auch darum gehen, das richtige Service Mesh Tool auszuwählen. Doch auch wenn ein Service Mesh nicht sofort in die Projekte eingeführt wird, möchte ich die Teilnehmer dazu anregen, darüber nachzudenken, wie (oder ob) typische Service-Mesh-Funktionen wie Monitoring, Resilienz und Sicherheit aktuell umgesetzt sind – oder auch nicht.

Es gibt nicht nur Nachteile bei einem monolithischen Ansatz. Gerade wenn es um hochintegrierte Frontends geht, kann hier eine Architektur, die auf ein Modulsystem aufsetzt und im Backend Microservices nutzt, viele Vorteile ausspielen.

Thomas Kruse: Es gibt nicht nur Nachteile bei einem monolithischen Ansatz. Gerade wenn es um hochintegrierte Frontends geht, kann hier eine Architektur, die auf ein Modulsystem aufsetzt und im Backend Microservices nutzt, viele Vorteile sowohl für Entwickler als auch Anwender ausspielen.

Typischerweise ist ein Frontend eher nach fachlichen Aufgaben aufgeteilt und weist eine etwas gröbere Granularitaet auf, als dies bei Microservices möglich ist. Jedoch bieten sich dafür auch flexiblere Möglichkeiten zur (Re-)Integration an, wie zum Beispiel Hyperlinks. Mit der passenden Architektur merkt dabei ein Nutzer nicht einmal unbedingt, dass er die Anwendung wechselt.

Markus Harrer: Softwarearchitekt*innen sollen sich von Anfang an mit den Qualitätsansprüchen der Stakeholder beschäftigen, um deren ganz konkreten Bedürfnisse frühzeitig als Einflussfaktoren für Architekturentscheidungen nutzen zu können.

Stephan Pirnbaum: Euer bestehendes System ist nicht ohne Grund so wertvoll und schwer ersetzbar geworden, wie es heute ist. Dieser Schatz darf aufgrund neuer Hypes nicht einfach weggeworfen werden. Eine Bewertung der Umsetzbarkeit neuer Technologien und Ansätze im Rahmen der kontinuierlichen Verbesserung ist daher unabdingbar. So kann man mit kontinuierlichem Einsatz und planvollem Vorgehen dem Monolithen zu neuem Glanz verhelfen, egal ob am Ende eine Microservices-Landschaft oder ein strukturierter Monolith steht.

Franziska Dessart: Unser Workshop ist ja in vier Teile gegliedert, die sich jeweils auf unterschiedliche Aspekte von Software-Architektur konzentrieren. Jeder der Teile bringt sicherlich eine eigene Kernbotschaft mit sich. Allen gemeinsam ist aber vermutlich: Am Ende geht es immer irgendwie um Kommunikation, um das Miteinander-Reden, um den Austausch und auch das Festhalten von Informationen. Wenn wir darin gut sind, schaffen wir es auch, eine gute Architektur für unsere Systeme zu erarbeiten.

Vielen Dank für Eure Interviews!

The post Software-Architektur-Trends 2019: Das sagen die Experten! appeared first on JAX.

The post Das namespace-Desaster: Jakarta EE ohne javax! appeared first on JAX.

Hans betreibt ein kleines Arthouse-Kino, das unter Cineasten einen hervorragenden Ruf genießt. Vorführungen werden oft durch Filmanalysen ergänzt. Lokales Craft-Bier rundet das Kinoerlebnis ab. Eines Tages begegnet Hans seiner Schulfreundin Anna. Als er erfährt, dass Anna seit fast zehn Jahren Apps entwickelt, kommt ihm eine Idee.

Hans: „Meine Kunden mögen den altmodischen Charme meines Kinos. Aber keiner hat Lust, drei Tage vor einer Vorstellung an die Kasse zu kommen und Karten zu kaufen. Und dann gibt’s lange Gesichter, wenn eine Vorstellung ausverkauft ist. Kannst du nicht eine App für mich entwickeln?“

Anna: „Ein Kinosaal, zwei bis drei Vorführungen pro Tag, Karten verkaufen. Klingt machbar.“

Hans: „Super! Aber eine Kleinigkeit noch: Wir haben auch Vorträge von Filmkritikern im Programm. Und die Abendkasse brauche ich schon noch, komplett auf die App zu setzen ist mir dann doch zu riskant. Aber die Abos würde ich schon gern über die App verwalten.“

Anna: „Abos? Vorträge? Abendkasse? Das ist ja komplizierter als gedacht…“

Am nächsten Tag treffen sich die beiden wieder. Sie stehen vor einem Whiteboard, Anna hält einen Whiteboard-Marker in der Hand.

Anna: „Ich hab gestern verstanden, dass die App im Wesentlichen drei Anwendungsfälle hat: Abos verkaufen, Einzeltickets verkaufen und Tickets für Vorträge verkaufen.“

Hans: „Äh, ja, das klingt gut.“

Anna: „Ich würde gern verstehen, wie du heute arbeitest. Die App muss ja schließlich in deine Arbeitsabläufe reinpassen. Wollen wir vielleicht mal mit dem Ticketverkauf an der Abendkasse anfangen?“

Hans: „Das ist einfach. Man verkauft die Karten und streicht den Sitzplatz aus dem Saalplan und…“

Anna: „Warte mal. Wer verkauft die Karten?“

Hans: „Ich habe zwei Studenten, die bei mir jobben. Aber manchmal mach ich das auch selbst.“

Anna: „Okay, aber welche Rolle hast du dann?“

Hans: „Ach so, bei uns heißt das Kartenverkäufer.“

Anna malt ein Männchen an das Whiteboard und schreibt „Kartenverkäufer“ darunter (Abb. 1).

Abb. 1: Hans‘ Rolle ist „Kartenverkäufer“

Anna: „Und wer kauft die Karten?“

Hans: „Ein Besucher. Also einer ohne Abo.“

Anna malt ein zweites Männchen und nennt es „Besucher“. Am Rand notiert sie, dass der Besucher kein Abo hat (Abb. 2).

 

Abb. 2: Der „Besucher“ hat kein Abo.

Anna: „Was muss ich als Besucher tun, um eine Karte zu kaufen?“

Hans: „Du sagst dem Kartenverkäufer, welche Vorstellung du sehen willst. Also welchen Film an welchem Tag und welcher Zeit. Und wie viele Karten du haben willst.“

Anna: „Ich male hier eine Sprechblase, weil die beiden miteinander reden.“

Anna zeichnet weiter. An den Pfeil schreibt Anna eine Eins (Abb. 3).

 

Abb. 3: Kartenverkäufer und Besucher kommunizieren

Anna: „Und dann?“

Hans: „Meistens schlägt der Kartenverkäufer die besten noch verfügbaren Sitzplätze vor.“

Anna: „Und wie macht der Kartenverkäufer das?“

Hans: „Man schaut auf den Saalplan der Vorstellung. Darauf sieht man, welche Sitzplätze schon verkauft sind und wo noch was frei ist.“

Anna zeichnet und wiederholt, was sie verstanden hat (Abb. 4).

 

Abb. 4: Der Ticketverkäufer sucht nach freien Sitzplätzen für den Besucher

Anna: „Der Ticketverkäufer sucht im Saalplan nach der gewünschten Anzahl freier Sitzplätze. Stimmt das so?“

Innerhalb weniger Minuten füllt sich das Whiteboard mit einer fachlichen Geschichte, die erzählt, wie ein Kinobesucher Karten an der Abendkasse kauft (Abb. 5). Am Ende erzählt Anna die Geschichte noch einmal von vorne.

 

Abb. 5: Wie ein Besucher Karten an der Abendkasse kauft

Hans: „Ja, das passt so. Nur die Filmanalysen habe ich vergessen.“

Anna: „Du meinst das mit den Filmkritikern? Sind das nicht eigene Veranstaltungen?“

Hans: „Nein. Die Filmanalysen finden nach der Vorführung statt. Wir bieten das bei ein, zwei Vorführungen pro Woche an. Die sind dann etwas teurer. Extra verkaufen tun wir die Vorträge nicht, das wäre zu kompliziert. Man muss die Besucher nur darauf hinweisen, dass die Vorführung im Anschluss von einem Filmkritiker analysiert wird.“

Anna: „Wann macht der Kartenverkäufer das?“

Hans: „Hier.“

Hans zeigt auf den Pfeil mit der Nummer 3. Anna ergänzt einen Kommentar (Abb. 6).

 

Abb. 6: Anna und Hans füllen ihr Modell mit Kommentaren

Anna: „Du verkaufst auch Abos. Wie funktioniert das?“

Anna dreht das Whiteboard um und Hans beginnt mit einer neuen Geschichte (Domain Story).

Nach wenigen Domain Stories hat Anna einen guten Einblick in die Domäne „Kino“ erlangt. Sie kennt Begriffe wie „Saalplan“, „Vorführung“ und „Kartenverkäufer“. Sie hat ein erstes Verständnis der wichtigsten Abläufe und kann sich nun Gedanken machen, was die Einführung einer App für diese Abläufe bedeuten würde.

Das Bild zur Geschichte

Es ist sehr einfach, jemandem zuzuhören und zu glauben, dass man ihn verstanden hat. Man nickt und stimmt zu – und hat dabei ein völlig anderes Bild im Kopf. Menschliche Kommunikation ist durch Missverständnisse geprägt. Deshalb unterstützt Domain Storytelling beim aktiven Zuhören. Wir lassen uns nicht nur einfach eine Geschichte erzählen. Beim Zuhören zeichnen wir die Domain Stories vor den Augen der Fachleute auf. Dazu verwenden wir bewusst einfache Symbole. Die Fachleute sehen unmittelbar, ob wir ihre Geschichte richtig wiedergeben können. Damit folgen wir dem agilen Grundprinzip des möglichst frühen Feedbacks.

Die Bildsprache besteht aus zwei Arten von Symbolen und einer Art von Pfeil (Abb. 7):

Actors – Die handelnden Personen und IT-Systeme einer Geschichte. Typischerweise benannt mit einer Rollenbezeichnung oder Persona.

Abb. 7.1: Der “Actor”-Teil der Bildsprache
 
Work Objects – Die Arbeitsgegenstände, mit denen die Akteure ihre Arbeit machen. Oft etwas, das man anfassen und sehen kann, wie der Saalplan. Manchmal auch ein vergegenständlichtes Konzept, wie die Vorstellung.

Abb. 7.2: Der “Work Object”-Teil der Bildsprache
 
Activities – Das, was die Akteure tun.

Abb. 7.3: Der “Activity”-Teil der Bildsprache

Durch die Symbole der Work Objects sehen wir, welche Informationen verbal ausgetauscht werden (Symbol: Gesprächsblase) und in welchen Schritten (digitale) Dokumente eine Rolle spielen (Symbol: Dokument). Die Symbole dienen also nicht bloß der Optik, sondern veranschaulichen wichtiges Wissen über den Prozess. Je nach Domäne werden die Symbole angepasst. In einem Logistikunternehmen ist beispielsweise ein Symbol für einen Container nützlich, wenn in der Domain Story dargestellt wird, dass Container verladen werden. Für diesen Artikel verwenden wir einige Google Material Icons [1], die gut zu typischen Bürotätigkeiten passen und sich in vielen Domänen bewährt haben.

Mit dieser einfachen Notation können wir leicht verständliche Sätze verbildlichen: „Der Kartenverkäufer sucht freie Sitzplätze im Saalplan“ wird zu Abbildung 8.

 

Abb. 8: Via Icons lassen sich Sätze leicht verbildlichen

Reiht man mehrere Sätze aneinander, entsteht eine Geschichte. Die Aktivitäten zu nummerieren drückt die Reihenfolge der Sätze aus. Da eine Geschichte ohne Fallunterscheidungen erzählt wird, benötigt die Bildsprache keine Symbole für Verzweigungen. Annahmen, Varianten und Ausnahmen einer Domain Story können als textuelle Notizen festgehalten werden. Wichtige Varianten, die sich nicht mit einer kurzen Notiz beschreiben lassen, verdienen eine eigene Domain Story.

Die Akteure sind der Dreh- und Angelpunkt einer Domain Story. Daher kommt jeder Akteur nur einmal pro Domain Story vor. Work Objects können hingegen mehrfach auftauchen, wenn sie zu unterschiedlichen Zeitpunkten der Geschichte eine Rolle spielen. Im Lauf der Geschichte können Work Objects durch unterschiedliche Symbole repräsentiert werden. In unserem Kinobeispiel könnte eine Kinokarte etwa erst digital als E-Mail verschickt und später auf Papier gedruckt werden.

Von der Erzählung zum Bild

Domain Stories werden in Workshops erzählt. Neben einem Moderator braucht es dazu Fachexperten, die aus erster Hand zur Geschichte beitragen können. In komplexen Domänen gibt es immer seltener eine einzelne Person, die eine Geschichte von Anfang bis Ende kennt. Deswegen versammelt man Vertreter verschiedener Fachabteilungen und der IT, die die Geschichte gemeinsam erzählen.

Domain Storytelling macht auf unterschiedliche Arten Spaß. Wenn man noch unerfahren ist, wird man es schätzen, wenn ein Moderator die Diskussion führt und zentral die Domain Story aufzeichnet. Häufig ist der Moderator der wichtigste Nutznießer der Domain Stories – etwa, wenn er als Product Owner, Softwareentwickler oder Businessanalyst das erworbene Wissen für ein Entwicklungsprojekt nutzt. Erfahrene Teams machen auch gerne Sessions, bei denen alle zusammen vor dem Whiteboard stehen und gemeinsam Pfeile malen und Zettel kleben.

Je nachdem, was mit dem Workshop bezweckt wird, müssen die Geschichten mal oberflächlich und breit und mal mit klarem Fokus und detailliert erzählt werden. Außerdem muss ein Moderator gegensteuern, wenn sich Diskussionen entwickeln, die das Fortschreiten der Geschichte verhindern. Ein typisches Beispiel: An einem Punkt der Geschichte diskutieren die Teilnehmer, was alles passieren könnte. Solche Diskussionen lassen sich auflösen, indem die Geschichte konkretisiert wird und Annahmen ergänzt werden: “Nehmen wir an, es sind genügend Sitzplätze nebeneinander frei. Was passiert als Nächstes?”. So verzetteln sich die Teilnehmer nicht in Sonderfällen.

Je nach Anzahl der Teilnehmer, verfügbarer Raumausstattung und der Anzahl an Domain Stories können unterschiedliche Werkzeuge zur Visualisierung eingesetzt werden. Flipcharts und Marker sind in den meisten Besprechungsräumen vorhanden. Leider sind Flipcharts am schlechtesten geeignet, weil Änderungen damit schwierig sind. Und weil man so oft missversteht, was eigentlich gemeint wurde, muss man Domain Stories häufig ändern. Deshalb hat sich als bisher gängigste Offlinevariante eine Kombination aus Whiteboard und Klebezetteln entwickelt (Abb. 9). Diese eignet sich auch sehr gut für kooperatives Domain Storytelling ohne dedizierten Moderator.

 

Abb. 9: Offlinevariante mit einer Kombination aus Whiteboard und Klebezetteln

Auch computergestützt gibt es einige Möglichkeiten, etwa mit Tablet und Stift oder auf Smartboards wie dem Surface Hub (Abb. 10). Generische Modellierungs- und Zeichenwerkzeuge eignen sich zwar, um Domain Stories nach einem Workshop zu digitalisieren, aber für den Einsatz in den Workshops selbst fühlen sich solche Werkzeuge oft zu sperrig an. Aus dieser Unzufriedenheit heraus entstand der Domain Story Modeler, ein Modellierungswerkzeug, das im Browser läuft. Einfach online ausprobieren [2] oder herunterladen [3]. Die Bilder für das einführende Kinobeispiel haben wir mit dem Modeler erstellt.

 

Abb. 10: Computergestützt stehen Tablet und Stift oder Smartboards wie das Surface Hub zur Verfügung.

Jedes Werkzeug hat seine Stärken und Schwächen. Egal, welches man verwendet – es ist wichtig, dass die Domain Story jederzeit für alle sichtbar ist. Nur so funktioniert Domain Storytelling als Methode für aktives Zuhören.

Am Ende geht es nicht um die Schönheit der visualisierten Domain Story, nicht um das perfekte Werkzeug und nicht um syntaktische Korrektheit. In den Workshops steht der gemeinsame Erkenntnisgewinn über dem Erstellen von Dokumentationen. Die abfotografierten oder digital erstellten Domain Stories dienen als Gedächtnisstütze für die Teilnehmer eines Workshops. Sie können die Teilnahme am Workshop aber nicht ersetzen.

Von Domain Stories zum Code

Wer nur einen Hammer als Werkzeug hat, sieht die Welt voller Nägel. In Entwicklungsprojekten reicht selten nur ein Modellierungsansatz aus. Wir starten zum Beispiel manchmal mit einem Big-picture-Event-Storming (siehe vorhergehender Artikel). Wenn wir dabei auf eine Häufung von Ereignissen stoßen, die von kooperativer Arbeit geprägt sind, nutzen wir im zweiten Schritt Domain Storytelling für eine tiefere Analyse.

Um eine Domäne zu verstehen und mit Fachexperten darüber zu sprechen, reicht es in der Regel aus, 80 Prozent der Fälle abzudecken: die wichtigsten, häufigsten, schwierigsten und aufwendigsten Varianten eines Geschäftsprozesses.

Aus diesem Verständnis heraus entstehen, oft parallel zur Softwareentwicklung, weitere Dokumente. Beispielsweise eignen sich Domain Stories, um Soll-Prozesse zu entwerfen. In unserem Kinobeispiel würden Hans und Anna visualisieren, wie der Verkaufsprozess an der Abendkasse in Zukunft abläuft. Sie werden dabei feststellen, dass die Kartenverkäufer einen digitalen Saalplan brauchen werden, der auch die per App verkauften Sitzplätze anzeigt (Abb. 11).

 

Abb. 11: Ein digitaler Saalplan zeigt auch per App verkaufte Karten an.

Aus solchen Domain Stories lassen sich leicht funktionale Anforderungen ableiten. Ein Beispiel: Will eine Besucherin unseres Kinos vor Ort Karten kaufen, sucht der Kartenverkäufer nach dem passenden Saalplan für die Vorstellung und bietet die freien Plätze an (Aktivitäten 2 und 3 in der Domain Story). Dazu kann man folgende Anforderung an das Kinosystem formulieren: “Als Kartenverkäufer will ich die freien Plätze für eine Vorstellung ermitteln, damit ich sie einem Besucher anbieten kann.”

Domain Storytelling und Domain-Driven Design

Domain Storytelling passt ideal zu Domain-Driven Design und unterstützt die drei Säulen des Domain-Driven Design (Kasten: „ Die drei Säulen des Domain-Driven Design“).

Überspannt werden diese drei Säulen vom Konzept der Ubiquitous Language. Diese haben wir als Fachsprache innerhalb eines Bounded Contexts bezeichnet. Diese Fachsprache soll allgegenwärtig (engl. ubiquitous) sein – vom Whiteboard bis hinein in den Code. Domain Storytelling hilft dabei, die Worte zu finden, die die Ubiquitous Language formen. Diese Worte werden wir später auch im Code wiederfinden.

Zum Schluss: Domain Storytelling lernen und selbst machen

Domain Storytelling ist eine einfache Technik. Um sie aber auch in größeren Gruppen sicher anwenden zu können, braucht man als Moderator etwas Erfahrung. Die bekommt man nur durch Übung. Wir empfehlen daher, erstmal klein anzufangen. Probieren Sie Domain Storytelling allein, mit Stift und Papier oder online mit dem Modeler. Wenn Sie die Notation verinnerlicht haben, schnappen Sie sich eine Kollegin oder einen Kollegen, um die Rolle des Fachexperten zu übernehmen. Üben Sie, wie Domain Storytelling im Dialog funktioniert. Danach sind Sie bereit für Workshops mit mehreren Teilnehmern.

Mehr zu Domain Storytelling finden Sie auf: http://domainstorytelling.org.

Links & Literatur

[1] Google Material Icons: https://material.io/icons/
[2] Domain Story Modeler ausprobieren: wps.de/modeler
[3] Domain Story Modeler auf GitHub: https://github.com/WPS/domain-story-modeler

The post Domain-Driven Design: Wie Domain Storytelling Fachexperten und Entwickler zusammenbringt appeared first on JAX.

Arne Limburg: Das hat mehrere Aspekte. Da ist zum Einen der technologische Aspekt. Moderne REST-APIs sind viel schlanker als frühere Lösungen wie SOAP oder XML-RPC und das sowohl im Design als auch bei der Datenmenge, die über die Leitung geht.

Dann gibt es natürlich den architektonischen Aspekt. Man hat mittlerweile erkannt, dass Architekturen, die auf einem ESB basieren, nicht so leicht zu warten und weiterzuentwickeln sind, als wenn sich die Services direkt unterhalten. Damit das gelingt, benötigt man aber gute APIs, die auch stabil bleiben. Da spielt das Thema Abwärtskompatibilität und Versionierung eine wichtige Rolle.

Und last but not least haben viele Unternehmen erkannt, dass sich mit gut definierten Public APIs auch Geld verdienen lässt. Unternehmen erschließen sich neue Vertriebskanäle, in dem sie APIs anbieten, über die z.B. Mobile Clients angebunden werden können (Stichwort: Multi-Channel-Strategie). Die Clients müssen dann nicht immer vom Unternehmen selbst gebaut werden. Es gibt auch interessante Konstellationen, in denen Drittanbieter an dem Unternehmensumsatz partizipieren können.

W-JAX: Deine Session auf der W-JAX heißt „Abwärtskompatible APIs – Strategien für den Projektalltag.“ Dabei gehst du darauf ein, wie man Schnittstellen sinnvoll weiterentwickelt, wenn sich beispielsweise die Anforderungen verändert haben. Warum genügt es nicht einfach, eine Versionierung für APIs einzuführen?

Arne Limburg: Es geht vor allem um die Pflege alter Versionen. Wenn ich ein Public API betreibe, kann ich nicht einfach eine Version 2 des API zur Verfügung stellen und Version 1 abschalten. Damit erzeuge ich hohen Aufwand bei meinen Clients, die dann zeitgleich updaten müssten. Auf Dauer macht das kein externer Client-Anbieter mit.

Die Erfahrung zeigt aber, dass die Pflege alter Versionen serverseitig sehr aufwendig ist, wenn man es nicht richtig angeht. Es geht also darum, einen Weg zu finden, serverseitig alte Versionen einfach pflegen zu können und gleichzeitig den Clients leichte Wege zu eröffnen, auf die neueste Version zu aktualisieren.

W-JAX: Kannst du einmal einen Tipp geben, wie man Abwärtskompatibilität von APIs sicherstellen kann, ohne sich im Support alter Versionen zu verlieren?

Arne Limburg: In aller Ausführlichkeit erkläre ich das natürlich in meinem Talk auf der W-JAX. Kurz gesagt, geht es darum, einerseits gewisse Anforderungen an den Client zu stellen (Stichwort: Tolerant Reader Pattern) aber andererseits auf dem Server auch dafür zu sorgen, dass die API kompatibel bleibt, in dem innerhalb einer Version nur Attribute hinzukommen, aber niemals welche entfernt werden. Beim Versionssprung ist es wichtig, dass das Mapping zwischen alter und neuer Version nicht zu aufwendig ist.

W-JAX: In den meisten Fällen haben Unternehmen noch Legacy-Systeme am Laufen, die bei der Einführung von APIs integriert werden müssen. Welche technologischen Herausforderungen gilt es dabei zu meistern?

Arne Limburg: Hier gibt es zwei Arten von Legacy-Systemen. Für die einen ist das Unternehmen im Besitz des Source Codes und hat auch das Know-How, um die Systeme weiterzuentwickeln. Hier empfehlen wir immer, ein sauberes RESTful API für das Legacy-System zu realisieren, um es in die „neue Welt“ einzubinden. Häufig ist das gar nicht so schwer.

Sollte sich das nicht realisieren lassen, empfehlen wir einen Anti-Corruption-Layer, der dann die saubere Schnittstelle zur Verfügung stellt und eigentlich nichts anderes macht als zwischen Legacy und neuer Welt hin- und herzumappen. Das kann dann z.B. auch ein Caching beinhalten, wenn das Legacy-System nicht auf eine so hohe Anzahl von Requests ausgelegt ist oder wenn es sogar nur im Batch-Betrieb läuft.

W-JAX: Bei der Einführung von APIs bleibt es aber ja nicht bei den technologischen Herausforderungen. Weshalb hat das auch Konsequenzen auf die gesamte Organisation eines Unternehmens?

Arne Limburg: In vielen Unternehmen ist es nach wie vor so, dass die Entwicklung sehr Projekt-getrieben ist. Die Einführung eines neuen Features ist ein eigenes Projekt, für das es ein separates Budget gibt und häufig auch noch ein Plichten- und Lastenheft.

Moderne APIs müssen allerdings als Produkt betrieben werden, das kontinuierlich weiterentwickelt wird und auf diese Weise benötigte Features zur Verfügung stellt. Die Art und Weise, wie neue Themen in die IT eingebracht werden, muss sich daher häufig komplett ändern.

W-JAX: Wie sollte man ein API-basiertes Projekt deiner Erfahrung nach angehen? Es gibt da ja verschiedenste Ansätze: Startet man technologisch, oder muss man zuerst das Unternehmen umstrukturieren? Braucht es zunächst ein ausgefeiltes Konzept zum API Management, oder ist der MVP-Ansatz hier besser: erstmal klein starten, Feedback einholen, weiterentwickeln?
Arne Limburg: Das Vorgehen, erst einmal klein anzufangen, um Erfahrung zu sammeln, ist auf jeden Fall ein Vorgehen, das sich bewährt hat. Dennoch sollte man sich beim Design einer API nicht von der Technologie treiben lassen. Es geht ja nicht primär darum, wie ich den Server schnell realisieren kann, sondern darum, eine API so aufzubauen, dass viele unbekannte Clients sie leicht nutzen können und gerne nutzen. Mein Ansatz ist deshalb immer der sogenannte Contract-First-Ansatz, wobei der Name etwas irreführend ist, weil er nicht das Ziel widerspiegelt. Eigentlich müsste man den Ansatz Client-First nennen. Gute APIs sind in der Regel die, bei denen das Design mit der Überlegung ausgeführt wurde: Was benötigt der Client?

W-JAX: Vielen Dank für dieses Interview!

The post Was Sie bei der Einführung von APIs wissen sollten appeared first on JAX.

Ralf D. Müller: Beide Aspekte der Architektur – Stabilität und Flexibilität – müssen wie immer ausgewogen vorhanden sein und bauen aufeinander auf. Erst wenn gewisse Standards existieren und die Vorgehensweise, Schnittstellen etc. dokumentiert sind, lässt sich eine Architektur auch gut ändern, ohne die Stabilität zu riskieren. Deshalb ist es ja auch so wichtig, dass die Architektur gut kommuniziert und die Pfade zur Umsetzung der architekturellen Aspekte ausgetrampelt werden.

Nur wenn jeder im Team weiß, auf was es architekturell ankommt, entsteht die benötigte Stabilität, um später flexibel auf geänderte Anforderungen reagieren zu können. Das arc42-Template von Gernot Starke und Peter Hruschka hilft hier bei der Strukturierung der Dokumentation.

W-JAX: Wie schafft man es, den richtigen Mix aus Stabilität und Flexibilität zu finden? Hast du da vielleicht einen Tipp aus deinen langjährigen Erfahrungen?

Ralf D. Müller: Jedes Projekt ist anders und bringt unterschiedliche Anforderungen bezüglich Stabilität und Flexibilität mit. Deswegen ist es wichtig, einen Blick auf die Requirements zu werfen und nicht einfach eine interessante Architektur eines anderen Projekts zu übernehmen. Die Requirements geben meist vor, welcher Teil der Architektur flexibel und welcher stabil sein muss.

Soll z.B. ein White-Label Produkt erstellt werden, dann ist das Design sicherlich flexibler zu halten als bei einer Anwendung zur internen Verwendung. Aber die beiden Attribute müssen sich auch nicht widersprechen: Erst die Stabilität in den Schnittstellen zwischen wohldefinierten Modulen ermöglicht die Flexibilität zur Änderung einzelner Module.

W-JAX: Im Zuge der DevOps-Bewegung erweitert sich das Bild des Software-Architekten noch um eine weitere Facette: Es geht nämlich nicht nur um Anwendungsentwicklung, sondern immer mehr auch darum, wie sich Anwendungen in einer Continuous-Delivery-Landschaft einbetten. „You build it, you run it“ heißt da das Stichwort. Wie hat die DevOps-Bewegung die Rolle des Software-Architekten verändert? Was musst du als Architekt heute anders machen, als früher, als man die Anwendungen noch einfach über den Zaun hin zum Ops-Team geworfen hat?

Ralf D. Müller: Hat man das früher gemacht – Anwendungen einfach über den Zaun hin zum Ops-Team geworfen?  Der Betrieb der Software war schon immer ein wichtiger Aspekt der Architektur. Eine Applikation wird meist länger betrieben, als entwickelt. Somit ist der Aspekt des Betriebs für den Erfolg der Software mindestens genauso wichtig wie z.B. der Aspekt des Clean Code.

Aus meiner Sicht hat sich in diesem Bereich die wichtigste Änderung nicht direkt durch DevOps ergeben, sondern durch die iterativen Entwicklungszyklen eines agilen Projekts. Es gibt nicht mehr das Upfront-Design der Architektur, sondern man kann ein Projekt nun über mehrere Release-Zyklen begleiten. Dadurch sieht der Architekt vor allem, wie die Architektur die Qualitätskriterien des Projekts auch tatsächlich implementiert und kann die Architektur entsprechend anpassen.

W-JAX: Ein weiterer Trend ist aktuell, das Design einer Software stark an den fachlichen Domänen auszurichten. Neben DDD als Theorie erobern gerade Microservices-Architekturen die Praxis. Neben den technologischen Aspekten, die Domänen-fokussierte Anwendungen mit sich bringen, geht es hier zentral auch darum, die beteiligten Leute erst einmal in ein Boot zu holen: Fachexperten, Entwickler und natürlich auch die Geschäftsleitung und Anwender bzw. Kunden. Ist man da als Software-Architekt nicht eigentlich zu 80% Projektmanager? Wie hältst du das persönlich: Wie stark nimmst du die Rolle des Projektmanagers ein, wie viel konzentrierst du dich auf Technologien?

Ralf D. Müller: Es stimmt schon, dass Software-Architektur streckenweise mehr mit Management als mit Technologie zu tun hat. Aber wie bei allem hängt es sehr stark vom eigentlichen Projekt und des Typs „Architekt“ ab, den man verkörpert. Mich selbst würde ich weniger als Projekt-, sondern mehr als Architekturmanager sehen. Die Architektur, die in meinem Kopf ist, muss irgendwie raus in die Umsetzung. Das geschieht durch Dokumentation, Kommunikation und auch Management.

W-JAX: Auf der W-JAX hältst du einen Talk namens „Docs-as-Code“. Wo liegt der große Unterschied zwischen dem Docs-as-Code-Ansatz, den ihr beschreibt, und der traditionellen Art und Weise, Software zu dokumentieren?

Ralf D. Müller: Der Unterschied ist recht groß und vielfältig. Ich denke, jeder kennt die klassische, mit einer Textverarbeitung erstellte Dokumentation, die getrennt vom Code verwaltet wird. Dokumentation gehört aber, wie Tests auch, zum Code und sollte mit diesem verwaltet werden. Dadurch ist immer klar, wo die aktuelle Version liegt.

Sobald die Dokumentation zusammen mit dem Code verwaltet wird, können auch weitere Aspekte der Softwareentwicklung auf die Dokumentation übertragen werden. So kann z.B. das Aktualisieren von Diagrammen automatisiert im Build umgesetzt und die Dokumentation sogar automatisiert getestet werden. Wird eine Änderung am Code vorgenommen, so gehört es mittlerweile zur Definition of Done, auch die Tests anzupassen. Mit Docs-as-Code wird im gleichen Schritt auch die Dokumentation gepflegt, weil ein Pull-Request sonst nicht als vollständig im Sinne der DoD angesehen wird.

W-JAX: Welchen Trend findest du im Bereich der Software-Architektur momentan besonders spannend – und warum?

Ralf D. Müller: Ich beobachte momentan, wie der Ansatz der Microservices reift. Zum Einen setzt sich die Erkenntnis durch, dass auch Microservices nicht die Lösung für jedes Problem sind und man abwägen muss. Aber auch die Art der Implementierung von Microservices auf der JVM entwickelt sich weiter. So steht mit micronaut.io mittlerweile ein Framework zur Verfügung, welches zielgerichtet auf Microservices hin entwickelt wurde und nicht als Full-Stack Framework entstand. Auch der Serverless-Ansatz ist in diesem Zusammenhang spannend. Solche Entwicklungen sorgen dafür, dass die Arbeit als Software-Architekt immer spannend bleiben wird.

Vielen Dank für dieses Interview!

The post Microservices sind kein Allheilmittel! appeared first on JAX.