The EU battery passport: How PLM and MES get you ready for February 2027

Four months. That is all that is left before the EU's first mandatory digital product passport goes live. From 18 February 2027, every EV battery, light means of transport (LMT) battery and industrial battery above 2 kWh placed on the EU market needs a digital battery passport. No passport, no market access.

This is not just an automotive problem. Grid-scale, C&I and most home storage systems count as industrial batteries, and that market is booming. SolarPower Europe's European Battery Market Outlook 2026–2030 reports 36 GWh of new storage installed in Europe in 2025, up 48%, taking total capacity past 100 GWh. Annual installations are expected to exceed 50 GWh in 2026 and reach 138 GWh by 2030.

The question for manufacturers, pack assemblers and storage integrators is no longer whether to prepare, but whether your product and production data can deliver what the passport demands. That is where PLM and MES come in.
‍

What the EU battery passport actually requires

The passport is created by Article 77 of the EU Batteries Regulation (EU) 2023/1542, with its content defined in Annex XIII. It is an electronic record per individual battery, reached through a QR code on the product and linked to a unique identifier.

Three categories are in scope from 18 February 2027:

• Electric vehicle batteries, regardless of capacity.
• Light means of transport (LMT) batteries, such as e-bike batteries.
• Industrial batteries above 2 kWh, including stationary storage for the grid, C&I sites and most homes.

The Battery Pass consortium translated the regulation into a data attribute longlist of roughly 90 mandatory data points, now formalized in DIN DKE SPEC 99100. They span product information, material composition, carbon footprint, recycled content, due diligence, performance and durability, circularity and dynamic state-of-health data. Access is tiered between the public, parties with a legitimate interest such as recyclers, and authorities.
‍

What the Commission clarified in 2026

• The registry is live. The EU Digital Product Passport Registry opened on 20 July 2026. Operators verify themselves with a qualified electronic seal and register each passport's identifier.
• Whoever finishes the battery owns the passport.The Commission's battery passport FAQ (September 2026) places responsibility with the operator that completes the working battery, usually where the BMS is fitted. Suppliers can enter data on its behalf, but legal responsibility stays with the operator.
• Second life means a new passport. A repurposed battery, such as an EV battery turned into stationary storage, needs a new passport linked to the old one.
• The date is not moving. The Environmental Omnibus (Omnibus VIII) amends parts of the regulation, but not the passport deadline. EUROBAT and RECHARGE are lobbying for a phased rollout; that is a position, not law.
  ‍

What is still open

The implementing act on who may access restricted data missed its 18 August 2026 deadline; Taylor Wessing expects adoption in Q4 2026. Carbon footprint and recycled content follow their own timelines, and due diligence reporting starts in August 2027. In short: the deadline is fixed, the rulebook is not, so your data architecture must absorb changes without a rebuild.
‍

A data problem, not a QR-code problem

It is tempting to treat the passport as a labelling exercise: generate a QR code, host a page, done. But the QR code is the easy part. The hard part is the data behind it, which lives in many places:

The pattern is clear: the designed product lives in PLM, the produced product lives in MES. The passport needs both, per battery, consistent and up to date across a life that can span a decade or more.

The companies that will struggle in February are not those without a passport platform. They are those with product data in spreadsheets, as-built records that cannot be traced to a design revision, and no clear view of which cell lot went into which pack.
‍

PLM: The product backbone of the passport

A battery passport is a structured description of a product, and your Product Lifecycle Management (PLM) platform already owns that description. With PLM for manufacturing on Siemens Teamcenter or Teamcenter X, PLM delivers four things the passport needs.

1. One trusted source for the as-designed battery
   Chemistry, capacity, weight, cell format and pack structure are all defined in the engineering BOM. Pulling passport data from PLM instead of spreadsheets gives every field an owner, a release status and a revision: data you can defend to a market surveillance authority.
2. Material compliance built into design
   Capturing supplier material declarations against parts in PLM means hazardous substances and critical raw materials are checked while the design is still changeable, not after the first production run. The same structure supports recycled content reporting later.
3. Carbon footprint as a design parameter
   The carbon footprint is declared per model and plant, and future rules foresee performance classes and maximum thresholds. That makes CO₂e a design constraint, just like cost and weight. Teamcenter Product Cost Management lets engineers compare the cost and carbon footprint of alternatives early, as we explored in AI in product cost management and sustainability.
4. Change management that keeps the passport up to date
   A new cell supplier, a firmware update or a different cathode blend can all change passport data. Formal change management in PLM ensures every relevant change triggers a passport update, with a full history of who changed what and why, including the dismantling and spare part information recyclers need.
   ‍

