Eine Systemlösung nachvollziehbar entwerfen

Aus Anforderungen wird noch keine Architektur

Die Auenblick Diagnostik GmbH betreibt drei medizinische Labore. Befunde liegen bisher auf einem einzelnen Dateiserver am Hauptstandort. Die Fachabteilung möchte künftig eine zentrale Befundanwendung nutzen. Alle Namen, Werte und Vorgaben in diesem Szenario sind für diese Lektion neu erstellt.

Die vorbereitete Anforderungsliste klingt zunächst eindeutig:

• Beschäftigte sollen Befunde über einen Browser erfassen und abrufen.
• Laborgeräte liefern Messdateien über SFTP.
• Das vorhandene Verzeichnis verwaltet Benutzerkonten und Gruppen.
• Die Anwendung soll während der Betriebszeit von 6 bis 22 Uhr verfügbar sein.
• Nach einem Ausfall soll der Dienst innerhalb von vier Stunden wieder nutzbar sein.
• Im Wiederherstellungsfall darf höchstens eine Stunde Datenarbeit verloren gehen.
• Eine Unternehmensvorgabe verlangt, dass Befunddaten auf Systemen an den eigenen Standorten gespeichert werden.
• Das IT-Team kann die Lösung werktags betreuen, aber keinen Bereitschaftsdienst rund um die Uhr leisten.

Eine Produktliste wäre jetzt zu früh. Du brauchst zuerst ein Lösungsmodell: Welche Bausteine erfüllen welche Anforderung? Wie hängen sie zusammen? Wo fließen Daten? Und welche Entscheidung erzeugt welches Risiko?

Nach dieser Lektion kannst du aus einer geklärten Anforderungsliste einen nachvollziehbaren Systementwurf entwickeln. Du wählst noch kein konkretes Servermodell und keinen bestimmten Hypervisor aus. Diese Entscheidungen brauchen eigene Kapazitäts-, Produkt- und Betriebsanalysen.

Anforderungen in Entwurfsgrößen übersetzen

Eine funktionale Anforderung beschreibt, was das System leisten soll. “Befunde im Browser abrufen” und “Messdateien importieren” sind Funktionen.

Eine Qualitätsanforderung beschreibt, wie gut oder unter welchen messbaren Eigenschaften eine Funktion bereitsteht. Dazu gehören im Szenario die Wiederanlaufzeit und der maximal akzeptierte Datenverlust.

Eine Randbedingung begrenzt den Lösungsraum. Die vorgeschriebene Speicherung an eigenen Standorten ist keine zusätzliche Funktion. Sie schließt aber Varianten aus, bei denen Befunddaten ausschließlich bei einem externen Cloud-Anbieter liegen.

Eine Annahme ist dagegen noch nicht bestätigt. Wenn du davon ausgehst, dass SFTP das einzige Geräteprotokoll ist, muss diese Annahme sichtbar im Entwurf stehen. Sonst wirkt eine offene Frage wie eine sichere Vorgabe.

Für den Entwurf formulierst du aus jeder relevanten Aussage eine Entwurfsfolge. Aus dem browserbasierten Zugriff folgt zum Beispiel ein Webzugang. Aus den vorhandenen Konten folgt eine Anbindung an den Verzeichnisdienst. Aus dem zulässigen Datenverlust von höchstens einer Stunde folgt, dass Sicherungen oder Replikationen mindestens zu diesem Ziel passen müssen.

Bausteine nach Verantwortung schneiden

Ein Architekturbaustein ist eine Komponente mit einer klaren Verantwortung. Für Auenblick reichen zunächst sechs logische Bausteine:

1. Ein Reverse Proxy nimmt HTTPS-Verbindungen an und leitet erlaubte Anfragen an die Anwendung weiter.
2. Der Anwendungsdienst verarbeitet Anmeldung, Befunderfassung und Suche.
3. Die Datenbank speichert strukturierte Befunde und Anwendungszustände.
4. Der Importdienst nimmt Messdateien der Laborgeräte entgegen, prüft sie und übergibt gültige Daten an die Anwendung.
5. Der Verzeichnisdienst bestätigt Identitäten und liefert Gruppen für die Berechtigungsprüfung.
6. Das Sicherungsziel nimmt getrennte Sicherungskopien auf und ermöglicht eine Wiederherstellung.

