Nicht jeder hat das Glück einen prall gefüllten Stiefel am Morgen vorzufinden, weshalb der JAX – Nikolaus Niko Köbler heute fleißig war und gleich drei Exemplare „Serverless Computing in der AWS Cloud“ an ein paar glückliche Entwickler verschenken wird!

Passend zum Anlass verlosen wir 3 Buchexemplare „Serverless Computing in der AWS Cloud“.

Dieses Praxisbuch zeigt, wie zeitgemäße, aber serverlose Microcervice Cloud Architekturen am Beispiel der AWS Cloud schnell und agil aufgebaut und betrieben werden können.  Das Buch führt in die Konzepte von Serverless Computing am Beispiel der AWS (Amazon Web Services) Cloud ein und beschreibt, wann der Einsatz von Serverless ein sinnvoller Lösungsansatz ist.

Benötigen Sie praxisnahe Tipps beim Einstieg in die Serverless-Welt? Dann haben Sie jetzt die Gelegenheit, dieses Buch noch heute zu gewinnen.

Bitte tragen Sie Ihre Email-Adresse ein, erhalten Sie somit den JAX-Newsletter und gewinnen Sie mit etwas Glück eins von drei Buchexemplaren „Serverless Computing in der AWS Cloud“ .

P.S. Auch treue BASTA-Newsletterabonnenten kommen in den Lostopf, wenn sie sich hier nochmal eintragen!

The post Das JAX Nikolaus – Gewinnspiel! appeared first on JAX.

THESE 1

Bernhard Löwenstein: Die meisten Unternehmen machen nicht Scrum, sondern verwenden lediglich einen Scrum-ähnlichen Prozess. So werden beispielsweise immer wieder die Daily Stand-ups oder die Retrospektiven nicht gemacht. Dadurch geht aber manch großer Vorteil verloren, dessen sich die Unternehmen aber gar nicht bewusst sind.

Konstantin Diener: Auf jeden Fall! Ich unterscheide gerne zwischen Unternehmen, die „agil machen“ und denen, die „agil sind“. Damit ein Team oder eine Organisation wirklich die Erträge agiler Entwicklung bekommt, muss man die zugrunde liegenden Konzepte verstehen. Zum Verständnis ist es nützlich, sich am Anfang an die Elemente des Scrum-Frameworks zu halten und nichts wegzulassen. Wenn die Konzepte und Beweggründe in Fleisch und Blut übergegangen sind, ist es vollkommen in Ordnung zu experimentieren, z. B. „Wir machen eine kurze Retro bei jedem Produktionsfehler, dafür aber nicht mehr unbedingt nach jedem Sprint“.

Ich unterscheide gerne zwischen Unternehmen, die „agil machen“

und denen, die „agil sind“.

THESE 2

Bernhard Löwenstein: Bei den früher klassischen Vorgehensmodellen gab es immer einen großen Aufschrei der Entwickler, wenn Codeteile im Nachhinein geändert werden mussten. Bei Scrum sind in den meisten Projekten die zwischendurch durchgeführten Codeadaptierungen noch wesentlich umfangreicher, allerdings wird dies nicht bewusst wahrgenommen. Um es mit einer Metapher auszudrücken: Am Ende steht zwar ein fertiges Haus, aber auf dem Weg dahin hat man oft in Summe auch ein ganzes Haus wieder eingerissen.

Konstantin Diener: Um auf diese These zu antworten, würde ich zunächst gerne beim Hausbaubeispiel bleiben. Wenn ich exakt weiß, wie das Haus aussehen soll und es sich über die Zeit daran nichts ändern wird, sollte ich gar keinen agilen Entwicklungsansatz wählen. Tatsächlich ist es aber in Softwareprojekten meist so, dass ich das nicht unbedingt so genau weiß. Da es Sommer ist, reicht es mir vielleicht zunächst, die Duschen (wegen der Privatsphäre) zu bauen und auf ihre Praxistauglichkeit zu untersuchen – essen und schlafen kann ich im Freien Mit den Erkenntnissen aus dieser ersten Baustufe kann ich das übrige Haus bauen.

Mit klassischen Modellen baue ich auch zwei Häuser. Ich merke aber erst nach der Fertigstellung, dass das erste Haus nicht sinnvoll nutzbar ist und muss dann noch einmal genauso lange auf die Fertigstellung warten. Und außerdem kann ich das „agile Haus“ schon teilweise benutzen.

Der Agile & Culture Track auf der JAX 2019

THESE 3

Bernhard Löwenstein: Es wird bei Scrum vorab kaum mehr etwas spezifiziert, sondern die Produktivität wird vorrangig daran gemessen, wie schnell die Entwickler loslegen und etwas Herzeigbares liefern. Das endet oftmals in Code, der deutlich eleganter geschrieben hätte werden können, oder in Architekturen, die sich später als suboptimal herausstellen.