MES: The production evidence behind every passport

PLM describes the battery you designed. But a passport is issued for each individual battery, and only the shopfloor knows what went into it. That is the job of your MES, part of a Manufacturing Operations Management (MOM) landscape built on solutions such as Siemens Opcenter.

1. A unique identity per battery
   Every passport needs an ISO/IEC 15459-compliant identifier linked to the QR code. MES assigns it when the battery is completed and ties it to the work order and the date and place of manufacture.
2. Full genealogy from cell to pack
   Because the passport sits with whoever finishes the battery, pack assemblers and storage integrators inherit the data work for components they did not make. A complete as-built genealogy connects supplier data on incoming cells to the finished product, and answers a recall or an authority's question in hours, not weeks.
3. Test results as performance data
   Capacity, internal resistance, power and round-trip efficiency are measured at end-of-line testing. Captured in MES, they become passport performance data and the baseline for later state-of-health reporting.
4. Plant-level data for the carbon footprint
   The footprint is declared per manufacturing plant. Energy use, scrap and yield from MES, combined with IoT data from Siemens Insights Hub, turn estimates into measured figures.
   ‍

The real value: Closing the loop

Released designs flow from PLM to the shop floor; as-built data, deviations and test results flow back. When a battery deviates from its released design, its passport reflects it. That digital thread from as-designed to as-built is exactly what the regulation asks you to prove.
‍

From compliance to the agentic enterprise

PLM and MES give you the data, but a passport is a living record: created at production, updated on change, extended on repurposing, closed at recycling. Across thousands of batteries, dozens of suppliers and an evolving rulebook, manual processes will not keep up.

This cross-system, rule-heavy, auditable work is what the agentic enterprise is built for: humans and AI agents working side by side on trusted data, inside governed processes. Enter Siemens Intelligence Center X (ICX), announced at Realize LIVE 2026 and built on Mendix. As our colleague Gerrit Kiefer explained in Make processes intelligent, ICX combines four capabilities on one governed foundation. Here is how they map onto the passport.
‍

Knowledge graph: One connected view of every battery

Graph Studio connects the design revision in Teamcenter, the genealogy in Opcenter, supplier declarations in ERP and BMS field data through one ontology, instead of copying them into yet another database. The passport becomes a governed view on that graph, with lineage for every field.
‍

Machine learning: From records to predictions

AI Studio runs models on that contextualised data: predicting state of health from test and field data, flagging production anomalies that may affect durability claims, or identifying the best second-life candidates in a storage fleet.
‍

Agentic applications: Let agents do the legwork

With the Mendix AI platform, teams build agentic applications such as:

• A passport readiness agent that checks each model against Annex XIII and flags missing or inconsistent fields before release.
• A supplier data agent that requests, validates and chases material and carbon footprint declarations.
• A change impact agent that detects when an engineering change affects passport data and proposes updates.
• A regulatory watch agent that maps new implementing and delegated acts to your data model.
  ‍

Orchestration and trust: Humans stay accountable

Legal responsibility stays with the company placing the battery on the market, whoever enters the data. Mendix Workflows orchestrate agents and people in one traceable process: an agent prepares, a human approves, the system publishes. The ICX trust layer adds guardrails, logging and access control, so every update has an owner, a timestamp and a data lineage. That is how AI becomes a compliance asset instead of a risk, and what we call intelligent enterprise orchestration.
‍

A practical roadmap to 18 February 2027

Four months is tight but workable. We recommend this sequence:

1. Confirm scope and role (now). Which products are EV, LMT or industrial batteries above 2 kWh? For modular storage, check whether units share a BMS, since their combined capacity then counts. If you finish the battery, the passport is yours.
2. Assess data gaps (November). Map the roughly 90 attributes against PLM, MES, ERP and supplier data, with a source, owner and quality level per field.
3. Secure supplier data (November–December). Agree written authorisations, data clauses, formats and update triggers with cell, module and material suppliers.
4. Connect the digital thread (December–January). Link released PLM data with serialisation, genealogy and test data in MES. Start your EU registry verification early.
5. Pilot one product family (January). Create, publish and update a passport end to end, including an engineering change and a repurposing scenario.
6. Go live and scale with agents (February onwards). Roll out across product families and automate with governed agents, ready for due diligence reporting from August 2027 and the obligations that follow.

Meanwhile, watch the access rights act: its draft, expected around year-end, decides who can read the restricted parts of your passport.
‍

How CLEVR helps you get passport-ready