Diese Liste legt noch nicht fest, ob jeder Baustein eine eigene physische Maschine bekommt. Mehrere logische Komponenten können auf einer Plattform laufen. Umgekehrt kann eine Komponente aus Gründen der Last oder Verfügbarkeit mehrfach bereitgestellt werden. Der Systementwurf beschreibt zuerst Verantwortungen und Abhängigkeiten. Hardwaredimensionierung und Virtualisierungsplattform folgen später.

Das Diagramm macht auch Fehlerfolgen sichtbar. Wenn der Verzeichnisdienst nicht erreichbar ist, kann eine neue Anmeldung scheitern, obwohl Anwendung und Datenbank laufen. Wenn nur der Reverse Proxy überwacht wird, bleibt ein Fehler im Dateiimport möglicherweise unbemerkt.

Schnittstellen vollständig beschreiben

Eine Linie im Diagramm reicht für die Umsetzung nicht. Eine Schnittstelle beschreibt mindestens beteiligte Endpunkte, Zweck, Protokoll oder Format, Schutz und erwartetes Fehlerverhalten.

Für die Geräteanbindung könnte der Entwurf festhalten:

“CSV über SFTP” beantwortet also nur einen Teil der Fragen. Ohne Festlegung für Zeichensatz, Pflichtfelder, Wiederholungen und fehlerhafte Dateien bleibt die Integration mehrdeutig. Genau solche Lücken führen später zu Problemen, die fälschlich einer einzelnen Komponente zugeschrieben werden.

Varianten erst ausschließen, dann bewerten

Das Team untersucht zwei grundsätzlich zulässige Varianten. Beide speichern Befunddaten an eigenen Standorten.

Variante A: zentraler Eigenbetrieb. Anwendung, Datenbank und Import laufen auf der vorhandenen Plattform am Hauptstandort. Das Sicherungsziel steht am zweiten Standort.

Variante B: verteilter Eigenbetrieb. Reverse Proxy und Anwendung laufen zusätzlich am zweiten Standort. Die Datenbank bleibt am Hauptstandort und wird für die Wiederherstellung an den zweiten Standort repliziert. Ein Umschalten erfordert einen dokumentierten Betriebsablauf.

Eine reine SaaS-Variante wird nicht weiter gewichtet, weil sie die bestätigte Speicher-Randbedingung des Szenarios nicht erfüllt. Das ist keine allgemeine Aussage gegen Cloud-Dienste. Eine andere Unternehmensvorgabe könnte zu einem anderen Lösungsraum führen.

Für das Szenario entscheidet sich das Team vorläufig für Variante A. Das Wiederanlaufziel von vier Stunden erscheint damit erreichbar, ist aber noch nicht bewiesen. Vor der Freigabe muss ein Wiederherstellungstest mit realistischen Daten zeigen, ob Sicherung, Plattformbereitstellung, Datenbankwiederherstellung und Anwendungstest zusammen in die Zeit passen.

Variante B bietet mehr Vorbereitung für einen Standortausfall, bringt aber zusätzliche Zustände und Abhängigkeiten in den Betrieb. Höhere technische Komplexität ist kein kostenloser Verfügbarkeitsgewinn. Sie muss dokumentiert, überwacht und regelmäßig getestet werden.

Risiken an Entscheidungen binden

Ein Risiko besteht aus einem möglichen Ereignis und seiner Auswirkung. “SFTP” ist kein Risiko. “Ein Laborgerät sendet ein unerwartetes Dateiformat, wodurch neue Befunde nicht importiert werden” beschreibt dagegen Ereignis und Folge.

Für den Entwurf reichen zunächst vier konkrete Risiken:

