Ist Fiori tot? Die eigentliche Frage steckt im Compositional Design System
11. August 2026 | Lesezeit: 7 Minuten
Solution Architect bei FIS
Was passiert, wenn KI nicht nur Inhalte, sondern ganze Benutzeroberflächen erstellt? SAP begegnet dieser Herausforderung mit dem Compositional Design System. Erfahren Sie, wie Regeln, Metadaten und Guardrails zur eigentlichen Grundlage moderner UX werden.
Aktuell wird viel darüber diskutiert, ob SAP Fiori vor dem Aus steht. Ausgelöst hat diese Debatte SAPs neue KI-Design-Sprache in Verbindung mit Joule Work, das auf Zuruf komplette Workspaces generiert. Inspiriert wurde dieser Blog-Beitrag durch einen LinkedIn-Artikel von John Stenby zur Frage „Is Fiori Dead?“ sowie durch SAPs eigene Erläuterungen zum Compositional Design System und zu Joule Work.
Die naheliegende Frage lautet dabei eigentlich nicht, ob Fiori verschwindet. Entscheidender ist: Wie viel von dem, was heute als klassischer Fiori-Screen gebaut wird, sollte überhaupt noch ein fest entworfener Screen sein? Diese strategische Ebene sorgt derzeit für intensive Diskussionen.
Ebenso spannend ist jedoch die technische Ebene darunter – und die wird bislang kaum beleuchtet: Wie schafft man es, dass eine KI zuverlässig UI generiert, ohne dass am Ende ein UX-Flickenteppich entsteht? SAPs Antwort darauf heißt Compositional Design System. Das Konzept dahinter reicht deutlich über SAP hinaus.
Joule Work und das Compositional Design System: Was steckt dahinter?
Joule Work ist SAPs neue Engagement-Schicht. Sie formulieren eine Absicht – etwa „zeig mir alle überfälligen Bestellungen mit Lieferverzug über 5 Tage“ – und das System orchestriert selbstständig Daten, Workflows und Agenten quer über SAP- und Nicht-SAP-Systeme hinweg. Daraus entsteht eine passende Oberfläche, ohne dass vorher ein Mensch eine feste Bildschirmmaske dafür entworfen hat.
Damit das nicht in beliebigem UI-Wildwuchs endet, hat SAP das klassische Fiori-Design-System um eine neue Schicht erweitert. Ein klassisches Design System liefert Designern Bausteine für konsistente Entscheidungen. Das Compositional Design System stellt diese Bausteine zusätzlich der KI zur Verfügung – als maschinenlesbare Logik und nicht nur als Referenzdokumentation. Drei Säulen tragen dieses Konzept:
Explizite Regeln definieren, welche Komponenten in welcher Kombination überhaupt Sinn ergeben.
Was ein erfahrener Fiori-Designer intuitiv weiß – eine KPI-Kachel gehört nicht in eine Objektseiten-Fußzeile –, muss jetzt als Regel kodiert sein, damit die KI dieselbe Entscheidung trifft.
Komponenten und Patterns erhalten eine fachliche Bedeutung: Welche Funktion erfüllen sie? Welche Nutzerabsicht unterstützen sie? In welchen Kontext passen sie?
Erst dadurch werden Designprinzipien zu operationalisierbaren, maschinenlesbaren Constraints – statt zu Richtlinien in einem PDF.
Compliance-Regeln, Barrierefreiheit und Validierungslogik greifen nicht mehr nachträglich im Review.
Sie sind bereits während der Generierung selbst aktiv eingebettet, damit Ergebnisse auditierbar bleiben.
SAP bezeichnet das Ergebnis ohne diese Struktur treffend als „Frankenstein UI“: aus technisch validen Einzelteilen zusammengesetzt, aber im Ganzen falsch. Genau darin liegt der Kern der Sache – die eigentliche Schwierigkeit generativer UI liegt nicht darin, Komponenten zu erzeugen, sondern die richtige Struktur zu erstellen.
SAP Fiori Masterclass: Wie Enterprise UX Design SAP Prozesse vereinfacht
Inhalte des Webinars
Kein SAP-Alleingang
Was SAP hier für die Enterprise-Welt aufbaut, ist die Ausprägung eines Musters, das sich branchenübergreifend als Standardarchitektur für generative UI etabliert. Das Prinzip folgt dabei fast immer demselben Schema:
Eine begrenzte, definierte Menge an UI-Bausteinen mit typisierten Props steht bereit.
Die KI erzeugt kein freies HTML und keine beliebigen Komponenten, sondern wählt ausschließlich aus diesem Katalog – das Gegenstück zu SAPs Structured Metadata.
Das Sprachmodell generiert keinen fertigen UI-Code, sondern ein strukturiertes, gegen ein Schema validierbares Objekt, das beschreibt, welche Komponente mit welchen Daten, wo im Baum sitzt.
Ein separater Renderer übersetzt dieses Objekt anschließend in tatsächliche UI.
Validierung, Berechtigungen und Konsistenzregeln laufen bereits beim Zusammenbau – nicht erst, wenn ein Mensch das Ergebnis später begutachtet.
Eine Nutzerinteraktion löst ein Ereignis aus, das gegen den erlaubten Zustandsraum geprüft wird, bevor eine neue Ansicht gerendert wird.
Die KI improvisiert nicht bei jedem Klick neu, sondern bewegt sich innerhalb definierter Übergänge.
Diese Grundidee findet sich mittlerweile bei mehreren Anbietern wieder, mit leicht unterschiedlichem Fokus. Frameworks für React, Vue und Svelte setzen auf klar typisierte Komponentenkataloge, gegen die ein Sprachmodell nur valide Strukturen erzeugen kann.
Der gemeinsame Nenner überall: Die Kreativität der KI wird bewusst auf die Kompositionsebene beschränkt, nicht auf die Bausteine selbst. Deshalb passt die Bezeichnung „Navigationssystem für KI“ für das Compositional Design System gut – es legt nicht fest, wie ein einzelner Screen aussieht, sondern nach welchen Regeln beliebig viele Screens zusammengestellt werden dürfen.
Was heute schon funktioniert – und was noch nicht
SAP selbst kommuniziert den Reifegrad offen: Die Screen-Generierung läuft aktuell in Minuten, nicht in Sekunden ab. Für die Freigabe einer Rechnung wartet niemand drei Minuten auf eine sich selbst bauende Oberfläche. Hochfrequente, präzisionskritische transaktionale Abläufe werden deshalb vorerst weiter durch klassische, fest gebaute Fiori-Apps abgebildet.
Das ist jedoch ein Performance-Problem, kein Architekturproblem – und Performance-Probleme lassen sich technisch in der Regel schneller lösen als strukturelle. Die eigentliche Vorarbeit – Beziehungslogik, Metadatenmodell, Guardrails – ist der schwer nachrüstbare Teil, und diesen hat SAP bereits gelegt.
Die Joule-Chat-Patterns, Insight Cards und Vorschläge sind dabei nicht neben Fiori entstanden, sondern Teil des SAP Design Systems geworden. Fiori bleibt somit das Fundament, auf dem die kompositorische Schicht aufsetzt.
Warum das für den Fiori-Backlog relevant ist
Die praktische Konsequenz ist weniger technisch als organisatorisch: Jede individuell gebaute Fiori-App ist eine Wette darauf, dass genau dieser Anwendungsfall dauerhaft eine von Menschen entworfene, feste Oberfläche verdient. Für hochvolumige, compliance-relevante oder zeitkritische Prozesse ist diese Wette solide.
Für einmalige Reporting-Ansichten, Freigabe-Cockpits und zusammengeklickte Übersichten – also einen guten Teil vieler Fiori-Backlogs – sieht die Rechnung anders aus. Genau für diesen Bedarf wird generative Komposition gebaut. Eine hartkodierte Maske für etwas zu entwickeln, das ein Agent in absehbarer Zeit dynamisch orchestrieren kann, bedeutet, Budget zweimal auszugeben.
Damit verschiebt sich auch die Governance-Frage: Setzt KI statt eines Designers die Oberfläche zusammen, werden die Metadaten- und Regelwerke – wer darf welche Komponenten kombinieren, mit welchen Daten, unter welcher Freigabe – zur eigentlichen Design-Entscheidung. Dieses Thema muss strategisch bei IT-Leitung und Architektur ankommen, nicht nur im UX-Team.
Fragen zu diesem Thema? Unser Team hilft Ihnen gerne persönlich weiter.
Lesen, Anschauen, Informieren
In unserem Downloadbereich finden Sie eine große Auswahl an wissenswerten Inhalten rund um SAP – Expert-Talks, Whitepaper, Flyer. Um direkt zu finden, was Sie suchen, nutzen Sie die Filterfunktion für Themen und Content-Art.
Podcast
What´s SAP? gibt kurze Antworten auf komplexe Fragen rund um SAP. Er ist für alle, die in ihrem Berufsalltag wenig Zeit, aber Lust auf spannende Inhalte für zwischendurch haben – ob während der Fahrt, in der Kaffeepause oder zwischen zwei Terminen.
Blog
Unsere Blog-Autoren und Gastautoren halten für Sie stets Augen und Ohren offen, um über aktuelle Trends und Geschehnisse am Markt zu schreiben. Reinschauen lohnt sich!