The battery passport is the EU's first mandatory digital product passport, not its last: the Ecodesign for Sustainable Products Regulation extends the same logic to many more products. A quick QR-code fix means starting over for every next regulation. Connected PLM and MES data, orchestrated by governed agents, builds a foundation for better traceability, faster recalls, smarter design and new second-life business models.

As the largest dedicated Siemens and Mendix partner in Europe, with more than 30 years of industry experience, CLEVR helps manufacturers and energy and utilities companies connect Teamcenter, Opcenter and existing systems into one digital thread, extended with agents through Intelligence Center X. We start where you are: A scope and data gap assessment, a pilot, and a roadmap to scale.

February 2027 is closer than it looks. Let's make sure your data is ready before your batteries are.

Teil 4 von 4, direkt vom Mendix Community Round Table Meetup am 2. Juni 2026 in Amersfoort. In den Teilen 1 bis 3 ging es um die Frage, welche Aufgaben für Berater bleiben, ob wir einem KI-Agenten dabei vertrauen können und ob die Plattform ihre Daseinsberechtigung noch hat. Dieser Artikel stellt die kommerzielle Frage, die all dem zugrunde liegt: Wer braucht eine solche Plattform eigentlich noch?

Ein Vertriebsmitarbeiter an einem der Tische hatte den niederländischen IT-Direktor einer erstklassigen Investmentbank angerufen, um ihn zu einer Veranstaltung einzuladen. Ein freundlicher Mann, also bekam er ein paar Minuten Zeit, die der Direktor nutzte, um zu erklären, warum die Antwort „Nein“ lautete. „Ich habe kein Problem mit Low-Code“, sagte er. „Wir machen das einfach nicht mehr. Wir erledigen jetzt alles mit KI, den gesamten Anwendungslebenszyklus.“ Und wie steuern Sie das alles? „Wir haben viertausend Ingenieure und die Ressourcen, um ganze Teams für die Überprüfung einzusetzen.“ Der Vertriebler erzählte uns hinterher, dass er dem nichts entgegenzusetzen hatte und auch nicht so tat, als ob.

Diese Antwort ließ mich den Rest des Abends nicht mehr los und schwebt seitdem über dieser Serie. Ich habe dreimal über den 2. Juni geschrieben: Was bleibt für den Berater zu tun, können wir einem Agenten dabei vertrauen und ist Mendix noch eine vertretbare Plattform dafür? Jedes Mal komme ich zu einem ähnlichen Ergebnis: Der Wert bleibt erhalten, wenn man es richtig aufbaut. Die kommerzielle Frage bleibt also bestehen. Wenn das alles stimmt, wer braucht es dann eigentlich?

‍

Das obere Marktsegment antwortete ehrlich

Die Bank war präzise, nicht abweisend. Ein Unternehmen mit viertausend Ingenieuren kann alles mit KI erledigen und ganze Teams für die Überprüfung der Ergebnisse abstellen, weil es sich das leisten kann. Diese Unternehmen haben ihre KI bereits implementiert und ihre Budgets ausgeschöpft, daher ist ihre Frage berechtigt: Warum sollten wir dafür eine Plattform hinzufügen, wenn wir bereits eine eigene aufbauen?

Der Instinkt, auf den viele von uns trainiert wurden – die größten Kunden zu jagen und das Enterprise-Geschäft an Land zu ziehen – verdient eine zweite Betrachtung. Unternehmen mit den meisten Ressourcen benötigen am wenigsten eine Plattform, die ihnen die Arbeit abnimmt, weil sie daran gewöhnt sind, den Aufwand selbst zu tragen. Zumindest, wenn sie bereits ein softwareorientiertes Unternehmen sind. Wenn nicht, bietet eine Plattform wie Mendix immer noch einen unglaublichen Vorsprung, ohne die jahrelange Arbeit, die nötig wäre, um selbst einen Plattform-Ansatz zu entwickeln. Denn ja, genau das ist nötig, um einen Stand zu erreichen, der dem nahekommt, was Plattformen wie die von Siemens bieten können.

‍

Eine Nuance, die ich selbst hinzufügen möchte

Liest man diese Antwort noch einmal, klingt es so, als hätte die KI die Tür weitgehend zugeschlagen. Ich glaube nicht, dass das der Fall ist. Hätte diese Bank jemals eine Low-Code-Plattform gekauft? Im Jahr 2019, mit denselben viertausend Ingenieuren, noch vor all dem? Fast sicher nicht, um ihren gesamten Tech-Stack zu ersetzen.

