Der Begriff, der diese Kategorie beschreibt, lautet Low-Code: eine Entwicklungsart, bei der visuelle Modellierung im Vordergrund steht und Programmcode nur noch punktuell für Sonderfälle ergänzt wird. Mendix zählt neben wenigen anderen Anbietern zu den Pionieren und Marktführern dieser Kategorie im Enterprise-Umfeld. Gegründet 2005 in Rotterdam, gehört das Unternehmen seit 2018 zu Siemens und ist damit Teil eines der größten Technologiekonzerne der Welt. Diese Konzernzugehörigkeit prägt die Positionierung stark: Mendix ist heute eng mit den Industrie-, SAP- und Automatisierungswelten von Siemens verzahnt.
Der entscheidende Unterschied zu reinen Workflow- oder No-Code-Automatisierungswerkzeugen ist der Anspruch: Mendix baut keine Verbindung zwischen fertigen Apps, sondern erzeugt neue, vollwertige Anwendungen. Wo ein Automatisierungswerkzeug zwei bestehende Systeme miteinander verknüpft, entsteht mit Mendix eine eigene Software mit eigener Datenhaltung, eigener Oberfläche und eigener Geschäftslogik. Das macht die Plattform mächtiger, aber auch anspruchsvoller in Einführung und Betrieb.
Aus unserer Projektpraxis lässt sich die Zielgruppe klar umreißen. Mendix lohnt sich für Unternehmen, die individuelle Fachanwendungen benötigen, für die es keine passende Standardsoftware gibt – etwa spezialisierte Verwaltungs-, Antrags-, Planungs- oder Prüfprozesse, die den Wettbewerbsvorteil ausmachen und deshalb nicht in ein generisches Produkt gezwängt werden sollen. Typische Anwender sind größere Mittelständler und Konzerne mit einer IT-Abteilung, die die Plattform verantwortet, sowie Fachbereiche, die eng mitwirken.
Weniger geeignet ist Mendix für sehr kleine Organisationen, die lediglich zwei Cloud-Tools miteinander verbinden wollen – dafür sind reine Automatisierungswerkzeuge schneller und günstiger. Auch wenn eine Aufgabe durch eine bewährte Standardsoftware vollständig abgedeckt wird, ist der Bau einer Eigenlösung selten sinnvoll. Die Kunst liegt darin, ehrlich zu unterscheiden, wo Individualität echten Wert schafft und wo sie nur Aufwand erzeugt. Diese Abgrenzung ziehen wir in jedem Projekt bewusst.
Der Aufstieg von Low-Code hat einen nüchternen Hintergrund: In vielen Unternehmen übersteigt der Bedarf an digitalen Lösungen die verfügbare Entwicklungskapazität bei Weitem. Fachbereiche warten oft Monate auf Anwendungen, die eigentlich dringend gebraucht werden, während die IT unter einer langen Liste von Projekten steht. Low-Code-Plattformen wie Mendix versprechen, diesen Rückstau aufzulösen, indem sie Entwicklung beschleunigen und einen Teil der Arbeit für fachnahe Kräfte zugänglich machen.
Gleichzeitig ist es wichtig, dieses Versprechen realistisch einzuordnen. Low-Code beschleunigt die Entwicklung, ersetzt aber nicht das Nachdenken über Architektur, Datenqualität, Sicherheit und Wartbarkeit. Eine schlecht durchdachte Anwendung wird auch mit Low-Code nicht gut – nur schneller gebaut. Genau deshalb betrachten wir Mendix als leistungsfähiges Werkzeug, das seinen Wert erst in Verbindung mit einer klaren fachlichen und technischen Führung entfaltet.
Die Produktfamilie folgt einem gestaffelten Modell: von einem kostenlosen Einstieg zum Ausprobieren und Lernen über kostenpflichtige Stufen für produktive Anwendungen bis hin zu umfassenden Enterprise-Paketen mit erweiterten Betriebs-, Sicherheits- und Governance-Funktionen. Grob lassen sich vier Ebenen unterscheiden, die je nach Marktkommunikation unterschiedlich benannt werden.
Seit der Übernahme durch Siemens im Jahr 2018 ist Mendix Teil der Digital-Industries-Strategie des Konzerns. Für Interessenten hat das mehrere praktische Konsequenzen. Erstens verleiht der Konzern der Plattform eine hohe wirtschaftliche und strategische Stabilität – ein Argument, das gerade bei geschäftskritischen Anwendungen zählt, deren Lebensdauer über viele Jahre geplant wird. Zweitens entsteht eine besondere Nähe zu industriellen Themen: Mendix wird häufig im Zusammenspiel mit Fertigungs-, IoT- und Automatisierungslandschaften positioniert, die im Siemens-Umfeld eine große Rolle spielen.
Drittens ist die enge Verbindung zur SAP-Welt bemerkenswert. Mendix wird regelmäßig als Weg beworben, um individuelle Erweiterungen und Oberflächen rund um SAP-Kernsysteme zu bauen, ohne das Standardsystem selbst zu verändern. Für Unternehmen mit gewachsener SAP-Landschaft kann das ein gewichtiger Grund sein, Mendix in die engere Wahl zu nehmen. Wir empfehlen jedoch, diese Nähe nicht als Selbstzweck zu sehen: Sie zahlt sich vor allem dann aus, wenn tatsächlich enge Kopplung an diese Ökosysteme gefragt ist.
Die Wahl der Edition folgt selten dem Bauchgefühl, sondern dem konkreten Vorhaben. Für einen Machbarkeitsnachweis genügt regelmäßig die Free-Edition; niemand sollte für eine reine Lern- oder Prototyp-Phase zahlen. Sobald eine Anwendung produktiv gehen und echte Nutzer bedienen soll, wird eine der kostenpflichtigen Stufen nötig – welche genau, hängt von Nutzerzahl, Anzahl der Anwendungen, Betriebsanforderungen und dem gewünschten Support-Niveau ab. Wir raten dazu, die Edition erst festzulegen, wenn die ersten belastbaren Anforderungen an Betrieb und Skalierung feststehen, und die Konditionen zu diesem Zeitpunkt direkt beim Anbieter zu verhandeln.
Mendix stellt seine Entwicklungsumgebung in zwei Ausprägungen bereit, die auf unterschiedliche Zielgruppen zugeschnitten sind. Das browserbasierte Studio ist bewusst einfach gehalten und richtet sich an fachnahe Anwender, die schnell und ohne tiefes technisches Wissen an einer Anwendung mitarbeiten wollen. Das Studio Pro ist die vollwertige Entwicklungsumgebung für professionelle Entwickler und bietet den kompletten Funktionsumfang, einschließlich der Möglichkeit, eigenen Code zu integrieren, wo die visuelle Modellierung an Grenzen stößt.
Entscheidend ist, dass beide Zugänge auf demselben zugrunde liegenden Modell arbeiten. Das ermöglicht die viel beworbene Zusammenarbeit von Fach und IT: Fachnahe Kräfte können Oberflächen und einfache Abläufe beisteuern, während Entwickler die anspruchsvollen Teile – komplexe Logik, Integrationen, Sicherheit – verantworten. In der Praxis funktioniert diese Arbeitsteilung dann gut, wenn klare Regeln bestehen, wer welchen Teil der Anwendung bearbeiten darf. Ohne diese Governance kann die vermeintliche Freiheit schnell zu unübersichtlichen Modellen führen.
Der typische Aufbau einer Mendix-Anwendung beginnt beim Datenmodell. Es beschreibt, welche Informationen die Anwendung verwaltet und wie sie zusammenhängen – etwa Kunden, Aufträge und Positionen mit ihren Beziehungen. Auf diesem Fundament entstehen die Seiten, die die Daten anzeigen und bearbeitbar machen, sowie die Microflows, die die Geschäftslogik dahinter ausführen. Für mehrstufige Abläufe mit menschlicher Beteiligung kommt der Workflow-Editor hinzu, der Zuständigkeiten, Freigaben und den Status eines Vorgangs abbildet.
Der große Vorteil dieses modellgetriebenen Ansatzes ist, dass viele technische Details automatisch entstehen: Die Datenhaltung, das Zusammenspiel von Oberfläche und Logik sowie das Deployment werden von der Plattform übernommen. Das reduziert Fehlerquellen und beschleunigt die Entwicklung erheblich. Der Preis dafür ist eine gewisse Bindung an die Denkweise und die Konzepte der Plattform – ein Punkt, den wir bei der Werkzeugwahl offen ansprechen.
Mendix bündelt seine KI-Fähigkeiten für die Entwicklung unter der Bezeichnung Maia, dem KI-Assistenten der Plattform. Daneben lässt sich KI auch in die gebauten Anwendungen selbst integrieren, damit diese ihrerseits intelligente Funktionen anbieten. Wir betrachten beide Bereiche getrennt, weil sich Nutzen und Risiken deutlich unterscheiden.
Der praxisnaheste KI-Einsatz betrifft die Entwicklung selbst. Ein KI-Assistent wie Maia unterstützt die Beteiligten dabei, schneller und mit weniger Fehlern zu modellieren: Er kann Vorschläge für den nächsten Schritt machen, wiederkehrende Muster automatisieren, bei der Erstellung von Logik oder Oberflächen assistieren und dabei helfen, Fehler frühzeitig zu erkennen. Der Reiz liegt darin, dass die ohnehin schon beschleunigte Low-Code-Entwicklung durch KI-Assistenz noch einmal produktiver wird – gerade für weniger erfahrene Anwender kann das die Einstiegshürde senken.
Aus unserer Sicht ist dieser Einsatz sinnvoll, solange er als Assistenz verstanden wird und nicht als Ersatz für fachliches Urteilsvermögen. Vorschläge einer KI müssen geprüft werden, bevor sie in eine geschäftskritische Anwendung übernommen werden. Wir erleben in Projekten den größten Nutzen dort, wo KI-Assistenz erfahrene Kräfte von Routinearbeit entlastet, nicht dort, wo sie unerfahrene Anwender zu unkritischer Übernahme von Vorschlägen verleitet.
Die zweite Ebene betrifft KI, die in die entstehenden Anwendungen eingebaut wird. Mendix ermöglicht es, KI-Dienste anzubinden, damit eine Fachanwendung selbst intelligente Aufgaben übernimmt – etwa Texte klassifizieren, Freitext auswerten, Vorhersagen treffen oder dialogbasierte Assistenten bereitstellen. Damit verschiebt sich KI vom Werkzeug des Entwicklers zur Funktion für den Endnutzer der Anwendung.
Für diesen Einsatz gilt aus unserer Sicht dieselbe Nüchternheit wie bei jeder anderen Plattform: KI ist kein Selbstzweck. Sie entfaltet ihren Wert dort, wo eine Aufgabe Sprach- oder Kontextverständnis erfordert, das mit festen Regeln nicht abbildbar wäre. Für rein strukturierte Verarbeitung ist eine klassische, deterministische Logik zuverlässiger, günstiger und einfacher zu testen. Diese Unterscheidung treffen wir bei jedem geplanten KI-Einsatz bewusst.
In der Praxis empfehlen wir zwei Prüffragen, bevor KI in eine Mendix-Anwendung einzieht. Erstens: Erfordert die Aufgabe wirklich Verständnis, oder genügt eine klar definierte Regel? Zweitens: Ist das Ergebnis toleranzfähig – also fängt der Prozess einen gelegentlichen Fehler des Modells auf, oder wäre er unmittelbar geschäftsschädigend? Erst wenn beide Fragen für einen KI-Einsatz sprechen, ist er verantwortbar.
Hinzu kommt eine datenschutzrechtliche Dimension, die wir gesondert in Kapitel 09 behandeln: Sobald eine Anwendung Daten an ein externes KI-Modell übermittelt, muss geklärt werden, welche Daten dies betrifft und wie sie beim Anbieter behandelt werden. Wir empfehlen, KI gezielt für klar umrissene Aufgaben einzusetzen und niemals sensible Daten ungeprüft an ein Modell weiterzugeben – unabhängig davon, wie bequem die Integration technisch auch sein mag.
Der Grundgedanke: Eine mit Mendix gebaute Anwendung soll Daten aus bestehenden Systemen lesen und schreiben können, Dienste anderer Anwendungen nutzen und selbst Schnittstellen anbieten. Dafür bringt die Plattform mehrere Wege mit, die sich je nach Anforderung kombinieren lassen.
Das Rückgrat jeder Integration sind offene Schnittstellen. Mendix kann als Konsument fremder APIs auftreten, also Daten und Funktionen anderer Systeme nutzen, und zugleich selbst APIs bereitstellen, damit andere Anwendungen auf die Mendix-App zugreifen können. Über gängige Web-Service-Standards lassen sich nahezu beliebige Systeme anbinden, sofern sie eine offene Schnittstelle besitzen. Das ist die universelle Grundlage, die auch dann trägt, wenn kein fertiger Konnektor existiert.
Für häufige Anbindungen stellt Mendix vorgefertigte Konnektoren bereit, die den Integrationsaufwand deutlich senken. Diese und viele weitere Bausteine – Widgets, Module, Vorlagen – finden sich im Mendix Marketplace, einem zentralen Katalog wiederverwendbarer Komponenten. Statt jede Funktion neu zu bauen, können Teams auf bestehende Bausteine zurückgreifen, sie anpassen und in die eigene Anwendung einbinden. Das beschleunigt die Entwicklung und ist ein wesentlicher Teil des Wertversprechens der Plattform.
Ein Hinweis aus der Praxis: Bausteine aus einem Marktplatz unterscheiden sich in Qualität, Pflegezustand und Support. Manche werden vom Anbieter selbst gepflegt, andere stammen aus der Community. Vor dem produktiven Einsatz sollte geprüft werden, wer einen Baustein verantwortet und wie zuverlässig er gewartet wird – ein ungepflegter Baustein kann später zum Risiko werden.
Ein Alleinstellungsmerkmal von Mendix ist die enge Verzahnung mit dem SAP- und Siemens-Ökosystem. Durch die Konzernzugehörigkeit zu Siemens und die strategische Partnerschaft mit SAP positioniert sich Mendix als bevorzugter Weg, um individuelle Erweiterungen rund um diese großen Standardsysteme zu bauen. Für Unternehmen mit gewachsener SAP-Landschaft bedeutet das: Anwendungen, die auf SAP-Daten aufsetzen oder Prozesse rund um SAP ergänzen, lassen sich mit besonders guter Unterstützung realisieren. Im industriellen Umfeld kommt die Nähe zu Siemens-Themen wie Fertigung, IoT und Automatisierung hinzu.
Diese Ökosystem-Nähe ist ein echter Vorteil – aber nur für Unternehmen, die tatsächlich in diesen Welten zu Hause sind. Wer weder SAP noch industrielle Siemens-Systeme im Einsatz hat, sollte diesen Punkt nicht überbewerten. Für eine reine Web-Fachanwendung ohne Bezug zu diesen Ökosystemen zählen andere Kriterien stärker. Wir bewerten diese Nähe in Projekten daher immer im Licht der tatsächlichen Systemlandschaft des Kunden.
Mendix spielt seine Stärken aus, wenn individuelle, geschäftskritische Anwendungen mit Enterprise-Qualität gefragt sind und wenn die Zusammenarbeit von Fachbereich und IT eine große Rolle spielt. Besonders überzeugend ist die Plattform für Unternehmen im SAP- oder Siemens-Umfeld, die Erweiterungen rund um diese Systeme bauen wollen, sowie für Organisationen, die Wert auf flexible Betriebsmodelle bis hin zum Betrieb in der eigenen Infrastruktur legen. Auch die Stabilität durch die Konzernzugehörigkeit ist ein Argument für Anwendungen mit langer geplanter Lebensdauer.
OutSystems ist der direkteste Wettbewerber und verfolgt eine sehr ähnliche Enterprise-Low-Code-Philosophie. In der Praxis wird die Wahl zwischen beiden oft weniger durch harte technische Unterschiede entschieden als durch die vorhandene Systemlandschaft, bestehende Partnerbeziehungen, das gewünschte Betriebsmodell und die konkreten Konditionen. Wo Mendix durch die Siemens- und SAP-Nähe punktet, positioniert sich OutSystems eher herstellerneutral. Microsoft Power Platform ist die naheliegende Wahl für Organisationen, deren Welt ohnehin stark um Microsoft 365 herum gebaut ist und die vor allem schnelle, fachnahe Business-Apps mit niedriger Einstiegshürde suchen – für hochindividuelle, komplexe Enterprise-Anwendungen sind die spezialisierten Low-Code-Plattformen jedoch tiefer.
In unseren Projekten formulieren wir die Faustregel gern so: Mendix und OutSystems für individuelle Enterprise-Anwendungen mit hoher Tiefe, Power Platform für schnelle Business-Apps in der Microsoft-Welt. Die Nähe zu SAP und Siemens ist der Faktor, der bei Mendix am häufigsten den Ausschlag gibt. Nicht selten ist die beste Lösung eine bewusste Kombination: eine spezialisierte Low-Code-Plattform für die geschäftskritischen Kernanwendungen und leichtere Werkzeuge für kleine Fachlösungen.
Mendix trennt bewusst zwischen der Entwicklung, die in der modellgetriebenen Umgebung stattfindet, und dem Betrieb der fertigen Anwendung. Für den Betrieb stehen unterschiedliche Modelle zur Verfügung, die sich in Kontrolle, Aufwand und Souveränität unterscheiden.
Aus unserer Projektpraxis folgt eine erfolgreiche Mendix-Einführung meist einem klaren Muster. Sie beginnt nicht mit der Plattform, sondern mit der Frage, welche Anwendung überhaupt gebaut werden soll und ob eine Eigenlösung wirtschaftlich sinnvoll ist. Erst danach folgen die Modellierung, der iterative Aufbau und schließlich der Betrieb.
Die Wahl zwischen Cloud, Private Cloud und On-Premises ist keine reine Technikfrage, sondern hat direkte Auswirkungen auf Datenschutz, Kosten und Betriebsaufwand. Wer aus Souveränitätsgründen auf On-Premises setzen muss, sollte das früh wissen, weil es Architektur und Betriebsplanung prägt. Umgekehrt ist die Cloud der bequemste Weg, wenn keine besonderen Souveränitätsanforderungen bestehen. Wir empfehlen, dieses Thema gemeinsam mit den Verantwortlichen für Datenschutz und IT-Betrieb zu Beginn zu klären und nicht auf einen späteren Zeitpunkt zu verschieben.
Auffällig ist ein Muster: Mendix glänzt dort, wo Individualität einen echten Wert schafft und wo eine Anwendung Enterprise-Qualität braucht – mit sauberer Datenhaltung, Rechten, Nachvollziehbarkeit und langfristiger Wartbarkeit. Der Nutzen entsteht nicht durch die Automatisierung einzelner Handgriffe, sondern durch die Ablösung ganzer Prozess- oder Systemlücken, für die es keine passende Standardlösung gibt. Genau hier rechtfertigt sich der Aufwand einer Low-Code-Plattform.
Wichtig für die Erwartungshaltung: Der Nutzen realisiert sich nur, wenn die fachlichen Anforderungen vorher sauber durchdacht sind. Eine schlecht definierte Anwendung wird durch Low-Code nicht besser – nur schneller gebaut. Deshalb steht in unseren Projekten die fachliche Klärung immer vor dem ersten Modell. Und ebenso ehrlich sagen wir, wenn eine Standardsoftware die bessere Antwort wäre: Nicht jedes Problem verdient eine Eigenentwicklung.
Gerade im Mittelstand ist die wichtigste Frage nicht, ob Mendix gut ist, sondern ob es zur konkreten Aufgabe passt. Eine Enterprise-Low-Code-Plattform bringt Governance, Betriebsaufwand und Lizenzkosten mit sich, die sich erst ab einer gewissen Anwendungsgröße und -bedeutung lohnen. Für ein kleines Unternehmen, das lediglich zwei Cloud-Tools verbinden will, ist ein reines Automatisierungswerkzeug die passendere und günstigere Antwort. Für ein Unternehmen dagegen, das eine geschäftskritische Individualanwendung mit langer Lebensdauer braucht, ist Mendix eine ernstzunehmende und tragfähige Wahl. Diese Unterscheidung treffen wir gemeinsam mit dem Kunden, bevor überhaupt über die Plattform gesprochen wird.
Konkrete Preise nennen wir hier bewusst nicht, weil Mendix seine Editionen, Kontingente und Konditionen regelmäßig anpasst und jede genannte Zahl schnell veralten würde. Entscheidend ist das Verständnis der Kostenlogik: Zu den Lizenzkosten der gewählten Edition kommen Betriebskosten der Infrastruktur sowie – oft unterschätzt – der interne Aufwand für Entwicklung, Governance und laufende Pflege. Eine Individualanwendung ist ein Produkt mit Lebenszyklus, nicht ein einmaliger Posten. Die tatsächlichen Konditionen sollten stets direkt beim Anbieter geprüft und verhandelt werden.
Datenschutzrechtlich ist der zentrale Hebel bei Mendix das Betriebsmodell. Anders als bei einem reinen SaaS-Automatisierungsdienst, bei dem Daten zwangsläufig durch die Cloud eines Anbieters fließen, hat ein Unternehmen bei Mendix die Wahl, wo seine Anwendung und deren Daten liegen. Genau diese Wahlfreiheit ist aus Souveränitätssicht der wichtigste Vorteil der Plattform.
Für Unternehmen mit hohen Anforderungen an Datenhoheit ist die Flexibilität der Betriebsmodelle das entscheidende Argument. Wer die Cloud nutzen möchte, sollte darauf achten, eine EU-Region zu wählen, um die Daten innerhalb des europäischen Rechtsraums zu halten – das ist regelmäßig die datenschutzrechtlich einfachere Konstellation. Wer noch strengere Anforderungen hat, etwa bei besonders schützenswerten Daten oder aus Compliance-Gründen, kann mit der Private Cloud oder dem Betrieb On-Premises sicherstellen, dass die Daten die eigene oder eine kontrollierte Infrastruktur nicht verlassen.
Diese Optionen unterscheiden Mendix positiv von reinen SaaS-Diensten, bei denen ein Selbst-Hosting gar nicht vorgesehen ist. Der Preis dafür ist Betriebsaufwand: On-Premises verlagert die Verantwortung für Verfügbarkeit, Sicherheit und Wartung vollständig auf das Unternehmen. Die Entscheidung ist letztlich eine bewusste Abwägung zwischen Bequemlichkeit und Kontrolle – und sollte gemeinsam mit den Verantwortlichen für Datenschutz und IT-Betrieb getroffen werden.
Ein Wort zur Anbieterstruktur: Mendix hat seine Wurzeln in den Niederlanden, gehört aber als Teil von Siemens zu einem global tätigen Konzern mit starker Präsenz in Deutschland und Europa. Für die datenschutzrechtliche Bewertung ist weniger die Herkunft des Anbieters entscheidend als vielmehr, wo die Anwendung konkret betrieben wird und welche vertraglichen Grundlagen bestehen. Genau deshalb ist die bewusste Wahl des Betriebsmodells und des Serverstandorts der Kern jeder seriösen Datenschutzbetrachtung bei Mendix – und der Punkt, an dem wir in Projekten am genauesten hinschauen.
