Backendhance

Endlich eine gute Architekturdokumentation

Fri, 23 May 2025 07:58:54 +0200

Bei der Entwicklung komplexer Softwaresysteme durchlaufen Teams häufig einen Dokumentationszyklus, der fast schon einem vorhersehbaren Muster folgt. Die anfängliche Euphorie ist geprägt von ambitionierten Zielen: Eine umfassende Dokumentation soll entstehen, die alle Aspekte des Systems beleuchtet und jede Entscheidung nachvollziehbar macht. Mit frischem Elan werden Werkzeuge evaluiert, Vorlagen erstellt und erste Dokumentationen verfasst.

Doch mit fortschreitender Projektdauer schleicht sich die Vernachlässigung ein. Der Entwicklungsdruck steigt, Features haben Priorität und die Dokumentation wird zum “Nice-to-have”, das man “später” nachziehen will. Diese Phase markiert den kritischen Wendepunkt, an dem die Weichen für den langfristigen Erfolg oder Misserfolg der Dokumentationsstrategie gestellt werden. Dieser Artikel zeigt, wie sich ein sehr viel Zeit kostendender Misserfolg verhindern lässt.

Anti-Pattern: Die perfekte Softwarearchitektur

Wed, 21 Aug 2024 16:14:55 +0200

Als junger Entwickler war ich naiv und ambitioniert. Ich suchte die perfekte Softwarearchitektur, einen Ansatz, den ich über alle Probleme stülpen könnte, unabhängig von der Branche, den Skalierungsanforderungen, den Sicherheitsmaßnahmen oder den Usern. Man müsste nur dieses eine Problem abstrakt lösen, dann könnte diese Architektur doch überall angewandt werden. Oder?

Dieser Artikel erschien erstmals im August 2024 als Premiumartikel auf Golem.de .

Dieser Artikel erklärt, warum die Suche nach der perfekten Softwarearchitektur eine Illusion ist. Aktuelle Trends und Moden diktieren oft universelle Lösungen, die jedoch die notwendige Flexibilität vermissen lassen, um im Markt zu bestehen. Das ist besonders relevant für technische Leiter und Entscheider im Mittelstand. Aber wie kann man eine Architektur gestalten, die flexibel genug ist, um sich an wechselnde Anforderungen anzupassen?

Surprising Architecture

Thu, 20 Jun 2024 00:00:00 +0000

Hi,

“RCoffee [ein internes Tool zur Content Produktion] greift per SSH auf die Testserver zu und stellt die Tomcat Logs dar”

Wow. Das kam überraschend.

Seit einem Jahr arbeite ich mit diesem Kunden zusammen.

Die Applikation ist Marktführer in ihrer Sparte und die aktuelle Version wurde vor über 10 Jahren entwickelt.

Da hat sich natürlich einiges angesammelt. Und wenn ich beauftragt werde, dann ist die technische Schuld meist sehr groß.

Too Big, Too Small, Just Right

Tue, 11 Jun 2024 00:00:00 +0000

Hi,

Ein alter Entwicklerwitz:

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. – Leon Bambrick

Oder als Variante:

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery – Mathias Verraes

Und es gibt etliche weitere:

There are so many variations on the “there are only two hard problems in computer programming…” joke that I’m starting to suspect that programming isn’t actually very easy. – Nat Pryce

Wie wird man Microservices wieder los?

Thu, 23 May 2024 11:05:12 +0200

In den vergangenen Jahren haben etliche Unternehmen aus dem Mittelstand die viel gepriesenen Microservices ausprobiert und mussten feststellen, dass diese weniger leichtgewichtig sind als der Name vermuten lässt – Microservices im Mittelstand sind oft Overengineering . Jetzt müssen sie zurückgebaut und in eine pragmatischere Architektur überführt werden. Wir erklären, wie das gelingt.

Dieser Artikel erschien erstmals im April 2024 als Premiumartikel auf Golem.de .