Ein paar Dinge führen dazu, dass ein Unternehmen dieser Größe seine eigene Lösung baut, und die meisten haben wenig mit KI zu tun.

• Gewohnheit und Geschichte. Eine Organisation, die seit zwanzig Jahren Software auf ihre eigene Weise entwickelt, hat einen Bestand, Standards, einen Überprüfungsprozess sowie vorhandene Ressourcen und Komponenten. Niemand reißt das alles ab, nur weil ein Anbieter mit einer besseren Geschichte auftaucht.
• Talent, das lokaler ist, als wir normalerweise zugeben. Wenn man viertausend Ingenieure einstellen kann und das dort tut, wo die Arbeitskosten stimmen, ist die Eigenentwicklung eine vertretbare Wahl. Für ein Unternehmen in den Niederlanden, das auch dort einstellt, kann diese Kalkulation völlig anders aussehen – ebenso wie die Werte und Überzeugungen, die dahinterstehen.
• Die Kosten, die sie bereits getragen haben – was die Bank nicht erwähnte. Jahre an Verfahren, internen Standards, ein Plattform-Team, eine interne Entwicklerplattform, die jemand am Laufen halten muss. Sie haben sich den Aufwand nicht erspart. Sie haben ihn sich ins Haus geholt und die Kosten über ein Jahrzehnt verteilt – eine teure Position, in die nur ein Unternehmen mit der entsprechenden Größe, Strategie und Zeit gelangen kann.

Die viertausend Ingenieure beweisen also nicht, dass das Plattform-Modell tot ist. Sie zeigen, dass ein Unternehmen, das groß genug ist und die richtige Strategie verfolgt, eine ähnliche Plattform-Erfahrung für sich selbst aufbauen kann. Diese Bank hat es getan, und es hat Jahre und echtes Geld gekostet. Das sagt wenig über Low-Code aus, aber viel darüber, wer es sich leisten kann, darauf zu verzichten.

‍

Ein sich wandelnder Markt

Ich habe nicht einmal das Gefühl, dass sich allzu viel geändert hat, mit einer wichtigen Ergänzung, auf die ich später zurückkomme. Die Chance liegt bei dem Unternehmen, das in etwa sagt: „Ich bin eine Baufirma, kein IT-Unternehmen“, und einen einzigen Anbieter möchte, der Sicherheit, Governance und Integrationen bereits abdeckt. Sie können keine internen Teams für die Überprüfung von High-Code-KI-Ergebnissen einsetzen, und das wollen sie auch gar nicht. Sie wollen sich den Aufwand abkaufen – was, wie ich letztes Mal argumentierte, das eigentliche Verkaufsargument für Low-Code ist, sobald man aufhört zu glauben, es ginge nur um die Geschwindigkeit der ersten Bereitstellung.

Eine nützliche Trennlinie durch die Mitte dieses Marktes ist in etwa die Anzahl der Anwendungen, die man betreibt. Ein Unternehmen mit einer einzigen App tendiert eher zu reinen Prompting-Tools als Vorsprung, denn warum sollte man bei einer App nicht einfach prompten und schauen, wie es läuft? Aber sobald man ein Dutzend Apps, Integrationen und Dinge hat, die miteinander kommunizieren und gemeinsam verwaltet werden müssen, braucht man etwas, das den gesamten Bestand zusammenhält. Eine Orchestrierungsplattform, die all das verwalten kann, ergibt hier auf eine Weise Sinn, wie es bei einer einzelnen App nie der Fall war. Das ist das Unternehmensprofil, in das all dies immer noch passt. Es ist zu klein, um aus domänenspezifischen Gründen aus der Plattform herausgewachsen zu sein, und zu groß, um seine eine App einfach zu prompten, ohne sich um das Gesamtbild zu kümmern. Ich nenne es die „orchestrierende Mitte“, und dort werden sich die meisten Unternehmen wiederfinden.

‍

Die Einwände

Einige Einwände tauchen jedes Mal auf, und ich möchte sie lieber beantworten, als sie einfach zu ignorieren.

Der erste ist die Wahrnehmung. In manchen Kreisen herrscht das Gefühl, dass die Entscheidung für Low-Code im Jahr 2026 die unkreative Option ist – die vernünftige und etwas langweilige Wahl, während alle anderen etwas Glänzendes mit KI machen. Diese Wahrnehmung ist nur teilweise berechtigt, wenn man die enormen KI-Investitionen von Siemens betrachtet. Die Plattform ist vielleicht nicht am Tag nach der Veröffentlichung einer neuen Version der großen Frontier-Modelle auf dem neuesten Stand der Möglichkeiten. Dennoch: Selbst seit dem Meetup im Juni (dieser Artikel wurde im September veröffentlicht) ist die KI-gestützte Entwicklung mit Mendix enorm gereift. Ich bin mir sicher, dass die Diskussion nuancierter ausfallen würde, wenn wir diese Sitzung noch einmal abhalten würden.

