Web-Entwicklung

Systemarchitektur

Die Systemarchitektur legt fest, welches System welche Aufgabe übernimmt, welche Angabe es führt und auf welchem Weg die Systeme miteinander sprechen.

In digitalen Handelsprojekten entscheidet die Architektur vor jeder Funktionsfrage: Sie ordnet Verkaufskanal, Warenwirtschaft und die Abläufe dazwischen einander zu und legt die Verbindungen zwischen ihnen fest.

In einfachen Worten

Eine Systemarchitektur beschreibt die Aufteilung der Arbeit zwischen mehreren Programmen. Für jede Aufgabe wird benannt, welches System sie übernimmt, und für jede Angabe wird benannt, welches System sie führt. Ein Verkaufskanal zeigt Sortiment und Preis, eine Warenwirtschaft führt Bestand und Belege, ein Auftragsmanagement-System steuert den Vorgang dazwischen. Dazu kommen die Verbindungen: welche Angaben in welche Richtung laufen, wie oft, und was geschieht, wenn eine Übertragung fehlschlägt. Diese Festlegungen entstehen vor der ersten Zeile Programmcode. Werden sie nachgeholt, sind Funktionen bereits gebaut, die von falschen Annahmen ausgehen.

Wozu brauche ich das?

Der typische Anlass ist ein Vorhaben, das mehr als ein System berührt: ein neuer Verkaufskanal neben einer bestehenden Warenwirtschaft, die Ablösung einer gewachsenen Einzellösung oder die Anbindung eines weiteren Kanals. In allen drei Fällen lautet die erste Frage, welches System künftig welche Angabe führt. Erst danach lässt sich entscheiden, welche Funktionen aus einem Standard kommen und welche entwickelt werden.

Beispiel aus der Praxis

Ein Händler betreibt eine Warenwirtschaft und plant einen Verkaufskanal für Geschäftskunden. Vor der Umsetzung wird für jede Angabe festgehalten, wo sie entsteht: Artikelstammdaten in der Warenwirtschaft, Beschreibungstexte in der Redaktion, Konditionen in der Warenwirtschaft, Bestellungen im Kanal. Aus dieser Liste ergeben sich zwei Verbindungen und ihre Richtungen. Ohne diese Vorarbeit wäre der Preis an zwei Stellen gepflegt worden, und die Abweichung wäre erst nach der Freischaltung aufgefallen.

Wirtschaftlicher Nutzen

Der wirtschaftliche Nutzen liegt in vermiedener Nacharbeit. Eine geklärte Architektur verhindert doppelte Pflege, widersprüchliche Stände und Funktionen, die zweimal gebaut werden. Sie macht außerdem sichtbar, welche Teile des Vorhabens Standard sind und welche Entwicklung verlangen, und damit wird der Aufwand vor der Beauftragung schätzbar.

Typische Fehler

  • Die Architektur erst nach der Auswahl der Software geklärt – die Systementscheidung legt dann Aufgaben fest, die woanders besser aufgehoben wären.
  • Keine Datenhoheit je Angabe festgelegt – ohne die Entscheidung, welches System führt, entstehen widersprüchliche Stände zwischen den Systemen.
  • Verbindungen ohne Fehlerbehandlung geplant – eine fehlgeschlagene Übertragung bleibt unbemerkt, und eine Bestellung fehlt im Zielsystem.
  • Interne Abläufe in den Verkaufskanal gebaut – jede spätere Änderung am Vertrieb berührt dann die Abläufe des Betriebs mit.
  • Die Architektur als einmaliges Dokument behandelt – sie veraltet mit jeder Anbindung, wenn sie nicht gepflegt wird.

Worauf achten?

  • Für jede Angabe schriftlich festhalten, welches System sie führt, und diese Liste im Projekt zugänglich halten.
  • Die Richtung jeder Verbindung benennen und klären, wie oft übertragen wird und was bei einem Fehlschlag geschieht.
  • Aufgaben dort ansiedeln, wo die zugehörigen Daten ohnehin liegen, damit keine zweite Pflege entsteht.
  • Eigene Entwicklung von der Standardsoftware getrennt halten, damit Aktualisierungen beide Seiten unberührt lassen.
  • Die Architektur bei jeder neuen Anbindung fortschreiben, damit sie den tatsächlichen Stand abbildet.

Häufig gestellte Fragen

Was gehört in eine Systemarchitektur?

Die Aufteilung der Aufgaben auf die beteiligten Systeme, die Festlegung, welches System welche Angabe führt, und die Beschreibung der Verbindungen zwischen ihnen einschließlich Richtung, Häufigkeit und Verhalten im Fehlerfall.

Wann wird die Architektur festgelegt?

Vor der Auswahl der Software und vor der ersten Entwicklung. Wird sie später nachgeholt, sind bereits Funktionen gebaut, die von anderen Annahmen ausgehen, und die Korrektur kostet mehr als die Klärung zu Beginn.

Was bedeutet Datenhoheit?

Datenhoheit benennt das System, das für eine bestimmte Angabe die verbindliche Quelle ist. Alle anderen Systeme übernehmen diesen Wert und pflegen ihn nicht selbst, damit keine widersprüchlichen Stände entstehen.