IT-Architektur planen: Weniger Abhängigkeiten, klarere Entscheidungen

Eine gute IT-Architektur zeigt, welche Systeme eine Aufgabe erfüllen, wem ihre Daten gehören und was bei einem Ausfall passiert. Das klingt unspektakulär. Genau diese Fragen entscheiden aber darüber, ob ein Unternehmen eine neue Funktion zügig einführen kann oder zunächst fünf Dienstleister und drei Datenbestände abstimmen muss. Ein Diagramm voller moderner Produkte beantwortet sie nicht automatisch.

„Einfach“ bedeutet dabei weder ein einziger Server noch möglichst wenig Technik um jeden Preis. Eine zusätzliche Sicherungskopie oder ein zweiter Anwendungsserver kann begründet sein. Problematisch wird Komplexität, wenn ihr Nutzen unklar bleibt, niemand sie betreut oder ihre Abhängigkeiten erst während einer Störung sichtbar werden. Die passende Architektur ist deshalb immer auch eine Entscheidung über Verantwortung und laufenden Aufwand.

Mit drei konkreten Geschäftsabläufen anfangen

Statt zuerst alle Geräte einzuzeichnen, wählt das Team drei relevante Abläufe: etwa Kundenanfrage bearbeiten, Auftrag ausführen und Rechnung stellen. Für jeden Ablauf wird der Weg durch Anwendung, Identität, Datenhaltung und externe Schnittstellen dargestellt. Dazu gehören auch E-Mail-Anhänge, Tabellen und manuelle Übertragungen. Diese informellen Verbindungen verursachen oft genau die Verzögerungen, die in einer reinen Serverliste fehlen.

Danach werden Qualitätsanforderungen konkret: Darf eine Anfrage während einer Wartung zehn Minuten warten? Müssen Mitarbeiter auch bei gestörter Internetverbindung weiterarbeiten? Wie viele gleichzeitige Nutzer werden erwartet, und welche Daten dürfen zeitversetzt erscheinen? Solche Antworten beeinflussen Hosting, Synchronisierung und Redundanz stärker als eine pauschale Vorgabe, alles in die Cloud oder alles ins eigene Büro zu stellen.

Wann eine zusätzliche Komponente ihre Kosten rechtfertigt

Diese Tabelle ist keine Aufforderung, auf nützliche Technik zu verzichten. Sie fordert eine überprüfbare Begründung. Wenn ein Cache auf der kritischen Strecke bisher nur wenige Millisekunden spart, seine veralteten Inhalte aber regelmäßig Support erzeugen, sollte die Lösung erneut bewertet werden. Wenn ein Import während der Geschäftszeit die gesamte Anwendung blockiert, kann eine entkoppelte Verarbeitung einen klaren Nutzen haben.

Monolith und Microservices sind keine Qualitätsstufen

Ein modular aufgebautes Programm kann fachlich saubere Grenzen haben und gemeinsam ausgeliefert werden. Ein verteiltes System kann trotz vieler Dienste eng gekoppelt sein. Microservices ermöglichen unabhängige Entwicklung und Skalierung, bringen aber zusätzliche Anforderungen an Kommunikation, Datenkonsistenz und Betrieb mit. Diese Abwägung beschreibt Microsoft in seinem Vergleich von Architekturstilen.

Für ein kleines Team mit einer gemeinsamen Veröffentlichung kann ein modularer Monolith übersichtlich sein: Kundenverwaltung, Aufträge und Abrechnung erhalten klare Schnittstellen, bleiben aber zunächst ein Deployment. Ein separater Bildverarbeitungsdienst kann später hinzukommen, wenn seine Last unabhängig wächst. Der Schritt folgt dann einem beobachteten Bedarf und übernimmt eine klar abgegrenzte Aufgabe.

