Wenn du nicht selbst entwickelst, dir aber effizient einen Überblick verschaffen musst, was für den Bau eines modernen IT-Systems zusammenspielen muss, bist du hier richtig.
Die Entwicklung komplexer Software ist heute weit mehr als nur das Schreiben von Code. Es ist ein Zusammenspiel aus abstrakter Architektur, präzisen Prozessen, menschlicher Psychologie (UX) und harter Infrastruktur.
Dieser Guide gibt dir das Werkzeug an die Hand, um zu verstehen, womit Entwickler beschäftigt sind und wo Lücken für eine erfolgreiche Umsetzung geschlossen werden müssen.
Wir konzentrieren uns rein auf die Solution Architecture: Use Cases, System-Architektur, Datenmodelle, Prozesse, User Experience und Operations.
Inhaltsverzeichnis
- Use Cases und User Stories: Das Fundament jeder Entwicklung
- System-Architektur: Von Monolithen zu Microservices
- Der Technologie-Stack: Auswahl und Risikomanagement
- Datenmodellierung: Struktur in der Informationsflut
- Prozesse und Digitalisierungsgrad
- User Experience (UX) & User Interface (UI)
- Operations & DevOps: Der moderne Betrieb
- Qualitätssicherung (QA) und Testing
- Fazit: Der Faktor Mensch im Systembau
1. Use Cases und User Stories: Das Fundament jeder Entwicklung
Jedes erfolgreiche System beginnt nicht mit Code, sondern mit dem Verständnis dessen, was es tun soll.
Bevor Technologie ausgewählt wird, müssen die Use Cases (Anwendungsfälle) designt werden.
Was sind Use Cases?
Use Cases bilden ab, was verschiedene Benutzer in ihren spezifischen Rollen mit dem System tun können müssen und was das System ihnen zeigen soll. Sie sind die abstrakte Beschreibung der Funktionalität.
Ein modernes System besteht typischerweise aus drei logischen Zugriffsebenen, die in den Use Cases berücksichtigt werden müssen:
- Kunden-Applikation: Der Bereich, in dem der Endnutzer arbeitet.
- Admin-Applikation: Ein Bereich für den Support oder das interne Management, um Daten zu pflegen, ohne direkt in die Datenbank eingreifen zu müssen.
- Authentifizierung: Der Prozess, der den Zugang regelt (oft ausgelagert an IAM-Systeme).
Von der Abstraktion zur User Story
Die Modellierung der Use Cases ist deshalb so relevant, weil aus ihnen direkt die in der agilen Softwareentwicklung (z.B. Scrum) erwarteten User Stories abgeleitet werden.
Definition User Story: Eine detaillierte Beschreibung einer Software-Funktion aus der Perspektive des Endnutzers. Sie dient als Bauplan für Entwickler und definiert Akzeptanzkriterien.
Beispiele aus der Praxis
Szenario 1: Schadenfall
- Use Case: Schadenfall Spezialist -> Liste von Schadenfällen sichten.
- User Story: „Als Schadenfall Spezialist will ich die Liste der mir zugeteilten Schadenfälle angezeigt erhalten…“ (Gefolgt von Details zu Filtern, Sortierung, angezeigten Daten).
Szenario 2: Kunde
- Use Case: Kunde -> Schadenfall erfassen.
- User Story: „Als Kunde will ich ein Formular angezeigt erhalten, wo ich die Details zu meinem Schadenfall erfassen kann…“ (Gefolgt von Feldbeschreibungen, Validierungsregeln).
Warum ist dieser Detaillierungsgrad nötig?
Für komplexe SaaS-Systeme können leicht zwischen 60 und 120 User Stories entstehen.
Diese Menge ist notwendig, um:
- Akzeptanzkriterien zu definieren: Was muss das Feature können, damit der Product Owner (PO) es abnimmt?
- Kosten zu schätzen: Entwicklungsdienstleister können nur auf Basis detaillierter Stories verbindliche Aufwandschätzungen abgeben.
- Testszenarien abzuleiten: Jede Anforderung in einer Story ist ein potenzieller Testfall.
Oft sind Product Owner (PO) sehr business-fokussiert und können die technische Tiefe nicht liefern. Hier kommen Business Analysten oder erfahrene Solution Architects ins Spiel, um die Brücke zur Technik zu schlagen.
2. System-Architektur: Von Monolithen zu Microservices
Die System-Architektur definiert, wie die Anforderungen technisch abgebildet werden.
Heute sind die meisten Systeme Web-Applikationen, bestehend aus Frontend und Backend, die über REST oder GraphQL kommunizieren.
Der Wandel: Monolith vs. Microservices
- Monolith: Früher wurde „alles in eine Box“ gepackt. Ein System, eine Codebasis. Einfach zu deployen, aber schwer zu skalieren und zu warten, wenn es wächst.
- Microservices: Der moderne Standard. Die Applikation wird in kleine, logisch und fachlich gekapselte Services aufgetrennt.
Vorteile von Microservices:
- Skalierbarkeit: Ein Service, der viel Rechenleistung braucht (z.B. Bildverarbeitung), kann unabhängig vom Rest skaliert werden.
- Sicherheit: Jeder Service kann eigene Sicherheitsrichtlinien haben („Security by Design“).
- Autonomie: Teams können an verschiedenen Services parallel arbeiten, ohne sich gegenseitig zu blockieren (sofern die Schnittstellen definiert sind).
Herausforderungen verteilter Systeme
Mit Microservices entstehen verteilte Systeme.
Das bringt neue Komplexität:
- Kommunikation: Services müssen über Netzwerke hinweg reden. Latenz und Ausfälle sind unvermeidbar.
- Asynchronität: Moderne Systeme warten nicht. Statt synchroner Aufrufe (Service A ruft B und wartet) nutzen wir Message Queues (wie RabbitMQ oder Kafka). Service A legt eine Nachricht in den „Briefkasten“ (Queue), Service B holt sie ab, wenn er bereit ist.
- Non-Functional Requirements (NFRs): Themen wie Logging, Error Handling, Monitoring und Backup/Recovery müssen architektonisch von Tag 1 an geplant werden.
Der „Durchstich“ im Projekt
Der Bau der Architektur-Komponenten (Grundgerüst, Datenbankanbindung, Authentifizierung) ist anfangs für Stakeholder unsichtbar.
Es ist wie beim Tunnelbau: Man gräbt, sieht aber kein Licht.
Für Architekten ist es entscheidend, schnell einen technischen Durchstich zu erreichen, also den Moment, in dem Daten vom Frontend durch alle Services in die Datenbank und zurück fliessen.
Das schafft Vertrauen.
3. Der Technologie-Stack: Auswahl und Risikomanagement
Der „Tech Stack“ umfasst alle Programmiersprachen, Frameworks und Tools, die eingesetzt werden.
Da kein Entwickler mehr alles beherrschen kann (Full-Stack ist ein Mythos bei komplexen Systemen), ist die Auswahl kritisch.
Die Evolutions-Falle
Technologie entwickelt sich rasend schnell.
Ein System, dessen Entwicklung 1-2 Jahre dauert, riskiert, beim Launch bereits veraltet zu sein.
- Strategie: Mut zu stabilen Beta-Versionen oder sehr neuen, aber vielversprechenden Technologien, um Nachhaltigkeit zu sichern. Wer auf „alte, sichere“ Versionen setzt, wird oft im Entwicklungsprozess von der Realität (End-of-Life Support) überrollt.
Kommerziell vs. Open Source
- Kommerzielle Software: Bietet Garantien und Support-Verträge. Risiko: Vendor-Lock-in, Strategiewechsel des Herstellers oder Übernahmen.
- Open Source: Maximale Flexibilität, keine Lizenzkosten. Risiko: Man ist selbst für die Qualitätssicherung verantwortlich. Die Community muss aktiv sein.
Der Faktor „Human Resources“
Ein oft unterschätzter Aspekt bei der Technologiewahl ist die Verfügbarkeit von Entwicklern.
Beispiel: Go (Golang) ist technisch exzellent für Backends. Doch finden Sie genug erfahrene Go-Entwickler?
In der Schweiz zeigte sich in Projekten des Bundesamtes für Informatik, dass die Personalsuche hier schwieriger war als erwartet. Entwickler wollen mit modernen Technologien arbeiten, um ihren Marktwert zu erhalten.
Veraltete Tech-Stacks schrecken Talente ab.
4. Datenmodellierung: Struktur in der Informationsflut
Die Aufschlüsselung der Use Cases und die Microservice-Architektur diktieren das Datenmodell.
Datenbank-Strategien
- Schema pro Service: Ein bewährter Ansatz bei Microservices ist, dass jeder Service seine eigenen Daten verwaltet. Es gibt keine riesige, zentrale Datenbank, auf die alle zugreifen („Shared Database“ Anti-Pattern).
- PostgreSQL: Hat sich als extrem zuverlässiger Standard etabliert. Es kann sowohl strikte relationale Daten als auch JSON-Konstrukte (NoSQL-artig) verarbeiten.
- Elastic Search: Wird oft parallel für das Logging oder komplexe Suchanfragen genutzt, um schnelle Lesezugriffe auf riesige Datenmengen zu ermöglichen.
Mandantenfähigkeit (Multi-Tenancy)
Bei SaaS-Applikationen (Software as a Service) ist die Trennung der Daten verschiedener Kunden (Mandanten) essenziell.
- Ansatz: In PostgreSQL kann der Zugriff über Schemas gesteuert werden (Row Level Security), sodass Mandant A technisch niemals die Daten von Mandant B sehen kann.
Typisierung
Moderne Entwicklung geht hin zu starker Typisierung (TypeScript im Frontend, Java/Go mit Typen im Backend). Auch die Datenbank sollte dies widerspiegeln. Blobs (Binary Large Objects) für alles zu verwenden, bläht die Datenbank auf und verhindert Validierung.
5. Prozesse und Digitalisierungsgrad
Ein System bildet Unternehmensprozesse ab.
Die These lautet: Die im System verankerten Prozesse zeigen den wahren Digitalisierungsgrad eines Unternehmens.
Automatisierung vs. Menschliche Interaktion
Ein hoher Digitalisierungsgrad bedeutet, dass das System Aufgaben koordiniert und an Spezialisten verteilt.
Aber Vorsicht: Zu viel Digitalisierung kann schaden.
Speziell im Kundenkontakt (CRM) haben viele Unternehmen über-automatisiert. Kosteneinsparungen durch Chatbots oder Self-Service-Portale führten oft zu Kundenfrust, Stornierungen und Verlust von Kundenbindung.
Die Architektur muss entscheiden:
- Business Process Engine: Einsatz spezialisierter Software (wie Camunda) für komplexe Prozessflüsse.
- Status-basierte Logik: Abbildung von Prozessen durch Status-Übergänge an Datensätzen (einfacher, oft ausreichend).
6. User Experience (UX) & User Interface (UI)
UX definiert, wie Benutzer mit dem System interagieren.
Es ist die Brücke zwischen der abstrakten Logik und dem Menschen.
Die Vielfalt der Geräte
Wir nutzen heute nicht mehr nur Desktop-PCs.
Smartphones, Tablets, Smart Watches, Brillen oder IoT-Geräte (Kühlschränke) interagieren mit Systemen.
UX muss alle diese Touchpoints orchestrieren.
Standards nutzen im UI
Im UI-Design haben sich Standards etabliert (Hamburger-Menü, Position von Buttons, Swipe-Gesten).
- Regel: Versuche nicht, das Rad neu zu erfinden. Benutzer erwarten gewohnte Muster. Ein kreatives Abweichen von Standards führt oft zu Verwirrung.
- Accessibility: Barrierefreiheit muss von Anfang an mitgedacht werden, um Menschen mit Einschränkungen nicht auszuschliessen (und rechtliche Vorgaben zu erfüllen).
Design als Kommunikationsmittel
Designs sollten parallel zu den Use Cases entwickelt werden.
Warum?
Weil Stakeholder und Investoren oft visuell denken.
Abstrakte Architekturdiagramme überzeugen niemanden.
Ein klickbarer Prototyp oder ein High-Fidelity Design macht das Zielbild greifbar. Es erlaubt dem PO, Feedback zu geben, bevor teurer Code geschrieben wurde.
7. Operations & DevOps: Der moderne Betrieb
Die Operations-Seite ist oft unsichtbar, aber kritisch. Hier geht es um das Deployment (Verteilung) und den Betrieb der Software.
Cloud & Sicherheit
Früher liefen Server im Keller (On-Premise) hinter einer Firewall. Heute ist praktisch alles in der Cloud. VPN-Tunnel sind in modernen Cloud-Architekturen oft nicht mehr durchsetzbar.
- Zero Trust: Jedes System, jeder Microservice und jede Datenbank muss sich selbst schützen, als ob es direkt im offenen Internet stünde.
- Geopolitik: Die Wahl des Cloud-Anbieters ist politisch geworden. Mit Blick auf den „Cloud Act“ und politische Veränderungen in den USA (Stichwort: Trump Administration), ist Datensouveränität in Europa (und der Schweiz) wichtiger denn je. Es ist ratsam, europäische Alternativen zu Big Tech zu prüfen, wenn es um sensitive Daten geht.
CI/CD und Automatisierung
Bei einem System aus dutzenden Microservices kann niemand mehr manuell Updates einspielen.
- CI/CD (Continuous Integration / Continuous Delivery): Automatisierte Pipelines, die Code testen, bauen und auf die Server schieben.
- Infrastructure as Code (IaC): Server werden nicht manuell konfiguriert, sondern per Skript (z.B. Terraform) hochgefahren. Das ermöglicht reproduzierbare Umgebungen (Test, Integration, Produktion).
Monitoring
Der Betrieb muss wissen, wenn etwas schiefgeht, bevor der Kunde anruft.
Strukturiertes Logging und Monitoring (z.B. Prometheus, Grafana) sind Pflicht, um in verteilten Systemen Fehler zu finden.
8. Qualitätssicherung (QA) und Testing
Sobald ein System auf die Produktionsumgebung übernommen wird, damit „Live“ geht und echte Daten enthält, beginnt der Lifecycle.
Fehler können nun Datenverlust bedeuten.
Die Test-Pyramide
- Unit Tests: Entwickler schreiben Tests für ihre kleinsten Code-Einheiten. Diese laufen bei jedem Build in der CI/CD-Pipeline.
- Integration Tests: Prüfen das Zusammenspiel mehrerer Komponenten.
- End-to-End (E2E) Tests: Simulieren einen echten Benutzer, der durch die Applikation klickt. Dies sollte idealerweise von einem unabhängigen QA-Team durchgeführt werden, um Betriebsblindheit zu vermeiden.
Penetration Testing
Vor dem Go-Live (und regelmässig danach) sind Penetration Tests durch externe Sicherheitsfirmen obligatorisch. Sie versuchen, das System zu hacken, um Lücken zu finden.
9. Fazit: Der Faktor Mensch im Systembau
Der Bau eines IT-Systems wird oft mit dem Hausbau verglichen, ist aber abstrakter. Es erfordert Ingenieurskunst, aber auch Kreativität.
Die grösste Herausforderung ist oft nicht technischer Natur, sondern menschlicher:
- Übersetzung: Entwickler/Architekten (abstrakt), Business/Stakeholder (zahlengetrieben) und Designer (ästhetisch) sprechen verschiedene Sprachen.
- Empathie: Erfolgreiche Projekte brauchen eine Kultur, in der diese Disziplinen Verständnis füreinander haben.
- Nutzer-Fokus: Die Endanwender müssen frühzeitig eingebunden werden. Das beste System ist wertlos („Rohrkrepierer“), wenn es an den Bedürfnissen der Nutzer vorbeigeht.
Die Komplexität beim Bau moderner Systeme kann erdrückend wirken. Doch mit einer sauberen Strukturierung in die hier beschriebenen Bereiche von Use Cases über Architektur bis zu Operations wird das Vorhaben beherrschbar.
Benötigst du Unterstützung bei der Architektur deines Systems oder ein unabhängiges Brainstorming? Attic Solutions hilft dir, dein Vorhaben methodisch korrekt aufzusetzen.
FAQ (Häufig gestellte Fragen)
Was ist der Unterschied zwischen Use Case und User Story? Ein Use Case beschreibt abstrakt eine Interaktion („Schaden melden“). Eine User Story ist eine konkrete Arbeitsanweisung für die Entwicklung, abgeleitet aus dem Use Case, oft mit Akzeptanzkriterien („Als Kunde möchte ich…“).
Warum Microservices statt Monolith? Microservices erlauben bessere Skalierung, höhere Ausfallsicherheit und ermöglichen es Teams, parallel an verschiedenen Teilen der Software zu arbeiten.
Was bedeutet DevOps? DevOps (Development + Operations) ist ein Ansatz, bei dem Entwicklung und Betrieb nicht mehr getrennte Silos sind, sondern gemeinsam für den gesamten Lebenszyklus der Software verantwortlich sind.
Warum ist UX/UI Design schon vor der Entwicklung wichtig? Weil Designs komplexe Prozesse visualisieren. Sie helfen Stakeholdern, das Produkt zu verstehen, noch bevor Geld für die teure Programmierung ausgegeben wird.