Sie haben ein Konzept oder einen Architekturvorschlag auf dem Tisch. Eine Unterschrift wird erwartet. Im Haus sitzt niemand, der die Kästen und Pfeile fachlich zerlegen kann — und das muss auch niemand können, um die drei Fragen zu stellen, an denen solche Vorlagen tatsächlich scheitern.
Die Prüfung eines IT-Angebots ist eine andere Arbeit. Dort geht es um Preise, Tagessätze und Leistungspositionen: ob der Aufwand plausibel ist und was in der Positionsliste fehlt. Hier geht es um das Konzept darunter. Die Vorlage kann preislich sauber sein und trotzdem eine Entscheidung verlangen, die sich unter Ihren Bedingungen nicht halten lässt.
Geprüft wird nicht, ob das Diagramm elegant ist. Geprüft wird, was wahr sein muss, was sich später noch umkehren lässt — und ob der Schnitt zur Organisation passt.
Was ein Konzept behauptet — und was nicht
Ein Architekturkonzept ist keine Bauzeichnung. Es ist eine Behauptung darüber, welche Teile eines Systems zusammengehören, wer welche Verantwortung trägt und welche Eigenschaften später noch verhandelbar sind. Die internationale Norm ISO/IEC/IEEE 42010:2022 trennt genau das: die Architektur eines Gegenstands von der Architekturbeschreibung, die sie ausdrückt. Eine Beschreibung ist ein Arbeitsprodukt. Sie kann vollständig, lückenhaft oder irreführend sein — unabhängig davon, wie überzeugend die Folien wirken.
Die Norm verlangt von einer Beschreibung unter anderem drei Dinge, die sich ohne Schnittstellenwissen prüfen lassen:
- Beteiligte. Wer hat ein berechtigtes Interesse am System — nicht nur Auftraggeber und Dienstleister, sondern Betrieb, Fachbereiche, Datenschutz, die Leute, die nach Go-live damit arbeiten.
- Anliegen. Welche Fragen dieser Beteiligten die Beschreibung beantworten soll — Kosten, Austauschbarkeit, Betrieb, Ausstieg — und welche ausdrücklich nicht.
- Sichten. Aus welchen Blickwinkeln das System gezeigt wird. Eine Kästchengrafik ist eine Sicht auf eines, nicht auf alle Anliegen.
Ein Konzept, das Beteiligte und Anliegen nicht nennt, hat sie nicht vergessen. Es hat sie implizit entschieden — zugunsten dessen, der die Vorlage geschrieben hat. Die Arbeitsgruppe hinter der Norm macht das im öffentlichen Begriffsmodell nachlesbar: Eine Sicht existiert, um ein benanntes Anliegen zu rahmen. Was nicht gerahmt ist, ist nicht geprüft.
Erste Prüfung: die unausgesprochenen Annahmen
Jedes tragfähige Konzept steht auf Voraussetzungen. Die teuren stehen selten im Text. Sie stehen zwischen den Sätzen: dass Stammdaten eindeutig sind, dass eine Abteilung eine Schnittstelle „schon irgendwie liefert”, dass eine Person, die das Altsystem kennt, noch zwei Jahre bleibt, dass das Volumen sich verdoppelt und nicht verzehnfacht.
Eine Annahme ist keine Schätzung. Eine Schätzung darf danebenliegen. Eine Annahme ist eine Bedingung, ohne die der Entwurf zerfällt. Wenn das Konzept ein zentrales System für drei Gesellschaften vorschlägt, ist die Annahme nicht „wir werden uns schon einig”. Die Annahme ist, dass dieselben Begriffe, Freigaben und Ausnahmen in allen drei Gesellschaften gelten — oder dass jemand die Macht hat, das durchzusetzen.
Fragen, die Sie stellen können:
- Welche Voraussetzung steht nicht im Text, ohne die dieser Entwurf nicht trägt? Lassen Sie die Antwort aufschreiben. Eine mündliche Selbstverständlichkeit ist keine Annahme, sondern eine Lücke.
- Was gilt als gegeben, das bei uns nicht gegeben ist? Datenqualität, Zuständigkeiten, vorhandene Schnittstellen, die tatsächliche Last, die Bereitschaft einer Fachabteilung, ihren Ablauf zu ändern.
- Was passiert, wenn die zentrale Annahme um ein Drittel danebenliegt? Nicht „dann skalieren wir”. Sondern: Welche Teile bleiben stehen, welche müssen neu geschnitten werden, und wer zahlt das.
- Welche Annahme gehört einer anderen Abteilung? Wenn Vertrieb, Produktion und Buchhaltung dieselbe Wahrheit über denselben Vorgang brauchen, das Konzept das aber nicht benennt, ist die Integration nicht entworfen. Sie ist verschoben.
Ein Konzept, das seine Annahmen auflistet, ist nicht schwächer als eines, das sie verschweigt. Es ist prüfbar. Genau das ist der Unterschied zwischen einer Unterlage, die eine Entscheidung vorbereitet, und einer, die sie ersetzt.
Zweite Prüfung: was sich später noch umkehren lässt
Nicht jede Entscheidung im Konzept wiegt gleich. Manche lassen sich in zwölf Monaten zurücknehmen: ein Werkzeug, eine Schnittstellenform, die Reihenfolge zweier Ausbaustufen. Andere nicht: das Datenmodell, in dem die Fachbegriffe festgeschrieben sind; der Vertrag, der den Ausstieg an eine Plattform bindet; die Organisationsgrenze, die das System nachzeichnet.
Michael Nygard hat 2011 dafür ein schmales Format vorgeschlagen, das sich in der Praxis durchgesetzt hat: das Architecture Decision Record. Ein solches Protokoll hält eine architektonisch bedeutsame Entscheidung fest — eine, die Struktur, Betriebseigenschaften, Abhängigkeiten, Schnittstellen oder die Art der Herstellung verändert. Der Kern ist nicht die Wahl selbst. Der Kern sind Kontext und Folgen. Nygard verlangt ausdrücklich, alle Folgen zu nennen, nicht nur die angenehmen.
Von einer Geschäftsführung ist kein Archiv solcher Protokolle zu erwarten. Erwartbar ist die Frage, ob die Vorlage überhaupt kennt, was sie entscheidet. Ein Konzept, das fünf Plattformen empfiehlt und keine einzige verworfene Alternative begründet, hat nicht abgewogen. Es hat ausgewählt.
Fragen, die Sie stellen können:
- Welche Entscheidung in diesem Konzept lässt sich in einem Jahr noch zurücknehmen — und welche nicht? Lassen Sie die unumkehrbaren auf eine halbe Seite schreiben. Mehr als eine Handvoll ist verdächtig: Entweder ist zu viel auf einmal festgezurrt, oder der Verfasser nennt alles unumkehrbar, um Widerspruch zu unterbinden.
- Was würde ein Kurswechsel konkret kosten? Nicht „dann migrieren wir”. Sondern: welche Daten, welche Verträge, welche Schulungen, welche Schnittstellen zu Dritten. Eine Zahl darf grob sein. Eine fehlende Zahl ist eine fehlende Folge.
- Steht die Begründung der Wahl — oder nur die Wahl? „Wir setzen auf Produkt X” ist keine Entscheidung. „Wir setzen auf Produkt X, weil unsere Abläufe Y erzwingen, und wir nehmen in Kauf, dass Z teurer wird” ist eine.
- Welche Folge trifft uns, nicht den Dienstleister? Ein Konzept kann für den Ersteller bequem und für den Betrieb teuer sein. Die Folgen gehören auf Ihre Seite der Tabelle.
Wenn niemand im Raum die unumkehrbaren Punkte benennen kann, ist das Konzept keine Entscheidungsgrundlage. Es ist eine Absichtserklärung mit Diagramm.
Dritte Prüfung: der Schnitt zur Organisation
Systeme kopieren die Kommunikationswege der Organisation, die sie baut. Melvin Conway hat das 1968 in How Do Committees Invent? formuliert: Organisationen sind auf Entwürfe festgelegt, die Kopien ihrer eigenen Kommunikationsstrukturen sind. Der Satz ist älter als die meisten Werkzeuge auf dem Tisch. Er ist trotzdem der nützlichste, den eine Geschäftsführung in dieser Lage hat.
Der vorgeschlagene Systemschnitt ist deshalb keine technische Geschmacksfrage. Er ist eine Aussage darüber, wer künftig mit wem reden muss, damit ein Vorgang durchläuft. Schneidet das Konzept die Systeme anders als die Verantwortlichkeiten, entsteht eine dauerhafte Übersetzungsarbeit: Tickets, Abstimmungsrunden, „das muss die andere Seite noch freigeben”. Schneidet es sie genauso, ohne dass die Verantwortlichkeiten tragfähig sind, zementiert es eine Schwäche.
Ein häufiger Fall: Das Konzept sieht eine zentrale Plattform vor, die Organisation hat aber drei Fachbereiche mit eigener P&L, eigenen Ausnahmen und keinem gemeinsamen Eigentümer für den Prozess. Die Plattform wird gebaut. Die Ausnahmen bleiben. Ein Jahr später steht sie neben den Systemen, die sie ersetzen sollte.
Fragen, die Sie stellen können:
- Wer ist nach Go-live für welches Stück verantwortlich — mit Namen, nicht mit Rollen? „Der Fachbereich” ist keine Antwort. Eine Abteilung, die den Vorgang nicht besitzt, wird ihn auch im neuen System nicht besitzen.
- Wo erzeugt der vorgeschlagene Schnitt eine Übergabe, die es heute nicht gibt? Jede neue Nahtstelle ist ein neuer Abstimmungsbedarf. Der muss jemand bezahlen: Zeit, Stellen oder Qualität.
- Welche Abteilung wird zum Flaschenhals, wenn das System so gebaut wird, wie gezeichnet? Wenn alle Änderungen durch ein Team müssen, das heute schon überlastet ist, skaliert nicht das System. Es skaliert die Warteschlange.
- Was ändert sich an der Organisation, damit dieser Schnitt trägt — und steht das im Konzept? Ein Entwurf, der die Aufbauorganisation voraussetzt, die er selbst erst erzeugt, hat die Reihenfolge vertauscht.
Diese Prüfung ist unbequem, weil sie nicht den Dienstleister trifft, sondern das eigene Haus. Genau deshalb gehört sie vor die Unterschrift, nicht in die erste Lenkungsausschusssitzung danach.
Die Fragen im Gespräch — als Liste
Die drei Prüfungen lassen sich in einem Termin abarbeiten. Nicht alle auf einmal, und nicht als Verhör. Als Reihenfolge, die verhindert, dass das Gespräch in Features und Folien versinkt:
- Wessen Anliegen beantwortet diese Vorlage — und wessen ausdrücklich nicht?
- Welche Annahme muss wahr sein, damit der Entwurf trägt, und wer im Haus kann das bestätigen?
- Welche Entscheidung ist in zwölf Monaten noch umkehrbar, welche nicht, und was kostet der Kurswechsel?
- Welche Alternative wurde verworfen, und welche Folge dieser Wahl tragen wir?
- Wer besitzt nach Go-live welchen Teil — und wo entsteht eine Übergabe, die es heute nicht gibt?
- Was am Konzept würden Sie selbst in sechs Monaten anders schneiden, wenn die zentrale Annahme nicht hält?
Die letzte Frage ist die entscheidende. Wer sie nicht beantworten kann, hat das Konzept nicht gegen Ihre Lage geprüft. Er hat es gegen ein Ideal geprüft — oder gegen das, was sich gut verkaufen lässt.
Was ein tragfähiges Konzept ausweist
Ein Konzept, das diese Prüfung besteht, sieht selten spektakulär aus. Es nennt Beteiligte und Anliegen, statt sie in einem Appendix zu verstecken. Es trennt Vorschlag und Begründung. Es listet Annahmen, die sich widerlegen lassen. Es sagt, was unumkehrbar ist, und was bewusst offen bleibt. Es beschreibt den Schnitt so, dass eine Geschäftsführung erkennen kann, welche Abteilung künftig wessen Arbeit mitträgt.
Ein schwaches Konzept tut das Gegenteil. Es zeigt Technologie, wo eine Entscheidung nötig wäre. Es verwendet „flexibel” und „zukunftssicher”, ohne zu sagen, welche Zukunft. Es verschiebt unbequeme Folgen in Phase zwei und behandelt die Organisation als Randbedingung, obwohl sie der eigentliche Gegenstand ist.
Norm und ADR-Praxis treffen sich hier: Eine Beschreibung ohne benannte Anliegen ist unvollständig. Eine Entscheidung ohne Folgen ist keine Entscheidung. Beides lässt sich lesen, ohne Architekt zu sein.
Wenn die Antworten nicht tragen
Manchmal ist die Vorlage gut. Dann ist das Ergebnis der Prüfung eine schriftliche Bestätigung — gegenüber Gesellschaftern, einem Beirat oder einer Bank oft das, was fehlt. Manchmal ist sie es nicht, und die richtige Handlung ist eine andere Vorlage, ein kleinerer Schnitt oder die Entscheidung, jetzt noch zu stoppen.
Wenn die Unterlagen allein nicht reichen, weil das Gespräch über das fehlt, was nicht im Text steht, ist eine Architektur-Zweitmeinung das passende Format: eine Woche, ein fester Preis, eine schriftliche Stellungnahme zu genau dieser Vorlage. Geprüft wird gegen Ihre Lage, nicht gegen eine Lehrmeinung. Aus der geprüften Vorlage nimmt 01PC keinen Folgeauftrag an — sonst wäre die Stellungnahme eine Akquise.
Liegt die eigentliche Frage tiefer als ein einzelnes Dokument, ist das die Grenze dieses Beitrags. Dann geht es nicht mehr um eine Vorlage, sondern um den Zustand der Systeme. Dafür ist das System-Audit das andere Werkzeug.
Quellen