Konstantin Diener: Die Frage ist immer, was eleganter bedeutet. Nicht ohne Grund gibt es den Spruch über Informatiker: „Gib ihnen ein Problem und sie entwickeln eine Programmiersprache bzw. ein Framework, mit dem solche Probleme perfekt gelöst werden können.“ Ich will damit sagen, dass wir uns in der Softwareentwicklung auch gern „verkünsteln“. Deswegen arbeitet man in agilen Teams in der Regel ja mit „Good enough for now“-Lösungen. Dieses Konzept ist aber nur richtig angewendet, wenn das Team kontinuierlich Refactoring betreibt (in der Summe ein ganzes Haus wieder einreißt). Außerdem habe ich mit detaillierten Spezifikationen die Erfahrung gemacht, dass die meisten der dort getroffenen Abstraktionen sich als falsch herausstellen.

THESE 4

Bernhard Löwenstein: Entwickler lieben Scrum vor allem deshalb, da die lästige Arbeit des Dokumentierens auf ein Minimum reduziert wird und das Programmieren im Vordergrund steht. Das erzeugt den Eindruck, dass man stets produktiv ist, auch wenn dies gesamtheitlich betrachtet nicht so der Fall ist.

Konstantin Diener: Das agile Manifest sagt nichts über den Umfang der Dokumentation, sondern nur, dass lauffähige Software wichtiger ist. Ich weiß, dass dieser Satz oft als „schreibt gar keine oder nur ganz wenig Dokumentation“ verstanden wird. Ich verstehe ihn als Anlass, über den richtigen Umfang von Dokumentation nachzudenken. In klassischen Projekten wird nämlich in der Regel viel zu viel sinnlose Dokumentation mit großem Aufwand erzeugt. Das geht zum Teil so weit, dass Klassen oder Methoden lausige Namen bekommen, weil man ja eh noch Javadoc dranschreiben muss. Oder dass Schnittstellendokumentationen in ein Write-only-Wiki geschrieben werden, anstatt sie in einem Format zu beschreiben, das sich gleichzeitig für automatisierte Tests eignet.

Scrum hat für mich nicht direkt etwas mit Technik zu tun, sondern ist ein Mittel zur Produktentwicklung, Arbeitsorganisation und kontinuierlichen Verbesserung.

THESE 5

Bernhard Löwenstein: Wer Scrum mit den früher klassischen Vorgehensmodellen vergleicht, macht oft den Fehler, dass er Scrum inklusive der heute bereitstehenden Werkzeuge und Techniken mit dem früher klassischen Prozess exklusive dieser Werkzeuge und Techniken vergleicht (da es diese eben damals noch nicht gab). Klarerweise scheint Scrum dann den „alten“ Vorgehensmodellen deutlich überlegen zu sein.

Konstantin Diener: Scrum hat für mich nicht direkt etwas mit Technik zu tun, sondern ist ein Mittel zur Produktentwicklung, Arbeitsorganisation und kontinuierlichen Verbesserung. Auch ohne die heutigen CI-Server und Testframeworks lässt sich mit Scrum immer noch einfacher auf Veränderungen reagieren und es lassen sich benutzbare Inkremente schneller ausliefern – noch dazu in einem sich verändernden Umfeld. Die Tools helfen uns in der Regel dabei, effizient zu sein. Scrum hilft uns dabei, effektiv zu sein. Kurz gesagt, bringen mir alle CI-Server, Testframeworks etc. keinen Mehrwert, wenn ich erst nach zwei Jahren feststelle, dass ich das falsche Produkt baue.

The post “Agil machen” oder “agil sein” – Fünf Thesen zu Scrum appeared first on JAX.

THESE 1

Bernhard Löwenstein: Die meisten Unternehmen machen nicht Scrum, sondern verwenden lediglich einen Scrum-ähnlichen Prozess. So werden beispielsweise immer wieder die Daily Stand-ups oder die Retrospektiven nicht gemacht. Dadurch geht aber manch großer Vorteil verloren, dessen sich die Unternehmen aber gar nicht bewusst sind.

Frank Düsterbeck: Diese These unterstütze ich. Die Sätze „Das Beste aus beiden Welten“ oder „Wir haben Scrum auf unsere Belange zugeschnitten“ höre ich relativ häufig. Ursache hierfür ist nicht selten die Angst, mit allen Konsequenzen von Scrum umgehen zu müssen – angefangen bei den Rollen bis zum potenziell auslieferbaren Produkt. Scrum ist ein Problemsensor, und als solcher zeigt es alle Hindernisse sehr schnell auf: in der Organisation, bei den Menschen und deren Interaktionen, bei den Prozessen und Praktiken und in den Technologien. Das muss man aushalten können und an die Ursachen ran. Die konsequente Abarbeitung der Hindernisse zur Optimierung des Wertstroms schaffen aber nur die wenigsten. Den Sensor beispielsweise durch das Weglassen der Retros zu verlieren, ist manchmal viel einfacher, bedeutet aber nichts anderes als die Ursachen zu ignorieren und das wirkliche Potenzial von Scrum nicht zu nutzen.

THESE 2

Bernhard Löwenstein: Bei den früher klassischen Vorgehensmodellen gab es immer einen großen Aufschrei der Entwickler, wenn Codeteile im Nachhinein geändert werden mussten. Bei Scrum sind in den meisten Projekten die zwischendurch durchgeführten Codeadaptierungen noch wesentlich umfangreicher, allerdings wird dies nicht bewusst wahrgenommen. Um es mit einer Metapher auszudrücken: Am Ende steht zwar ein fertiges Haus, aber auf dem Weg dahin hat man oft in Summe auch ein ganzes Haus wieder eingerissen.