Der zweite Punkt ist der Lock-in-Effekt, und das ist eine berechtigte Sorge. „Es kostet die Hälfte, und danach gehört mir das geistige Eigentum“ ist etwas, das Käufer tatsächlich sagen, wenn sie eine verwaltete Plattform gegen High-Code abwägen. High-Code fühlt sich nach Freiheit an, eine verwaltete Plattform kann sich wie ein Käfig anfühlen, und KI hat, wenn überhaupt, die High-Code-Seite weniger „eingesperrt“ aussehen lassen als früher. Den Lock-in zu leugnen, hilft nicht. Klarheit darüber zu schaffen, was man dafür bekommt, hilft hingegen schon – ebenso wie Klarheit darüber, was eine Migration kosten würde. Bei einer halbwegs offenen Plattform wie Mendix sind diese Kosten niedriger, als die Leute erwarten, und mit Maia Transform ist es mittlerweile recht gut machbar, Codebasen zu und von Mendix zu migrieren. Diese Option zu haben, kann ein beruhigendes Gefühl sein, während man die Vorteile der Plattform genießt.

Der dritte Punkt ist leiser. Ein Kunde, der bereits andernorts eine ausgereifte KI-Strategie verfolgt, möchte nicht noch mehr KI an den Ressourcenpool einer weiteren Plattform anbinden. Er möchte das nutzen, worin er bereits investiert hat. Wer nur „grüne Wiese“ und „KI hier hinzufügen“ anbietet, wird immer wieder auf Käufer treffen, die sich dem Thema KI aus einer anderen Richtung genähert haben und bereits weiter sind. Dies zu respektieren, ermöglicht ein wesentlich tiefergehendes Gespräch über den tatsächlichen Bedarf – zumal Mendix es Ihnen erlaubt, „deren“ KI zu nutzen, Ihre eigene einzubringen oder beides zu einer Mischung zu kombinieren, die Ihnen zusagt.

‍

Das eigentliche Verkaufsargument

Es ist präziser als das, was zuvor kam, auch wenn es sich zunächst wie ein Rückschritt anhört.

Sie verkaufen das Ergebnis: den Anbieter, der Governance, Sicherheit und Integration bereits gelöst hat, sodass das Bauunternehmen dies nicht mehr tun muss. Für den richtigen Kunden ist „wir haben den schwierigen Teil bereits erledigt“ ein stärkeres Argument als „wir sind schneller“ – ein Versprechen, das in dem Moment hinfällig wurde, als Prompts schneller erstellt werden konnten, als wir alle es je könnten. Auch wenn es sich bei der ersten Bereitstellung meist um Prototypen und nicht um Anwendungen auf Enterprise-Niveau handelt: Wenn Sie Ihre Mendix-App am ersten Tag bereitstellen, erhalten Sie ISO 27001, 27017, 27018, 9001 und SOC 2 Typ II-Berichte sowie Unterstützung für DSGVO, HIPAA und PCI-DSS, ohne dass Sie wissen müssen, was diese im Detail beinhalten. Das ist und bleibt einer der wichtigsten Gründe, sich für Mendix als Enterprise-App-Plattform zu entscheiden.

Es gibt zudem einen Bereich, den die „Viertausend-Entwickler-Fraktion“ nicht für sich beanspruchen kann, da es hier nicht um Ressourcen, sondern um Vertrauen geht: Daten. Ein Berater an einem anderen Tisch brachte es bei einem Gespräch über einen Behördenkunden auf den Punkt: Sie haben „große Angst davor, was mit den Daten passiert“. Man führt also nicht mit der KI. Man baut zuerst Vertrauen auf, lässt die Daten in den Händen des Kunden auf einer Infrastruktur, die er kontrolliert, und lässt die KI erst an zweiter Stelle folgen. Für eine ganze Klasse von Kunden – in der Regierung, im Gesundheitswesen, überall dort, wo Daten das Haus nicht verlassen dürfen – ist genau das der Grund, warum sie überhaupt „Ja“ sagen können. Lokale LLMs finden hier schnell ihren Platz, und Mendix sowie Maia können diese ebenso gut nutzen.

