Publikationen

Wer schon in einem Entwicklungsteam gearbeitet hat, der kennt das bestimmt: Schattenboxen mit Problemen, die konkrete Schmerzen bereiten, aber deren Ursache schwer greifbar ist. “Ich komm zu nix!”, “Warum wurde dieser Service schon seit Jahren nicht geupdatet?”, “Bei dem Thema sind wir jetzt der Flaschenhals”, “Diesen Sprint haben wir wieder nicht viel geschafft, es waren zu viele Ablenkungen”. Die schwer greifbare Ursache ist nicht selten die zu hohe kognitive Last – Cognitive Load – des Teams. Aber was ist das genau? Woher kommt das? Und was macht man dagegen? Das wollen wir uns in diesem Artikel mal genauer anschauen.

Heutige Softwareentwicklung wendet häufig Techniken des modernen Domain-Driven Design an. In dessen Kern gilt es, mit geeigneten Kommunikationsmitteln abgeschlossene Kontexte zu finden und in Software zu gießen (Achtung: Conway‘s Law). Die soziologische Systemtheorie nach Luhmann fokussiert auf Kommunikation und nimmt in ihrem Kern die Unmöglichkeit unabhängigen Beobachtens an. Zusammengenommen kann dies ein besseres Verständnis für die Anforderungsfindung und das Zusammenstellen und -arbeiten von Teams liefern.

Javamagazin Heft 2|21: Puh, endlich geschafft. Die Artikelserie geht dem Ende zu. Diese Menge Code zu einem anständigen Modulithen zu formen, war ganz schön anstrengend. Zum Glück ist er jetzt fertig, alle Arbeit ist getan! Wie? Weiterentwicklung? Wartung und Betrieb? Neue Anforderungen? Das Team skalieren? Technische Schulden? Aber das Ding ist doch ganz neu! Warum müssen wir da schon wieder ran? Tja, machste nix. Oder doch?

Javamagazin Heft 1|21: So manche Codebase macht nur auf den ersten Blick einen aufgeräumten Eindruck. Schön in Packages sortierter Code ohne Abhängigkeitsmanagement ist wie ein „auf-geräumtes“ Kinderzimmer, bei dem einem die Lawine entgegenkommt, wenn man es wagt, die Schranktür aufzumachen. Um zu verhindern, dass Abhängigkeitszyklen und wuchernde Queraufrufe den Code zu einem „Big Ball of Mud“ machen, gilt es, höllisch aufzupassen.

Javamagazin Heft 12|20: „Wir haben diesen Legacy-Monolithen, den wollen wir in Microservices aufbrechen“. So einen Satz hört man als Berater in der Softwarebranche oft. Auf die Frage „Warum“ erhält man oft die Antwort „Modularisierung“. Denn es herrscht die weitverbreitete Ansicht, dass Monolithen grundsätzlich aus schlecht strukturiertem Legacy-Code bestehen und sich Monolithen und Modularisierung gegenseitig ausschließen. Dass dem nicht so ist, zeigt die Architekturform der Modulithen.

Informatik Aktuell: In seiner Arbeit von 1968 formulierte Melvin Conway die nach ihm benannte (empirische) Gesetzmäßigkeit: “Jede Organisation, die im weitesten Sinne ein System entwirft, wird ein Design erzeugen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.” [1] Diese Gesetzmäßigkeit – als Conways Law bekannt – kann auf unterschiedliche Arten und Weisen interpretiert werden (EuroPLoP). Seit einiger Zeit ist auch der Begriff des inversen Conway-Manövers (Inverse Conway Maneuver) bekannt, das sich als Werkzeug versteht, eine Organisation so zu formen, dass das Ergebnis einem formulierten Architekturwunsch entspricht: “Idealerweise sind die technologische Struktur und die Geschäftsstruktur zueinander isomorph.” [2] Dieser von Conways Law konstatierte Isomorphismus, der eine strenge formale Gleichheit zwischen System(design) und der Kommunikationsstruktur im Unternehmen beschreibt, hat also zwei Richtungen. D.h. Änderungen in der Unternehmenskommunikation beeinflussen notwendig die Struktur des Softwareproduktes, und umgekehrt beeinflusst (und steuert) eine Software notwendig die Prozesse, die sie abbildet.

Java aktuell Heft 2|19: Kubernetes ist eines der bekanntesten und am stärksten wachsenden Frameworks zur Container- Orchestrierung. Einige der meistbeworbenen Features sind die einfache Automatisierbarkeit, Selbstheilung, Load Balancing, Skalierbarkeit und die Möglichkeit, Infrastruktur als Code zu beschreiben und zu versionieren. Viele Manager fordern daraufhin die Migration auf eine Kubernetes-Plattform, viele Entwickler stellen sich allerdings die Fragen: Brauchen wir das überhaupt? Wie kommt unsere App da jetzt rein? Wie stelle ich sicher, dass die nötigen Abhängigkeiten und Ressourcen für meine Applikation bereitstehen?

mehr info zum Magazin Java Aktuell: iJUG

Java aktuell Heft 3|18: „Microservices“ steht für ein Architektur-Muster, das den Fokus auf eine fachliche Modularisierung des gesamten Software-Stacks legt. Gestützt durch technischen Fortschritt und organisatorische Entwicklung, lassen sich besser nachvollziehbare Architekturen umsetzen, die viele Vorteile mit sich bringen.

Der Artikel zeigt, wie im Rahmen der Software-Entwicklung der Coupon-Verwaltung bei dm-drogerie markt eine monolithische Anwendung in eine Microservice-Architektur transformiert wurde, wobei zunächst gezielt mit einem strukturierten Monolithen angefangen wurde.

Javamagazin Heft 6|17: Viele Softwareunternehmen versuchen zurzeit, DevOps zu implementieren und ihre Prozesse und Abläufe entsprechend zu optimieren. Im Zuge dieses Hypes halten verschiedene neue und wiederentdeckte Techniken Einzug in den Arbeitsalltag. Eine davon ist ChatOps.