Frank Düsterbeck: Das sehe ich anders. Scrum – wenn ernst genommen – führt die Entwickler dahin, von vornherein Wert zu schöpfen. Projekte, in denen erst das gesamte Datenmodell und dann die Stammdaten ausprogrammiert werden, sollten demnach der Vergangenheit angehören. Gerade in letzteren Projekten war es eher notwendig, größere Teile oder sogar alles noch mal über den Haufen zu werfen. Insbesondere, weil man im Vornherein eben nicht alles weiß. Eine iterative, evolutionäre Entwicklung wie mit Scrum schützt vor Fehlentwicklungen und führt daher nicht zwangsweise zu mehr Codeadaptierung.

Scrum – wenn ernst genommen – führt die Entwickler dahin, von vornherein Wert zu schöpfen.

Der Agile & Culture Track auf der JAX 2018

THESE 3

Bernhard Löwenstein: Es wird bei Scrum vorab kaum mehr etwas spezifiziert, sondern die Produktivität wird vorrangig daran gemessen, wie schnell die Entwickler loslegen und etwas Herzeigbares liefern. Das endet oftmals in Code, der deutlich eleganter geschrieben hätte werden können, oder in Architekturen, die sich später als suboptimal herausstellen.

Frank Düsterbeck: Das sehe ich anders. In Scrum ist es durchaus sinnvoll und notwendig, mit geeigneten Praktiken (z. B. Personas, Story Mapping) vorab Erkenntnisse zu gewinnen und das Product Backlog für die ersten Sprints vorzubereiten, um nicht ins Blaue loszucoden. Natürlich ist es wichtig, schnell Wert zu schöpfen. Dies sollte immer das Ziel sein. Denn nur dann werden wir die Hindernisse, die der Wertschöpfung entgegenstehen, konsequent eliminieren. Das hat aber meiner Meinung nach keinen negativen Einfluss auf die Codequalität. Diese hängt eher vom Selbstverständnis der Entwickler, dessen Manifestation in der Definition of Done und der konsequenten Einhaltung dieser ab. Gerade in rein sequenziellen Projektumfeldern, in denen Refactoring kein kontinuierlicher Prozess ist, leidet die innere Qualität stärker als in agilen Umfeldern, in denen Refactoring kontinuierlich stattfindet.

THESE 4

Bernhard Löwenstein: Entwickler lieben Scrum vor allem deshalb, da die lästige Arbeit des Dokumentierens auf ein Minimum reduziert wird und das Programmieren im Vordergrund steht. Das erzeugt den Eindruck, dass man stets produktiv ist, auch wenn dies gesamtheitlich betrachtet nicht so der Fall ist.

Frank Düsterbeck: Längst nicht alle Entwickler lieben Scrum – ganz im Gegenteil! Durch die hohe Transparenz können sich Menschen, die beispielsweise in einer Misstrauenskultur gearbeitet haben, stark unter Druck gesetzt fühlen und Scrum negativ empfinden. Es gibt eben keine Möglichkeit, sich zu verstecken, sondern Vertrauen und Offenheit sind die Basis des guten Miteinanders. Was die Dokumentation angeht, so macht Scrum dort keine Vorgaben. Das bedeutet: Auch in Scrum-Umfeldern kann viel Dokumentation anfallen (z. B. in der Medizintechnik). Die These ist eher eine beliebte Fehlinterpretation der agilen Werte und hat mit Scrum eigentlich gar nichts zu tun. 

In Scrum ist es durchaus sinnvoll und notwendig, mit geeigneten Praktiken (z. B. Personas, Story Mapping) vorab Erkenntnisse zu gewinnen und das Product Backlog für die ersten Sprints vorzubereiten, um nicht ins Blaue loszucoden.

THESE 5

Bernhard Löwenstein: Wer Scrum mit den früher klassischen Vorgehensmodellen vergleicht, macht oft den Fehler, dass er Scrum inklusive der heute bereitstehenden Werkzeuge und Techniken mit dem früher klassischen Prozess exklusive dieser Werkzeuge und Techniken vergleicht (da es diese eben damals noch nicht gab). Klarerweise scheint Scrum dann den „alten“ Vorgehensmodellen deutlich überlegen zu sein.

Frank Düsterbeck: Die heute modernen Praktiken und Methoden, die es teilweise schon länger als Scrum gibt (z. B. Automatisierung, XP, CCD, Story Mapping, Design Thinking, Microservices), können selbstverständlich auch in klassischen Umfeldern hilfreich sein. Durch die iterative Vorgehensweise, das Rollenmodell, die Transparenz, Inspektion und Adaption hat Scrum jedoch eindeutige Vorteile gegenüber klassischen sequenziellen Modellen.

Man darf auch nicht außer Acht lassen, dass einige klassische Vorgehensweisen Iterationen bzw. Rückkopplungen der verschiedenen Phasen eingeführt haben, da eine rein sequenzielle Abarbeitung einer komplexen Problemstellung eben falsch ist. Diese Rückkopplungen habe ich persönlich aber in noch keinem einzigen Wasserfallprojekt als bewussten Prozessschritt gesehen – schade!