Keine Angst: Der Rück- und Umbau der Architektur ist nicht nur aufwendig, sondern auch eine Chance. Denn in der Softwareentwicklung gibt es keine One-Size-Fits-All-Lösung; die passende Architektur für die eigene Software wird auf Basis der Anforderungen an die Software ausgewählt. Dafür werden die Anforderungen aller Stakeholder zusammengetragen. In vielen Projekten wird das nicht ausreichend gemacht. Bei einem Umbau der Architektur kann es nachgeholt und überprüft werden.

Mittelstand, Finger weg von Microservices!

Mon, 15 Apr 2024 08:43:56 +0200

Seit mehr als zehn Jahren vergeht kaum eine Konferenz ohne das Thema Microservices. Fachmagazine publizieren eine hohe Anzahl von Artikeln zum Thema und externe Beratungsunternehmen verkaufen Workshops, beraten aktiv zum Wechsel zu einer Microservice-Architektur und preisen die Vorteile an. Für viele kleine und mittlere Unternehmen klingt das attraktiv – was bei den Großen so viel nützt, kann doch den kleineren nicht schaden? Ein folgenschwerer Trugschluss.

Dieser Artikel erschien erstmals im März 2024 als Premiumartikel auf Golem.de .

Denn Overengineering – also der Einsatz unnötig komplexer Software – kostet KMUs nicht nur viel Geld und Zeit, es nimmt ihnen auch ihren wichtigsten Wettbewerbsvorteil gegenüber den Konzernen.

Was Accidental Complexity in der Entwicklung kostet

Fri, 22 Mar 2024 14:00:00 +0100

Anfangs setzen IT-Teams schnell neue Features um, dann wird die Entwicklungszeit meist länger. Accidental Complexity ist häufig die Ursache – wir erklären, wie sie entsteht und was sich dagegen tun lässt.

Dieser Artikel erschien erstmals im Juni 2023 als Premiumartikel auf Golem.de .

Es ist kein Geheimnis, dass Systeme über die Zeit komplexer und damit die Entwicklungszeiten länger werden. Das ist nicht zu vermeiden, wenn das Problem inhärent komplex ist, man spricht dann von Essential Complexity. In anderen Fällen wird die Umsetzung eines Features komplexer, als es sein müsste. Zwei Monate für ein eigentlich einfaches Feature? Ein klarer Fall von Accidental Complexity. Sie ist ärgerlich, kostet viel – und ist vermeidbar, wie wir an einigen praktischen Beispielen zeigen.

My War on Kubernetes

Tue, 05 Mar 2024 00:00:00 +0000

Hi,

Ich muss direkt ein Geständnis machen: Ich bin auf Kriegsfuß mit Kubernetes.

Dabei trifft Kubernetes gar keine Schuld. Meine Projekte sind es. Beziehungsweise die Teams, in denen ich mich bewege.

Es sind Teams mit maximal 30 Software-Entwicklern, noch ein paar Business-Menschen und Designer oben drauf. Aber es sind nicht soooo viele Entwickler.

Diese Teams brauchen kein Kubernetes!

Nein. Noch deutlicher: Diese Teams können kein Kubernetes halten!

“Aber Marcus. Das ist doch kein Problem. Ich habe das doch schon bei XY gemacht, und es war so einfach, wenn man sich an YX hält und das ZY-Prinzip einhält.”

Another Microservice Desaster

Thu, 07 Dec 2023 00:00:00 +0000

Hi,

Microservice Architektur

Dieses Buzzword, ist für mich inzwischen ein Trigger geworden. Darüber habe ich schon oft geschrieben.

Anfang des Jahres trendete mein Artikel Microservices are a Big Ball of Mud auf Hacker News

In den 343 Kommentaren zu meinem Artikel kann man gut sehen, wie sehr das Thema die Gemüter erhitzt 😉 Natürlich ist der rationale Blick darauf ein anderer, als ich in dem Artikel dargestellt habe. Es kommt IMMER auf den Kontext an. AppContinuum ist ein hervorragendes Paper zu einem reflektierten Blick auf die Thematik.

