Antwort

Im klassischen Systemanalyse ist es wichtig, die Grenzen des zu entwerfenden Systems korrekt zu bestimmen – welche Funktionen innerhalb des Systems ausgeführt werden, was an externe Dienste abgegeben wird und wie die Integration mit ihnen gestaltet ist. In großen Projekten ist dieser Schritt entscheidend, um die Architektur zu vereinfachen und Risiken zu minimieren.

Schlüsselmerkmale:

• Die Grenzen des Systems werden nach Geschäfts-Funktionen, Verantwortungsbereichen, Datensatzbestand definiert.
• Eine regelmäßige Analyse vorhandener Dienste und Schnittstellen ist notwendig, um Duplizierung zu vermeiden.
• Es ist wichtig, Integrationsszenarien, Formate und Eingangs-/Ausgangspunkte zu entwickeln.

Historie der Fragestellung

Bereits in den 70er und 80er Jahren wurde bei der Analyse großer Systeme offensichtlich, dass falsch festgelegte Grenzen zu kostspieligen Integrationsnacharbeiten und Chaos in der Architektur führen.

Problem

Zu breite oder enge Grenzen des Systems erschweren die Wartung, erhöhen die Anzahl der Integrationen und führen zu Inkonsistenzen der Daten.

Lösung

Verwenden Sie die Technik des Context Diagram (Kontextdiagramm) sowie die Service Responsibility Matrix zur Verteilung von Funktionen und Verantwortlichkeiten. Den Fokus auf die Geschäftsziele richten, damit die Grenzen des Systems der tatsächlichen Struktur des Unternehmens entsprechen.

Fangfragen.

Muss man immer maximalen Autonomie der geschaffenen Systeme anstreben?

Nein, manchmal ist es effizienter, einen Teil der Funktionen an andere Systeme zu delegieren, um Duplizierung zu vermeiden.

Muss der Analyst die Datenformate für alle Integrationen vor Beginn der Umsetzung festlegen?

Nein, dies geschieht auf der Ebene des High-Level Designs. Detaillierte Formate werden später gemeinsam mit Architekten und Integratoren ausgearbeitet.

Ist es sehr schlecht, wenn dieselbe Funktion in mehreren Systemen realisiert ist?

Das führt zu Duplizierung, Synchronisationskosten und Verlust der Datenintegrität, daher sollten solche Überlappungen vermieden werden.

Typische Fehler und Anti-Patterns

• Das Kontextdiagramm nicht ausarbeiten.
• Vorhandene Dienstleistungen des Unternehmens ignorieren.
• Sofort in technische Details der Integrationen gehen, ohne die Geschäftsgrenzen zu bestimmen.

Beispiel aus dem Leben

Negativer Fall:
Das System wurde ohne Berücksichtigung der Struktur des Unternehmens entworfen, es wurde nicht klar definiert, welche Funktionen intern und welche in anderen Diensten sind.
Vorteile: schneller Start der Entwicklung, minimaler Ressourceneinsatz. Nachteile: viele redundante Integrationen, ständige Datenübertragungsprobleme, aufgeblähte Architektur.

Positiver Fall:
Der Systemanalytiker erstellte ein Kontextdiagramm, stimmte die Systemgrenzen mit dem Geschäft und den Architekten ab und minimierte die Integrationsinteraktionen.
Vorteile: transparente Architektur, weniger Integrationsfehler, bequeme Wartung. Nachteile: große Vorbereitungsarbeit am Anfang, Expertise in allen angrenzenden Systemen erforderlich.