Software-Architektur

Architektur ist nicht das Diagramm. Architektur ist die Summe der Entscheidungen.

Und wir treffen diese Entscheidungen bewusst, dokumentieren sie und stehen dazu – auch wenn sie unbequem sind.

Unsere Architektur-Leads sind keine Theoretiker. Sie schreiben Blueprint Code, definieren Coding Standards und arbeiten im gleichen Repository wie alle anderen. Architektur ist bei uns kein Elfenbeinturm, sondern ein handwerkliches Fundament.

Dokumentation, die nützt

Wir arbeiten mit Arc42 als Dokumentationsrahmen und schreiben Architecture Decision Records (ADRs) – kurze, klare Protokolle darüber, warum eine Entscheidung so und nicht anders gefallen ist. Nicht für die Schublade, sondern für das Team in zwei Jahren.

Architektur, die sich selbst prüft

Wir definieren Architekturregeln und schreiben ArchUnit-Tests, die diese Regeln automatisch durchsetzen. Wenn jemand versehentlich eine Schicht verletzt, schlägt der Build an – nicht erst das Code Review drei Wochen später.

Blueprint Code & Komponentenbibliotheken

Neue Projekte starten nicht auf der grünen Wiese. Wir liefern Blueprint Code, der zeigt wie Dinge gemacht werden sollen – Fehlerbehandlung, Logging, API-Struktur, Testmuster. Dazu entwickeln wir projektübergreifend einsetzbare Widget Libraries und gemeinsame Komponenten, die sich wirklich wiederverwenden lassen.

Qualitätsstandards mit Konsequenz

• SonarQube mit strikten Regeln – kein «Quality Gate», das man einfach wegklickt
• Renovate Bot – Dependencies bleiben automatisch aktuell, Sicherheitslücken werden nicht verschlafen
• Harbor als private Container Registry – wir wissen, was in unseren Images steckt
• OpenTelemetry statt proprietärer Monitoring-Lösungen – weil Observability keine Vendor-Abhängigkeit sein sollte

Security by Design

Sicherheit ist kein Nachgedanke. Wir definieren Bedrohungsmodelle, legen Sicherheitsanforderungen fest und bauen sie von Anfang an ein – in Architektur, Code und Pipeline gleichermassen.

Unsere Haltung

Wir folgen keiner Hype-Kurve. Microservices, weil alle Microservices machen? Nicht bei uns. Wir wählen die Architektur, die zum Problem passt – und erklären auch warum. Ein gut begründeter Monolith schlägt einen schlecht begründeten Microservice-Zoo jederzeit.