Softwarearchitektur Grundprinzipien – Systemintegration & Legacy-Systeme
Dieser Beitrag ist eine Begriffserklärung zu Softwarearchitektur-Grundprinzipien – inklusive Prüfungsfragen und Tags.
In a Nutshell
Softwarearchitektur bedeutet, Anwendungen so zu strukturieren, dass sie wartbar, erweiterbar und an bestehende IT-Landschaften anpassbar bleiben – insbesondere bei der Integration von Altsystemen und Umgebungswechseln.
Kompakte Fachbeschreibung
Die Softwarearchitektur definiert die grundlegende Struktur eines Systems: Komponenten, deren Beziehungen sowie die eingesetzten Technologien. Im betrieblichen Alltag geht es selten um “Greenfield”-Entwicklung – viel häufiger müssen bestehende Systeme berücksichtigt oder erweitert werden. Die Einbindung von Legacy-Systemen stellt besondere Anforderungen an Schnittstellen, Datenformate und Protokolle. Moderne Architekturen müssen oft mit monolithischen oder schwer wartbaren Anwendungen interagieren. Bei einem Umgebungswechsel (z.B. von On-Premise zu Cloud) ist die Portierbarkeit zentral. Technische Schulden, modulare Zerlegung, Schichtenmodelle und klare Schnittstellendefinitionen sind Schlüsselaspekte.
Prüfungsrelevante Stichpunkte
- Architektur definiert Struktur, Kommunikation, Abhängigkeiten
- Berücksichtigung von Legacy-Systemen = Pflicht bei Erweiterungsprojekten
- Schnittstellenfähigkeit = zentrale Entwurfsanforderung
- Refactoring statt Neuentwicklung bei stabilen Altsystemen (IHK-relevant)
- Praxis: häufige Integration über REST, Middleware, Adapter-Pattern
- Sicherheitsaspekte: Datenformate, API-Security, Zugriff auf Legacy-Datenbanken
- Wirtschaftlichkeit: Wiederverwendung vs. Neuentwicklung
- Dokumentation mit Diagrammen, Schnittstellenbeschreibungen und Migrationsstrategie
Kernkomponenten
- Analyse bestehender Systemarchitektur
- Identifikation technischer Schulden
- Abgleich von Anforderungen mit IST-System
- Schnittstellenkonzept
- Auswahl von Integrationsstrategien (Wrapper, Proxy, Adapter)
- Definition der Zielumgebung (Betriebssystem, Cloud)
- Migrationsstrategie (Big Bang vs. inkrementell)
- Refactoring von Altkomponenten
- Testkonzepte für Kompatibilität
- Dokumentation der Architekturentscheidungen
Praxisbeispiel
// Erweiterung einer Warenwirtschaft um REST-API für Web-Frontend
1. Altsystem (monolithisch, nur lokale DB-Zugriffe)
2. Ziel: moderne Web-UI → REST-API als Middleware
3. Adapter zwischen Alt-Datenstruktur und JSON-Antwort
4. API dokumentiert mit OpenAPI/Swagger
5. Nutzung bestehender Logik, keine Duplizierung
Erklärung: Die bestehende Logik bleibt erhalten, neue Clients kommunizieren über REST mit einem zwischengeschalteten API-Layer.
Vorteile und Nachteile
Vorteile
- Nutzung bestehender Systeme spart Zeit und Kosten
- Integration erhöht Lebensdauer von Altsystemen
- Architekturbewusstsein reduziert spätere Umstellungskosten
Nachteile
- Alte Systeme sind oft schlecht dokumentiert
- Schnittstellen nachträglich schwer realisierbar
- Umgebungswechsel können Sicherheitsrisiken erzeugen
Typische Prüfungsfragen (mit Kurzantwort)
- “Berücksichtigung bestehender Systeme”? Neue Lösung muss kompatibel zur vorhandenen IT-Landschaft sein.
- Was ist ein Legacy-System? Altsystem, das weiterverwendet wird, oft ohne aktuellen Support oder Dokumentation.
- Altsysteme anbinden? Über Schnittstellen, Adapter, Wrapper oder Datenreplikation.
- Was ist Middleware? Software als Vermittler zwischen Alt- und Neusystemen.
- Risiken bei Umgebungswechsel? Inkompatibilität, Datenverlust, Sicherheitslücken.
- Architekturentscheidungen dokumentieren? Mit Komponenten-, Schichten-, Schnittstellendiagrammen und textlicher Begründung.
- Refactoring vs. Neuimplementierung? Refactoring sinnvoll bei stabiler Kernlogik mit Modernisierungsbedarf.
- “Lose Kopplung” im Kontext? Komponenten sind unabhängig, Änderungen sind lokal möglich.