Endlich eine gute Architekturdokumentation

Endlich eine gute Architekturdokumentation

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.

Marcus Held

Anti-Pattern: Die perfekte Softwarearchitektur

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 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?

Marcus Held

Surprising Architecture

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ß.

Marcus Held

Too Big, Too Small, Just Right

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

---

Marcus Held

Wie wird man Microservices wieder los?

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.

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.

Marcus Held