Softwareentwicklung / Individualsoftware

Wie stellt ihr sicher, dass Geschäftslogik nicht in UI-Schichten oder der Datenbank landet, also architektonisch sauber gekapselt bleibt?

Wir setzen konsequent auf Domain-Driven Design mit hexagonaler Architektur. Die Domänenschicht ist strikt von Infrastruktur und UI getrennt, Datenbanken sind austauschbare Adapter, keine Abhängigkeiten. Im Waldenburger-Versicherungsprojekt haben wir genau das umgesetzt: drei dedizierte Services (Calculation, Quotation, Contracting), vollständig durch automatisierte Unit-Tests abgesichert. Geschäftsregeln leben ausschließlich im Domänenmodell, nicht im ORM, nicht im Controller.

Wie geht ihr mit Architektur-Governance während des Projekts um, wer dokumentiert ADRs, und wie verhindern wir, dass proprietäre Entscheidungen ohne unsere Zustimmung getroffen werden?

Wir arbeiten technologie-agnostisch: Best-of-Breed statt Stack-Präferenz. Architekturentscheidungen treffen wir gemeinsam, nicht stellvertretend für euch. Infrastructure-as-Code im CI-Prozess macht jede Infrastrukturänderung nachvollziehbar und versionierbar. APIs definieren klare Verträge zwischen Frontend und Backend, dokumentiert und standardisiert authentifiziert. Governance-Artefakte wie ADRs erwarten wir als selbstverständlichen Teil des Projektprozesses, nicht als nachträglichen Audit.

Wir betreiben einen Mix aus Legacy-Systemen ohne APIs und modernen Cloud-Services. Wie integriert ihr neue Business-Anwendungen in diese heterogene Landschaft, ohne neue Abhängigkeiten aufzubauen?

Unser API-Layer, idealerweise GraphQL, orchestriert Backend-Systeme unabhängig von deren Technologie-Generation. Legacy-Systeme werden über Adapter-Schichten angebunden, nicht direkt verdrahtet. Wir unterstützen Hyperscaler, On-Premise und hybride Setups gleichwertig. Neue Services laufen containerisiert auf Kubernetes, isoliert, skalierbar, ohne Seiteneffekte auf Bestandssysteme. Der Strangler-Pattern-Ansatz für schrittweise Migration gehört zu unserem operativen Repertoire.

Wie stellt ihr sicher, dass neue Business Applications nicht als isolierte Insellösungen entstehen, sondern sich in unsere bestehende ERP/CRM-Landschaft einfügen?

Wir starten mit der Domänenmodellierung, bevor wir Technologie benennen. Über Domain-Driven Design und hexagonale Architektur trennen wir Fachlichkeit von technischen Details, das macht Drittsysteme wie ERP oder CRM über standardisierte APIs austauschbar, ohne die Geschäftslogik anzufassen. Beim Waldenburger-Projekt haben wir genau so drei Kerndienste entwickelt, die nahtlos in eine bestehende Webservices-Architektur integriert wurden, und dabei für andere businesskritische Anwendungen wiederverwendbar geblieben sind.

Wir haben intern Bedenken, dass wir nach Projektabschluss das Know-how und die Kontrolle über unsere Systeme verlieren. Wie adressiert ihr das konkret?

Drei strukturelle Hebel: Erstens setzen wir Infrastructure-as-Code ein, Infrastrukturänderungen laufen durch euren CI-Prozess, sind versioniert und nachvollziehbar. Zweitens schützt Event Sourcing euren Audit-Trail: Alle Systemaktionen werden als Events gespeichert, jede Änderung ist vollständig rekonstruierbar. Drittens definieren unsere APIs klare Verträge zwischen Frontend und Backend, standardisierte Authentifizierungs- und Autorisierungsmechanismen inklusive. Kein Black-Box-Betrieb, volle Revisionsfähigkeit.

Unsere IT-Governance erfordert klare Deployment-Prozesse und Qualitätssicherung. Was ist euer Standard, und wie verhindert ihr, dass Releases zum Risiko werden?

Automatisierte Tests sind in unsere CI/CD-Workflows eingebunden, kein Deployment ohne definierten Qualitätsdurchlauf. Infrastrukturänderungen deployen wir per IaC direkt durch den CI-Prozess: reproduzierbar, auditierbar, ohne manuelle Eingriffe. Container-basierte Virtualisierung stellt sicher, dass Produktiv- und Entwicklungsumgebung identisch sind. CQRS trennt Schreib- und Lesepfade für Performance-Stabilität unter Last. Das reduziert Release-Risiken strukturell, nicht durch Prozessversprechen.

