chatgpt image 10. feb. 2026, 09 22 37

Wenn IT-Architekturen versagen: Die wahren Ursachen

IT-Architekturen müssen flexibel, skalierbar und robust sein. Doch viele Projekte scheitern nicht an Technologie, sondern an technischen und organisatorischen Mustern.
stiehl volker
Prof. Dr. Volker Stiehl

Die zunehmende Marktdynamik, Künstliche Intelligenz, Prozessautomatisierung und digitale Transformation erzeugen enormen Druck auf Unternehmen: Ihre IT-Architekturen müssen skalierbar, flexibel und belastbar sein. Doch die Wirklichkeit zeichnet ein anderes Bild. Zahlreiche Architekturvorhaben misslingen, wobei der Grund nicht in fehlendem technischem Wissen liegt, sondern in sich wiederholenden Mustern mit technischen und organisatorischen Ursachen. Genau diese Muster möchten wir in diesem Beitrag beleuchten. Der Praxisblick zeigt: Ob serviceorientierte Architekturen, moderne Prozessanwendungen oder klassische Enterprise-Systeme, die Hindernisse gleichen sich verblüffend.

1. Starke Abhängigkeiten:
Wenn Systeme sich gegenseitig blockieren

Eine der Hauptursachen für das Versagen zeitgemässer Architekturen liegt in der übermässigen Abhängigkeit von existierenden Systemen und ihrer Datenhaltung.

Beispielsweise scheiterten Projekte in der frühen SOA-Zeit trotz modernster Frameworks, weil sie zu fest mit der Systemlandschaft verknüpft waren. Jede Backend-Änderung zog unmittelbar Anpassungen in der Endanwendung nach sich.

Charakteristische Konsequenzen:

  • jede Anpassung verursacht erhebliche Kosten
  • Prozesse lassen sich kaum flexibel anpassen
  • niemand durchblickt mehr die Abhängigkeiten
  • die Weiterentwicklung kommt zum Erliegen

Lose Kopplung wird zwar oft gefordert, aber selten konsequent realisiert.

2. Mangelnde Abstraktion und unpassende Architekturparadigmen

Eine weitere Ursache für das Scheitern: Paradigmen aus monolithischer Entwicklung werden direkt in verteilte Architekturen übernommen.

In frühen SOA-Projekten übertrug man einfach objektorientierte Muster in serviceorientierte Szenarien, was fatale Auswirkungen hatte: Datentypen, Transaktionen, Kommunikationsmuster und Zustandsverhalten harmonierten nicht mehr miteinander.

Die Gefahren dabei:

  • OO-Patterns funktionieren nicht automatisch in verteilten Umgebungen
  • Entwickler greifen auf gewohnte statt auf passende neue Konzepte zurück
  • die Komplexität wächst, die Robustheit nimmt ab

3. Budgetengpässe und Projektzeitdruck

Die Projektrealität: Architekturqualität wird häufig dem kurzfristigen Lieferdruck untergeordnet.

Budgetrestriktionen und Zeitmangel verhindern den Aufbau robuster Architekturen, obwohl die Konsequenzen seit Jahren bekannt sind.

Kurzfristig gewinnt man Zeit, langfristig steigen die Wartungskosten massiv.

Charakteristische Folgen:

  • Architekturprinzipien fehlen
  • technische Schulden häufen sich
  • Verantwortlichkeiten bleiben unklar
  • Dokumentation ist nicht vorhanden

Das Resultat: Systeme, die nach kurzer Zeit kaum mehr weiterentwickelt werden können.

4. Unklare Verantwortlichkeiten und organisatorische Silos

Nicht die Technik allein bestimmt den Erfolg, sondern oft die Organisation.

Projekte misslingen, wenn:

  • IT, Business und Architekturteam nicht eng kooperieren
  • Rollen und Schnittstellen unklar bleiben
  • Entscheidungen politisch statt sachlich gefällt werden
  • kein gemeinsames Verständnis zwischen Stabilität und Flexibilität besteht

Besonders in prozessgesteuerten Architekturen ist die abteilungsübergreifende Zusammenarbeit erfolgsentscheidend und stellt oft die grösste Herausforderung dar.

5. Mangelnder Fokus auf Nachhaltigkeit und Unabhängigkeit

Ein besonderer Aspekt: Architekturen versagen, weil Unabhängigkeit nicht als primäres Ziel definiert wird.

Obwohl die Bedeutung der Entkopplung von Backend-Systemen bekannt ist, werden deren Daten und Strukturen trotzdem direkt in Anwendungen eingebunden, oft mit der Begründung „Das brauchen wir zwingend in unserer Endanwendung”.

Das eigentliche Problem ist nicht die Abhängigkeit an sich, sondern die mangelnde Bereitschaft, Alternativen zu entwickeln:

  • Integrationsschichten
  • kanonische Datenmodelle
  • Prozessentkopplung
  • servicevertragliche Abstraktion
  • Cross-Referenz-Tabellen

Diese Instrumente sind verfügbar, werden organisatorisch aber häufig nicht priorisiert.

Fazit: IT-Architekturen versagen selten wegen Technologie, sondern wegen der Haltung

Die Beispiele aus der Projektpraxis zeigen:
Scheitern entsteht immer dort, wo kurzfristige Entscheidungen Vorrang vor langfristiger Architekturqualität erhalten.

Erfolgreiche Architekturen kennzeichnen sich durch drei Merkmale:

  1. Technische Prinzipien wie klare Serviceverträge, lose Kopplung, Abstraktion und Wiederverwendbarkeit.
  2. Organisatorische Reife, die Entscheidungswege, Rollen und Zusammenarbeit definiert.
  3. Kulturelles Mindset, das nachhaltige Architektur als strategisches Asset versteht.

Wer diese Aspekte konsequent umsetzt, entwickelt nicht nur Software, sondern schafft ein Fundament für Innovation, Agilität und Wettbewerbsfähigkeit.

 


Quelle / Ursprung

Dieser Blogbeitrag basiert auf Inhalten aus dem Buch
„Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN:
Wie flexible Anwendungsarchitekturen wirklich erreicht werden können”
von Prof. Dr. Volker Stiehl.

stiehl volker

Prof. Dr. Volker Stiehl

Aufsichtsrat, Procubator AG

stiehl volker

Prof. Dr. Volker Stiehl

Aufsichtsrat, Procubator AG