The post Fluch oder Segen? – Fünf Thesen zu Scrum appeared first on JAX.

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für  Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

W-JAX:   Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Stefan Tilkov: Das vielleicht offensichtlichste Beispiel sind die vielen Web- und E-Commerce-Systeme, die oft durch eine Initiative einer Marketing-Abteilung entstanden sind und oft auch dort betreut wurden, während sich die restlichen Fachabteilungen mit der IT-Abteilung abstimmt, von ihr betreut wird oder sich mit ihr auseinandersetzt. In der Gesamtarchitektur spiegelt sich das dann auf einmal in einer Vielzahl wenig sinnvoller Redundanzen wider, die im Moment in vielen Unternehmen gerade aufgelöst werden.

Doch man findet die Effekte von Conway’s Law auch bei den vielen Querschnittsabteilungen, die sich verselbständigen und Systeme betreuen, die dann in einer Architektur als Fremdkörper auftauchen. Das können zentrale Datenbanken, monolithische Systeme oder Integrationsserver sein, die von einer Organisationseinheit regelrecht bewacht werden, sodass die Prozesse unglaublich aufwändig werden und jede Änderung mit massiven Schmerzen verbunden ist.

Aber auch wenn fast alles richtig gelaufen ist, bekommt man manchmal durch Unachtsamkeit frische Conway-Effekte: Es gab bei der Neuentwicklung eines großen Shopsystems eine schöne SCS-artige Architektur, bei der knapp zehn Teams hervorragend parallel arbeiten konnten, da die von ihnen realisierten Teilsysteme über wenige, standardisierte Schnittstellen miteinander kommunizierten, mit Hilfe von Redundanz auf Autonomie geachtet wurde, jedes Team volle Verantwortung für alle Schichten von Persistenz bis UI hatte – eigentlich eine wunderbare Struktur, bei der Architektur und Organisation aufeinander abgestimmt waren. Aber dann gab es die Initiative, für die Auslieferung von Frontend-Komponenten und -Assets ein zentrales Team aufzusetzen.

Das hat – wie jede Form der Zentralisierung – durchaus Vorteile, man muss z.B. alles nur an einer Stelle lösen. Es hat aber auch massive Nachteile – in diesem Fall konkret, dass das neu eingeführte zentrale Frontend-Team zum Bottleneck für alle anderen wurde. Die Architektur veränderte sich, mit allen Nachteilen, weil die Organisation sich im Zweifelsfall durchsetzt.

Also am besten das dringendste Problem identifizieren und sich zunächst auf dessen Lösung konzentrieren, anstatt gleich zu versuchen, alles auf einmal zu ändern.

W-JAX:   Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Stefan Tilkov: Am wichtigsten ist aus meiner Sicht, sich darüber klar zu werden, welchen Kampf man für den wichtigsten hält, um sich nicht an X Fronten gleichzeitig aufzureiben (wenn mir die militaristische Metapher gestattet ist). Also am besten das dringendste Problem identifizieren und sich zunächst auf dessen Lösung konzentrieren, anstatt gleich zu versuchen, alles auf einmal zu ändern. In unserer Architekturarbeit, aber auch in unseren Entwicklungsprojekten versuchen wir in aller Regel als erstes, wenige globale Regeln in Verbindung mit viel lokaler Autonomie zu etablieren. Damit beschränkt man die Entscheidungsfreiheit bestehender Strukturen und Teams zwar, aber nicht in einem zu großen Maße. Gleichzeitig schafft man die Möglichkeit, schrittweise Verbesserungen einzuführen.

Der Software Architecture Track auf der JAX 2018

W-JAX:   Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Stefan Tilkov: Ich würde es anders formulieren: Organisation, Architektur und auch Prozesse müssen aufeinander abgestimmt sein, sonst ist jede einzelne Facette – wie toll sie auch immer gestaltet sein mag – zum Scheitern verurteilt. Im Idealfall werden sie gemeinsam entwickelt. Ist das nicht möglich, z.B. weil eine Organisation schon da ist und nicht einfach geändert werden kann, müssen sich Zielarchitektur und -Prozesse daran orientieren, sonst werden sie nie Realität. Das Gleiche gilt auch andersherum.

W-JAX: Jeff Sussna hat einmal in einer Keynote darauf hingewiesen, dass Conway aus seiner Ursprungsthese etwas seiner Meinung nach viel Wichtigeres folgert: Dass es für jedes gegebene Design nämlich immer ein noch besseres geben könnte. Wichtiger als gutes System-Design wird damit die Fähigkeit zum Redesign. Würdest du dem zustimmen? Und wenn ja, wie kann man dem in der Software-Architektur Rechnung tragen?

Stefan Tilkov: Das ist aus meiner Sicht die ganz zentrale Erkenntnis in der Diskussion über die „richtige“ Architektur: Es gibt sie nicht. Man kann nur darauf hinarbeiten, einen Architekturrahmen zu definieren, der Evolution und Weiterentwicklung unterstützt. Das ist nach meinem Verständnis die zentrale Idee hinter Microservices, Self-contained Systems und ähnlichen Ansätzen.

