Der orbitale Move am Beispiel des „Export-Button-Konflikts“
Nehmen wir ein Szenario, das nahezu jedes Software-Unternehmen kennt.
Ausgangslage auf Bodenhöhe:
Kunden fordern einen Excel-Export aller Daten aus der Admin-Konsole. Der Vertrieb erhöht den Druck mit Kündigungsandrohungen, während die IT auf Performance-Probleme, fehlende Zeitstempel und technische Schulden hinweist. Die Diskussion kreist um ein einzelnes Feature – den Export-Button – und bleibt dabei vollständig im Status quo gefangen. Indizes, In-Memory Tabellen, können wir einrichten, aber das Problem ist vielleicht auch auf einer anderen Ebene lösbar.
An diesem Punkt ist es notwendig, den Boden zu verlassen.
Der orbitale Move besteht darin, die konkrete Feature-Forderung bewusst auszublenden und die Situation aus größerer Höhe zu betrachten. Nicht mit dem Ziel, kreativer zu werden, sondern präziser. Die Frage lautet nicht mehr: „Brauchen wir einen Excel-Export?“, sondern: „Was fehlt im System, dass diese Forderung überhaupt logisch erscheint?“
Aus dieser Perspektive wird deutlich:
Es fehlt kein Button. Es fehlt Souveränität über die eigene Datenhistorie.
Das System verhält sich aus Sicht des Nutzers wie ein geschlossenes System, ein Datenraum ohne gesicherte Beweiskraft nach außen. Die Daten existieren, aber sie gehören dem Nutzer nur solange, wie er vor dem System steht, oder eben die Daten exportiert.
In dem Moment, in dem dieses Verhöltnis klar wird, bröckelt etwas, es entsteht der Impuls, die Daten „herauszuholen“.
Der Excel-Export ist kein Produktwunsch, sondern ein Fluchtversuch.
Das dahinterliegende Schutzbedürfnis ist Autonomie in Verbindung mit Revisions- und Nachweissicherheit sowie Einsicht und Integration des Adressaten in das Ereignis. Der Nutzer möchte sicher sein, dass seine Arbeit nicht im System verschwindet, nicht manipuliert wird und jederzeit belegbar bleibt – auch unabhängig vom Anbieter.
An dieser Stelle folgt der zweite Schritt: die Abstraktion über eine Champion-Domäne. Die Frage lautet nun: In welchen Systemen wird dieses Bedürfnis nach Souveränität und Beweiskraft bereits zuverlässig erfüllt – ohne dass man Daten „exportieren“ muss?
Zwei naheliegende Beispiele sind das Grundbuchwesen und -> technisch moderner gedacht -< die Blockchain. In beiden Fällen existiert kein Export im klassischen Sinne. Stattdessen gibt es eine unveränderliche, kontinuierlich fortgeschriebene Spur. Jede relevante Änderung ist für Berechtigte jederzeit einsehbar, prüfbar und nachvollziehbar. Vertrauen entsteht nicht durch Kopien, sondern durch transparente Systemwahrheit.
Das abstrahierte Prinzip lautet daher:
Permanente, granulare Sichtbarkeit der System-Wahrheit.
Dieses Prinzip wird nun zurück in den ursprünglichen Kontext geführt, unter Berücksichtigung der realen Constraints, insbesondere der Performance-Sorgen der IT. Genau hier entsteht gesteuerte Emergenz.
Statt einen schweren Excel-Export zu bauen, der immer nur einen veralteten Snapshot liefert, wird das System um einen kontinuierlichen Ereignisstrom ergänzt. Jede relevante Änderung erzeugt einen kleinen, performanten Event-Eintrag. Dieser Event-Feed kann eingesehen, abonniert oder extern weiterverarbeitet werden – etwa über einen Log-View oder Webhooks.
Partizipation ist kein Vertrauensbruch
Wer jetzt daran denkt: Wo bleibt die Vertraulichkeit, der maskiert oder kürzt Ereignisse, soweit, dass der Datenschutz 100% gewährleistet ist. Es geht ja nicht um Offenlegung der Daten, sondern Partizipation des Adressaten.
Der Nutzer muss seine Daten nicht mehr „retten“.
Das System hält sie dauerhaft sichtbar.
Damit verschiebt sich der Charakter des Produkts fundamental. Aus einem geschlossenen Datenraum wird ein transparentes System. Der ursprüngliche Excel-Wunsch verliert damit automatisch an Bedeutung, weil das eigentliche Bedürfnis bereits auf einer tieferen Ebene erfüllt ist.
Der Unterschied lässt sich klar benennen:
Die lineare Lösung baut ein Feature und lindert ein Symptom.
Die metaflorative Lösung integriert ein Prinzip und heilt eine Systemlogik.
Genau hier liegt die Radikalität des orbitalen Moves. Er benennt nicht den Wunsch, sondern das Vakuum. Er spricht nicht über Buttons, sondern über Systemcharakter. Das kann für Organisationen unbequem sein, weil Begriffe wie „Gefängnis“ oder „Geiselhaltung von Daten“ emotional reagieren lassen. Aber die Logik dahinter ist kaum zu widerlegen.
Wer nur den Fluchtweg baut, erhält das Gefängnis.
Wer die Mauern transparent macht, braucht keinen Fluchtweg mehr.
In diesem Sinne zeigt das Beispiel, was Metafloration leistet: Sie verwandelt eine lästige Support-Anfrage nicht in ein weiteres Feature, sondern in eine strategische Veredelung des Produkts – indem sie den Denkraum verlässt, bevor sie ihn neu ordnet.
Feststellung über den Ist-Zustand jedes Systems:
Ereignisse passieren ohnehin.
Daten werden ohnehin geschrieben.
Zustandsänderungen sind real.
Ein ereignisbasierter Feed ist damit keine zusätzliche Last, sondern lediglich eine sichtbare Repräsentation dessen, was bereits geschieht.
Der klassische Performance-Einwand entsteht nur dann, wenn man gedanklich noch im alten Export-Paradigma verharrt: große Datenmengen, Snapshot-Denken, synchrone Abfragen. Genau dieses Paradigma wird durch den orbitalen Move verlassen.
Ein Event-Feed – vergleichbar mit File Integrity Monitoring, aber in Echtzeit – arbeitet nicht mit Masse, sondern mit Granularität. Jeder Event ist klein, eindeutig typisiert und zeitlich präzise. Die entscheidende Stellschraube ist dabei nicht die Datenmenge, sondern die Selektivität. Durch einen Event-Type-Filter wird nicht „alles“ gestreamt, sondern genau das, was für den jeweiligen Adressaten relevant ist. Das reduziert nicht nur Last, sondern erhöht die semantische Schärfe der Wahrnehmung.
Damit kippt das Performance-Argument vollständig:
Das System schreibt die Events ohnehin.
Das Anzeigen oder Weiterleiten ausgewählter Ereignisse ist kein Killer – es ist eine saubere Nutzung vorhandener Realität.
Und an diesem Punkt wird aus der technischen Lösung ein struktureller Mehrwert.
Denn der Feed ist nicht nur ein Nachweis-Instrument, sondern ein operatives Wahrnehmungsorgan. Ereignisse werden nicht mehr retrospektiv gesucht, sondern sind unmittelbar sichtbar. Fehlerquellen zeigen sich zum Zeitpunkt ihrer Entstehung. Abweichungen bleiben nicht latent, sondern treten in Erscheinung. Das System fordert Handlung nicht durch Alarme, sondern durch Präsenz.
Genau hier wird aus dem vermeintlichen „Performance-Risiko“ ein Killer Feature:
- Für den Nutzer entsteht Souveränität, weil nichts verborgen bleibt.
- Für den Betrieb entsteht Sicherheit, weil Probleme früh sichtbar werden.
- Für das Produkt entsteht Vertrauen, weil Systemwahrheit nicht exportiert, sondern gelebt wird.
Der entscheidende Punkt ist:
Ein Excel-Export versucht, Kontrolle nachträglich herzustellen.
Ein ereignisbasierter Feed verhindert, dass Kontrolle jemals verloren geht.
Damit ist die ursprüngliche Feature-Diskussion nicht widerlegt, sondern obsolet.
Der Wunsch nach Export verschwindet nicht, weil er abgelehnt wurde, sondern weil das System ihm zuvorgekommen ist.
Und genau das ist der Kern des Arguments – sauber aber hart.
Was real geschieht, sichtbar zu machen, ist kein Performance-Problem.
Es ist ein Wahrnehmungs-Upgrade.
Sicht der kognitiven Ergonomie
Der Adressat / Nutzer wird Teil der Ereignisse, die er auslöst oder die ihn betreffen.
Informationen befrieden Sorgen, stellen zufrieden oder können uns zur Handlung auffordern, sobald sie uns erreichen.
Natürlich müssen Daten auch exportiert werden.
Aber das Verlangen nach Exports ist auch ein Angst Reflex. Vielleicht nicht bei Ihnen, vielleicht nur bei mir.
Die Verschiebung von Angst zu kognitiver Entlastung
Dieses kontinuierliche Feedback führt zu Sicher- und Gewissheit über Prozesse, die im System stattfinden. Es zeigt uns: Das System ist gesund, ich sehe Lebenszeichen, ich sehe Reaktion.
Das Bedürfnis, alles unter Kontrolle haben zu müssen, wird gelindert, aber auch eine mögliche Arglosigkeit kann reduziert werden. Denn, erhalte ich eine unmittelbare Einsicht auf die Konsequenzen, dann werfe ich nochmal einen Blick drauf.
Der Kunde ist vielleicht nur Data Subject, aber seien wir mal ehrlich:
Wir brauchen den Kunden mit seinen Daten.
Also überlegen wir uns, ob wir dem Kunden nicht nur seine Daten geben können, sondern auch Augen im System bieten.
Meine These bedeutet für die Entwicklung: Investiert in Filter und Abonnements des Feeds. Wenn der Nutzer sich seinen Feed so konfigurieren kann, dass er nur die für ihn kritischen Ereignisse sieht, wird der Export-Button zu einem Relikt für die Archivare. Und das ist wahrlich nicht böse gemeint.
Der „aktive“ Nutzer arbeitet mit dem Fluss der Ereignisse.
Das ist die wahre Emergenz: Die Architektur heilt nicht nur das Performance-Problem, sie heilt das Nutzerverhalten. Der Nutzer wird vom „Daten-Sammler“ zum „Ereignis-Manager“.
Ich sage: Korrekte Informationen sind kein Technik-Feature. Es ist ein Grundbedürfnis.
Das ist kein Nice-to-have.
Das ist Systemreife.