
A12 FAQ
Kapitel 1: Low Code
1.1 Was bedeutet „Low Code“? Was ist eine „Low Code Platform“?
Der Begriff Low Code, oder Low Code Platform, wurde 2014 vom Marktforschungsunternehmen Forrester geprägt. Er bezeichnet Entwicklungsplattformen, die den Einsatz von manuellem Code durch grafische und modellbasierte Methoden minimieren. Ziel ist es, die Softwareentwicklung zu beschleunigen und sie auch für Nicht-Entwickler zugänglich zu machen.
A12 existierte als modellbasierter Architekturansatz, bevor der Begriff Low Code überhaupt eingeführt wurde. Wir bezeichnen A12 dennoch als Low Code Platform, da dieser Begriff die Kernidee – weniger Code, mehr Modell – präzise erfasst und in der Branche gut etabliert ist.
1.2 Wie passen modellgetriebene Softwareentwicklung und Low Code zusammen?
Low Code ist ein Begriff für Ansätze, die seit Jahrzehnten in ähnlicher Form praktiziert werden – insbesondere Model-Driven Engineering (MDE). A12 basiert auf MDE-Prinzipien: Geschäftsobjekte, Formulare, Workflows und Anwendungsstrukturen werden als Modelle definiert und zur Laufzeit interpretiert. Dies ermöglicht es Business-Analysten, professionelle Anwendungen ohne Programmierkenntnisse zu erstellen und zu warten.
1.3 Was ist eine „Enterprise Low Code Platform“? Wie definiert mgm den Begriff?
Es gibt erhebliche Unterschiede zwischen den heute verfügbaren Low-Code-Ansätzen. Einige Anbieter bieten Plattformen als geschlossene, cloudbasierte Produkte an. Andere stellen offene, erweiterbare Systeme bereit, die für die Entwicklung von Unternehmenssoftware konzipiert sind.
Wir definieren eine Enterprise Low Code Platform als einen zweckmäßigen Ansatz, der eine Reihe von Entwicklungsoptionen kombiniert – von der reinen Modellierung bis zur vollständigen programmatischen Erweiterung. Das Ergebnis: schnellere Entwicklung, geringere Kosten und gleichzeitig die Qualität, Robustheit und Skalierbarkeit, die Unternehmensanwendungen erfordern.
Kapitel 2: A12 im Überblick
2.1 Was ist A12?
A12 ist eine Plattform zur Entwicklung von Enterprise-Applikationen in komplexen IT-Landschaften. Sie basiert auf modellgetriebener Softwareentwicklung und ermöglicht es Teams, leistungsstarke, sichere und wartbare Applikationen effizient zu entwickeln.
A12 besteht aus zwei Kernbereichen:
• A12 Modeling Environment: Werkzeuge, mit denen Teile einer Applikation langfristig als unabhängige Fachlogik-Module erstellt und gepflegt werden können – ohne Programmierkenntnisse.
• A12 Runtime Platform: Modulare client- und serverseitige Komponenten in einer modernen Enterprise-Architektur – mit vollständiger Unterstützung für individuellen Code, DevOps und Sicherheit. Entwickler arbeiten dabei in ihren gewohnten Umgebungen: sowohl im integrierten Modeling Environment als auch in klassischen IDEs.
2.2 Wofür steht „A12“?
A12 steht für „Alliance 2012“. Ursprünglich war A12 eine Initiative von mgm für die projektübergreifende Zusammenarbeit. Aus dieser Initiative entstand die heute bekannte A12 AI Low Code Plattform.
2.3 Für wen ist A12 gedacht?
A12 richtet sich an mittlere und große Unternehmen sowie Behörden, die individuelle Software benötigen.
A12 eignet sich besonders für:
• Business Analysten/ Fachexperten: Erstellen und pflegen Applikationslogik durch Modellierung – ohne Programmierkenntnisse.
• Entwickler: Nutzen die Runtime Platform mit vollständiger Kontrolle und modernem Technologie-Stack (TypeScript/React/Redux, Java/Spring Boot).
• DevOps-Teams: Standardisierte Deployment-Prozesse mit Docker, Helm, Kubernetes und Jenkins-Pipelines.
• IT-Entscheider: Reduzierter TCO, digitale Souveränität durch Open Source, nachgewiesener Einsatz in geschäftskritischen Umgebungen.
2.4 Für welche Arten von Applikationen ist A12 geeignet?
Mit A12 können hochskalierbare, sichere und robuste Web-Applikationen entwickelt werden. Die besonderen Stärken des modellgetriebenen Ansatzes kommen vor allem in vier Szenarien zum Tragen:
• Komplexe Individualsoftware: eGovernment-Portale, Fachanwendungen des öffentlichen Sektors, Versicherungsplattformen, Enterprise-Portale.
• Core-Plattform für integrierte IT-Landschaften: Konsolidierung und Modernisierung der IT-Landschaft auf einheitlicher Architektur.
• Ablösung von Excel/Access-Applikationen: Migration auf eine offene Plattform inkl. automatisierter Migrationswerkzeuge.
• Softwareproduktentwicklung: Bewährte Grundlage für langlebige Softwareprodukte mit kürzerer Time-to-Market.
2.5 Wie unterscheidet sich A12 von anderen Low Code-Plattformen?
A12 kombiniert einen Low Code-Ansatz, bei dem Business-Experten eine Applikation ohne Programmierkenntnisse erstellen können, mit einem vollständig offenen und erweiterbaren System für Entwickler.
Der Fokus von A12 liegt nicht auf einfach zusammenzuklickenden Apps für den temporären Einsatz.
A12 gibt eine Antwort auf die Anforderungen an langlebige, geschäftskritische Software:
• Keine geschlossene SaaS-Plattform: A12 läuft auf der eigenen Infrastruktur, nicht in einer Vendor-Cloud.
• Kein Vendor Lock-in: Offene Plattformarchitektur, Open-Source-Verfügbarkeit (EUPL 1.2).
• Volle Entwicklerkontrolle: Fine-grained Extension Points statt eingeschränkter Anpassungsmöglichkeiten.
• Echtes Enterprise-Niveau: Gebaut für komplexe, geschäftskritische Applikationen in regulierten Umgebungen.
• Trennung von Daten- und UI-Modellen: Höhere Flexibilität und Wiederverwendbarkeit als bei GUI-Builder-Ansätzen.
2.6 Ist A12 eine deutsche Plattform? Was bedeutet das für die digitale Souveränität?
Ja. A12 ist eine entwicklungsorientierte Low Code-Plattform aus Deutschland, entwickelt von mgm technology partners GmbH mit Sitz in München. Als deutsches Unternehmen unterliegt mgm deutschem und EU-Recht - und damit weder dem US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) noch dem Foreign Intelligence Surveillance Act (FISA). In souveränen Umgebungen betrieben bieten A12-Anwendungen damit volle digitale Souveränität - ein Aspekt, der im Kontext KI-gestützter Entwicklung zunehmend an Bedeutung gewinnt.
A12 wurde gemeinsam mit der öffentlichen Verwaltung entwickelt und ist konsequent auf digitale Souveränität ausgerichtet:
• Modelle liegen als offene JSON-Strukturen vor — transparent, portierbar, Git-versioniert
• Kein Vendor Lock-in: offener Technologie-Stack, alle Artefakte bleiben vollständig in der Hand der eigenen Organisation
• Open Source unter EUPL 1.2 ab 27. Mai 2026 auf openCode.de und GitHub
2.7 Was sind die Vorteile von A12?
A12 bietet sechs zentrale Vorteile für Enterprise-Projekte:
1) Open Source: A12 basiert auf Open-Source-Standards und wird unter der EUPL 1.2 veröffentlicht – für vollständige Transparenz, Auditierbarkeit und Unabhängigkeit von einzelnen Anbietern. Die Community Edition ist frei verfügbar auf GitHub und openCode.de. Die Enterprise Edition umfasst Zusatzkomponenten und SLA-gestützten Support.
2) Digitale Souveränität: Mit A12 erhalten Organisationen die vollständige Kontrolle über ihren digitalen Kern, also über Architektur, Daten und Betrieb. Die auf offenen Standards und europäischen Prinzipien basierende Plattform verhindert Vendor Lock-in. Als deutsches Softwarehaus unterliegt mgm ausschließlich deutschem und EU-Recht, nicht dem US CLOUD Act oder FISA. Im Zusammenspiel mit einer souveränen Cloud bieten A12-Anwendungen als Software „Made in Germany” somit maximale digitale Souveränität. Die langlebige und anpassungsfähige Architektur stellt sicher, dass geschäftskritische Systeme über viele Jahre hinweg kontrollierbar und weiterentwickelbar bleiben.
3) Offene Plattformarchitektur: A12 ist eine offene, modulare Plattform, die mit der Enterprise-Landschaft mitwächst. Offene APIs und Standards ermöglichen eine tiefe Integration und gezielte Erweiterung. Während Geschäftsmodelle stabil bleiben, findet technische Evolution auf Plattformebene statt – das reduziert Reimplementierungsaufwand und technische Schulden.
4) Mehr als Low Code: A12 geht über reines Low Code hinaus: Sicherheit, Datenschutz, Qualitätssicherung, Barrierefreiheit und Deployment-Governance sind direkt in der Plattform integriert – Qualität und Compliance by Default. Eine klare Trennung der Verantwortlichkeiten zwischen Business und IT verbessert die Zusammenarbeit und führt zu robusteren, langfristig wartbaren Systemen.
5) Deterministisches KI-Framework: A12 ermöglicht die Kombination von KI-Einsatz und modellgetriebener Softwareentwicklung. KI bleibt damit transparent, beherrschbar und Enterprise-sicher. KI operiert auf expliziten Domänenmodellen, in denen Geschäftslogik klar von der technischen Implementierung getrennt ist. Entscheidungen bleiben nachvollziehbar und überprüfbar. Governance und Kontrolle verbleiben beim Team – anstelle intransparenter Automatisierung.
6) Ein vollständiges Entwicklungs-Ökosystem: A12 bietet ein durchgängiges Entwicklungs- und Delivery-Ökosystem: Von Modellierung und Implementierung bis hin zu Betrieb, Monitoring und Qualitätssicherung (Q12 Quality Landscape) sind alle Komponenten aufeinander abgestimmt. Fachexperten können aktiv zur Domänenmodellierung beitragen, während die IT in den gewohnten Umgebungen agiert und die architektonische Kontrolle behält. Diese gemeinsame Sprache reduziert Reibung und steigert Liefergeschwindigkeit.
2.8 Senkt A12 die Kosten eines Entwicklungsprojekts?
Durch den Einsatz von Low Code lassen sich erhebliche Geschwindigkeitsvorteile in der Softwareentwicklung erzielen. Die Modellierungsansätze ermöglichen eine deutlich schnellere Umsetzung von Anforderungen. Kunden berichten in typischen A12-Projekten von signifikanten Produktivitätssteigerungen im Vergleich zu konventioneller Entwicklung.
2.9 In welchem Maß bindet mich die Nutzung von A12 an mgm?
A12 ist als offenes System konzipiert, das größtmögliche Flexibilität für die langfristige Wartung und Weiterentwicklung bietet. Mit der Open-Source-Freigabe unter EUPL 1.2 ist die Plattform frei verfügbar. Durch die offene Architektur sind alle Artefakte (Modelle, Konfigurationen, Skripte) vollständig im Besitz des Auftraggebers und können ohne Einschränkungen von anderen Teams weiterentwickelt werden.
Kapitel 3: Einsatz von A12
3.1 Wie wird A12 in der Praxis eingesetzt?
A12 wird in individuellen Softwareentwicklungsprojekten eingesetzt. Dabei spricht man von einem A12-Projekt. Das Ziel eines solchen Projekts ist die Entwicklung einer maßgeschneiderten Applikation auf Basis der A12 AI Low Code Plattform. Typischerweise umfasst ein A12-Projekt ein interdisziplinäres Team aus Business Analysten, Entwicklern und DevOps-Spezialisten.
3.2 Welche Gemeinsamkeiten und Unterschiede gibt es zwischen einem A12-Projekt und einem konventionellen Softwareentwicklungsprojekt?
Auch in einem A12-Projekt sind eine vollständige Entwicklungsumgebung und professionelles Projektmanagement unverzichtbar. Der entscheidende Unterschied: Ein Großteil der Geschäftslogik modellbasiert umgesetzt – durch Business Analysten, nicht durch Entwickler. Das spart Zeit, erhöht die Qualität und ermöglicht schnellere Feedbackzyklen.
Gleichzeitig bringt A12 auch für die Entwicklung wesentliche Bausteine mit: qualitätsgesicherte Softwarekomponenten, ein Widget-Set - maßgeschneidert für die Anforderungen komplexer, barrierefreier Anwendungen - sowie klar definierte Extension Points für die gezielte Erweiterung der A12-Funktionalitäten.
3.3 Wie kann ich A12 erhalten?
Seit der Open-Source-Freigabe am 27. Mai 2026 ist die Community Edition (EUPL 1.2) frei auf openCode.de und GitHub verfügbar. Für Enterprise-Projekte mit Support, SLAs und erweiterten Funktionen steht ein Enterprise Subscription & Support-Modell zur Verfügung. Der zentrale Einstiegspunkt für alle A12-Ressourcen ist das Portal GetA12 (geta12.com). Interessenten können sich an hello.A12@mgm-tp.com wenden.
3.4 Kann meine Abteilung A12 eigenständig nutzen?
Wenn eine A12-Applikation im Rahmen eines Projekts erstellt wurde, kann die Abteilung die Applikation mithilfe der Modellierungswerkzeuge weitgehend eigenständig pflegen und weiterentwickeln. Dies setzt voraus, dass das Team in A12-Modellierung geschult ist.
3.5 Wie funktioniert die Zusammenarbeit rund um A12-Projekte?
Grundsätzlich ist die Zusammenarbeit zwischen Kunde und Auftragnehmer ein wichtiger Erfolgsfaktor in A12-Projekten. Es gibt verschiedene Kollaborationsmodelle:
| Kollaborationsmodell | Beschreibung |
| Auftragnehmer übernimmt Gesamtverantwortung | Der Auftragnehmer ist für die gesamte Applikation verantwortlich. Das Projektteam ist für die A12-Modelle und alle Entwicklungsarbeiten zuständig. |
| Aufgabenteilung: Modellierung / Entwicklung | Der Kunde übernimmt die domänenorientierte Modellierung, der Auftragnehmer die Entwicklung und Technologie. Voraussetzung: Schulung im Bereich A12-Modellierung. |
| Kooperative Entwicklung | Wenn der Kunde über ein eigenes Entwicklungsteam verfügt, das den A12-Technologie-Stack beherrscht, kann dieses Team in vollem Umfang an der Entwicklung beteiligt sein. |
3.6 Was ist Citizen Development mit A12?
A12 unterstützt das Konzept des Citizen Developers: Fachliche Mitarbeitende können aktiv an der Entwicklung mitwirken oder eigenständig Anwendungen erstellen — ohne Programmierkenntnisse.
Die Modellierungswerkzeuge ermöglichen folgende Tätigkeiten ohne Programmierung:
• Content-Modellierung (statische und dynamische Web Pages)
• Datenmodellierung, Formulare, fachliche Prüf- und Berechnungsregeln
• Druckvorlagen und Dokumentlayouts
• Workflow-Modellierung (Freigabe, Vier-Augen-Prinzip, Benachrichtigungen, Eskalation)
• Konfiguration von Oberflächenstrukturen und Navigationsstrukturen
In einem großen Steuerverfahren verantwortet die Fachabteilung über 300.000 Felder und über 150.000 Berechnungsregeln vollständig eigenständig, ohne Programmierkenntnisse und ohne fachlichen Zugriff durch mgm. In einem anderen Projekt wurden über 30 Personen aus mehr als sechs Ministerien in A12-Modellierung geschult, um über 100 Microsoft Access-Altverfahren durch A12-Webanwendungen abzulösen.
Kapitel 4: Modellierung
4.1 Welche Modellierungswerkzeuge stehen zur Verfügung?
Der Simple Model Editor (SME) bündelt alle Modellierungsfunktionalitäten von A12. Das webbasierte Werkzeug ermöglicht die einfache Verwaltung aller A12-Modelle – sowohl in der Baumansicht eines Workspace als auch in einem dedizierten Editor für jeden Modelltyp. Der SME unterstützt mehrere Modellierungsansichten, kontextsensitive Hilfe und direktes Feedback zu Modellierungsfehlern.
Neu seit 2025.06: Der SME enthält einen experimentellen KI-Prototyp, der automatisch erste Document Models aus bereitgestellten PDFs generiert. Mehr dazu im Nutzerportal GetA12.
Zusätzlich steht mit dem A12 Cloud Modeling Environment eine vollständig browserbasierte Version der Modellierungsumgebung zur Verfügung – ohne lokale Installation.
4.2 Welche A12-Modelle gibt es?
Eine aktuelle Übersicht aller Modell-Typen finden sich in unserem User Portal GetA12:
geta12.com/#/docs/2025.06/ext5/overall/types_of_models4.3 Was kann ich mit A12 modellieren und was nicht?
Der aktuelle Modellierungsumfang umfasst den gesamten fachbezogenen Inhalt und Teile der Benutzeroberfläche. Mit den Daten-, UI- und Ausgabe-Modellen können Business Analysten den Großteil einer Applikation ohne Programmierkenntnisse erstellen.
Nähere Informationen finden sich in der A12-Dokumentation:
geta12.com/#/docs/2025.06/ext5/overall/a12_modeling4.4 Gibt es ein Schulungsprogramm von mgm für die Modellierungswerkzeuge?
Ja, das Business Professional Services Team von A12 bietet Schulungen in der Nutzung der Modellierungswerkzeuge an. Sie sind auf Fachexperten und Business Analysten ausgerichtet, die keine Programmierkenntnisse haben. Die Schulungen sind in verschiedenen Formaten verfügbar: als Präsenz-Workshop, als Online-Schulung oder als Selbstlernmaterial.
4.5 Können A12-Modelle wiederverwendet werden?
Ja, Wiederverwendung ist für alle Modelltypen möglich. Besonders verbreitet ist sie bei den A12-Datenmodellen. Datenmodelle können in anderen Datenmodellen referenziert und erweitert werden, was die Konsistenz und Wartbarkeit von Datenstrukturen erhöht.
Neu seit 2025.06: Combination Modeling (Additive, Selection, Decoration Models) ermöglicht erweiterte Modellkomposition – Modelle können nun additiv kombiniert, selektiv eingeschränkt oder dekorativ erweitert werden.
4.6 Was ist Business Scripting?
Business Scripting ist eine experimentelle, TypeScript-basierte Funktion, die es Business-Analysten ermöglicht, komplexe Geschäftslogik umzusetzen, die sich mit reiner Modellierung allein nicht abbilden lässt. Mit einer auf die Bedürfnisse von Business-Analysten abgestimmten API für A12-Operationen ermöglicht Business Scripting die Automatisierung von Geschäftsprozessen – ohne tiefgehende Programmierkenntnisse vorauszusetzen.
Kapitel 5: Security
5.1 Wie wird die Sicherheit der A12-Plattform gewährleistet?
A12 folgt dem Prinzip Security by Design. Sicherheitsanforderungen werden von Anfang an berücksichtigt, um potenzielle Schwachstellen zu minimieren. Der Ansatz umfasst regelmäßige Sicherheitsaudits, Penetrationstests und die Integration von Sicherheitstools in den Build & Deployment-Prozess.
Die A12 Backend Docker-Images sind sicher per Default: vertrauenswürdiges Basis-Image (eclipse-temurin:17-jre-jammy), keine Root-Prozesse, kein Shell-Zugang, schreibgeschützte Filesysteme, keine SSH-Schlüssel, minimale installierte Pakete.
5.2 Wie werden A12-Projekte abgesichert?
Die jeweils erforderlichen Sicherheitsmaßnahmen müssen entsprechend den Anforderungen des Projekts individuell definiert werden. A12 bietet hierfür umfassende Sicherheitsfunktionen:
• Authentifizierung: OIDC (empfohlen, Keycloak als IdP), SAML, mTLS, API Key. JWT-basierte Anfragen-Authentifizierung (CSRF-Schutz).
• Autorisierung: RBAC (Role-Based Access Control) und ABAC (Attribute-Based Access Control).
• Datenverschlüsselung: TLS/HTTPS für alle Verbindungen, Verschlüsselung sensibler Daten in der Datenbank.
Für die kontinuierliche Absicherung im Entwicklungsprozess setzt mgm auf ATLAS – ein internes Security-Toolset, das Werkzeuge wie OWASP Dependency Check, ZAP und statische Code-Analyse in den Build & Deployment-Prozess integriert und eine automatisierte Reaktion auf Sicherheitsereignisse ermöglicht.
5.3 Meine Applikation muss die Sicherheitsanforderungen der IT-Grundschutz-Bausteine des BSI erfüllen. Ist das mit A12 möglich?
Ja, der Software-Entwicklungslebenszyklus (SDLC) von A12 berücksichtigt bereits die Anforderungen des Bausteins CON.8 Software-Entwicklung. Die relevanten Anforderungen müssen in der Entwicklungsphase der Anwendung auf Basis von A12 aktualisiert werden. Darüber hinaus sind Vorgaben für den Betrieb (OPS-Baustein) zu beachten. mgm verfügt über Erfahrung in der erfolgreichen Umsetzung der strengen Vorgaben der IT-Grundschutz-Bausteine – sowohl als Lieferant als auch als Betreiber.
Kapitel 6: UI / UX
6.1 Was ist A12 Plasma?
A12 Plasma ist ein Design-System, das mgm speziell für Business-Applikationen entwickelt hat. Es besteht aus UI/UX-Komponenten, Designrichtlinien und Patterns für die Entwicklung konsistenter und barrierefreier Web-Applikationen.
Im Gegensatz zu generischen Design-Systemen berücksichtigt Plasma auch die erweiterte Funktionalität, die in Business-Applikationen benötigt wird: komplexe Formulare, Tabellen mit Bearbeitungsfunktion, Massenoperationen, mehrstufige Workflows und mehr.
6.2 Wie funktioniert die UI-Modellierung in A12?
A12 nutzt spezielle UI-Modelle für die Gestaltung der Benutzeroberfläche. Auch diese folgen der Idee, Technologie von Inhalt zu trennen: Die Modelle definieren die Struktur und das Verhalten der Benutzeroberfläche, ohne spezifische Implementierungsdetails vorzuschreiben.
6.3 Unterstützt A12 Barrierefreiheit?
Ja, die A12-Plattform ist für die Entwicklung barrierefreier Web-Applikationen ausgelegt. Zahlreiche UI-Komponenten – darunter Formulare, Tabellen und Navigationsstrukturen – erfüllen die WCAG 2.1 AA-Anforderungen. Die Print Engine generiert barrierefreie PDFs gemäß PDF/UA-Standard.
6.4 Kann man mit A12 mobile Applikationen erstellen?
Ja, A12 ist für die Entwicklung responsiver und geräteunabhängiger Web-Applikationen ausgelegt. Sie bieten eine erstklassige Nutzererfahrung auf Desktop, Tablet und Smartphone. Native Mobile Apps (iOS/Android) werden aktuell nicht unterstützt.
6.5 Welche Themes bietet A12?
A12 bietet offiziell unterstützte Themes (Default, Compact, Flat und Flat-Compact), die speziell auf die Anforderungen von Business-Applikationen zugeschnitten sind. Individuelle Themes können per SCSS-Customizing erstellt werden.
Kapitel 7: Betrieb
7.1 Welche Optionen bietet mgm für den Betrieb von A12-Applikationen?
Für geschäftskritische Software ist es unerlässlich, dass sensible Daten in einer vertrauenswürdigen, sicheren Umgebung gespeichert werden und ein reibungsloser Betrieb gewährleistet ist. A12 bietet folgende Deployment-Optionen:
1) On-Premises-Betrieb im eigenen Rechenzentrum (Classic oder Kubernetes)
2) Betrieb in der Private Cloud von mgm, gehostet in einem Rechenzentrum in Deutschland
3) Cloud-Betrieb bei einem beliebigen Cloud-Anbieter (technisch als Kubernetes-Umgebung des Auftraggebers)
Gemeinsam mit öffentlichen IT-Dienstleistern werden bereits standardisierte Betriebsmodelle für A12-basierte Anwendungen in öffentlichen Rechenzentren etabliert. Je nach Projektanforderung stehen dedizierte oder geteilte Umgebungen zur Verfügung – etwa für Mandantentrennung, Datentrennung und unterschiedliche Schutzbedarfe.
7.2 Unterstützt A12 Kubernetes?
Ja, A12-Applikationen sind standardmäßig für das Deployment auf Kubernetes-Clustern ausgelegt. Auf Basis der Erfahrungen aus mehreren großen Softwareprojekten haben wir eine Auswahl an Werkzeugen aus dem Kubernetes-Ökosystem integriert: Helm-Charts für das Applikations-Deployment, Jenkins-Pipelines für CI/CD und Prometheus/Grafana für das Monitoring.
7.3 Läuft A12 auf OpenShift-Clustern?
A12-Applikationen laufen nicht out-of-the-box auf Red Hat OpenShift-Clustern, können aber durch Anpassung der Konfiguration in solchen Umgebungen betrieben werden.
7.4 Wie löst A12 Mandantentrennung?
A12 unterstützt zwei Ansätze für Mandantentrennung:
• Separate Instanzen: Eigene Datenbank, eigene Benutzerverwaltung, eigene Konfiguration pro Mandant – physische Trennung über Kubernetes-Namespaces. Beispiel: Cloud-Plattformen für kommunale Anwendungen in mehreren Bundesländern.
• Granulare Zugriffssteuerung: RBAC- und ABAC-Berechtigungsregeln innerhalb einer gemeinsamen Instanz. Beispiel: Länderspezifische Ausprägungen eines gemeinsamen Antragsportals mit je Bundesland unterschiedlichen Benutzerverwaltungen und Drittsystemanbindungen.
7.5 Unterstützt A12 IPv6?
Ja. A12 unterstützt IPv6 über Kubernetes Dual-Stack-Konfiguration.
Kapitel 8: Technologie
8.1 Können Teile der A12-Plattform separat eingesetzt werden?
Ja, A12 ist modular aufgebaut und in verschiedene Komponenten unterteilt. Der Zuschnitt der A12-Komponenten ist technisch motiviert. Jede Komponente hat einen klar umrissenen Aufgabenbereich und klar definierte Schnittstellen, über die sie mit anderen Komponenten kommuniziert.
8.2 Welche A12-Komponenten stehen zur Verfügung?
Eine Übersicht aller Komponenten finden sich in der A12-Dokumentation auf unserem User Portal GetA12:
geta12.com/#/docs/2025.06/ext5/base/base-documentation-bundle8.3 Auf welchen spezifischen Technologien basiert A12?
| Bereich | Technologie |
| Frontend | TypeScript, React, Redux (Redux-Saga) |
| Backend | Java 17, Spring Boot |
| Database | PostgreSQL |
| Prozess Engine | CIB 7 (Open-Source-Fork von Camunda Community Edition) |
| Identity provider | Keycloak (OIDC) |
| Build | Gradle, npm/pnpm |
| Deployment | Docker, Helm, Kubernetes, Jenkins |
| Design system | Plasma |
| Caching | Hazelcast |
Kapitel 9: Open Source
9.1 Wann und wie wurde A12 als Open Source veröffentlicht?
A12 wurde am 27. Mai 2026 offiziell als Open Source veröffentlicht. A12 ist auf openCode.de und GitHub verfügbar – unter der EUPL 1.2 (Community Edition).
A12 hat sich über Jahre in sicherheitskritischen, hochkomplexen Behördenapplikationen bewährt – unter anderem in der Steuerverwaltung, im Versicherungssektor und in der öffentlichen Verwaltung mehrerer Bundesländer. Die Open-Source-Freigabe ist ein konsequenter nächster Schritt zur Stärkung digitaler Souveränität.
9.2 Wo finde ich den Quellcode von A12?
Der A12-Quellcode ist unter der EUPL 1.2 (Community Edition) auf openCode und GitHub verfügbar.
• openCode: https://gitlab.opencode.de/a12• GitHub: https://gitlab.opencode.de/mgm-tp/a12/a12overview9.3 Unter welcher Lizenz steht A12?
A12 verwendet ein Dual-License-Modell:
• Community Edition: Lizenziert unter EUPL 1.2 (European Union Public License, Version 1.2) – für alle, die A12 frei nutzen möchten.
• Enterprise Subscription & Support: Proprietäre Lizenz für Kunden mit spezifischen Enterprise-Anforderungen (ersetzt die bisherigen „A12 Nutzungsbedingungen“).
Die EUPL (European Union Public License) ist eine von der Europäischen Kommission erstellte und gepflegte Open-Source-Lizenz. Sie ist die erste europäische Free/Open-Source-Software-Lizenz und fördert die Wiederverwendung von Software in der öffentlichen Verwaltung.
9.4 Warum hat mgm A12 als Open Source veröffentlicht?
mgm stellt sich mit der Veröffentlichung hinter die digitale Souveränität in Deutschland und Europa und unterstützt die Strategie der Bundesregierung zur Förderung von Open-Source-Lösungen und offenen Standards im öffentlichen Sektor (z.B. Deutschland-Stack).
Die Freigabe markiert einen Meilenstein für die digitale Souveränität in Deutschland. Die breite Verfügbarkeit ermöglicht es öffentlichen Einrichtungen, A12 ohne Lizenzkosten einzusetzen und aktiv zur Plattformentwicklung beizutragen.
9.5 Welche Bedeutung hat die EUPL-1.2-Lizenz für die öffentliche Verwaltung?
Für die öffentliche Verwaltung hat die Wahl der EUPL 1.2 konkrete Vorteile:
• A12 unterliegt als deutsches Produkt deutschem und EU-Recht — nicht dem US CLOUD Act oder dem FISA. Ob diese Souveränität auch für den gesamten Betrieb einer A12-Anwendung gilt, hängt von den Entscheidungen des Kunden ab: Wer eine europäische KI-Lösung integriert und auf einem europäischen Hoster betreibt, kann eine durchgängig souveräne Lösung realisieren. A12 schafft dafür die Voraussetzung - schreibt aber weder einen bestimmten KI-Anbieter noch eine bestimmte Betriebsumgebung vor.
• Die Open-Source-Freigabe unterstützt die Strategie der Bundesregierung in ihren Bestrebungen zur Digitalen Souveränität durch Open-Source Lösungen und offenen Standards (Deutschland-Stack).
• Modelle liegen als offene JSON-Strukturen, konfigurierbare Artefakte in offenen Formaten wie yaml vor — transparent, versionierbar in Git, vollständig im Besitz des Auftraggebers.
• A12 ist auf openCode.de veröffentlicht — der deutschen Open-Source-Plattform für die öffentliche Verwaltung.
9.6 Was ändert sich für bestehende Projekte?
Zunächst ändert sich nichts. Bestehende Projekte können weiterhin unter der proprietären Lizenz betrieben werden. Bei Interesse kann allerdings auch ein Wechsel auf die Open-Source-Lizenz evaluiert werden. Die Open-Source-Freigabe ist eine konsequente Weiterentwicklung in Richtung digitaler Souveränität und ermöglicht es neuen Projekten, A12 kostenfrei zu nutzen.
9.7 Was ist die A12 Community?
A12 ist als Open-Source-Projekt auf GitHub und der DSGVO-konformen Plattform openCode öffentlich zugänglich. Für den Austausch steht ein Community-Forum auf Basis von Discourse zur Verfügung. Externe Code-Beiträge sind derzeit noch nicht möglich – die entsprechende Infrastruktur (Guidelines, Review-Prozesse, Qualitätsstandards) wird aktuell aufgebaut. Updates dazu werden im A12 Blog veröffentlicht.
9.8 Kann ich zu A12 beitragen?
Der Quellcode von A12 ist frei verfügbar und kann eingesehen, genutzt und weiterentwickelt werden. Die A12-Community kann Issues melden, Feedback geben und sich über Discourse austauschen. Die Öffnung für direkte Code-Beiträge wird aktuell vorbereitet – inklusive Contribution Guidelines, Review-Prozessen und Qualitätssicherungsstandards, wie sie für eine Enterprise-Plattform dieser Größenordnung erforderlich sind.
9.9 Wo finde ich weitere Informationen zu A12 Open Source?
Kapitel 10: Künstliche Intelligenz mit A12
10.1 Ist A12 eine KI-Plattform?
Ja, als A12 AI Low-Code-Plattform ist A12 von Grund auf für die KI-gestützte Entwicklung konzipiert – ohne fest eingebaute KI-Modelle, aber mit maximaler Flexibilität bei der Modellauswahl. Die Enterprise Edition beinhaltet das A12 AI Tooling, das bewährte Werkzeuge zur Integration von LLMs bereitstellt.
mgm nutzt KI sowohl im Entwicklungskontext für Agentic Coding und Agentic Modeling als auch auf Ebene der A12-Applikationen, die mit KI-Fähigkeiten ausgestattet werden können.
10.2 Was bedeutet „kontrollierte KI-Integration"?
„Kontrollierte KI-Integration" ist mgms Leitprinzip für den Einsatz von KI:
• KI wird innerhalb eines kontrollierten, sicheren Rahmens eingesetzt.
• Generative und agentenbasierte KI kann effektiv und verantwortungsvoll eingesetzt werden.
• Qualitätssicherung, Sicherheitstests sowie Build- und Deployment-Prozesse bilden den Kontrollrahmen.
• Kein unkontrolliertes „Vibe Coding" in geschäftskritischen Kontexten
10.3 Was bietet A12 heute an KI-Fähigkeiten?
A12 Claude Plugin Marketplace: Der A12 Claude Plugin Marketplace ist der zentrale Weg, KI-Fähigkeiten innerhalb der Organisation bereitzustellen und zu nutzen. Er steht Kunden der Enterprise Edition zur Verfügung und umfasst einen Public Marketplace mit spezialisierten Plugins – jeweils getrennt für Modellierer und Entwickler:
Für Modellierende:
• Modeling Agents: KI-Agenten, die bei der Erstellung und Pflege von A12-Modellen unterstützen.
• Model Checker: Werkzeuge zur Qualitätssicherung und Validierung von A12-Modellen.
Für Entwickelnde:
• Development Skills: Spezialisierte Skills mit gezieltem Wissen und Anweisungen für KI-Agenten im Entwicklungskontext.
Für Modellierende und Entwickelnde:
• A12 Knowledge MCP (Model Context Protocol): Strukturierter Zugriff für KI-Agenten auf Plattformwissen, Projektartefakte und Dokumentation – versionsspezifisch und entwicklungsrelevant.
Da sich das KI-Angebot schnell weiterentwickelt, empfehlen wir, stets die Dokumentation auf geta12.com auf dem neuesten Stand zu prüfen.
10.4 Was ist das mgm AI Agent Orchestration Framework?
A12 stellt ein KI-Agenten-Framework bereit, das speziell für die Ausführung von KI-Workflows konzipiert ist. KI-Workflows sind eigenständige, versionierbare Services. Das Framework steht Kunden der Enterprise Edition zur Verfügung. Beispiele für sofort einsetzbare Agenten sind:
• Automatische Erstellung von A12-Modellen aus PDF-Formularen
• Excel-Mapping und Datentransformation
• PDF-Generierung und Dokumentenerstellung
• Erstellung von Jira-Tickets
• Schnittstellenintegration mit externen Fachsystemen
Ein struktureller Vorteil von A12: Bei der Erstellung von A12-Modellen kann die volle Leistungsfähigkeit von LLMs genutzt werden, während Modell-Interpreter und -Generatoren zur Laufzeit eine deterministische Ausführung sicherstellen.
Kapitel 11: Qualitätssicherung von A12
11.1 Was ist die Q12 Quality Landscape?
Die Q12 Quality Landscape ist das umfassende QA-Ökosystem von mgm technology partners für den gesamten Software-Lebenszyklus. Es vereint spezialisierte Tools und Services, die sich nahtlos in bestehende Entwicklungsworkflows integrieren lassen – von der Testfallerstellung und Abnahmetests bis hin zu Reporting und Sicherheitstests.
Q12 deckt funktionale und nicht-funktionale Tests ab, einschließlich Barrierefreiheit, Sicherheit, Performance und Lastverhalten. Die Tools werden von mgm selbst in A12-Projekten eingesetzt und kontinuierlich weiterentwickelt. Einzelne Produkte können unabhängig voneinander oder als Gesamtpaket genutzt werden.
Weiterführende Infos zur Quality Landscape: https://www.mgm-tp.com/q12.html
11.2 Which Q12 tools are available?
| Tool | Anwendungsbereich | Beschreibung |
| Q12-ATA (Automated Test Automation) | A12 Applikationen | Modellgetriebenes Testautomatisierungs-Tool. Generiert automatisch Testcode für UI-Tests aus A12-Modellen. Wenn sich Formulare ändern, wird der Testcode einfach neu generiert – jede A12-Applikation kann unmittelbar nach dem Modellieren automatisiert getestet werden. |
| Q12-TDG (Test Data Generator) | A12 Applikationen | Automatische Generierung valider Testdaten auf Basis von Document Models. Führt mathematische Konsistenzprüfungen an Document Models durch und unterstützt komplexe Formulare. |
| Q12-TDS (Test Data Suite) | A12 Applikationen | Funktionales Testen von Datenmodellen. Fokus auf Regeln, Felddefinitionen, Mappings und Berechnungen – speziell für modellbasierte A12-Applikationen. |
| Q12-TMT (Test Management Tool) | Web-, Mobile- und Desktop-Applikationen | Testfalldokumentation, Reporting und manuelle Testausführung. Unterstützt Web-Applikationen, Mobile Apps und lokale Software. |
| Q12-QFT (UI Test Automation) | Web-, Mobile- und Desktop-Applikationen | Automatisierte UI-Tests für Web-Applikationen, Mobile Apps und lokale Software. |
| Q12-ATLAS (Automated Toolset for Lean Application Security) | Alle Applikationen | Orchestrierung von Sicherheitsanalyse-Tools (u. a. OWASP Dependency Check, ZAP, sqlmap). Automatisiertes Security-Testing mit konsolidiertem Reporting. Prüft auf bekannte Schwachstellen in Drittkomponenten, Konfigurationsprobleme und API-Robustheit. Passt das so? |
| Q12-PERL (Performance and Load Testing) | Alle Applikationen | Analyse, Ausführung und Monitoring von Performance- und Lasttests über die gesamte Applikationsinfrastruktur. |
11.3 Welche QA-Services bietet mgm an?
Ergänzend zu den Tools bietet mgm folgende QA-Services an:
• Testing as a Service: Testdurchführung durch erfahrene mgm-Experten. Vertraulicher Umgang mit Informationen, umfangreiche Testerfahrung und effiziente Prozesse.
• QA Expert Support: Beratung auf Basis jahrzehntelanger Expertise. Aufbau kundeneigener Teams von Grund auf und temporäre Unterstützung bestehender Prozesse.
11.4 Wie integriert sich Q12 in den A12-Entwicklungsprozess?
Q12 ist tief in den A12-Entwicklungslebenszyklus integriert:
• Modellierung: Q12-TDS validiert Datenmodelle bereits in der Modellierungsphase.
• Entwicklung: Q12-ATA generiert Testcode direkt aus A12-Modellen; Code-Qualitäts-Tools (Checkstyle, OpenRewrite, ESLint & Prettier) stellen die Codequalität sicher.
• CI/CD: Q12-ATLAS scannt automatisch auf Sicherheitslücken in der Jenkins-Pipeline; Q12-PERL prüft Performance und Last.
• Release: Q12-TMT dokumentiert Testfälle und Abnahmeergebnisse für den Release-Prozess.
End-to-End-Tests laufen seit 2025.06 auf Playwright (lokal 60%+ schneller, im CI 37–57% schneller im Vergleich zum vorherigen Cypress-Setup).
11.5 Unterstützt Q12 Barrierefreiheitstests?
Ja. Q12 umfasst sowohl manuelle (Q12-TMT) als auch automatisierte Barrierefreiheitstests (Q12-QFT). Die Tests basieren auf internationalen Kriterien wie der europäischen Norm EN 301 549 und den Web Content Accessibility Guidelines (WCAG 2.1 AAA). Dies ergänzt die Barrierefreiheitsfunktionen, die bereits in den A12-Plasma-UI-Komponenten integriert sind.
Kapitel 12: Erste Schritte
12.1 Wie kann ich A12 ausprobieren?
Seit dem Open-Source-Release am 27. Mai 2026 ist die A12 Community Edition (EUPL 1.2) frei verfügbar – auf openCode.de und GitHub. Zentraler Einstiegspunkt für alle A12-Ressourcen ist das GetA12-Portal (geta12.com): Dort finden sich Installationspakete für die A12 Modeling Environment, die vollständige Plattformdokumentation sowie Links zu wichtigen Ressourcen wie dem Discourse-Community-Forum und dem Artifact Repository.
Für den technischen Einstieg steht ein A12 Project Template mit Setup-Dokumentation zur Verfügung. Für Business-Anwender gibt es eine dedizierte Modellierungsdokumentation sowie den A12 Installer für die lokale Modellierungsumgebung.
12.2 Wo finde ich Dokumentation und Lernmaterialien?
Die vollständige Plattformdokumentation – für Entwickler und Modellierer gleichermaßen – ist unter docs.geta12.com verfügbar. Die A12 Showcases und der A12 Widget Showcase bieten interaktive Einblicke in die Möglichkeiten der Plattform. Das A12 Whitepaper liefert einen kompakten Überblick über Architektur und Positionierung.
Wichtige Ressourcen auf einen Blick:
• GetA12-Portal: geta12.com – zentraler Einstiegspunkt für Installationspakete, Dokumentation und Ressourcen• A12 Dokumentation: geta12.com – vollständige Dokumentation für Entwickler und Modellierer• Community-Forum: geta12.com – Fragen, Antworten und Diskussionen rund um A12• A12 Showcases: Interaktive Demonstrationen der Plattformfähigkeiten• A12 Whitepaper: Kompakter Überblick über Architektur und Positionierung (PDF)Kapitel 13: Support & Community
13.1 Welchen Support bietet mgm für A12 an?
Das A12 Professional Services Team ist die zentrale Anlaufstelle für alle Fragen rund um A12. Das Team vereint Plattformentwicklung, Projekterfahrung und Partner-Management und besteht je nach Schwerpunkt aus Fach- und Technikexperten.
Support offerings include:
• Documentation: Modeling and developer documentation for all users of the A12 platform
• Community forum (Discourse): Open platform for sharing questions, answers, and best practices around A12 (discourse.geta12.com)
• A12 Support Portal: Structured submission of requests, bug reports, training needs, and feedback for partners
• Jira access: For mgm projects, project-specific Jira access is available for submitting requirements and bug reports
• Enterprise Subscription & Support: Individual SLAs and extended support for enterprise projects
13.2 Gibt es eine A12-Community?
Ja. Das Discourse-Community-Forum unter discourse.geta12.com steht allen A12-Nutzern offen. Es ist ein Ort, um Fragen zu stellen, Wissen zu teilen und Informationen zur Plattform und zu Projekten zu finden.
13.3 Gibt es Schulungen für A12?
Ja. Das A12 Professional Services Team bietet Schulungen für verschiedene Zielgruppen an. Fachexperten und Business-Analysten ohne Programmierhintergrund können auf Schulungen zugreifen, die speziell auf die Modellierungswerkzeuge zugeschnitten sind — als Präsenz-Workshops, Online-Kurse oder Selbststudienmaterialien. Entwickler haben außerdem Zugang zu dedizierten Schulungen in Frontend-, Backend- und Full-Stack-Entwicklung. Eine vollständige Übersicht aller verfügbaren Schulungsangebote findet sich hier:
geta12.com/#/trainings/trainings-overview13.4 Gibt es ein Partnerökosystem für A12?
Ja. Neben mgm technology partners als Plattformanbieter gibt es ein wachsendes Partnerökosystem aus IT-Beratungsunternehmen, Systemintegratoren und öffentlichen IT-Dienstleistern, das eine unabhängige Beratung, Entwicklung und den Betrieb von A12-Projekten ermöglicht.
Das Partnerökosystem dient auch als Absicherung gegen Vendor-Lock-in: Mehrere Partner sind in der Lage, A12-Projekte eigenständig zu entwickeln und zu betreiben — ohne auf mgm angewiesen zu sein.
Kapitel 14: Roadmap & Weiterentwicklung
14.1 Wie wird A12 weiterentwickelt?
A12 wird von mgm technology partners kontinuierlich weiterentwickelt. Neue Versionen werden in einem regelmäßigen Release-Zyklus veröffentlicht. Jede Hauptversion wird als LTS-Release (Long Term Support) für mindestens zwei Jahre unterstützt.
Die vollständige Versionshistorie mit Changelogs und Abhängigkeiten ist auf geta12.com verfügbar. Jede Version umfasst Updates für alle Plattformkomponenten — von Kernel Language und Data Services bis hin zu den Engines (Form, Overview, Tree), dem Simple Model Editor und der Print Engine.
14.2 Was ist die Cloud Modeling Environment (CME)?
Die Cloud Modeling Environment (CME) ist eine geplante Erweiterung der A12-Modellierungswerkzeuge. Die CME ermöglicht kollaboratives Modellieren direkt im Browser — ohne lokale Installation. Sie eignet sich besonders für verteilte Teams und Citizen-Developer-Szenarien, in denen Fachabteilungen standortunabhängig an Modellen arbeiten müssen.
14.3 Wie ist A12 in den Deutschland-Stack integriert?
A12 ist in der OZG-Cloud-Systemarchitektur 2026 explizit als Low-Code-Plattform verankert. Bestehende Integrationen umfassen zentrale Authentifizierungsdienste, Postfach- und Zustelldienste (z. B. FIT-Connect) sowie Zahlungsdienstleister. Die technische Grundlage basiert auf offenen Standards: BPMN 2.0, REST/JSON, SAML/OAuth 2.0/OIDC.
mgm erwartet, dass A12 mittelfristig formal in den Deutschland-Stack aufgenommen wird.
14.4 Plant mgm eine Komponentenbibliothek zur Wiederverwendung?
Ja. Im Rahmen der Open-Source-Strategie ist eine Bibliothek wiederverwendbarer Komponenten für gängige Verwaltungsverfahren geplant, die auf openCode.de bereitgestellt werden soll. Der Marktplatz Deutschland Digital ist als zentraler Distributionskanal vorgesehen. Ziel ist es, die Entwicklung von Fachanwendungen zu beschleunigen, indem bewährte Modellbausteine und Referenzimplementierungen projektübergreifend wiederverwendet werden können.
Kapitel 15: Migration
15. Kann ich von einer anderen Plattform zu A12 migrieren?
A12 bietet bewährte Migrationspfade für eine Vielzahl von Ausgangsszenarien. Für die Ablösung von Legacy-Microsoft-Access-Anwendungen stehen automatisierte Migrationswerkzeuge zur Verfügung — in einem Projekt auf Landesebene wurden auf diese Weise über 100 Anwendungen erfolgreich migriert. Die Migration von Microsoft Dynamics 365 Business Central zu A12 wurde ebenfalls bereits in der Praxis umgesetzt und ist auf ca. 3.000 Mandanten skalierbar.
Kapitel 16: Lizenzierung & Preise
16.1 Was kostet A12?
Die A12 Community Edition ist unter der EUPL 1.2 kostenlos verfügbar — auf openCode.de und GitHub.
Für Unternehmensprojekte bietet mgm ein A12 Enterprise Subscription & Support-Modell an. Dieses umfasst eine A12 Development License für die Entwicklungsphase (nutzbar durch das eigene Team des Kunden oder durch Entwicklungspartner) sowie ein Jahresabonnement für den Produktionsbetrieb — skalierend nach Produktionsumgebungen, Anwendungsinstanzen und Anwendungsnutzern. Dev-/Testumgebungen sind kostenfrei. Der Endnutzerzugang durch Bürgerinnen und Bürger ist im Enterprise-Modell enthalten.
Informationen zu Lizenzierungsoptionen, Editionsvergleich und Preisen sind direkt beim A12-Vertrieb erhältlich:
geta12.com/#/editions-licensing16.2 Was ist in der Community Edition enthalten und was in der Enterprise Edition?
Die Community Edition (EUPL 1.2, kostenlos) umfasst den vollständigen Plattformkern, Modellierungswerkzeuge, Client- und Server-Runtimes sowie die Entwickler-Toolchain — alles, was zur Entwicklung produktionsreifer Unternehmensanwendungen benötigt wird.
Die Enterprise Edition erweitert die Community Edition um zusätzliche proprietär lizenzierte Komponenten, darunter: A12 AI Services, A12 AI Extensions, Cluster Deployment, Notification Center sowie weitere Komponenten auf Anfrage. Die Enterprise Edition ist ausschließlich über ein A12 Enterprise Subscription & Support-Abkommen erhältlich. Für eine detaillierte Übersicht der verfügbaren Enterprise-Komponenten und Lizenzierungsbedingungen empfehlen wir, sich direkt an das A12-Lizenzierungsteam zu wenden: a12-license@mgm-tp.com
Kapitel 17: Compliance & Zertifizierungen
17.1 Welche Compliance-Anforderungen erfüllt A12?
A12 berücksichtigt die Anforderungen des BSI-IT-Grundschutz-Bausteins CON.8 (Software-Entwicklung) und stellt einen dedizierten Security-Leitfaden für projektspezifische Maßnahmen bereit. Als deutsches Produkt unterliegt die Plattform deutschem und europäischem Recht und ist weder dem US CLOUD Act noch FISA unterworfen.
Barrierefreiheit wird gemäß WCAG 2.1 und der europäischen Norm EN 301 549 unterstützt. Die Print Engine erzeugt barrierefreie PDFs nach dem PDF/UA-Standard.
A12 wird kontinuierlich aktualisiert, um aktuellen regulatorischen Anforderungen zu entsprechen. Die Compliance-Roadmap umfasst: BFSG/EAA (Barrierefreiheitsstärkungsgesetz / European Accessibility Act), ISO 27001, DIN SPEC 66336, FIM-Standards und BSI IT-Grundschutz. Für den Betrieb steht die mgm-C12-Infrastruktur mit ISO-27001- und BSI-C5-Testat in geo-redundanten deutschen Rechenzentren zur Verfügung.
17.2 Is A12 GDPR-compliant?
A12 is designed as a platform for use in regulated environments. The architecture supports data minimization, granular access control (RBAC/ABAC), and encrypted data transmission (TLS/HTTPS). Since A12 is operated on the client's own infrastructure, all data remains under the client's control.
A12 is not offered as a shared SaaS tenant but is always operated as a dedicated instance. Client data remains in dedicated environments. BSI IT-Grundschutz-compliant operations are possible (CON.8 anchored in the SDLC, OWASP ASVS, encryption, penetration testing, incident response). Service levels (availability, response times, and recovery times) are agreed upon individually.
Kapitel 18: Exit-Strategie & Vermeidung von Vendor Lock-in
18.1 Wie vermeidet A12 Vendor Lock-in?
A12 ist mit Herstellerunabhängigkeit als Kernprinzip konzipiert. Ein Plattformwechsel wird nicht durch proprietäre Barrieren erschwert:
• Offene Modelle: Alle fachlichen Inhalte (Datenmodelle, Formulare, Regeln, Workflows) werden als JSON in Git gespeichert — ohne A12 lesbar und maschinell konvertierbar
• Standarddatenbanken: JDBC-kompatibel (PostgreSQL); Export- und Backup-Tools sind im Betriebskonzept enthalten
• Offene Schnittstellen: REST/JSON, OAuth 2.0/OIDC/SAML, BPMN 2.0, DMN, PDF/A-3, PDF/UA, JMS
• Open-Source-Technologie-Stack: Spring, React, Keycloak, Kubernetes — die Laufzeitkomponenten sind nicht an mgm gebunden
• Containerisiertes Deployment: Docker/Kubernetes/Helm — portabel, kein Hosting Lock-in
• Open Source seit Mai 2026: Vollständiger Quellcode auf openCode.de und GitHub; betreibbar ohne aktiven Herstellersupport
• Kein SaaS-Mandantenbetrieb: Kundendaten in dedizierten Umgebungen; geordnete Übergabe an Nachfolgepartner deutlich vereinfacht
18.2 Wie sieht ein konkretes Exit-Szenario aus?
Vertraglich vereinbarte Exit-Szenarien — mit Datenmigration, Dokumentation, Wissenstransfer und Parallelbetrieb — sind gängige Praxis. Eine Migration erfordert im Wesentlichen den Aufbau einer neuen Laufzeitumgebung für Datenmodell, Geschäftsregeln und UI; die fachlichen Inhalte selbst liegen in offenen Formaten vor.
Zusätzlich bietet das Partner-Ökosystem eine zweite Absicherungsebene: Mehrere Partner im A12-Ökosystem verfügen über unabhängiges A12-Know-how und können A12-Projekte ohne Beteiligung von mgm weiterentwickeln und betreiben.