Wie stellen Sie sicher, dass wir bei Vertragsende nicht in einem proprietären Systemkonstrukt feststecken?

Vendor Lock-in reduzieren wir strukturell: Unsere Architekturen basieren auf offenen Standards, GraphQL-APIs, containerisierte Deployments via Kubernetes, Infrastructure as Code. Geschäftslogik wird per Domain-Driven Design sauber von der Technik getrennt, sodass Datenbanken und Drittsysteme austauschbar bleiben. Code-Eigentum und Nutzungsrechte regeln wir vertraglich explizit, inklusive Trennung von Pre-existing IP. Beim Projektabschluss übergeben wir vollständige Dokumentation, IaC-Konfigurationen und Repository-Zugriffe.

Welchen Nachweis haben Sie für Revisionsfähigkeit und lückenlosen Audit-Trail in produktionskritischen Systemen?

Wir setzen Event Sourcing ein: Jede Zustandsänderung im System wird als unveränderliches Ereignis gespeichert, keine Snapshot-Überschreibung, vollständige Nachvollziehbarkeit aller Aktionen zu jedem Zeitpunkt. Das haben wir produktiv umgesetzt, u. a. für die Waldenburger Versicherung, wo businesskritische Prozesse wie Prämienberechnung und Vertragsanträge über dieses Verfahren laufen. CQRS trennt dabei Schreib- und Lesemodelle für Performance ohne Abstriche bei der Datenintegrität.

Haben Sie Referenzprojekte in regulierten Branchen, bei denen Security- und Compliance-Anforderungen von Architekturanfang an integriert waren?

Ja. Für die Waldenburger Versicherung haben wir eine Event-Driven-Architektur mit CQRS und Event Sourcing implementiert, Dunkelverarbeitung, automatisierte Unit-Tests zur durchgehenden Funktionssicherung und eine Webservices-Integration, die Compliance-Anforderungen strukturell abbildet. Sicherheit und Compliance wurden nicht nachgelagert aufgesetzt, sondern sind Bestandteil des Architekturentwurfs. Wir können dieses Projekt als Referenz für Ihre Due-Diligence-Prüfung benennen.

Wie stellt ihr sicher, dass kritisches technisches Know-how nicht ausschließlich bei euch als Agentur bleibt, wir wollen keine Abhängigkeit aufbauen, die uns bindet?

Wir setzen auf Domain-Driven Design mit hexagonaler Architektur: Fachlichkeit und Technik sind sauber getrennt. Euer Team versteht die Domänenlogik, weil sie explizit modelliert ist, nicht in proprietären Konstrukten versteckt. Event Sourcing legt jeden Systemzustand nachvollziehbar offen, vollständiger Audit-Trail inklusive. Wir streben langfristige Partnerschaften an, bauen aber Systeme, die auch ohne uns handlungsfähig bleiben.

Habt ihr Referenzen, wo ihr komplexe Systemintegrationen mit messbaren Ergebnissen umgesetzt habt, nicht nur technisch, sondern mit Auswirkung auf Prozesse?

Bei Waldenburger Versicherung haben wir drei eng verzahnte Services, Prämienberechnung, Angebotserstellung, Dunkelverarbeitung, in eine bestehende Webservices-Architektur integriert. Alle Services sind wiederverwendbar: Der Tarifrechner läuft sowohl im Frontend als auch in automatisierten Backend-Prozessen. Automatisierte Unit Tests sichern Funktionalität kontinuierlich ab. Das Ergebnis: schnellere Reaktionsfähigkeit bei Tarifänderungen, keine manuellen Prozessbrüche zwischen den Diensten.

Wir brauchen Echtzeit-Dashboards für Leadership-Reporting. Kann eure Architektur das leisten, ohne dass wir dafür separate Daten-Exports bauen müssen?

Ja, wir trennen Schreib- und Lesemodelle über CQRS. Leseprojektionen liefern Dashboard-Daten in Echtzeit, ohne die Transaktionslast auf das Schreibmodell zu legen. Für Live-Updates im Browser nutzen wir Golang-basierte Kommunikations-Services über Websockets. Statistiken und KPIs aktualisieren sich automatisch, kein Export, kein Refresh-Zyklus, keine Verzögerung.