Diese FAQ beantwortet eine Reihe häufig gestellter Fragen rund um die Enterprise Low Code Plattform A12. Eine strukturierte Einführung in A12 bietet das Whitepaper „A12 – Low Code für individuelle Enterprise Software“. Der Fragenkatalog wird sukzessive erweitert. Haben Sie weitere Fragen? Kommen Sie gerne auf uns zu oder vereinbaren Sie gleich einen Demotermin.
Inhalt
1. Low Code
1.1. Was bedeutet „Low Code“? Was ist eine „Low Code Plattform“?
1.2. Wie hängen modellbasierte Softwareentwicklung und Low Code zusammen?
1.3. Was ist eine „Enterprise Low Code Plattform“? Was versteht mgm darunter?
2.1. Was ist A12?
2.2. Wofür steht die Bezeichnung A12?
2.3. An wen richtet sich A12?
2.4. Für welche Arten von Anwendungen ist A12 ausgelegt?
2.4. Für welche Arten von Anwendungen ist A12 ausgelegt?
2.5. Wie unterscheidet sich A12 von anderen Low Code Plattformen?
2.6. Welche Vorteile bringt A12?
2.7. Sind die Kosten eines Entwicklungsprojekts mit A12 niedriger?
2.8. Inwieweit bindet mich die Nutzung von A12 an mgm?
2.8. Inwieweit bindet mich die Nutzung von A12 an mgm?
3.1. Wie wird A12 in der Praxis eingesetzt?
3.2. Was sind die Parallelen und Unterschiede zwischen einem A12- Projekt und einem herkömmlichen Softwareentwicklungsprojekt?
3.3. Wie kann ich A12 beziehen?
3.4. Kann meine Abteilung A12 eigenständig nutzen?
3.5. Wie läuft bei einem A12-Projekt die Zusammenarbeit zwischen dem Auftraggeber und Auftragnehmer?
4. Modellierung
4.1. Welche Modellierungswerkzeuge gibt es?
4.2. Welche A12-Modelle gibt es?
4.3. Was kann ich mit A12 modellieren und was nicht?
4.4. Gibt es ein Schulungsprogramm von mgm für die Modellierungstools?
4.5. Lassen sich A12-Modelle wiederverwenden?
1. Low Code
1.1. Was bedeutet „Low Code“? Was ist eine „Low Code Plattform“?
Das Buzzword Low Code bzw. Low Code Plattform wurde 2014 durch das Marktforschungsunternehmen Forrester ins Leben gerufen. Es bezeichnet eine Reihe ganz unterschiedlicher Ansätze, die in der Tradition modellbasierter Softwareentwicklung stehen.
Eine Gemeinsamkeit ist das Prinzip, Programmcode auf Basis von Modellen zu generieren. Genau darauf bezieht sich der Begriff Low Code. Es geht darum, mit weniger manuell
geschriebenem Code zu einer lauffähigen Software zu kommen. Der Softwareentwicklungsprozess soll dadurch beschleunigt werden, an Effizienz gewinnen und weniger voraussetzungsreich sein. A12 gab es als modellbasierten Architekturansatz bereits, bevor das Buzzword Low Code auftauchte. Wir bezeichnen A12 heute nichtsdestotrotz als Enterprise Low Code Plattform. Denn der neue Begriff transportiert sehr gut die zentrale Idee, dass wir Software durch den Einsatz von Modellen und mittels Code-Generierung schneller und effizienter entwickeln sowie einfacher anpassbar und wartbar machen können.
1.2. Wie hängen modellbasierte Softwareentwicklung und Low Code zusammen?
Low Code ist ein neuer Begriff für Verfahren, die in ähnlicher Form seit Jahrzehnten erprobt werden. Dazu gehört insbesondere die modellbasierte Softwareentwicklung. Um Anwendungen mit weniger manuell geschriebenen Code zu realisieren, muss ein Teil des Codes generiert oder interpretiert werden. Die Voraussetzung ist eine vorangegangene Modellierung, typischerweise in einer domänenspezifischen Sprache.
1.3.Was ist eine „Enterprise Low Code Plattform“? Was versteht mgm darunter?
Bei den bestehenden Low Code Ansätzen gibt es große Unterschiede. Einige Anbieter
stellen Plattformen als geschlossene Ökosysteme bereit, in denen Anwender kleine Apps
zusammenklicken und veröffentlichen können. Dieses Baukastenprinzip hat den Vorteil,
dass Ergebnisse sehr schnell sichtbar sind. Die Einarbeitung ist minimal, es sind kaum
Vorkenntnisse erforderlich. Es hat allerdings auch den Nachteil, dass nur eine begrenzte
Komplexität abgebildet werden kann. A12 ist hingegen als offene Plattform konzipiert,
die sehr nah an dem modernen Werkzeugkasten eines Entwicklers bleibt. Je nach Problemstellung lassen sich flexibel unterschiedliche Lösungsansätze verwenden.
Wenn wir uns den Softwareentwicklungsprozess wie eine Fertigungsstraße vorstellen,
dann erfordern unterschiedliche Stationen unterschiedliche Grade an Variabliität. Manchmal reichen vorgefertigte Bausteine, die eins zu eins wiederverwendet werden. Manchmal müssen wir die Bausteine parametrisieren und konfigurierbar machen, um die nötige Variabilität
abbilden zu können. Wenn bestimmte Bausteine in sehr vielen unterschiedlichen Konfigurationen immer wieder benötigt werden, können wir domänenspezifische Sprachen entwickeln. Damit wird eine noch größere Variabilität beherrschbar.
Dann gibt es aber auch immer wieder Fälle, die hochkomplex sind, aber nicht immer wieder auftauchen. Hier ist eine individuelle Umsetzung der beste Weg. Wir gehen davon
aus, dass Projekte für geschäftskritische Enterprise Anwendungen immer auch Anteile enthalten, die indivuell entwickelt werden müssen. Und zwar, weil das in vielen Konstellationen schlichtweg der effizienteste und nachhaltigste Weg ist. Unnötige Abstraktionen führen zu einer unnötigen Komplexität und diversen Folgeproblemen wie einer erschwerten Wartbarkeit.
Als Enterprise Low Code Plattform bezeichnen wir einen problemadäquaten Ansatz, der
die oben skizzierten Entwicklungsoptionen kombiniert. Low Code, wo möglich und sinnvoll. Individualentwicklung, wo nötig.
2. A12 Allgemein
2.1. Was ist A12?
A12 ist eine Enterprise Low Code Plattform für die Realisierung von Unternehmensanwendungen in komplexen IT-Landschaften. Die Modellierungsplattform
von A12 stellt Werkzeuge bereit, um Teile einer Anwendung ohne Programmierkenntnisse schnell zu erstellen und langfristig zu pflegen.
Die Laufzeitplattform von A12 bietet die nötige Flexibilität, um Low Code Apps mit professioneller Individualsoftwareentwicklung und Systemintegration zu voll integrierten Unternehmensanwendungen zu entwickeln.
2.2. Wofür steht die Bezeichnung A12?
A12 steht für „Allianz 2012“. Ursprünglich war A12 eine Initiative von mgm für projektübergreifende Zusammenarbeit. Das Bekenntnis für die Allianz markiert gleichzeitig
den Startpunkt für die Entwicklung der Plattform und den Fokus auf modellbasierte Softwareentwicklung. Obwohl die Plattform in Hinblick auf die Technik mehrere Evolutionsstufen durchlaufen hat, sind wir dem Namen treu geblieben.
2.3. An wen richtet sich A12?
A12 richtet sich an mittelgroße und große Unternehmen und Behörden, die individuelle
Software benötigen. Mit A12 lassen sich schnell Prototypen und einfache Anwendungen
realisieren, die zu komplexen, voll integrierten Unternehmensanwendungen wachsen
können.
2.4. Für welche Arten von Anwendungen ist A12 ausgelegt?
Mit A12 lassen sich hochskalierbare, sichere und robuste Webanwendungen entwickeln.
Dazu gehören beispielsweise Underwriting-Plattformen für Industrieversicherungen, Portale, Antragsmanagement-Systeme und Fachverfahren für den öffentlichen Sektor sowie Online-Shops, Marktplätze und integrierte Lösungen für den Online-, Filial- und Versandhandel. A12 spielt die besonderen Stärken des modellbasiertes Ansatzes vor allem in geschäftskritischen Bereichen aus, in denen Anwendungen lange Bestand haben, aber aufgrund fachlicher Weiterentwicklungen oder veränderter regulatorischer Vorgaben immer wieder angepasst werden müssen.
2.5. Wie unterscheidet sich A12 von anderen Low Code Plattformen?
A12 kombiniert einen Low Code Ansatz, bei dem Fachexperten eine Anwendung ohne
Programmierkenntnisse erstellen können, mit professioneller Individualsoftwareentwicklung und Systemintegration. Der Fokus von A12 liegt nicht auf leicht zusammenklickbaren Apps für den temporären Einsatz. A12 liefert vielmehr eine Antwort auf die Frage, wie Anwendungen langfristig zu voll integrierten, geschäftskritischen Unternehmenensanwendungen werden können.
Damit verfolgt mgm einen anderen Weg als viele Low Code-Plattformanbieter. A12 ist kein Platform as a Service (PaaS) Angebot, mit dem einfache Anwendungen zusammengeklickt und deployt werden können. Es ist kein geschlosenes Ökosystem. Als Enterprise Low Code Plattform kommt A12 nur in professionellen, individuellen Softwareentwicklungsprojekten zum Einsatz.
Eine weitere Besonderheit besteht darin, dass A12-Projekte direkte Anforderungen an die A12-Basis stellen können – analog zu den Anforderungen an die eigene Projektsoftware. Damit sind die Projekte viel stärker einbezogen, sie können die Weiterentwicklung von A12 sehr direkt beeinflussen.
Mit dem Plasma Designsystem ist A12 auch im Bereich UI/UX speziell auf die Anforderungen ausgewachsener Geschäftsanwendungen ausgerichtet.
2.6. Welche Vorteile bringt A12?
Ein zentraler Vorteil von A12 ist die Trennung von Fachlichkeit und Technik. Vor allem geschäftskritische Software, die viele Jahre Bestand hat, profitiert davon enorm. Fachliche
Inhalte, die einem ständigen Wandel unterliegen, können durch die Modellierung deutlich schneller und mit geringerem Aufwand in der Software abgebildet werden. Technische Innovationen können realisiert werden, ohne sämtliche fachlichen Inhalte der Anwendung berücksichtigen zu müssen. So lässt sich zum Beispiel eine neue Technik in der
Gestaltung und Realisierung der Benutzeroberfläche, in der Persistierung oder in der Server-Verarbeitung einführen.
Selbstbestimmter Umgang mit fachlichen Inhalten
Fachexperten und Business Analysten können mit Modellierungswerkzeugen den fachlichen Kern der Software eigenständig abbilden und langfristig pflegen.
- Anpassung fachlicher Aspekte ohne Programmierkenntnisse
- Schnelle Umsetzung fachlicher Änderungen
- Automatisierte Code-Generierung modellierter Inhalte
- Losgelöste Innovierung der Technik
Offene Plattform statt geschlossenes Ökosystem
A12 ist als offenes System ausgelegt, das eine größtmögliche Flexibilität für die Entwicklung sowie die langfristige Pflege und Weiterentwicklung der Software ermöglicht.
- Low Code, Individualsoftwareentwicklung und Systemintegration aus einem Guss
- Flexible Nutzung modular aufgebauter Laufzeitkomponenten
- Konsequenter Einsatz von Open Source Technologien
- Volle Kontrolle bzgl. Betrieb – On-Premise oder in der (Private) Cloud
- Möglichkeit, Anforderungen direkt an die A12-Basis zu stellen
Zukunftssichere Plattform für langlebige Software
Die konsequente Trennung von Fachlichkeit und Technik ermöglicht es, auch bei
Technologiesprüngen den fachlichen Kern beizubehalten.
- Losgelöste Innovierung der Technik durch modellbasierten Ansatz
- „Data First“-Prinzip für nachhaltige fachliche Modellierung
- Sorgfältige Technologie-Auswahl und Nutzung von Industrie-Standards
- Kontinuierliche Weiterentwicklung der technischen Basis
2.7. Sind die Kosten eines Entwicklungsprojekts mit A12 niedriger?
Durch den Einsatz von Low-Code lassen sich drastische Geschwindigkeitsvorteile bei der
Softwareentwicklung erzielen. Die erste lauffähige Version einer Anwendung und das Minimum Viable Product (MVP) einer Business Applikation stehen sehr schnell bereit. Wie hoch die Zeitersparnisse und Kostenvorteile sind, hängt letztlich davon ab, wie intensiv das Projekt auf Standardkomponenten zurückgreift. Je mehr Standardlösungen von A12 zum Einsatz kommen, desto geringer sind individuelle Aufwände und desto höher sind die Kostenvorteile.
2.8. Inwieweit bindet mich die Nutzung von A12 an mgm?
A12 ist als offenes System ausgelegt, das eine größtmögliche Flexibilität für die langfristige Pflege und Weiterentwicklung der Software ermöglicht. Es gibt keine Lock-in-Effekte. Einen Großteil der Anwendung – die modellierte Fachlichkeit – können Kunden von Anfang an eigenständig mitentwickeln und pflegen. Der Anteil individuell geschriebenen Codes ist im Vergleich zu klassischen individuellen Softwareprojekten deutlich geringer. Das vereinfacht auch die Übergaben – falls nach Projektabschluss ein internes Entwicklungsteam oder ein anderer Dienstleister die weitere Betreuung übernehmen soll.
3. Einsatz von A12
3.1. Wie wird A12 in der Praxis eingesetzt?
A12 kommt bei individuellen Softwareentwicklungsprojekten zum Einsatz. Wir sprechen
in diesem Fall von einem A12-Projekt. Ziel eines A12-Projekts ist es, eine sichere, performante und skalierbare Geschäftsanwendung (A12-Anwendung) zu erstellen und schnell in Produktion zu bringen.
3.2. Was sind die Parallelen und Unterschiede zwischen einem A12-Projekt und einem herkömmlichen Softwareentwicklungsprojekt?
Auch bei einem A12-Projekt sind eine vollständige Entwicklungsumgebung und ein professionelles Projektmanagement unabdingbar. Durch den Einsatz der A12-Plattform ist
jedoch eine bewährte technische Basis gegeben, die viele typische Herausforderungen von Enterprise Software bereits löst. Individuelle Erweiterungen bauen darauf auf. Ein weiterer Unterschied ist eine neue Form der Arbeitsteilung: Durch den Low Code-Ansatz lassen sich fachliche Inhalte mit Hilfe spezieller Tools durch Business Analyst:innen modellieren. Neben die
Arbeit am Quellcode tritt die Arbeit an Modellen.
3.3. Wie kann ich A12 beziehen?
Der Bezug von A12 ist stets an ein Projekt gekoppelt, bei dem mgm oder ein offizieller
A12-Partner als Auftragnehmer fungiert. Nehmen Sie bei Interesse gerne Kontakt mit uns auf.
3.4. Kann meine Abteilung A12 eigenständig nutzen?
Wenn im Rahmen eines Projekts eine A12-Anwendung erstellt wurde, ist die Fachabteilung in der Lage, die Anwendung durch Modellierungswerkzeuge eigenständig anzupassen. A12 ist jedoch kein App-Baukasten, der ein Zusammenklicken der Anwendung und ein Deployment auf Knopfdruck mit sich bringt. Eine Nutzung von A12 außerhalb eines Softwareentwicklungsprojekts ist in dieser Form nicht vorgesehen.
3.5. Wie läuft bei einem A12-Projekt die Zusammenarbeit zwischen Auftraggeber und Auftragnehmer?
Grundsätzlich ist die partnerschaftliche Zusammenarbeit zwischen Auftraggeber (AG) und -nehmer (AN) bei A12-Projekten ein wichtiger Erfolgsfaktor. In Hinblick auf die Aufgabenteilung durch den Einsatz der Low Code-Plattform sind folgende Konstellationen denkbar:
Zusammenarbeitsmodell |
Beschreibung |
|
AN übernimmt Gesamtverantwortung
|
Der AN verantwortet die gesamte Anwendung. Er nimmt die Anforderungen des AG im Rahmen einer Anforderungsanalyse und in laufenden Iterationen auf. Das Projekt-Team des AN ist für die Erstellung der entsprechenden A12-Modelle und für alle Entwicklungs-, Test- und Release-Tätigkeiten verantwortlich.
|
|
Aufgabenteilung: Modellierung / Entwicklung
|
Der AG übernimmt die fachliche Modellierung. Der AN verantwortet die Entwicklung und Technik. Voraussetzung dieses Modells ist eine Schulung der Fachexperten/Business Analysten des AG in der A12-Modellierung. Da die Modelle die Fachlichkeit der Geschäftsdomäne abbilden, ist diese Aufgabenteilung sehr sinnvoll. Der AN bietet Support bei Modellierungsfragen und verantwortet die gesamten Entwicklungs- und Technik-Aufgaben. |
|
Kooperative Entwicklung
|
Falls der AG über ein eigenes Entwicklungsteam verfügt, das den Technologiestack von A12 beherrscht, ist eine Einbindung dieses Teams in die Entwicklung der A12-Anwendung möglich. Voraussetzung ist die Weiterbildung der Teammitglieder mit Schulungen über die Entwicklung mit der A12-Plattform. Der Vorteil dieses Modells ist aus Sicht des AG eine größere Unabhängigkeit von Dienstleistern und die Möglichkeit, künftige Ergänzungen der Anwendung eigenständig zu entwickeln |
4. Modellierung
4.1. Welche Modellierungswerkzeuge gibt es?
Der Simple Model Editor (SME) bündelt sämtliche Modellierungsfunktionalitäten von A12.
Das webbasierte Tool ermöglicht eine einfache Verwaltung sämtlicher A12 Modelle –
sowohl in der Baumansicht eines Workspace Explorers als auch visuell durch den integrierten Model Graph Diagram Editor. Für die Bearbeitung der einzelnen Modelltypen enthält das Tool jeweils spezialisierte Editier-Module.
4.2. Welche A12-Modelle gibt es?
Kategorie |
Bezeichnung |
Beschreibung |
| Data Model | Document Model | A12-Dokumentenmodelle enthalten Felddefinitionen und zugehörige Validierungsregeln in einer Hierarchie aus Gruppen. Validierungsregeln reichen von einfachen Einschränkungen, z.B. der Definition von Pflichtfeldern, bis hin zu komplexen Mustern und Bedingungen über mehrere Felder hinweg. |
| Relationship Model | Relationship-Modelle beschreiben Verknüpfungen zwischen Dokumenten. Sie modellieren die Beziehungseigenschaften und -beschränkungen. | |
| UI Model | Form Model | Form-Modelle definieren die Strukturen und Inhalte von Online-Formularen. A12-Formulare bestehen aus gängigen UI-Elementen wie Eingabefeldern, Schaltflächen, Beschriftungen, Ankreuzfeldern usw. Die Modellierungswerkzeuge bieten leistungsstarke Möglichkeiten, diese Elemente zu organisieren. |
| Overview Model | Overview-Modelle bieten vielfältige Möglichkeiten für eine tabellarische Darstellung von Daten. | |
| Tree Model | Tree-Modelle erlauben es, Datenstrukturen hierarchisch darzustellen und zu bearbeiten. | |
| Workflow | BPMN 2.0 | A12 unterstützt die Modellierung von Geschäftsprozessen im BPMN (Business Process Model and Notation) Standard. BPMN-Modelle greifen nahtlos mit A12-Modellen ineinander. |
| App Model | App Model | Ein App-Modell definiert den Rahmen der Anwendung und fungiert als eine Art Container für alle weiteren Modelle. |
| Output Model | Print Model | Mit dem Print Model lassen sich Druckvorlagen für die Generierung barrierefreier PDFs erstellen. |
4.3. Was kann ich mit A12 modellieren und was nicht?
Der aktuelle Modellierungsumfang umfasst die gesamte Fachlichkeit und Teile der Anwendungsoberfläche. Die Entscheidung, was in A12 modellierbar wird, richten wir an dem Mehrwert aus, den die Modellierbarkeit bringen würde. In komplexen Geschäftsanwendungen gibt es immer wieder Aspekte, die sich individuell schneller, effizienter und nachhaltiger entwickeln lassen.
Mit den Datenmodellen und der Regelsprache für Validierungen und Berechnungen lassen sich sehr komplexe fachliche Zusammenhänge abbilden. Geschulte Fachexperten und Business Analysten sind dadurch in der Lage, mit den Modellierungswerkzeugen die fachlichen Aspekte einer Anwendung eigenständig festzulegen – ohne dabei auf ein Entwicklungsteam angewiesen zu sein. Nur in Ausnahmefällen – zum Beispiel bei Berechnungen mit sehr komplexen Formeln – kann es komfortabler sein, die Berechnungen direkt im Code und nicht über die Modellierungstools abzubilden.
Die Modellierung der Oberfläche beschränkt sich derzeit auf die Bereiche, in denen modellgetriebene Komponenten zum Einsatz kommen.
Modellierbar |
Individuell umsetzbar
|
| Fachlichkeit – Datenmodelle mit Validierungsregeln und Berechnungen | Komplexe Algorithmen (z.B. generischer Prämienrechner im Versicherungsumfeld) |
| Rahmen einer Anwendung inkl. Platzierung von modellgetriebenen Engines | Platzierung von Widgets des Plasma Designsystems |
| Formulare, inkl. wiederholbaren Strukturen | Definition oder Anpassung von Designelementen |
| Tabellarische Übersichten von Datensätzen | |
| Baumartige Übersichten von Datensätzen | |
| Beziehungen zwischen verschiedenen modellgetriebenen Komponenten | |
| Barrierefreie PDF-Dokumente |
4.4. Gibt es ein Schulungsprogramm von mgm für die Modellierungstools?
Ja, das Business Professional Services Team von A12 bietet Trainings für den Umgang mit den Modellierungstools. Sie richten sich in erster Linie an Business Analyst:innen, die in Projekten Teile der Modellierung übernehmen. Neben Präsenzschulungen, die je nach Vorwissen individuell gestaltbar sind, steht ein E-Learning Modul für die Einführung in die Datenmodellierung bereit.
4.5. Lassen sich A12-Modelle wiederverwenden?
Ja. Die Wiederverwendung ist bei allen Modelltypen möglich. Vor allem bei den A12- Datenmodellen ist sie gängige Praxis. Datenmodelle lassen sich modular aufbauen. So können untergeordnete Submodelle zum Beispiel in mehreren anderen Modellen wiederverwendet werden. Darüber hinaus können spezielle Typdefinitionen – zum Beispiel für zentrale Länderlisten und Rechtsformen – erstellt werden, die in mehreren Modellen genutzt werden können. So lassen sich modellübergreifende Aspekte an einer einzigen Stelle definieren, um Dopplungen und etwaige Inkonsistenzen zu vermeiden.
Sie wünschen weitere Informationen?
Den Kontakt zum A12-Team finden Sie hier
