Softwarearchitektur setzt das Verständnis der Unternehmensarchitektur voraus
Softwarearchitektur: Wer die Unternehmensarchitektur nicht versteht, baut Schulden — beim Kunden
Es gibt eine Art von Architekturschuld, die besonders tückisch ist: Sie entsteht nicht durch schlechte Implementierung, nicht durch fehlende Tests, nicht durch technische Nachlässigkeit. Sie entsteht, weil eine Softwarekomponente von Anfang an die falsche Rolle in der Unternehmensarchitektur ihres Kunden spielt.
Und sie entsteht oft, bevor die erste Zeile Code geschrieben wird.
Das eigentliche Problem
Softwarehersteller, die konfigurierbare Standardsoftware für mehrere Kunden entwickeln, stehen vor einer Frage, die selten explizit gestellt wird: Welche Rolle spielt meine Komponente in der Unternehmensarchitektur meiner Kunden — und welche Rolle sollte sie nicht spielen?
Wer diese Frage nicht beantwortet, neigt dazu, Funktionsumfang als Qualitätsmerkmal zu behandeln. Mehr Features, mehr Datenmodelle, mehr integrierte Logik. Das klingt nach Mehrwert. In der Praxis bedeutet es häufig das Gegenteil: Datenhaltung, Geschäftslogik und Reporting-Funktionen, die in die Komponente hineingewachsen sind, aber eigentlich woanders hingehören. Redundanzen, die niemand explizit entschieden hat. Abhängigkeiten, die sich später als Fesseln erweisen.
Der Kunde bemerkt das oft erst bei der Einführung — oder noch später, wenn er versucht, die Architektur weiterzuentwickeln. Zu diesem Zeitpunkt sind die Schulden längst aufgebaut.
Was vorher verstanden sein muss
Softwarearchitektur existiert nicht im Vakuum. Sie ist immer Teil eines größeren Gefüges — und dieses Gefüge bestimmt, was eine Komponente leisten soll und was nicht.
Das bedeutet konkret: Bevor das Design einer Softwarekomponente beginnt, muss ihre Rolle in der Unternehmensarchitektur geklärt sein. Unabhängig davon, ob es sich um Eigenentwicklung, einen Auftragnehmer oder Standardsoftware handelt. Die Fragen sind dieselben:
- Welche Geschäftslogik gehört in diese Komponente — und welche gehört explizit nicht hierher?
- Wie interagiert die Komponente mit anderen Systemen? Über welche Schnittstellen, nach welchen Standards?
- Welche Daten hält die Komponente, welche bezieht sie, welche gibt sie weiter? (Wer den Datenarchitektur-Artikelgelesen hat, erkennt hier die direkte Verbindung: Die Dateneigenschaften bestimmen, was eine Komponente sinnvollerweise überhaupt halten und verarbeiten kann.)
- Wird die Komponente in mehreren Fachprozessen verwendet — und ist sie dafür entworfen?
- In welche Compliance- und Sicherheitsstandards muss sie sich einfügen?
Diese Fragen klingen nach Vorbereitung. Sie sind es auch — aber sie sind keine bürokratische Pflichtübung. Sie sind der Mechanismus, der verhindert, dass Komplexität unkontrolliert wächst.
Was Konzentration auf die Kernkompetenz wirklich bedeutet
"Fokus auf die Kernkompetenz" ist ein Satz, der in Architekturdebatten oft fällt und selten operationalisiert wird. In der Softwarearchitektur hat er eine sehr konkrete Bedeutung: Wenn die Rolle einer Komponente in der Unternehmensarchitektur klar ist, entfallen viele Komplexitätstreiber im Design von selbst.
Eine Komponente, die weiß, was sie nicht tun soll, ist einfacher zu entwerfen, einfacher zu testen, einfacher zu warten — und fügt sich besser in das Gesamtsystem ein. Skalierbarkeit, Ressourcennutzung, Wiederverwendung: All das wird leichter, wenn die Grenzen der Komponente vorab gezogen sind, nicht im Nachhinein verhandelt.
Umgekehrt gilt: Eine Komponente, deren Grenzen nie explizit definiert wurden, wächst in der Regel über sie hinaus. Nicht böswillig, sondern weil jede neue Anforderung irgendwo untergebracht werden muss — und "hier" immer die naheliegende Antwort ist.
Die Konsequenz
Softwarearchitektur, die ohne Verständnis der Unternehmensarchitektur entworfen wird, kann technisch einwandfrei sein und trotzdem scheitern. Sie liefert Komponenten, die funktionieren — aber nicht in dem System, in dem sie funktionieren sollen.
Die Schulden, die dabei entstehen, sind real — und sie entstehen auf beiden Seiten. Beim Kunden zeigen sie sich in Integrationsproblemen, in Datensilos, in Systemen, die schwer zu ändern sind, weil niemand mehr genau weiß, was wo wohnt. Und sie zeigen sich in dem Moment, in dem ein Unternehmen seine Architektur weiterentwickeln will — und merkt, dass einzelne Komponenten das nicht mitmachen können.
Beim Softwarelieferanten entstehen dieselben unklaren Grenzen als Entwicklungskosten: Funktionen, die außerhalb der eigentlichen Kernkompetenz liegen, wurden gebaut — weil der Kunde sie vermeintlich brauchte und niemand früh genug gefragt hat, ob sie wirklich in diese Komponente gehören. Das Ergebnis ist Software, die breiter ist als sie sein müsste, teurer in der Pflege, und für die der Kunde mit jeder Weiterentwicklung weniger zahlungsbereit wird. Was wie ein Mehrwert aussah, wird zur Last — für beide Seiten.
Die Ursache ist dieselbe: fehlende Klarheit über Rolle und Grenzen der Komponente im Gesamtgefüge. Die Lösung liegt nicht in mehr Funktionsumfang, sondern in der frühen, expliziten Antwort auf die Frage, was diese Komponente leisten soll — und was nicht.
Das ist kein unvermeidliches Schicksal. Es ist das Ergebnis von Entscheidungen, die ohne die richtigen Fragen getroffen wurden — und von Fragen, die zu spät gestellt wurden.