Die Verpackung der Anwendung ist eine weitere Entscheidung. Container können sowohl einen Monolithen als auch einzelne Dienste ausliefern. Eine Containerumstellung verlangt deshalb nicht automatisch eine Aufteilung in Microservices. Der Beitrag Docker und Container im Betrieb erklärt, wann diese Auslieferungsform hilft und welche Aufgaben trotzdem bleiben.

Beispiel: Kundenportal, Warenwirtschaft und Buchhaltung

Ein Unternehmen betreibt eine Warenwirtschaft und eine separate Buchhaltung. Kunden sollen nun im Portal ihre Stammdaten sehen und Dokumente abrufen. Die schnelle Abkürzung wäre, dem Portal direkten Schreibzugriff auf beide Datenbanken zu geben. Damit hängen seine Releases jedoch von internen Datenstrukturen zweier Fremdsysteme ab. Ein Update dort kann den neuen Kundenprozess unerwartet beeinflussen.

Ein besser prüfbares Zielbild legt zunächst fest: Die Warenwirtschaft führt operative Kundendaten, die Buchhaltung führt gebuchte Belege, das Portal besitzt seine eigenen Zugangsdaten und Darstellungspräferenzen. Vereinbarte Schnittstellen übertragen benötigte Informationen. Die Oberfläche kennzeichnet bei Bedarf den Aktualisierungsstand, statt eine nicht gewährleistete Echtzeitdarstellung vorzutäuschen.

Diese Trennung hat ebenfalls Kosten. Schnittstellen müssen versioniert, Übertragungsfehler sichtbar und Wiederholungen eindeutig behandelbar sein. Bei einem kleinen internen Werkzeug kann eine einfachere, dokumentierte Leseschnittstelle ausreichend sein. Die Entscheidung hängt von Änderungsbedarf, Fehlerfolgen und Teamkapazität ab. Wo Systeme schrittweise angepasst werden, ergänzt der Leitfaden zur Legacy-Modernisierung den Migrationsweg.

Entscheidungen dokumentieren, bevor das Wissen verloren geht

Ein Architecture Decision Record (ADR) hält eine wichtige Entscheidung mit Kontext, geprüften Alternativen und Konsequenzen fest. Er sollte sich auf eine konkrete Frage beschränken und später erkennbar durch eine neue Entscheidung ersetzt werden können. Die AWS-Empfehlungen zum ADR-Prozess beschreiben dafür einen nachvollziehbaren Lebenszyklus. Entscheidend ist die erhaltene Begründung, nicht die Länge des Dokuments.

Für das Portal könnte ein Eintrag festhalten: „Kundendaten bleiben in der Warenwirtschaft, weil deren Sachbearbeitung die führende Pflege übernimmt. Das Portal zeigt einen synchronisierten Lesestand. Eine Verzögerung bis zur vereinbarten Grenze ist akzeptiert. Wir überprüfen diese Wahl, sobald Kunden Änderungen selbst verbindlich ausführen sollen.“ Damit erkennt ein neues Teammitglied sowohl die heutige Grenze als auch den Anlass für eine Änderung.

Wirtschaftlichkeit über den gesamten Betrieb bewerten

Zum Vergleich von Varianten gehören Implementierung, Infrastruktur, Lizenzen, Betreuung, Einarbeitung und Ausstieg. Eine Lösung mit geringem Serverpreis kann teuer werden, wenn für jede Anpassung Spezialwissen benötigt wird. Eine verwaltete Plattform kann Arbeit reduzieren, bringt aber Vertrags- und Exportabhängigkeiten mit. Das Team sollte deshalb denselben Zeitraum und dieselben Anforderungen für alle Varianten verwenden.

Die Kalkulation von Serverkosten hilft beim Betriebsbudget; IT-Infrastruktur für kommende Anforderungen behandelt Erweiterbarkeit und Planung unter Unsicherheit. Unsere Architektur- und IT-Beratung setzt bei diesen Entscheidungen an. Im folgenden Praxisteil wird aus dem Zielbild ein konkreter Review mit messbaren Kriterien für Änderung, Ausfall und Übergabe.