This FAQ answers common questions about the Enterprise Low Code platform A12. For an in-depth introduction, refer to the Whitepaper “A12 – Low Code for Custom Enterprise Software.” The FAQ is continuously updated. Have more questions? Feel free to reach out or schedule a demo.
Contents
2.4. What types of applications is A12 designed for?
2.8. How much does using A12 bind me to mgm?
1. Low Code
1.1. What does “Low Code” mean? What is a “Low Code Platform?”
The buzzword Low Code or Low Code Platform was coined in 2014 by the market research company Forrester. It refers to a variety of approaches rooted in the tradition of model-based software development. A commonality is the principle of generating program code based on models, precisely what the term Low Code implies. The goal is to create a functional software with less manually written code, accelerating the software development process, increasing efficiency, and reducing prerequisites. A12 existed as a model-based architectural approach before the Low Code buzzword emerged. Nevertheless, we still refer to A12 today as an Enterprise Low Code Platform because the new term effectively conveys the central idea of developing software faster and more efficiently, making it easier to adapt and maintain through the use of models and code generation.
1.2. How are model-based software development and Low Code related?
1.3. What is an “Enterprise Low Code Platform”? What does mgm mean by it?
Existing Low Code approaches vary significantly. Some providers offer platforms as closed ecosystems where users can assemble and publish small apps. This modular approach has the advantage of quickly visible results, with minimal onboarding and little required prior knowledge. However, it has the drawback of only accommodating limited complexity. In contrast, A12 is designed as an open platform closely aligned with a developer’s modern toolkit. Depending on the problem at hand, various flexible solution approaches can be employed.
If we envision the software development process as an assembly line, different stations require varying degrees of variability. Sometimes prefabricated building blocks that are reused as-is are sufficient. At other times, we need to parameterize and make building blocks configurable to achieve the necessary variability. If certain building blocks are needed in many different configurations repeatedly, we can develop domain-specific languages, making even greater variability manageable.
However, there are also cases that are highly complex but don’t recur frequently. Here, individual implementation is the best way. We assume that projects for critical enterprise applications always include components that need to be individually developed. This is because, in many scenarios, it’s simply the most efficient and sustainable approach. Unnecessary abstractions lead to unnecessary complexity and various subsequent issues, such as increased difficulty in maintenance.
We refer to an Enterprise Low Code Platform as an appropriate approach that combines the development options outlined above. Low Code where possible and meaningful. Individual development where necessary.
2. A12 Overview
2.1. What is A12?
A12 is an Enterprise Low Code platform designed for implementing enterprise applications in complex IT landscapes. The modeling platform of A12 provides tools to quickly create and maintain parts of an application without programming knowledge.
The runtime platform of A12 offers the necessary flexibility to develop Low Code apps into fully integrated enterprise applications through professional individual software development and system integration.
2.2. What does the term A12 stand for?
A12 stands for “Allianz 2012.” Initially, A12 was an initiative by mgm for cross-project collaboration. The commitment to the alliance simultaneously marked the starting point for platform development and a focus on model-based software development. Despite undergoing several evolutionary stages in terms of technology, we have remained true to the name.
2.3. Who is A12 for?
A12 is designed for medium to large enterprises and government agencies in need of custom software. A12 enables the rapid realization of prototypes and simple applications that can grow into complex, fully integrated enterprise applications.
2.4. What types of applications is A12 designed for?
A12 allows the development of highly scalable, secure, and robust web applications. This includes underwriting platforms for industrial insurance, portals, application management systems, and specialized procedures for the public sector, as well as online shops, marketplaces, and integrated solutions for online, brick-and-mortar, and mail-order retail. A12 leverages the unique strengths of the model-based approach, especially in critical business areas where applications have a long lifespan but need to be adapted repeatedly due to domain advancements or changing regulatory requirements.
2.5. How does A12 differ from other Low Code platforms?
A12 combines a Low Code approach, allowing domain experts to create applications without programming knowledge, with professional individual software development and system integration. A12 does not focus on easily clickable apps for temporary use but provides an answer to how applications can become fully integrated, critical enterprise applications in the long term.
This distinguishes mgm’s approach from many Low Code platform providers. A12 is not a Platform as a Service (PaaS) offering for clicking together and deploying simple applications. It is not a closed ecosystem. A12, as an Enterprise Low Code platform, is only used in professional, individual software development projects. Another unique aspect is that A12 projects can directly impose requirements on the A12 base—similar to requirements for their own project software. This involvement allows projects to influence the development of A12 more directly. With the Plasma Design System, A12 is specifically tailored to the UI/UX requirements of mature business applications.
2.6. What are the advantages of A12?
A key advantage of A12 is the separation of business logic and technology, particularly beneficial for critical software with a long lifespan. Business aspects undergoing constant change can be modeled much faster and with less effort. Technical innovations can be implemented without having to consider all business aspects of the application, allowing, for example, the introduction of new technology in user interface design, persistence, or server processing.
Empowered Management of Business Content
Experts and business analysts can independently capture and sustain the core business logic of the software using modeling tools.
- Adjustment of business aspects without programming knowledge
- Swift implementation of business changes
- Automated code generation for modeled content
- Independent innovation of technology
Open Platform Instead of Closed Ecosystem
A12 is designed as an open system, providing maximum flexibility for development and the long-term maintenance and evolution of software.
- Integration of Low Code, individual software development, and system integration seamlessly
- Flexible utilization of modular runtime components
- Consistent utilization of open-source technologies
- Full control over operations – On-Premise or in the (Private) Cloud
- Ability to directly impose requirements on the A12 base
Future-Proof Platform for Long-Lasting Software
The meticulous separation of business logic and technology allows maintaining the core business logic even during technological advancements.
- Independent innovation of technology through a model-based approach
- “Data First” principle for sustainable business modeling
- Careful technology selection and utilization of industry standards
- Continuous development of the technical foundation
2.7. Are development costs lower with A12 projects?
The use of Low Code can achieve significant speed advantages in software development. The first functional version of an application and the Minimum Viable Product (MVP) of a business application are quickly available. The extent of time savings and cost advantages ultimately depends on how extensively the project relies on standard components. The more A12 standard solutions are used, the lower the individual efforts and the higher the cost advantages.
2.8. How much does using A12 bind me to mgm?
3. A12 Deployment
3.1. How is A12 used in practice?
A12 is employed in custom software development projects, referred to as A12 projects. The objective of an A12 project is to create a secure, performant, and scalable business application (A12 application) and swiftly deploy it into production.
3.2. What are the parallels and differences between an A12 project and a traditional software development project?
While a complete development environment and professional project management are essential for an A12 project, the A12 platform provides a proven technical foundation that already addresses many typical challenges of enterprise software. Individual extensions are built upon this foundation. Another difference lies in a new form of division of labor: the Low Code approach enables business analysts to model business content using specialized tools, introducing model-based work alongside source code work.
3.3. How can I access A12?
The acquisition of A12 is always tied to a project where mgm or an official A12 partner acts as the contractor. Feel free to contact us if you are interested.
3.4. Can my department use A12 independently?
3.5. How does collaboration work between the client and contractor in an A12 project?
Collaboration Model |
Description |
|
Contractor Assumes Overall Responsibility
|
The contractor (CT) takes on complete responsibility for the application. They gather the client’s (CL) requirements through requirement analysis and ongoing iterations. The project team, led by the contractor, is responsible for creating the relevant A12 models and all development, testing, and release activities.
|
|
Task Division: Modeling / Development
|
The client handles the business modeling, while the contractor is responsible for development and technology. This model assumes training for the client’s business analysts in A12 modeling. Given that the models represent the business domain’s functionality, this division of tasks is meaningful. The contractor provides support for modeling questions and oversees all development and technology-related tasks. |
|
Cooperative Development
|
If the client has an in-house development team proficient in the A12 technology stack, integration of this team into the development of the A12 application is possible. This involves training team members on A12 platform development. From the client’s perspective, the advantage of this model is greater independence from service providers and the ability to develop future application enhancements independently. |
4. Modeling
4.1. Which modeling tools are available?
The Simple Model Editor (SME) consolidates all modeling functionalities within A12. This web-based tool facilitates the straightforward management of all A12 models. Users can navigate models through a tree view in the Workspace Explorer or visually through the integrated Model Graph Diagram Editor. Specialized editing modules are included in the tool for working on individual model types.
4.2. Which A12 models exist?
Category |
Designation |
Description |
| Data Model | Document Model | A12 Document Models contain field definitions and associated validation rules organized in a hierarchy of groups. Validation rules range from simple constraints, such as defining mandatory fields, to complex patterns and conditions across multiple fields. |
| Relationship Model | Relationship Models describe connections between documents, modeling relationship properties and constraints. | |
| UI Model | Form Model | Form Models define the structures and contents of online forms. A12 forms consist of common UI elements like input fields, buttons, labels, checkboxes, etc. The modeling tools provide powerful capabilities to organize these elements. |
| Overview Model | Overview Models offer diverse options for tabular data representation. | |
| Tree Model | Tree Models allow hierarchical representation and editing of data structures. | |
| Workflow | BPMN 2.0 | A12 supports the modeling of business processes in the BPMN (Business Process Model and Notation) standard. BPMN models seamlessly integrate with A12 models. |
| App Model | App Model | An App Model defines the framework of the application, serving as a container for all other models. |
| Output Model | Print Model | The Print Model enables the creation of print templates for generating accessible PDFs. |
4.3. What can and can’t I model with A12?
The current modeling scope encompasses the entire domain logic and parts of the application interface. The decision on what is modelable in A12 is guided by the added value that modeling would provide. In complex business applications, there are often aspects that can be developed individually more quickly, efficiently, and sustainably.
The data models and the rule language for validations and calculations allow the representation of very complex business relationships. Trained domain experts and business analysts can independently define the functional aspects of an application using the modeling tools, without relying on a development team. Only in exceptional cases—such as calculations involving highly complex formulas—it might be more convenient to represent calculations directly in code rather than through the modeling tools.
The modeling of the interface currently focuses on areas where model-driven components are employed.
Modelable |
Individually implementable
|
| Business Logic – Data models with validation rules and calculations | Complex Algorithms (e.g., generic premium calculator in the insurance domain) |
| Application framework, including placement of model-driven engines | Placement of Widgets from the Plasma Design System |
| Forms, including repeatable structures | Definition or customization of design elements |
| Tabular overviews of datasets | |
| Tree-like overviews of datasets | |
| Relationships between various model-driven components | |
| Accessible PDF documents |
