Building systems from scratch: A mastertutorial for decision-makers and architects

If you’re not developing yourself, but need to efficiently get an overview of what needs to work together to build a modern IT system, you’re in the right place.

Developing complex software today is much more than just writing code. It is an interplay of abstract architecture, precise processes, human psychology (UX), and solid infrastructure.

This guide gives you the tools to understand what developers are working on and where gaps need to be closed for successful implementation.

We focus solely on the solution architecture: use cases, system architecture, data models, processes, user experience, and operations.

Index

1. Use Cases and User Stories: The Foundation of any Development

Every successful system begins not with code, but with an understanding of what it is meant to do.

Before selecting technology, the use cases must be designed.

What are Use Cases?

Use cases map out what different users, in their specific roles, need to be able to do with the system and what the system should show them. They are the abstract description of functionality.

A modern system typically consists of three logical access layers, which must be considered in the use cases:

Customer Application: The area where the end user operates.
Admin Application: An area for support or internal management to maintain data without directly interacting with the database.
Authentication: The process that controls access (often outsourced to IAM systems).

From Abstraction to the User Story

Modeling use cases is particularly relevant because they directly inform the user stories expected in agile software development (e.g., Scrum).

Definition of a User Story: A detailed description of a software feature from the end user’s perspective. It serves as a blueprint for developers and defines acceptance criteria.

Practical Examples

Scenario 1: Claim Case

Use Case: Claims Specialist -> Review claims list.
User Story: “As a claims specialist, I want to see the list of claims assigned to me…” (followed by details on filters, sorting, and displayed data).

Scenario 2: Client

Use Case: Client -> Create claim.
User Story: “As a customer, I want to be presented with a form where I can enter the details of my claim…” (followed by field descriptions and validation rules).

Why is this level of detail necessary?

For complex SaaS systems, it’s easy to end up with between 60 and 120 user stories.

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.

Leave a Reply

Leave a Reply Cancel reply

Kontakt

Dienstleistungen

Suchen und finden