Warum Low-Code-Plattformen nach zwei Jahren an ihre Grenzen stoßen

Es gibt einen Moment, den fast jedes Low-Code-Projekt irgendwann erlebt. Er kommt nicht in Woche zwei, wenn die erste Anwendung steht und alle im Lenkungskreis beeindruckt sind. Er kommt im dritten Jahr, in einem Besprechungsraum, und er klingt ungefähr so:

„Zeigen Sie mir, wer am 4. März 2023 die Freigabeberechtigung für diesen Datensatz geändert hat – und wie der Datensatz an dem Tag aussah, als die Zahlung freigegeben wurde.”

Und dann wird es still.

Nicht, weil niemand die Antwort wüsste. Sondern weil die Plattform sie nicht liefern kann. Es gibt ein Änderungsprotokoll, ja. Es zeigt, dass „User admin_2″ etwas geändert hat. Was genau, in welchem Zustand der Datensatz vorher war und ob zwischendurch jemand über die REST-Schnittstelle direkt auf die Datenbank geschrieben hat – das steht dort nicht. Es stand nie dort.

Dieser Artikel handelt davon, warum das kein Konfigurationsfehler ist, sondern eine strukturelle Eigenschaft der meisten Low-Code-Plattformen. Und was die Alternative wäre.

Low-Code ist auf die ersten sechs Wochen optimiert

Der Markt für Low-Code-Plattformen wird über eine einzige Kennzahl verkauft: Time-to-first-App. Wie schnell steht der erste Prototyp? Wie schnell sieht der Fachbereich einen klickbaren Screen? Genau darauf sind Bubble, Mendix und OutSystems hervorragend optimiert – und genau daran werden sie im Proof of Concept gemessen.

Das Problem ist, dass Unternehmensanwendungen nicht sechs Wochen leben, sondern zehn Jahre. Und die Anforderungen, die im zehnten Jahr zählen, tauchen im PoC überhaupt nicht auf.

Vier Stellen, an denen es strukturell bricht

1. Historisierung als Zusatzmodul statt als Grundfunktion

Die meisten Plattformen bieten ein Änderungsprotokoll: eine Tabelle, in die Ereignisse geschrieben werden. Das ist etwas anderes als Historisierung.

Ein Änderungsprotokoll sagt: Es wurde etwas geändert. Historisierung sagt: So sah die Welt zu diesem Zeitpunkt aus. Der Unterschied wird in dem Moment relevant, in dem jemand nicht die Änderung sehen will, sondern den Zustand – den kompletten, konsistenten Datenstand eines Stichtags, inklusive aller Beziehungen und Berechtigungen.

Dazu kommt: Ein Änderungsprotokoll auf Anwendungsebene erfasst nur, was durch die Anwendung läuft. Der nächtliche Import-Job, das Hotfix-Skript, die Integrationsschnittstelle des Nachbarsystems – alles Schreibwege, die am Protokoll vorbeigehen können. Ein Protokoll mit Lücken ist im Audit schlimmer als keines, weil es Vollständigkeit suggeriert.

2. Rechteprüfung in der Anwendungsschicht

Wenn die Berechtigungslogik in der Anwendung liegt, gilt sie exakt für den Weg durch die Anwendung. Alles, was daran vorbeigeht, sieht die Daten roh: die generierte REST-API, der Reporting-Zugriff, der Datenbank-Client des Dienstleisters, die Integrationsschicht.

In der Praxis führt das zu einem Muster, das man in fast jedem gewachsenen System findet: Die Rechtelogik existiert nicht einmal, sondern drei- oder viermal – in der Oberfläche, in der API, im Reporting, im Export – und diese Kopien driften auseinander. Der Datenschutzvorfall entsteht dann selten durch einen Angriff, sondern durch eine Auswertung, die jemand über den Report-Baukasten zusammengeklickt hat.

3. Beziehungen im relationalen Korsett

Sobald Fragen über mehrere Beziehungsebenen gehen – Konzernstrukturen, Organigramme, Berechtigungsvererbung, Abhängigkeitsketten – wird SQL mit rekursiven Joins unhandlich. Die übliche Antwort: eine Graph-Datenbank danebenstellen und synchronisieren.

Damit hat man zwei Datenbanken, zwei Wahrheiten, einen Sync-Prozess, der nachts auch mal fehlschlägt, und ein Wiederherstellungskonzept, das plötzlich zwei Systeme konsistent halten muss. Und die Frage, welches der beiden Systeme im Audit als führend gilt.

4. Die Konfiguration selbst ist geschichtslos

Das ist der Punkt, der am seltensten diskutiert wird und im dritten Jahr am meisten weh tut.

Ihre Geschäftsdaten sind vielleicht protokolliert. Ihre Konfiguration ist es nicht: das Formular, aus dem jemand ein Pflichtfeld entfernt hat, die Prozessdefinition, in der eine Freigabestufe verschwunden ist, die Auswertung, deren Filter sich still geändert hat. Diese Dinge liegen in einem proprietären Repository, im besten Fall versioniert über Deployment-Pakete – aber nicht so, dass sie gemeinsam mit den Daten zu einem Stichtag abfragbar wären.

Die Folge: Sie können vielleicht zeigen, welcher Wert im Feld stand. Aber nicht, welche Regeln damals galten, als er hineingeschrieben wurde. Für einen Auditor ist genau das die interessantere Hälfte der Frage.

Die Gegenthese: Die schwierigen Dinge gehören in den Kern

Yoonite ist metamodellgetrieben aufgebaut – und das ist kein Marketing-Adjektiv, sondern der Grund, warum sich die folgenden Eigenschaften zentral umsetzen lassen statt in jeder Anwendung neu.