W-JAX: Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Stefan Tilkov: Für mich ist die Rückkehr zu pragmatischen, einfachen, dem tatsächlich identifizierten Problem angemessenen Lösungen im Kleinen anstelle generischer, eierlegender Wollmilchsäue ein wichtiger Gedanke. Wenn ich Software so baue, dass die einzelnen Teile, aus denen sie besteht, nicht für die Ewigkeit perfekt sein müssen, sondern sich schnell und unkompliziert austauschen lassen, kann ich mich auf das Problem konzentrieren und genau das lösen. Passt die Lösung in 12 Monaten nicht mehr, werfe ich den einen Baustein im Zweifelsfall weg und entwickle ihn auf eine andere, bessere, vielleicht modernere Art neu.

Die ganz zentrale Erkenntnis in der Diskussion über die „richtige“ Architektur: Es gibt sie nicht. 

W-JAX:  Stefan, auf der W-JAX stellst du Patterns und Antipatterns von Microservices vor. Kannst du einmal ein Beispiel nennen, wann eine Microservices-Architektur eine gute Lösung, wann aber auch eher ein Irrweg darstellen kann?

Stefan Tilkov: Ein schönes Beispiel, ebenfalls aus der Praxis: Man entwickelt eine Microservice-Architektur, bestehend aus unzähligen, winzig kleinen Services, schneidet aber so, dass einzelne Services eine zentrale Rolle spielen und fast alle anderen von ihnen abhängen. Man kauft sich damit enorme Koordinationsprobleme ein und wundert sich, dass man statt einer agilen Architektur nur einen verteilten Monolithen bekommt, der sich vor lauter Container-Overhead auf einem 16GB-Entwickler-Laptop nur noch mit Mühe starten lässt. Im Prinzip ist das auch wieder eine Conway-Verletzung, weil man vergisst, dass ein zentraler Grund für Modularisierung eine gute Entkopplung und eine „Separation of Concerns“ ist. Das hat David Parnas übrigens schon Anfang der 70er gut erkannt …

The post Die ewige Suche nach der “richtigen” Architektur appeared first on JAX.

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für  Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

W-JAX:   Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Dr. Gernot Starke: Darf ich voranstellen, dass ich „Conway’s Law“ für eine totale Fehlbenennung halte: Es sollte „Conway’s Observation“ heißen – weil es weder ein Gesetz noch eine eiserne Regel ist, sondern eine (empirische) Beobachtung.

Als Softwarearchitekten arbeiten wir häufig in einem Unternehmenskontext, bei dem wir auf organisatorische Randbedingungen meistens Rücksicht nehmen müssen, und selten einmal „organizational change“ anstoßen können, um diese Randbedingungen für unsere Entwicklung zu lockern. Meistens hingegen liegen organisatorische Änderungen außerhalb der uns zugestandenen Kompetenzen – und wir müssen mit der bestehenden Organisation leben.

Zu der eigentlichen Frage, wo mir Conway bereits begegnet ist: Ich müsste eher überlegen, bei welchen meiner Kunden bzw. Projekte die interne Organisation keine Auswirkungen auf die Softwarestruktur hatte. Conway hat bei mir beispielsweise im Maschinenbau zugeschlagen:

Diverse Komponenten von Großmaschinen wurden von verschiedenen Ingenieurteams entwickelt, mit jeweils ziemlich speziellen Anforderungen. Die Software für die Rüstung dieser Maschinen war in komplett anderer Technologie entwickelt, genauso wie die Software zur Überwachung/Monitoring zur Laufzeit. Das hat Synergien gründlich verhindert 

Ein zweites Beispiel stammt von Versicherungen: Dort habe ich Datenbankteams angetroffen, die losgelöst von den sogenannten Client/Server-Teams gearbeitet haben. Dann brauchte es noch eine dritte Gruppe, die Integrations-Leute, die C/S und DB zu den berüchtigten Deployment-Monolithen zusammengebracht haben.

Ein Unternehmen auf Softwarearchitektur abzustimmen benötigt extrem hohe Motivation seitens der Unternehmensführung, und diese Software muss grundlegende Bedeutung für das Unternehmen haben.

W-JAX:   Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Dr. Gernot Starke: Ja, Separation-of-Concern: für organisatorische Änderungen Leute dazuholen, die das professionell und Full-time machen. Als Softwarearchitekten neben der Entwicklungsarbeit noch schnell eine Abteilung oder gar Unternehmen umorganisieren, wäre aus meiner Sicht ein etwas vermessener Anspruch…

Einer meiner Kunden hat das beherzigt und einen Profi für „Change Management“ angeheuert – eine erfahrene, empathische und trotzdem durchsetzungsstarke Dame. Sie hatte sowohl strategisches wie politisches Verständnis, hat die Software-Teams „mitgenommen“, aber auch das Management. Diese Zusammenarbeit war für mich eine positive Erfahrung, weil sich durch ihre Arbeit in diesem Unternehmen wirklich Dinge positiv verändert haben – was viele Software-Teams in den Jahren vorher nicht annähernd geschafft hatten.
 

Der Software Architecture Track auf der W-JAX 2018