Für diejenigen, die diesen Teil der Serie erreicht haben und sich fragen: Was ist mit Siemens? Da ein Großteil der niederländischen Mendix-Community Erfahrung in anderen Bereichen als der Fertigung hat, überrascht es nicht, dass dieser Aspekt an keinem Tisch zur Sprache kam. Ignorieren sollte man ihn dennoch nicht. Mit Mendix im Portfolio, einschließlich der oben genannten umfassenden (KI-)Fähigkeiten, kann ich mich nur für die Kunden freuen, die bereits stark in das Siemens-Ökosystem investiert sind.

‍

Abschluss der Serie

Die Bank mit viertausend Entwicklern war nie das Hauptwachstumsziel, und wer ihr hinterherjagt, fühlt sich am Ende nur austauschbar. Das Wachstum liegt bei all jenen unterhalb dieser Schwelle, die es nicht selbst tun können und auch nicht wollen: der „orchestrierende Mittelstand“, die regulierten Branchen, diejenigen, die einen vertrauenswürdigen Anbieter suchen, der die schwierigen Aufgaben übernimmt und ihre Daten dort lässt, wo sie hingehören.

Das waren vier Fragen aus einem Abend: Was bleibt für uns zu tun, können wir dem Agenten dabei vertrauen, rechtfertigt die Plattform weiterhin die Wahl und wer braucht sie eigentlich? Jetzt, da ich sie aufgeschrieben habe, stelle ich fest, dass es bei keiner der Antworten wirklich um die Technologie geht. Es läuft auf Urteilsvermögen, Vertrauen und das Wissen darüber hinaus, für wen man da ist. Das ist eine beruhigende Erkenntnis für einen Raum voller Berater, die sich Sorgen um die KI machten und sich nun durch ihre Gespräche eine klare Sicht erarbeitet haben.

Vielen Dank fürs Lesen, falls Sie es bis zum Ende der Serie geschafft haben. Diese Artikel spiegeln die Diskussionen im Raum wider, ergänzt durch meine eigene Meinung. Ich bin daher sehr gespannt auf Ihre Gedanken. Deckt es sich mit Ihren Erfahrungen? Sind Sie glücklich oder besorgt über die möglichen neuen Perspektiven? Wie dem auch sei, ich freue mich darauf, später in diesem oder Anfang nächsten Jahres einen weiteren Round Table zu veranstalten, um einige dieser Aussagen persönlich zu vertiefen.

‍

Ursprünglich veröffentlichthier.

Teil 3 von 4, vom Mendix Community Round Table Niederlande in Amersfoort am 2. Juni 2026. In Teil 1 und 2 ging es um die Frage, welche Aufgaben dem Berater bleiben und ob man einem Agenten dabei vertrauen kann; dieser Teil befasst sich mit der Plattform, die beidem zugrunde liegt.

Jemand am Tisch brachte das Argument für Mendix auf den Punkt: Man kauft sich von einer Menge Ärger frei. Eine verwaltete Cloud, ein validierter Stack, Sicherheit inklusive, Siemens im Rücken – alles wird in Ordnung gehalten, damit man es selbst nicht tun muss. Nicht die Geschwindigkeit. Nicht einmal wirklich ein Modell, das man lesen kann. Die gesamte Plattform.

Ich habe nun schon zweimal über den 2. Juni geschrieben. Der erste Artikel beleuchtete, welche Aufgaben dem Berater bleiben. Der zweite fragte, ob man einem Agenten dabei vertrauen kann. Dieser dritte Teil widmet sich dem Fundament von beidem: der Plattform, auf der wir alles aufbauen. Ist die Entscheidung für Mendix im Jahr 2026 noch vertretbar, wenn sich Konzepte wie TCO und Entwicklerproduktivität scheinbar monatlich ändern?

‍

Was die Verteidiger tatsächlich verteidigten

Die Behauptung am Tisch war bewusst direkt: Der Grund, sich 2026 für Mendix statt für KI-gestütztes React zu entscheiden, ist nicht die Entwicklungsgeschwindigkeit, sondern die Tatsache, dass das Ergebnis auch 2034 noch Bestand hat, lesbar und verwaltet ist.

Die Runde, die Mendix verteidigte, tat etwas, das ich als erstes Argument nicht erwartet hatte. Sie verteidigte Mendix, ohne sich auch nur einmal auf die Geschwindigkeit zu stützen. „Geschwindigkeit war noch nie das Wichtigste“, sagte einer von ihnen, „denn sonst würde ja bereits jeder Low-Code verwenden.“ Wenn also nicht Geschwindigkeit, was dann?