Graph-Abfragen direkt auf PostgreSQL. Beziehungsfragen werden in Cypher formuliert. Yoonite übersetzt sie zur Laufzeit in SQL und führt sie auf derselben PostgreSQL-Datenbank aus wie alles andere:

MATCH ( eventBooking :EventBooking )
      -[ :belongsTo ]->
      ( event :Event )
RETURN event.itemId, event.itemName




Keine zweite Datenbank, kein ETL-Abgleich, keine Eventual Consistency zwischen Graph und Relation. Ein Commit, eine Wahrheit.

Zeitreise als Grundfunktion. Jede Tabelle hat einen Historien-Zwilling mit VALID_FROM und VALID_TO. Eine Sitzung wird mit einem Zeitstempel eröffnet – und ab da liefert die Datenbank den Datenstand von damals: dieselben Formulare, dieselben Auswertungen, derselbe Graph, nur zum Stichtag. Der Auditor bekommt keine Rekonstruktion aus Protokollzeilen, sondern das System, wie es war.

Historisierung, die man nicht vergessen kann. Jedes INSERT, UPDATE und DELETE schreibt seinen Historieneintrag per Datenbank-Trigger – automatisch, ausnahmslos. Ersteller, Bearbeiter, Prüfer und die jeweiligen Zeitstempel hängen als Spalten an jedem Datensatz. Kein Entwickler kann die Revisionssicherheit versehentlich aushebeln, weil sie nicht in dem Code lebt, den er schreibt.

Rechteprüfung in Triggern und Views. Die Berechtigungslogik sitzt unter der Anwendung, nicht in ihr. Wer kein Recht hat, bekommt die Zeile nicht – nicht über die Oberfläche, nicht über die API, nicht über ein Reporting-Tool, nicht über eine SQL-Konsole. Granular je Gruppe bis auf Item-Typ, einzelne Eigenschaft, einzelne Beziehung, Eigenschaft einer Beziehung und einzelne Objektinstanz, mit den Stufen Lesen, Ändern, Anlegen und Löschen. Die Regel existiert einmal statt viermal.

Die Konfiguration erbt all das. Der Application Designer ist selbst eine Yoonite-Anwendung. Formulare, Menüs, Auswertungen und Prozesse liegen als ganz normale Daten im Konfigurationsschema – und sind damit historisiert, rechtegeprüft, transaktionssicher und zeitreisefähig, mit demselben Mechanismus wie Ihre Geschäftsdaten. Das Zurücknehmen einer Formularänderung ist keine Migration, sondern eine Zeitreise.

KI mit Rechteschranke. Fragen in natürlicher Sprache werden zu Cypher, das Cypher zu SQL. Entscheidend ist der Weg: Die generierte Abfrage läuft durch dieselben rechte-gefilterten Views wie jede andere. Ein Sprachmodell kann in Yoonite strukturell nichts zutage fördern, was der fragende Mensch nicht ohnehin sehen dürfte. Den Anbieter wählen Sie frei – jede OpenAI-kompatible Schnittstelle, auch ein eigenes Modell im Haus.

Der gemeinsame Nenner: Nichts davon ist nachrüstbar. Entweder es sitzt im Fundament, oder es ist später ein Umbauprojekt.

Was das kostet – ehrlich gesagt

Diese Architektur hat einen Preis, und es wäre unseriös, ihn zu verschweigen.

Yoonite ist nicht die Plattform, mit der ein Marketing-Team am Freitagnachmittag eine Landing Page oder ein kleines Kampagnen-Tool zusammenklickt. Für solche Anwendungsfälle sind die schnellen Baukästen die bessere Wahl, und wir sagen das auch in Vorgesprächen.

Yoonite lohnt sich dort, wo Daten Konsequenzen haben: wo geprüft wird, wo Aufbewahrungsfristen gelten, wo eine falsche Berechtigung ein meldepflichtiger Vorfall ist. Unsere Referenzen kommen entsprechend aus genau diesen Bereichen – Mercedes-Benz auf der Konzernseite, die Caritas auf der Seite der Non-Profit-Organisationen, die mit hochsensiblen Personendaten arbeiten. Zwei Organisationen, die kaum unterschiedlicher sein könnten und trotzdem dieselbe Anforderung stellen: nachweisen können, wer wann was gesehen und geändert hat.

Die Plattform selbst ansehen

Wir haben eine kostenlose SaaS-Version von Yoonite bereitgestellt: die Kernplattform mit Metamodell-Editor, den grafischen Designern und den Basisfunktionen. Sie ist dafür gedacht, dass Sie die Architektur nicht glauben müssen, sondern anschauen können – wie ein Metamodell entsteht, wie Historisierung ohne Zusatzkonfiguration auf Ihren Rohdaten greift, wie eine Cypher-Abfrage auf Ihren eigenen Daten aussieht.

Eine Einschränkung dabei: Die Zeitfunktionen sind in der kostenlosen SaaS-Umgebung nur auf Rohdaten aktiviert. Zeitreise über die gesamte Designer-Suite hinweg – also inklusive der Konfigurationsobjekte selbst (Formulare, Prozesse, Auswertungen) – ist in der kostenlosen Version deaktiviert.

Was in der kostenlosen Version bewusst nicht enthalten ist, sind unsere 26 fertigen Fachmodule – von CRM über Facility Management bis zur CMDB. Die sind Teil eines Implementierungsprojekts, weil sie ohnehin auf Ihre Domäne angepasst werden. Wenn Sie beim Testen an diesem Punkt ankommen, melden wir uns für ein Gespräch. Genau dafür ist der Zugang da.

Andere Low-Code-Plattformen lassen Sie schnell etwas bauen. Yoonite lässt Sie etwas bauen, das in zehn Jahren noch beweisen kann, wer wann was geändert hat – und wie die Welt damals aussah.