W-JAX:   Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Dr. Gernot Starke: Ein Unternehmen auf Softwarearchitektur abzustimmen benötigt extrem hohe Motivation seitens der Unternehmensführung, und diese Software muss grundlegende Bedeutung für das Unternehmen haben.

Bei eCommerce-Unternehmen habe ich solche Motivation kennengelernt – ja, und davon haben einige auch hervorragende Systeme zustande gebracht. Als Softwarearchitekten bzw. Entwicklungsteams fallen viele Entscheidungen dann leichter, weil das Unternehmen viel mehr unterstützt.

Die eher klassischen Unternehmen aus Finance, TelCo, Handel und Maschinenbau sind aber anders organisiert, und meiner Beobachtung nach auch ziemlich träge damit, ihre IT- beziehungsweise Entwicklungsorganisation zu flexibilisieren, also mehr in Richtung cross-funktionale Teams aufzustellen.

Ich müsste eher überlegen, bei welchen meiner Projekte die interne Organisation keine Auswirkungen auf die Softwarestruktur hatte.

W-JAX:   Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Dr. Gernot Starke: Bei vielen Entwicklungsteams, auch in großen Unternehmen, ist mittlerweile angekommen, dass der Wandel unserer Branche immer schneller wird. Das führt dazu, dass verkrustete Strukturen und überkommene Entscheidungen vermehrt in Frage gestellt werden, dass Organisationen und Entwickler die Notwendigkeit für Änderungen, Innovation und Evolution mehr einsehen.
 

W-JAX: Dr. Gernot, du erzählst auf der kommenden W-JAX die „VENOM“-Story. Klingt irgendwie giftig. Worum wird es gehen?

Dr. Gernot Starke: Im Open-Source-Projekt (aim42) engagiere ich mich für mehr Systematik bei der Verbesserung und Evolution bestehender Systeme. VENOM illustriert anhand eines (riesigen) Beispiels, was dabei geschehen könnte, und zeigt praktische Maßnahmen auf, um große Systeme wieder „auf die Spur“ zu bringen. Dabei prallen Meinungen aufeinander, es gibt Streit, Opfer und überraschende Wendungen. Wie der Showdown ausgeht, verrate ich erst im Vortrag.

The post Die Evolution der Softwarearchitektur appeared first on JAX.

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für  Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

 
W-JAX:   Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Lars Röwekamp:  Es ist für mich immer wieder faszinierend, feststellen zu „dürfen“, wie aktuell dieses vor fast 50 Jahren aufgestellte Gesetz heute noch ist. Wir als open knowledge sind häufig bei großen Kunden mit klassischen Konzernstrukturen im Einsatz. Die dort vorherrschenden, sehr komplexen Organisations- und Kommunikationsstrukturen sorgen nicht selten dafür, dass von speziellen Architektur-Teams extrem umfangreiche und hoch generische, konzernweite Architekturen vorgegeben werden.

Die eigentlichen Anwendungen bzw. deren konkrete Fachlichkeiten werden dann via architekturspezifischer DSLs, XML-Konfigurationen oder irgendeinem anderen Voodoo-Ansatz auf mystische Art und Weise generiert. Was ursprünglich einmal gut gemeint war, führt in der Regel dazu, das selbst kleinste Features – dank Medienbruch – nur sehr umständlich umzusetzen sind und ein fachliches Debugging kaum noch möglich ist.

Als ich bei einem unserer größeren Kunden einmal Conway’s Law thematisiert habe, hat dieser das aktuelle Organisationsdiagramm und ein Schaubild der „gelebten“ Architektur gegenüber gestellt. Beide Schaubilder sahen sich erschreckend ähnlich und erinnerten eher an den U-Bahn-Fahrplan einer europäischen Großstadt als an ein strukturiertes und gut durchdachtes System.

W-JAX:   Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Lars Röwekamp: Hier sprichst du ein sehr wichtiges Thema an. In vielen Unternehmen herrschen historisch bedingt Strukturen vor, die von den meisten Mitarbeitern einfach als von Gott gegeben hingenommen und somit nicht mehr hinterfragt werden. Es kommt daher nicht von ungefähr, dass sich gerade in großen Unternehmen immer wieder kleine Lab-ähnlich Teams herausbilden. Dies ist häufig die einzige Möglichkeit, legitim aus den vorgegebenen Strukturen auszubrechen. Projekte werden als Prototypen oder Proof-of-Concepts getarnt, da für diese weniger starre Auflagen gelten als für normale Software-Projekte.

In meiner Rolle als Architekt hinterfrage ich grundsätzlich den Nutzen bestehender Strukturen, Frameworks etc. Kann mir keiner der Beteiligten einen sinnvollen Grund für das Vorhandensein nennen – „das war schon immer so“ ist übrigens KEIN sinnvoller Grund – dann stelle ich das Konstrukt auf den Prüfstand und entsorge es gegebenenfalls.

Psychologisch gesehen sollte man hier natürlich mit einem gewissen Feingefühl vorgehen. Oftmals wird ein architektonisches Refactoring als eine Art Schuldeingeständnis für eine Fehlplanung der Vergangenheit interpretiert. Dies ist insbesondere dann der Fall, wenn sich spezielle Teams für die Architektur verantwortlich zeichnen und andere für die Implementierung der Anwendungen auf Basis dieser Architektur. Hier ist ein Finger-Pointing quasi vorprogrammiert. Es ist also wichtig zu vermitteln, dass Software lebt und Refactoring somit einen ganz natürlich Prozess darstellt, um auf geänderte Anforderungen bzw. einen geänderten Kontext zu reagieren.