The Microwave With Feature Creep

Thu, 31 Aug 2023 00:00:00 +0000

Hi,

Meine Mikrowelle war kaputt.

Also: Eine neue muss her.

Ich habe hier aber einen kleinen Tick. Das betrifft alles unvergängliche das ich kaufe. Ich will einen Fehlkauf vermeiden. Lieber einmal mehr Geld ausgeben, als in zwei Jahren wieder neu kaufen.

Hier muss ich aufpassen nicht in einer Rabbit-Hole zu landen. Ich kann Stunden in das Lesen von Reviews versenken.

Aber was will ich überhaupt vergleichen?

Als erstes Kommt die Anforderungsanalyse

Bevor ich überhaupt zwischen Modellen vergleichen kann, muss ich mir klar werden was ich eigentlich brauche.

State Is the Root of All Evil

Thu, 17 Aug 2023 00:00:00 +0000

Hi,

Was unterscheidet eine Anwendung von einer (mathematischen) Funktion?

Eine Funktion nimmt einen Input x und transformiert ihn zu einem Output. Wenn gilt f(x) = 2 * x, dann ist das Ergebnis dieser Funktion bei der Eingabe von jedem x immer gleich.

Es gibt keine Seiteneffekte. Wir nennen dieses Verhalten stateless.

Aber was hat das mit der Frage vom Anfang zutun? Eine Anwendung geht darüber hinaus. (Fast) jede Anwendung muss mit State arbeiten. Sobald wir I/O Operations in unserem System haben, haben wir inhärent State. Und häufig kann ein methodenaufruf, mit dem gleichen Input, zu unterschiedlichen Zeiten, unterschiedliche Resultate liefern. Und das ist auch nicht vermeidbar und liegt in der Natur der Aufgabe, die wir lösen wollen.

Sliced Onion Architecture

Thu, 03 Aug 2023 00:00:00 +0000

Hi,

Vor einer Woche hat Oliver Drotbohm eine erweiterte Idee der Onion Architecture publiziert: The Sliced Onion Architecture .

Hexagonal Architecture und deren Erweiterung die Onion Architecture sind den meisten Softwareentwicklern bekannt. Die Idee (vereinfacht): Man decoupled seinen Businesscode mithilfe von Adaptern von Infrastrukturcode.

Damit ist es weniger wahrscheinlich den “Big Ball of Mud” zu erschaffen.

Was sehe ich in der Praxis?

Die meisten Entwickler haben verstanden, dass es eine gute Idee den Businesscode nicht mit Infrastrukturcode zu vermischen.

Double-Entry Bookkeeping

Thu, 13 Jul 2023 00:00:00 +0000

Hi,

Ein Fehler in der Buchhaltung kann teuer sein. Gerade in großen Unternehmen, in denen es sehr viele Transaktionen gibt, ist es leicht eine zu übersehen.

Und wenn das passiert, dann merke ich es noch nicht einmal. Vielleicht steht das Unternehmen viel besser da, als es die Bücher hergeben? Oder vielleicht ist es eigentlich unprofitabel?

Die Kaufleute haben im 13 Jahrhundert das Problem erkannt. Es musste ein System gefunden werden, dass Fehler unwahrscheinlicher macht. Es wurde die doppelte Buchhaltung erfunden.

Microservices are a Big Ball of Mud

Thu, 28 Jul 2022 00:00:00 +0000

Over the past years I attended hundreds of interviews. Many candidates proudly told tales on how they develop their projects with a microservice architecture. Often (I don’t want to say “always”, but from my memory I think it actually is “always”) it does not require many questions to see that they used a rocket launcher to kill a mouse. Microservices are hard. Everyone who experienced the pain of operating such an architecture can relate to it. The complexity kills you at one point or the other. You already had to do multiple refactorings of your architecture - because your domains didn’t work out. I wonder - why is this architecture so appealing to developers? And then I remember why I found them appealing 10 years ago.