Loading...
Backendhance
de en
Hot Topic

Endlich eine gute Architekturdokumentation

Architecture
23. Mai 2025
Zum Post

Letzte Beiträge

Architecture 23. Mai 2025

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.

Avatar Marcus Held
Architecture 21. August 2024

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?

Avatar Marcus Held
Architecture 23. Mai 2024

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.

Avatar Marcus Held
Architecture 15. April 2024

Mittelstand, Finger weg von Microservices!

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.

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.

Avatar Marcus Held
Architecture 22. März 2024

Was Accidental Complexity in der Entwicklung kostet

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.

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.

Avatar Marcus Held
Top