Vor allem Sicherheit und Governance. Man kauft keine schnellere Art zu tippen. Man kauft eine verwaltete Cloud, die bereits eingerichtet ist, einen Stack, der seit Jahren validiert ist, und etwas, das, wie es ein Berater ausdrückte, „einfach läuft“, mit Siemens im Rücken. „Wenn ich jetzt ein Kunde wäre“, sagte jemand, „würde ich mich immer noch für Mendix entscheiden, weil Siemens dahintersteht.“ Das Verkaufsargument war nie der Build selbst. Es war alles, was den Build umgibt und was man sonst selbst zusammenstellen, absichern und verantworten müsste.

Das ist ein echtes Argument, und ein besseres als „wir liefern schneller“. Mit Mendix sind wir es seit Langem gewohnt, Software schneller auszuliefern. Aus erster Hand wissen wir also, dass es großartig ist, die nötige Zeit in Anforderungen und Akzeptanz investieren zu können, anstatt sich mit einer Programmiersyntax herumzuschlagen.

Ich muss hier persönlich anmerken, dass Kommunikation meiner festen Überzeugung nach eines der kostspieligsten und zeitaufwendigsten Hindernisse bei der Schaffung neuer Dinge ist – egal ob Software oder etwas anderes. Seit Jahrzehnten ermöglicht Mendix sehr kleinen Teams den Bau von Software auf Enterprise-Niveau, während High-Code-Ansätze deutlich größere Teams erfordern, um dasselbe zu erreichen. KI kann helfen, die Teamgröße bis zu einem gewissen Grad zu reduzieren, aber das bedeutet nicht, dass die Verantwortung mit einer Organisation wie Siemens geteilt wird. Vielmehr teilt man sie mit einem LLM, das von jemand anderem entwickelt wurde – inklusive eines Verfallsdatums für dessen Verfügbarkeit. Das sollte man zumindest im Hinterkopf behalten.

‍

Lesbarkeit ist Teil des „Alles läuft“

Ein Teil dieses Pakets ist heute wichtiger als noch vor zwei Jahren, und es ist der Punkt, den die Leute zuerst nennen: Man kann es immer noch lesen.

Wenn ein Agent den Code schreibt, ist die Fähigkeit, ihn zu öffnen und zu verstehen, kein nettes Extra mehr. Es ist der Unterschied zwischen dem Besitz der eigenen App und dem Mieten einer Blackbox. „Ich sehe eine App ungern als Blackbox“, sagte ein Entwickler, „bei der man einen Prompt eingibt, sie baut, und man nicht weiß, wie es im Inneren funktioniert.“ Seine Sorge war konkret und kundenorientiert: Wenn der Kunde fragt, wie man es gebaut hat, möchte man nicht, dass die einzige ehrliche Antwort lautet: „Das war mein Prompt.“ Wenn ein Produktionsfehler zur Unzeit auf dem Tisch landet, möchte man einen Ablauf, den man lesen kann, selbst wenn ein Agent ihn geschrieben hat. Und das lesbare Modell ist es, das es einem Entwickler und jemandem aus dem Fachbereich ermöglicht, sich dasselbe anzusehen und tatsächlich darüber zu sprechen. Selbst wenn die KI das Ganze generiert, so die Argumentation der Verteidiger, kann man immer noch auf etwas Lesbares zurückgreifen und es gemeinsam durchgehen.

Bis hierhin ist das ein starkes, erwachsenes Argument für Mendix. Verwaltet, sicher, für ein breites Publikum lesbar und jemand anderes hält es in Schuss. Was den nächsten Teil interessant macht.

‍

Warum sagte also die Hälfte des Raumes „weder noch“?

Weil das gesamte Paket auf einer Annahme beruht, und die Skeptiker zielten genau darauf ab. Die Plattform ist nur dann ihr Geld wert, wenn Mendix selbst stabil bleibt und die Nase vorn behält. 54 % der Stimmen entfielen auf „weder noch“; das Versprechen der Langlebigkeit setzt voraus, dass Mendix seinen Teil einhält, und daran hatten sie ihre Zweifel.

Die andere Seite drückte es klar aus. „In zehn Jahren werden die Leute Mendix als High-Code betrachten“, sagte einer, „oder als Legacy.“ Ein anderer glaubte nicht, dass wir in zehn Jahren überhaupt noch Code schreiben werden, auch nicht in Mendix. Jemand verwies auf reine Prompting-Tools, bei denen man „nichts mehr tun muss, außer zu prompten“, und dass dies „alles verändert hat“. Die verwaltete, validierte, lesbare Plattform ist eine großartige Antwort – bis zu dem Moment, in dem jemand anderes dieselbe Governance „kostenlos“ anbietet und einen per Prompt ans Ziel kommen lässt. Aber ist das überhaupt möglich, ohne hineinsehen zu können? Und wenn jemand das mit jahrelanger Erfahrung in geteilter Verantwortung genau in diesem Bereich leisten kann, dann doch Mendix, oder?