• Verzeichnisdienst nicht erreichbar: Neue Anmeldungen schlagen fehl. Gegenmaßnahmen sind Überwachung, ein abgestimmtes Störungsverfahren und ein getesteter administrativer Notzugang.
• Fehlerhafte oder doppelte Messdatei: Befunde fehlen oder werden doppelt verarbeitet. Der Importdienst validiert, erkennt Wiederholungen und legt Fehler in einer Quarantäne ab.
• Sicherung nicht wiederherstellbar: Das Datenverlust- und Wiederanlaufziel wird verfehlt. Automatische Sicherungsmeldungen allein reichen nicht. Regelmäßige Wiederherstellungstests liefern den Nachweis.
• Unklare Schnittstellenversion: Ein Geräteupdate bricht den Import. Ein versioniertes Schema, Kompatibilitätstests und ein geregelter Änderungsprozess begrenzen das Risiko.

Dokumentiere auch, was der Entwurf nicht beantwortet

Ein nachvollziehbarer Entwurf enthält mindestens:

• bestätigte Anforderungen, Randbedingungen und offene Annahmen,
• logische Komponenten mit ihren Verantwortungen,
• Datenflüsse, Schnittstellen und externe Abhängigkeiten,
• betrachtete Varianten und Ausschlussgründe,
• Auswahlkriterien und begründete Entscheidung,
• Risiken, Gegenmaßnahmen und verbleibende Restrisiken,
• geplante Funktions-, Integrations- und Wiederherstellungstests,
• offene Folgeentscheidungen mit verantwortlicher Rolle.

Im Projekt Auenblick bleiben zum Beispiel Hardwareleistung, Speicherwachstum und die konkrete Virtualisierungsplattform offen. Das ist kein Fehler, solange die offenen Punkte sichtbar sind und vor der Beschaffung bearbeitet werden. Problematisch wäre eine scheinbar vollständige Zeichnung, in der ungeprüfte Annahmen verborgen bleiben.

Das nimmst du in den nächsten Entwurf mit

• Übersetze jede Anforderung in eine Entwurfsfolge und einen späteren Nachweis.
• Trenne logische Komponenten von konkreter Hardware und Plattformtechnik.
• Zeige auch vorhandene externe Dienste als Abhängigkeiten.
• Beschreibe an Schnittstellen mehr als nur das Transportprotokoll.
• Schließe Varianten aus, die Muss-Anforderungen oder Randbedingungen verletzen.
• Binde Risiken an konkrete Entscheidungen und plane Gegenmaßnahmen.
• Dokumentiere Annahmen, Grenzen und offene Folgeentscheidungen.

Damit steht ein Systementwurf, den ein anderes Team prüfen und weiter ausarbeiten kann. Der Entwurf ist noch keine Installation. Er macht aber sichtbar, warum die spätere Lösung genau diese Form bekommen soll.

Quellenbasis und Abgrenzung

Der Lernfeldbezug folgt Lernfeld 12b des KMK-Rahmenlehrplans. Dort steht die kundenspezifische Systemintegration als vollständige berufliche Handlung im Mittelpunkt. Die Fachinformatikerausbildungsverordnung ordnet das Konzipieren und Realisieren von IT-Systemen der Fachrichtung Systemintegration zu. Für den Projektprüfungsbereich nennt sie unter anderem Anforderungsanalyse, Lösungsalternativen, Systemänderungen und Dokumentation.

Der FISI-Prüfungskatalog 2026 konkretisiert mögliche Themen mit Anforderungen an Systemkomponenten und Netzwerke, Infrastrukturwahl, Schnittstellen, Kompatibilität, Tests und Lebenszyklus. Die Themenbreite ist keine Vorhersage für einen bestimmten Prüfungstermin. Das wiederkehrende Muster, eine Architektur anhand eines Szenarios zu bewerten, wurde aus vorhandenen Beispielprüfungen abstrahiert. Szenario, Daten, Aufgaben und Lösungen dieser Lektion sind eigenständig erstellt.

Die Lektion beginnt mit einer bereits geklärten Anforderungsliste. Wie du Kundenbedarf erhebst und Anforderungen mit Kundinnen und Kunden abstimmst, gehört in eine eigene Lektion. Ebenso ausgeklammert sind konkrete Hardwaredimensionierung, Produktauswahl, Netzwerkadressierung, Wahl einer Virtualisierungsplattform und technische Umsetzung. Hier geht es um den logischen Entwurf und seine Begründung.

Belegmatrix