System of Record
Das System, in dem eine fachliche Wahrheit verbindlich gefuehrt wird, zum Beispiel Vertrag, Konto, Police oder Rechnung.
Einordnung · Prio 10 · Version 4
Gesamtlandschaft und Denkmodell
Wie fachliche Prozesse, technische Plattformen, Integrationswege, Datenbesitz, Betriebsmodell und Modernisierung zusammenhaengen.
Kurzverständnis und Systemgrenze
Eine Enterprise-Legacy-Landschaft ist selten ein einzelner alter Monolith. Sie besteht aus Kernsystemen, Middleware, Batchketten, Datenbanken, Files, Benutzeroberflaechen, Reporting, Sicherheitssystemen und vielen betrieblichen Sonderregeln. Moderne Architekturarbeit beginnt deshalb nicht beim Code, sondern beim Verstehen der Landschaft.
Das wichtigste Denkmodell lautet: Fachprozess, Datenbesitz, Transaktionsgrenze, Integrationsweg und Betriebsnachweis muessen gemeinsam betrachtet werden. Wer nur eine REST-Schnittstelle um ein Altsystem baut, hat die Kopplung oft nur versteckt, nicht geloest.
Version 4 dieses Lehrbuchs betrachtet jedes System mit konkretem Ablauf, typischen Artefakten, Fehlerbildern, Modernisierungspfaden und Beispielcode. Dadurch entsteht ein technisches und fachliches Arbeitsmodell fuer Analyse, Refactoring, Migration und Schulung.
Daten- und Verantwortungsgrenze: Die Gesamtlandschaft gehoert fachlich nicht einer einzelnen Anwendung. Sie ist ein sozio-technisches System aus Fachbereich, Betrieb, Entwicklung, Security, Datenmanagement und Revision. Entscheidend ist, wer fachliche Wahrheit besitzt, wer Daten veraendert und wer im Fehlerfall entscheidet.
Fachliche und technische Darstellung
Wichtige Begriffe und Artefakte
System of Engagement
Oberflaechen und Portale, die Benutzerinteraktion leisten, aber oft keine finale Datenhoheit besitzen.
Integration Layer
Schicht, die Nachrichten transformiert, routet, validiert und technische Protokolle entkoppelt.
Operational Truth
Betriebliche Wahrheit aus Logs, Monitoring, Batchprotokollen, MQ-Tiefen, Datenbankkontrollen und Auditdaten.
Typischer Ablauf Schritt für Schritt
- Fachlicher Ausloeser entsteht in Portal, Callcenter oder Partnerkanal.
- UI oder Service ruft einen Anwendungsmonolithen auf.
- Monolith prueft Regeln, schreibt Daten und ruft Host, DB, SOAP oder MQ.
- Asynchrone Folgeprozesse laufen ueber Queue, Batch, ETL oder File Transfer.
- Reporting und Archivierung erzeugen Nachweise fuer Fachbereich und Revision.
Ausführliche Praxisbeispiele mit Code und Konfiguration
Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.
Analyse-Checkliste als YAML
legacy-landscape-assessment:
business-capabilities:
- name: Vertrag fuehren
systemOfRecord: MAINFRAME-POLICY
consumers: [JavaEE-Monolith, Reporting, PartnerPortal]
criticality: sehr hoch
interfaces:
- name: CreateInvoice
protocol: SOAP
owner: Billing-Team
error-channel: ESB-Fehlerqueue
retry-policy: 3 Versuche, danach manuelle Klaerung
operations:
batch-window: "22:00-05:30"
monthly-close: "letzter Bankarbeitstag"
audit-retention-years: 10
modernization-candidates:
- capability: Rechnungsvorschau
pattern: Strangler Fig + Facade
reason: lesender Use Case mit geringem Rueckschreib-Risiko
Risiken, Fehlerbilder und Diagnose
| Aspekt | Beschreibung |
|---|---|
| Fachliches Risiko | Unklare Verantwortung fuer Geschaeftsprozess-Karte fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem. |
| Technisches Risiko | CMDB und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen. |
| Betriebsrisiko | Fehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert. |
| Migrationsrisiko | Neue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern. |
Typische Fallen:
- Nur technische Abhaengigkeiten betrachten und fachliche Datenhoheit uebersehen.
- Schnittstellen katalogisieren, aber Fehlerkanaele, Retry und manuelle Workarounds vergessen.
- Batch- und Reporting-Prozesse als Nebensache behandeln, obwohl sie Monatsabschluss, Buchhaltung oder Revision steuern.
- Modernisierung als Big Bang planen, ohne Parallellauf, Golden-Master-Tests und Rollback-Pfade.
Modernisierungspfad und geeignete Entwurfsmuster
| Pattern | Einsatz in diesem System |
|---|---|
| Strangler Fig Pattern | Neue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen. |
| Anti-Corruption Layer | Altbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen. |
| Facade | Komplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln. |
| Adapter | Protokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen. |
| Golden Master Test | Bestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen. |
Empfohlene Schritte:
- Erstelle zuerst eine fachliche Domänenkarte mit System-of-Record-Markierung.
- Erfasse pro Schnittstelle Vertrag, Dateninhaber, SLA, Fehlerkanal, Wiederanlauf und Monitoring.
- Schneide Modernisierung nach fachlichen Faehigkeiten, nicht nach technischen Tabellen oder Teams.
- Nutze Strangler Fig, Anti-Corruption Layer, Facade und Adapter, um Risiken schrittweise zu reduzieren.
Analysefragen für echte Projekte
- Wer besitzt fachlich die Wahrheit fuer Geschaeftsprozess-Karte?
- Welche technische Komponente ist kritisch: CMDB, Schnittstellenkatalog, Logging/Audit?
- Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
- Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
- Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
- Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
- Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
- Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung
Erstelle fuer eine fiktive Rechnungslandschaft eine Matrix aus System, Datenhoheit, Schnittstelle, Fehlerkanal, SLA und Modernisierungsmuster. Markiere anschliessend drei Use Cases, die sich risikoarm aus dem Altsystem herausloesen lassen.