Obwohl ich selbst nicht in diesem Raum war, glaube ich nach wie vor, dass die Plattform selbst hier den größten Mehrwert bietet. Viele Mendix-Kunden möchten nicht viel Zeit oder Budget in ihre IT-Landschaft investieren, wenn es nicht nötig ist. Selbst wenn man „funktionierende“ Software sehr schnell liefern kann: Wenn es keinen Ort gibt, an dem man sie so ablegen kann, dass man nachts ruhig schlafen kann, ohne eine teure Abteilung oder andere Mechanismen, die sich darum kümmern, was hat einem dann die Schnelligkeit bei der ersten Lieferung wirklich gebracht? Mit der großen Kundenbasis profitiert Mendix einfach von Skaleneffekten. Die Kunden profitieren von diesem einheitlichen Ansatz zum Preis einer Lizenz.

‍

Der Punkt, der Mendix am meisten beunruhigen sollte

Das kam nicht von einem Skeptiker im Raum. Es kam von jemandem, der Mendix verteidigte.

Er legte das gesamte Argument dar – die verwaltete Cloud, den validierten Stack, Siemens, alles – und sprach dann das Unausgesprochene laut aus: „Wenn man auf das Jahr 2034 blickt, warum sollte eine KI-Code-Lösung nicht dasselbe Vertrauen und dieselbe Governance bieten können? Und das ist die größte Herausforderung für Mendix.“

Das ist der eigentliche Wettbewerb, und es geht dabei nicht um die Build-Geschwindigkeit von KI-gestütztem React. Es geht darum, ob ein KI-nativer Stack dasselbe Maß an Vertrauen, Governance und Lesbarkeit bieten kann, das Mendix heute verkauft. Nichts davon ist ein Naturgesetz. Es ist lediglich ein Vorsprung. Der Aufwand, den man sich mit Mendix erspart, ist ein Aufwand, den man auch bei einem Konkurrenten vermeiden könnte, sobald dieser nachzieht. Während ich dies auf Basis der Ergebnisse des Round Tables schreibe, vertraue ich fest darauf, dass Mendix am Ball bleibt. Es war noch nie ganz einfach (im positiven Sinne), bei den monatlichen Release-Notes auf dem Laufenden zu bleiben, aber mittlerweile haben sowohl die Breite als auch die Tiefe der Releases noch weiter zugenommen.

‍

Also, verteidigbar oder nicht?

Ja, und zwar aus den richtigen Gründen: wegen der kontrollierten Plattform und des lesbaren Modells, nicht wegen der Geschwindigkeit bei einer Demo. Aber dieser Vorteil erneuert sich nicht von selbst. Mendix konkurriert nicht wirklich damit, ob es die App bauen kann. Es konkurriert damit, ob es der am besten kontrollierte, lesbarste und strukturierteste Weg bleibt, um Software zu entwickeln, während KI-Tools stetig auf dasselbe Versprechen hinarbeiten. Das ist ein Wettrennen, kein Burggraben. Um auf meine persönliche Notiz zurückzukommen: Bessere Software mit weniger Leuten zu bauen, war schon immer eine der großen Stärken des Mendix-Ökosystems. Und genau hierfür habe ich bisher nur wenige ernsthafte Herausforderer gesehen, wenn es um Software auf Enterprise-Niveau geht, die nicht an eine bestimmte Domäne oder ein spezifisches Software-Ökosystem gebunden ist.

Die Verteidiger in diesem Raum hatten nicht Unrecht. Sie waren nur ehrlich in Bezug auf die Zeit. Der Grund, sich für Mendix zu entscheiden, ist nach wie vor gut. Die Frage ist nur, wie lange noch, und diese Antwort hängt weniger davon ab, was die KI als Nächstes tut, als vielmehr davon, was Mendix als Nächstes tut. Mit dem kürzlich angekündigten Intelligence Center Xkönnen wir mit Sicherheit sagen, dass Siemens die Nase vorn hat.

Damit bleibt noch eine Frage vom 2. Juni offen, und zwar die unangenehme kommerzielle: Wenn das alles stimmt, wer braucht es dann eigentlich? Mehr dazu beim nächsten Mal.

‍

Ursprünglich veröffentlichthier.