Das ist kein Zufall. Und es ist auch kein Versagen der Methodik. Es ist ein Hinweis auf etwas, das in der professionellen Diskussion rund um Requirements Engineering und Softwarearchitektur selten offen ausgesprochen wird: Wirklich gute Ergebnisse entstehen nicht dort, wo Methodik am konsequentesten durchgezogen wird. Sie entstehen dort, wo jemand weiß, was er weglässt – und warum.
Das Versprechen der Methodik
Strukturierte Anforderungserhebung, arc42, IREB-konforme Prozesse, Modellierungssprachen wie UML und BPMN – all das hat seinen Platz. Methodik schafft Orientierung. Sie macht Entscheidungen nachvollziehbar, Ergebnisse vergleichbar und Projekte steuerbar. Gerade in regulierten Umfeldern, bei Schnittstellen-Spezifikationen oder sicherheitskritischen Systemen ist konsequente Methodik keine Option, sondern Pflicht.
Aber Methodik hat eine stille Annahme eingebaut: dass das Problem, wenn man es nur präzise genug beschreibt, auch präzise genug gelöst werden kann. Diese Annahme stimmt – für eine bestimmte Klasse von Problemen. Ein Abwasserrohr soll dreißig Jahre unter der Erde funktionieren. Da will niemand, dass jemand kreativ wird. Kreativität erzeugt Varianz. Varianz erzeugt Komplexität. Und Komplexität in einem System, das einfach laufen soll, ist kein Gewinn – sie ist ein Risiko.
Das Problem beginnt, wenn dieselbe Logik auf Probleme angewendet wird, die keine Abwasserrohre sind.
Die Grenze der Reproduzierbarkeit
Komplexe Softwaresysteme, organisationale Transformationen, neue digitale Produkte – das sind Vorhaben, bei denen das Ziel selbst noch nicht vollständig bekannt ist. Wo Stakeholder widersprüchliche Vorstellungen haben, ohne es zu wissen. Wo die eigentliche Anforderung noch gar nicht auf dem Tisch liegt.
Gruppen denken kollektiv. Sie entwickeln implizite Annahmen, unausgesprochene Konflikte, gemeinsame blinde Flecken. In der Sozialpsychologie ist das unter dem Begriff Groupthink gut beschrieben: die Tendenz von Gruppen, Konsens über Richtigkeit zu stellen und unbequeme Wahrheiten systematisch zu vermeiden. Groupthink ist kein Fehler im System – er ist das System, solange niemand ihn sichtbar macht.
Genau das ist die Aufgabe des Requirements Engineers und Architekten in solchen Kontexten: nicht zu protokollieren, was gesagt wird, sondern herauszukitzeln, was gedacht, aber nicht ausgesprochen wird. Und dann mutig genug zu sein, es in die Runde zu stellen – auch wenn es den Raum kurz unangenehm macht.
Manchmal ist die wichtigste Frage in einem Projekt: Warum bauen wir das eigentlich? Sie wird erschreckend selten gestellt. Das leistet kein Framework. Das ist Urteilsvermögen.
Was der Impressionismus damit zu tun hat
Claude Monet konnte zeichnen. Nicht ungefähr – präzise, akademisch, technisch vollständig ausgebildet. Er beherrschte die Regeln seiner Zunft. Und dann hat er sich entschieden, nur einen Bruchteil davon zu zeigen.
Seine Kathedralen-Serie – dreißig Gemälde derselben Fassade, zu verschiedenen Tageszeiten, in verschiedenem Licht – ist kein Versuch der vollständigen Dokumentation. Es ist das Gegenteil: die bewusste Reduktion auf das Wesentliche. Licht, Stimmung, Perspektive. Was bleibt, wenn man alles weglässt, was nicht trägt.
Gute Architekturarbeit hat dieselbe Logik. Es geht nicht darum, alles zu erfassen. Es geht darum, die richtigen Dinge sichtbar zu machen – und die Dinge, die bereits klar sind, bewusst im Hintergrund zu lassen. Weil die Aufmerksamkeit einer Gruppe eine begrenzte Ressource ist. Was man in den Fokus hebt, verdrängt etwas anderes. Diese Entscheidung zu treffen – bewusst, situativ, mit Blick auf das Ziel – ist selbst eine fachliche Leistung.
Das ist keine Analogie, die leichtfertig gezogen wird. Ein IT-Architekt ist kein Künstler im klassischen Sinne. Aber die strukturelle Ähnlichkeit ist real: In beiden Feldern ist die volle Beherrschung des Handwerks die Voraussetzung dafür, es gezielt nicht anzuwenden.
Der Unterschied zwischen großer impressionistischer Kunst und dem, was manche als „moderne Kunst" belächeln – ein verkehrt aufgehängtes Pissoir, scheinbar beliebige Farbkleckse – liegt genau hier. Im ersten Fall steckt hinter der scheinbaren Leichtigkeit jahrelange handwerkliche Disziplin. Im zweiten Fall fehlt das Fundament, und man spürt es. Die meisten Menschen können das nicht erklären – aber sie spüren es.
Die Falle des vollständigen Methodeneinsatzes
Wer neu in der Methode ist, wendet alles an. Das ist verständlich – man hat Werkzeuge gelernt und will sie einsetzen. Das Ergebnis sind oft Projekte mit umfangreicher Dokumentation, detaillierten Modellen und hohem Prozessaufwand. Und ein Projektteam, das am Ende ein einziges klares Bild gebraucht hätte: was es bauen soll.
Man muss die gesamte Klaviatur kennen – und dann drei Tasten spielen. Das ist keine Vereinfachung. Es ist die schwierigste Form der Anwendung.
Erfahrene Praktiker erkennt man nicht daran, dass sie mehr Methodik einsetzen. Man erkennt sie daran, dass sie weniger einsetzen – und trotzdem präzisere Ergebnisse liefern. Manchmal ist das ein vollständiges arc42-Dokument. Manchmal ist es eine handgezeichnete Skizze auf einem Whiteboard. Diese Entscheidung setzt zweierlei voraus: fachliche Tiefe und Menschenkenntnis. Beides entwickelt sich nur durch Erfahrung – und durch die Bereitschaft, die eigene Methodik immer wieder in Frage zu stellen.
Die Grammatik der Organisation
Weglassen klingt intuitiv. In der Praxis ist es eine der schwierigsten Entscheidungen im Projekt – weil sie voraussetzt, dass man versteht, in welcher gedanklichen Welt eine Organisation lebt. Jede Organisation hat eine eigene Sprache, in der sie denkt: semantische Muster, nach denen sie Probleme beschreibt, Entscheidungen trifft und Prioritäten setzt.
Manche Organisationen denken in Produkten: Was bauen wir, wer kauft es, wie entwickeln wir es weiter? Andere denken in Prozessen: Vertrieb, Logistik, After-Sales – das Produkt ist hier austauschbar, der Ablauf ist das Eigentliche. Wieder andere – besonders in IT-nahen Umfeldern – denken primär in Infrastruktur: Netzwerksegmente, Schutzzonen, Hardwareebenen.
Diese Muster findet man nicht nur in Organigrammen. Man findet sie in der Sprache der Menschen, in den Fragen, die gestellt werden, in dem, was als selbstverständlich gilt und nie erklärt wird. Für den Methodeneinsatz hat das direkte Konsequenzen: Wer in einer Prozessorganisation prozessorientiert modelliert, baut auf etwas auf, das bereits im Kopf aller Beteiligten existiert. Das bringt Geschwindigkeit und Akzeptanz – solange das Ziel ist, innerhalb dieser Denkwelt zu bauen.
Wenn die Denkwelt selbst das Problem ist
Das große Aber kommt dann, wenn die Strategie des Unternehmens genau diese Denkwelt verändern will. Aus einer Prozessorganisation soll eine Produktorganisation werden. Aus einer Infrastrukturorganisation soll eine werden, die in Services denkt. Diese Transformationen sind häufig – und sie scheitern häufig. Nicht an Technologie. Nicht an Methodik. Sondern daran, dass die alten semantischen Muster weiter wirken, während man offiziell schon in der neuen Welt operiert.
Hier reicht es nicht mehr, in der Sprache der Organisation zu arbeiten. Man muss gezielt den Reibungspunkt erzeugen – die Stelle sichtbar machen, wo das alte Denkmuster mit dem neuen Ziel kollidiert. Das ist kein Fehler im Prozess. Das ist der eigentliche Inhalt der Arbeit.
Wer Geschwindigkeit will
Bleibt in den Strukturen. Bekannte Denkmuster beschleunigen Kommunikation, reduzieren Reibung und erhöhen die Akzeptanz von Ergebnissen. Legitimiert – solange das Ziel die Optimierung innerhalb der bestehenden Welt ist.
Wer Strukturen verändern will
Muss sie explizit machen. Der kognitive Clash – das Unbehagen, wenn ein vertrautes Denkmuster plötzlich sichtbar und hinterfragbar wird – ist kein Kollateralschaden. Er ist der Hebel. Wer ihn vermeidet, schützt den Status quo.
Diese Entscheidung bewusst zu treffen – situativ und mit Blick auf das, was die Organisation wirklich will, nicht was sie sagt – ist keine Methode. Es ist Urteilsvermögen. Und es ist der Punkt, an dem die Arbeit interessant wird.
Wie viel Kunstfertigkeit wollen Sie?
Das führt zu einer Frage, die in Projekten und Beratungsgesprächen selten explizit gestellt wird: Welchen Grad an Perspektive und Eigenständigkeit wollen Sie in Ihren Ergebnissen?
Wer ein System baut, das klar spezifizierbar ist, stabile Anforderungen hat und über lange Zeit wartungsarm laufen soll, braucht keine interpretative Tiefe im Anforderungsprozess. Konsequente Methodik ist hier die richtige Antwort. Mehr wäre Aufwand ohne Mehrwert.
Wer dagegen ein neues Produkt entwickelt, eine Organisation transformiert oder eine Architektur für ein Umfeld entwirft, das sich selbst noch nicht vollständig kennt – der braucht jemanden, der den Raum gestaltet, in dem die richtigen Fragen überhaupt erst möglich werden. Der erkennt, was zwischen den Zeilen steht. Der weiß, wann ein Zögern vor einer Antwort mehr verrät als die Antwort selbst.
Diese Entscheidung sollte am Anfang stehen – nicht am Ende, wenn die Erwartungen längst gesetzt sind.
Ordnung als Voraussetzung, nicht als Ziel
Requirements Engineering und IT-Architektur sind in komplexen Kontexten keine rein analytischen Tätigkeiten. Sie sind auch interpretative. Das bedeutet nicht, dass sie beliebig sind. Im Gegenteil: Die Freiheit zur Interpretation setzt die vollständige Beherrschung des Handwerks voraus. Wer nicht weiß, was er weglässt, lässt nicht weg – er vergisst.
Und genau das ist der Unterschied, der in der Praxis zählt. Nicht wie viel Methodik jemand kennt. Sondern ob er weiß, wann er sie einsetzt – und wann nicht. Die Spannung zwischen Struktur und Urteilsvermögen, zwischen Reproduzierbarkeit und Gespür, zwischen der Grammatik der Organisation und dem Mut, sie zu hinterfragen – das ist keine Problemstellung, die gelöst werden muss.
Sie ist die eigentliche Arbeit.