Es ist faszinierend, wie aktuell dieses vor fast 50 Jahren aufgestellte Gesetz heute noch ist

Der Software Architecture Track auf der JAX 2018

W-JAX:   Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Lars Röwekamp: Ich würde es eher so formulieren: Eine schlanke Unternehmensorganisation bzw. -kommunikation erhöht die Chancen, dass am Ende ein System herauskommt, bei dem die konkrete Fachlichkeit – also die jeweils umzusetzende Domäne (DDD lässt grüßen) – im Fokus steht und nicht eine unternehmensweite Architektur bzw. ein Rahmenwerk, in welches die Fachlichkeit irgendwie hineingepresst werden muss.

Wir haben in unseren Projekten häufig feststellen dürfen, dass fachlich organisierte Teams, im Vergleich zu rein technisch organisierten Teams, qualitativ bessere Software in kürzerer Zeit produzieren. Dies liegt nicht selten daran, dass ein Großteil der für die Implementierung der Software notwendigen Kommunikation direkt innerhalb des Teams stattfinden kann.

W-JAX:   Jeff Sussna hat einmal in einer Keynote darauf hingewiesen, dass Conway aus seiner Ursprungsthese etwas seiner Meinung nach viel Wichtigeres folgert​. Dass es für jedes gegebene Design nämlich immer ein noch besseres geben könnte. Wichtiger als gutes System-Design wird damit die Fähigkeit zum Redesign. Würdest du dem zustimmen? Und wenn ja, wie kann man dem in der Software-Architektur Rechnung tragen?

Lars Röwekamp: Da gebe ich Jeff Sussna zu 100% recht! Leider wird in der Praxis die „Fähigkeit zum Redesign“ immer wieder gerne mit „generischen“ und somit scheinbar hoch flexiblen Systemen verwechselt, in denen am Ende mehr deklariert als programmiert wird.

Aber zurück zu der Aussage von Jeff Sussna: Nehmen wir einmal als Beispiel die wunderschöne Welt der Microservices. Ein gut durchdachtes Design sieht von Anfang an vor, dass die Schnittstellen der Services – egal ob synchrones REST API oder Messaging – sich im Laufe der Zeit verändern dürfen und dass einzelne Services oder ganze Service-Gruppen durch andere ersetzt werden können. Gut und richtig gemacht, ergibt sich am Ende eine Gesamtarchitektur als Choreographie des Zusammenspiels der einzelnen Services und nicht als Orchestration durch eine zentralen Instanz. Die Fähigkeit zum Redesign ist somit per Definition Bestandteil der Architektur.

Von Anfang an sollte man „tolerante“ Schnittstellen in seinem Design einplanen.

W-JAX:   Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Lars Röwekamp: Wenn wir schon bei „Gesetzen“ sind, fällt mir sofort Postel’s Law ein: „Be conservative in what you do, be liberal in what you accept from others.“ Auch dieses Gesetz deckt sich stark mit der Aussage von Jeff Sussna, da es sinngemäß besagt, dass ich von Anfang an „tolerante“ Schnittstellen in meinem Design einplanen sollte, um so flexibel auf geänderte Anforderungen reagieren zu können.

Ebenfalls für extrem wichtig halte ich – nicht nur, aber vor allem auch bei lose gekoppelten Systemen, wie Microservices – ein gutes Domänen-Design. Mir wird leider nach wie vor viel zu viel über Technologie und zu wenig über eine geschickte Modularisierung der Fachlichkeit diskutiert. Gut durchdachte Bounded Contexts verbunden mit einem sauberen, zukunftssicheren Schnittstellendesign haben schon so manches Projekt zum Erfolg geführt.

W-JAX: Lars, auf der W-JAX hältst du unter anderem auch einen Talk zum Thema Serverless. Welchen Zusammenhang siehst du zwischen Serverless und der Theorie Conway’s?

Lars Röwekamp: Im Zusammenhang mit Serverless fällt auch immer wieder der Begriff NoOps. NoOps bedeuten in diesem Zusammenhang zwar nicht, dass gar kein operationaler Aufwand mehr notwendig ist. In Konsequenz benötigt man aber kein dezidiertes Ops bzw. DevOps Team. Auf die Spitze getrieben könnte man also soweit gehen und behaupten, dass dank Serverless keine Kommunikation mit anderen und somit auch keine Architektur mehr notwendig ist. Dies wäre allerdings ein wenig blauäugig, denn in der Praxis muss sich natürlich trotzdem jemand um die ursprünglich bei dem Ops- oder DevOps-Team aufgehängten Themen, wie Security, API Gateway etc. kümmern und die durch den Cloud-Anbieter für diesen Zweck zur Verfügung gestellte Infrastruktur konfigurieren und administrieren. Gleiches gilt für weitere, klassische Cross-Cutting-Aspekte, wie zum Beispiel verteiltes Logging und übergreifendes Monitoring.

