Enterprise-Architektur-Initiativen scheitern aus meiner Sicht häufig daran, dass Anforderungen und Architektur nebeneinander statt miteinander entstehen. Das Twin-Peaks-Modell zeigt, wie beide im Gleichschritt wachsen. Meine Erfahrung aus einem Bankenprojekt: Strukturierte Interviews unter Einbezug der Architektur machen den Unterschied.

1.     Wenn die Architektur allein losläuft

Bei der Ablöse einer veralteten Output-Management-Software in einer Bank habe ich es selbst erlebt: Das bestehende System wurde von Mitarbeitenden im Front Office für das Erzeugen und Versenden von Kundenkorrespondenz (z.B. per Post, E-Mail, SMS) genutzt. Die Business-Seite wollte «einfach ein besseres Tool» und die Unternehmensarchitektur lief zunächst allein los und entwarf eine Lösung, bevor die Anforderungen sauber erhoben waren. Erst ein strukturierter Ansatz im Requirements Engineering nach IREB-Standard hat die Annahmen der Architektur validiert und ergänzt.

2.     Was die Forschung über gescheiterte EA-Initiativen sagt

Gong und Janssen haben 15 Faktoren aus der Literatur zusammengetragen, an denen Initiativen der Unternehmensarchitektur scheitern. Drei davon betreffen direkt die Zusammenarbeit von Anforderungen und Architektur:

Quelle: Gong & Janssen (2022), Information Systems Frontiers, 25, 1401–1419 (Auszug, Übersetzung mit KI-Unterstützung).

Stakeholder sind alle, die von einem System betroffen sind oder es beeinflussen. Ihre Interessen erkennen, einordnen und Konflikte lösen: Das ist nach IREB Kernaufgabe des Requirements Engineering. Wer die Architektur davon trennt, riskiert genau diese Fehler. Die Studie zeigt zudem: Die Faktoren hängen in Ursache-Wirkungs-Ketten zusammen. Als Ursachen gelten vor allem fehlendes EA-Wissen im Management und mangelnde Kommunikationskompetenz der Architektur. Einschränkung: Diese Analyse stützt sich auf die Einschätzung von nur acht Fachleuten.

3.     Das Twin-Peaks-Modell: zwei Gipfel, ein Weg

Bashar Nuseibeh stellte 2001 das Twin-Peaks-Modell vor. Seine Beobachtung: Viele Organisationen froren Anforderungsdokumente ein und übergaben sie der Entwicklung. Oder eine fest definierte Architektur blockierte spätere Änderungen. Nuseibeh setzt dem ein Bild entgegen: Anforderungen und Architektur sind zwei gleich wichtige Gipfel.

Anforderungen und Architektur wachsen im Twin-Peaks-Modell parallel vom Groben ins Detail. (Bildquelle: eigene Darstellung nach Nuseibeh 2001, KI-generiert mit Claude)

Beide Seiten starten grob und allgemein. In mehreren Runden werden sie parallel detaillierter, ähnlich wie im Spiralmodell der Softwareentwicklung. Problem («Was braucht es?») und Lösung («Wie bauen wir es?») bleiben gedanklich getrennt, werden aber gleichzeitig bearbeitet. Jede Architekturfrage schärft die Anforderungen und umgekehrt.

4.     Drei typische Sorgen und wie das Modell hilft

Das Twin-Peaks-Modell adressiert bewusst drei typische Sorgen des Managements nach Barry Boehm:

1. «I’ll know it when I see it»: Viele Nutzende können Anforderungen erst präzisieren, wenn sie einen Prototyp sehen. Twin Peaks erkundet den Lösungsraum früh mit Prototypen und holt so rasch Feedback ein.
2. Standardsoftware statt Eigenentwicklung: Oft wählt man zwischen fertigen Produkten. Twin Peaks gleicht Anforderungen und Produktarchitekturen schrittweise ab. Genau das ist die Situation bei vielen Systemablösen.
3. Schneller Wandel: Anforderungen ändern sich laufend. Twin Peaks nimmt sie laufend auf und passt die Architektur kontinuierlich an.

5.     Meine Tipps aus der Praxis

In unserem Projekt haben sich strukturierte Interviews nach IREB Elicitation bewährt, die die Architektur begleitet hat. So floss technisches Wissen direkt ins Gespräch ein, und die Architektur hörte die Anforderungen aus erster Hand.

• Ermittlungsziel festlegen: Es ist ratsam, vor dem Interview zu klären, was Sie herausfinden wollen.
• Struktur von Interviews: Die Interviewfragen sollten nach Rolle & Kontext, Nutzung & Prozess, Was läuft gut?, Pain Points & Risiken sowie Medienbrüche & Workarounds und Anforderungen & Prioritäten strukturiert sein.
• Architektur von Anfang an einbeziehen: nicht erst, wenn es um die Lösung geht. So kann sie früh auf technische Grenzen hinweisen.
• Annahmen abgleichen: Prüfen Sie Architekturentwürfe gegen die Interviewergebnisse.

6.     Fazit

Twin Peaks ist über 20 Jahre alt und aktueller denn je. Viele Organisationen arbeiten heute iterativ. Trotzdem scheitern EA-Initiativen weiterhin an Stakeholder-Konflikten und isolierter Architektur. Wer Anforderungen und Architektur gemeinsam entwickelt, senkt dieses Risiko. Twin Peaks sollte daher gemäss meiner Erfahrung unterstützend mit Werkzeugen aus der IREB-Schulung eingesetzt werden, um schon in der Analysephase, so früh wie möglich, einem Scheitern der EA-Initiativen entgegenzuwirken.

Quellen und weiterführende Literatur:

• Boehm, B. (2000). Requirements that handle IKIWISI, COTS, and rapid change. Computer, 33(7), 99–102. https://doi.org/10.1109/2.869384
• Brand, A., Häusser, D., Lauenroth, K., van Loenhoud, H. & Steiger, P. (2024). Handbuch Requirements Elicitation: Practitioner | Specialist (Version 2.1.1). International Requirements Engineering Board (IREB). IREB Elicitation Handbuch
• Gong, Y. & Janssen, M. (2022). Why organizations fail in implementing enterprise architecture initiatives? Information Systems Frontiers, 25, 1401–1419. https://doi.org/10.1007/s10796-022-10298-x
• Nuseibeh, B. (2001). Weaving together requirements and architecture. Computer, 34(3), 115–119. https://doi.org/10.1109/2.910904

KI eingesetzt für: ☐ Recherche-Unterstützung ☐ Ideen/Sparring ☒ Struktur/Textentwurf ☒ Sprache/Korrektur ☒ Übersetzung ☒ Bildgenerierung