Architektur im Mittelstand bewerten und verstehen

Entwickeln Sie effizienter und reduzieren Sie komplexität mit meinem Architektur Review.

Jetzt anfragen

Lange Entwicklungszeit für kleine Änderungen?

Hoher Personalbedarf für einfache Anwendungen?

Lange Analysezeiten nach Kundenbeschwerden oder Ausfällen?

Hohe Infrastruktur- und Cloudkosten?

Vorteile des Architektur-Audits

Komplexitätsreduktion

Identifizieren und beseitigen Sie unnötige Komplexität in Ihrer Softwarearchitektur.

Kosteneffizienz

Reduziere Infrastruktur- und Betriebskosten durch optimierte Lösungen.

Wissensaustausch

Ermögliche deinem Team, sein Wissen über das Projekt untereinander auszutauschen.

Overengineering als Herausforderung im Mittelstand

Software in kleinen und mittleren Unternehmen ist oft komplexer und umfangreicher konstruiert, als für ihren Verwendungszweck erforderlich.

Beispiele für Overengineering:

Wozu brauchen Sie eine Microservice-Architektur, wenn Sie nur 10 Entwickler haben?
Warum setzen Sie auf Serverless, wo Sie nur eine simple CRUD Anwendung brauchen?
Wieso setzen Sie Kubernetes ein, wenn eine Uptime von 95% für Ihre Kunden akzeptabel wäre?

Der Mittelstand muss nicht die Kosten für hochverfügbaren Anwendungen zahlen. Dazu fehlt schlichtweg das Personal!

Großunternehmen erreichen eine Hochverfügbarkeit mit Hunderten von Entwicklern. Sie bauen komplexe Software und teilen diese Erfahrung auf Konferenzen und in Fachmagazinen. Es sind diese Berichte, die im Mittelstand den Eindruck erwecken, man müsse dieselben Prinzipien anwenden.

Die Folgen: vertane Chancen, unprofitable Geschäfte und Wachstumshemmnisse durch lange Entwicklungszeiten.

Mehr zu diesem Thema finden Sie in meinem Blog-Beitrag.

Die Lösung:
Unterstützung durch einen externen Experten

Als Head of Engineering bei einem Dienstleistungsunternehmen war ich einst selbst verantwortlich für Projekte im Mittelstand. Ich kenne die Herausforderungen.

Das größte Problem in vielen Teams: Overengineering. Ich versuchte, das Problem eigenständig zu lösen, indem ich erfahrene Entwickler rekrutierte, aber der Wettbewerb mit Großunternehmen erschwerte dies erheblich. Zudem investierte ich in die Fortbildung des Teams, was sich jedoch als langwierig und ineffektiv für akute Probleme herausstellte. Die Teams hatten Schwierigkeiten, ihre Fehlentscheidungen zu erkennen und zu korrigieren. Schließlich arbeitete ich selbst im Team mit, was sich als ineffizientes Micromanagement erwies und keine nachhaltigen Lösungen bot. All diese Strategien führten insgesamt nicht zum gewünschten Erfolg.

Die richtige Balance zwischen Over- und Underengineering zu finden erfordert jahrelange Erfahrung und selbst erlebte Verantwortung in einer Vielzahl an Projekten.

Sie brauchen jemanden, der die besonderen Herausforderungen des Mittelstandes kennt, versteht und erfolgreich gelöst hat.

"Everything should be made as simple as possible, but not simpler."

Albert Einstein

In 7 Schritten zu einer besseren Software-Architektur

Es kann keine sinnvolle Bewertung der Architektur stattfinden, ohne die Anforderungen aller Stakeholder zu verstehen. Darum ist es unerlässlich, in verschiedenen Formaten die relevanten Informationen zusammenzutragen.

Business Constraints

Die Architektur- und Technologieentscheidungen einer Software werden durch den Rahmen des Unternehmens und der Organisation geprägt. In dieser Sitzung wird dieser Kontext mit den relevanten Stakeholdern (z. B. CEO, Vertriebsleiter, PO usw.) analysiert. Die wichtigsten Anforderungen an die Qualität der Software werden anhand von ISO 25010 ermittelt. Auf der Grundlage dieser Erkenntnisse wird der Schwerpunkt der nachfolgenden Formate gelegt.

Technology Map

Das Tech Stack Canvas dient zur Ermittlung aller verwendeten Technologien. Diese Erkenntnisse sind wichtig für die Bewertung der Anforderungen an Leistung, Sicherheit und Skalierung

Architektur-Workshop

Um die Architektur einer Software zu verstehen, müssen die Abgrenzungen der Module, ihre Interaktionen und die Integrationen aus verschiedenen Perspektiven betrachtet werden.

Auf der Grundlage des arc42-Dokumentationsformats werden die statischen und dynamischen Elemente der Software gemeinsam mit dem Entwicklungsteam modelliert.

Interviews

Es werden Interviews mit allen wichtigen Mitarbeitern geführt, um den Reifegrad des Unternehmens zu beurteilen. Unter anderem mit: CEO, CTO, Head of Development, Lead Developer, Teamlead, Scrum Master, Product Owner, Lead Administrator, Support Lead und Quality Assurance Lead.

Code Review

Nachdem ein vollständiges Verständnis der Konzepte der Software und ihrer Architektur gewonnen wurde, wird die Software im Detail geprüft. Besonderes Augenmerk wird dabei auf die Umsetzung der zentralen Konzepte und Qualitätsmerkmale gelegt.

Unter anderem werden folgende Aspekte analysiert: Modulverteilung, Build-Tool, CI/CD-Pipeline, Datenbankschema, Abhängigkeiten, Codequalität, Dokumentation, API-Reife, Authentifizierung und Autorisierung, Profiling, Standardisierungsgrad, ...

Schriftlicher Bericht

Alle analysierten Aspekte werden in einem Abschlussbericht zusammengefasst und gewichtet. Für jeden Mangel werden eine Risikobewertung und eine Handlungsempfehlung abgegeben.

Der Bericht gliedert sich in organisatorische, personelle, infrastrukturelle, architektonische und implementierungsbezogene Aspekte.

Umsetzung

Der Bericht bietet eine optimale Grundlage für die Verbesserung deiner Software-Architektur. Auf Wunsch stehe ich Ihnen für die Umsetzung der vorgeschlagenen Handlungsempfehlungen gerne zur Verfügung. Die Maßnahmen können ergänzt werden durch Themen wie Versionierungs-strategie, Build Pipeline, Deployment Automatisierung und Testabdeckung, um sicherzustellen, dass die Architektur flexibel und an die Unternehmensbedürfnisse angepasst bleibt.