The post Die Rebellion gegen vorgegebenen Strukturen appeared first on JAX.

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für  Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

 
W-JAX:   Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Eberhard Wolff:  Für mich ist das Gesetz von Conway ein wichtiges Werkzeug, um zu verstehen, was in Projekten vor sich geht. Wenn unterschiedliche Dienstleister für die verschiedenen Teile des Projekts verantwortlich sind, dann beeinflusst das die Kommunikation und die Architektur.

Kommunikation über Firmengrenzen hinweg ist aufwändig, insbesondere wenn die Teams am jeweiligen Firmenstandort des Dienstleisters arbeiten. So entstehen sehr isolierte Module. Ein Zusammenhalt der Architektur ist schwierig.

Dass Teams, die nach Fachlichkeiten aufgestellt sind, die Architektur beeinflussen, haben wir schon vor 15 Jahren in einem Projekt festgestellt. Allerdings haben wir es damals noch nicht zur Steuerung der Architektur genutzt.

Software-Architektur ist nur scheinbar ein technisches Thema.

W-JAX:   Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Eberhard Wolff: Bei der Einstellung von Mitarbeiten oder bei Umorganisationen werden Architekten oft mit einbezogen, da sie die technische Expertise der Personen am besten abschätzen können. Dann können sie auch andere organisatorische Maßnahmen vorschlagen, um die Architektur zu beeinflussen.

Generell ist Software-Architektur nur scheinbar ein technisches Thema. Ein Architekt muss Ideen und Kritik aus den Teams aufnehmen und die Architektur kommunizieren. Diese Maßnahmen beeinflussen die Kommunikationsstrukturen und damit die Architektur.

W-JAX:   Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Eberhard Wolff:  Conway’s Paper diskutiert, dass Projekte zu großen Teams neigen. Das ist gut für das Prestige, und bei einem Fehlschlag kann man argumentieren, dass selbst ein sehr großes Team die Aufgabe nicht lösen konnte. Dann kommt das Gesetz von Parkinson: Eine Aufgabe hält alle verfügbaren Mitarbeiter beschäftigt. Das Gesetz erklärt die Beobachtung, dass eine Verwaltung beliebig mehr Mitarbeiter einstellen kann – die Aufgaben dauern gleich lange.

Ein großes Projekt hat aber entsprechende Kommunikationsschwierigkeit und dann auch Herausforderungen in der Architektur. Also hat Conway schon in seinem Paper erläutert, dass gute Architektur nur mit guter Kommunikation möglich ist.

Architekten müssen die Architektur ständig kritisch hinterfragen und weiterentwickeln.

Der Software Architecture Track auf der JAX 2018

W-JAX:   Jeff Sussna hat einmal in einer Keynote darauf hingewiesen, dass Conway aus seiner Ursprungsthese etwas seiner Meinung nach viel Wichtigeres folgert . Dass es für jedes gegebene Design nämlich immer ein noch besseres geben könnte. Wichtiger als gutes System-Design wird damit die Fähigkeit zum Redesign. Würdest du dem zustimmen? Und wenn ja, wie kann man dem in der Software-Architektur Rechnung tragen?

Eberhard Wolff: Problematische Architekturen entstehen, weil der richtige Zeitpunkt zur Änderung verpasst worden ist. Nicht nur die Anforderungen ändern sich. Es gibt auch neue Technologien und Techniken, die neue Verbesserungen ermöglichen. So ist es unausweichlich, dass eine Architektur sich immer weiter vom Optimum entfernt.

Also müssen Architekten die Architektur ständig kritisch hinterfragen und weiterentwickeln. Vorsorglich Flexibilität in Architekturen einzubauen führt hingegen zu erhöhten Aufwänden, und am Ende ist die Flexibilität leider meistens an den falschen Stellen.

W-JAX:   Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Eberhard Wolff:  Continuous Delivery (CD) ist für mich ein wichtiger Fortschritt für die Produktivität. Microservices unterstützt CD in der Architektur. Die beiden Themen finde ich so wichtig, dass ich darüber Bücher geschrieben habe. Microservices machen Fachlichkeit und Domain-driven Design wieder wichtiger. Alle diese Punkte sind meiner Meinung nach bei der Software-Architektur wegweisend.

Gute Architektur ist nur mit guter Kommunikation möglich.

W-JAX:  Eberhard, auf der W-JAX hältst du eine Session, in der du hinter den aktuellen Hype um Microservices blickst. Was würdest du momentan eher dem Hype zuordnen, was der echten Wertschöpfung, die die Microservices-Idee ermöglicht?

Eberhard Wolff:  Für mich sind Microservices ein guter Türöffner, um eine Architektur-Diskussion zu starten und Themen wie Fachlichkeit, Domain-driven Design oder Continuous Delivery ebenfalls anzusprechen. Dafür ist der Hype auf jeden Fall nützlich. Außerdem erlauben Microservices viel stärkere Entkopplung und lösen so viele Probleme klassischer Modularisierung. Mit Self-contained Systems gibt es außerdem einen Best-Practices-Ansatz für Microservices, deren Vorteile in der Praxis schon viele Projekte aufgezeigt haben.

The post Gute Architektur braucht gute Kommunikation appeared first on JAX.