Why Enterprise Low Code Doesn’t Mean the End of Developers – A Technical Perspective

A look behind the scenes reveals why enterprise low code doesn’t mean the end of developers. Learn how domain experts and developers work together to build tailored solutions—and why separating business logic from technology pays off. Let’s dive into the world of the mgm A12 platform.

The low-code approach drives the collaborative work between modelers and developers. It means that domain experts, who possess deep knowledge of their specific field, define the business requirements of an application through models. These experts understand the domain details—such as legal texts or industry-specific documents—and can describe them precisely. They create models that represent the domain. These models include different types, like data and user interface models, which reflect the domain and run within the application’s runtime environment. Developers can extend these models with custom code. Together, this results in the delivery of a complete application (see Figure 1).

Advantages of Separating Domain Logic and Technology

Separating domain logic from technology allows recurring functions, like forms, to be handled through models. If the required domain logic cannot be fully captured by modeling, the platform can be extended. When extending the platform with custom development, the software team doesn’t need to understand the entire domain—an advantage especially valuable for complex enterprise applications.

Many application properties are defined directly by business users: fields with data types, validation and formatting rules, labels, and dependencies between fields.

In these scenarios, custom development often becomes necessary to implement specific functions or business processes not covered by existing models. The final application combines models and custom code, delivered as a complete solution. This is exactly what the mgm A12 Enterprise Low-Code Platform supports.

Modeling should remain accessible to business professionals without a technical background. This means no programming or coding language knowledge is required to create models. Instead, a basic technical understanding and the ability to clearly express business rules matter most. This empowers business units to maintain and extend models independently from the software development team.

Another benefit of using models lies in technology independence. Components that execute the models can be implemented in a different (newer) technology without affecting the models’ usability.

Goal with A12: Low Code with as Much Custom Development as Needed

The A12 platform aims to build applications entirely through modeling. Many business processes—like reading, writing, and updating data—can be represented this way. A typical example involves a travel expense application: employees enter their expenses, which the back office then reviews and forwards to accounting. Such applications emerge purely from models within the low-code platform—without custom-written code. This approach aligns with the no-code principle.

Dependencies between models or complex rules get defined upfront in the domain layer, not later in development. This simplifies the process from the start, lowers complexity, and reduces the risk of developers handling complicated rules with countless “if” statements. Developers often define fields on several levels: user interface, UI object, transfer object, backend object, and persistence. Modeling requires defining the field just once, which makes changing data structures much easier.

The Low-Code Principle: How It All Began

To better understand low code development, it helps to look at its origins. In the past, people talked about 4GL applications, including tools like PowerBuilder or VBA.

Developers built applications mostly using a designer, defining events to add code—for example, for an OK button (see Figure 2). However, this approach had major drawbacks, especially the lack of code structure for the developer.

Over time, this often results in thousands of lines of code within the application, particularly around key functions like the OK button. Changes frequently require duplicating code, leading to messy, hard-to-maintain applications.

A12 aims to fundamentally change the development process through a modeling approach. The key lies in interpreting models directly at runtime—with few exceptions—rather than generating code.

Custom development happens alongside and remains clearly separate as an independent code structure. For software developers, modelers, and citizen developers, A12 combines no-code and low-code approaches with a clean option for extending functionality through custom code.

Architecture of the A12 Low-Code Platform

A12 builds on a unified technology stack (see Figure 3). The frontend relies on TypeScript with React and Redux as core technologies, while the backend uses Java with Spring Boot.

In the no-code part of the platform, the client plays a central role. It forms the runtime environment, provides features like navigation, menus, and a basic role-based access system, and integrates typical web elements such as headers, footers, notification bars, and status information.

The client incorporates advanced UI components called “engines.” These interpret models at runtime and handle functions like list displays through the Overview Engine or forms via the Form Engine.

Data gets stored generically on the server as JSON documents. Single records (documents) can be queried, or APIs can search for documents. The client supports both model-driven interfaces and custom screens. Custom screens, like the engines, are based on A12 widgets but can also include engines since the A12 ecosystem follows a modular design. Additionally, besides the standard persistence service, custom backend services can be integrated (see Figure 3).

Both low-code and no-code approaches run within the same client framework in the browser and use generic document persistence on the backend.

Low Code — The Requirements

As described earlier, A12 aims to deliver applications entirely through low-code modeling. Writing custom code or maintaining build and deployment scripts becomes unnecessary. Configuration and development happen directly through modeling, with simple save buttons for storing models. Changes can be reviewed using a preview function before deployment to a server.

Low Code and Custom Development Work Perfectly Together in the A12 Framework

Low-code platforms must offer much more than simple user interfaces. Providing functions like submitting travel expense claims isn’t enough. What really matters is the platform’s ability to fully and efficiently map the underlying business processes—from submission to processing and accounting.

A12 targets complex business processes across industries such as insurance and the public sector. This involves supporting multiple user groups and straightforward calculation rules.

To achieve this, the data must decouple from the user interface. Additional information beyond the application process—like approval status or relevant accounting details—also needs storing. This is easily done by saving such data within the business object “application,” though hidden from applicants. This structure allows different data views—for example, one for applicants entering data and others for expense processing by clerks or accounting.

Low Code Complements Custom Development — Not the Other Way Around

A core principle of A12 states: low-code development complements, but does not replace, custom development. Companies expect tailored solutions that fit their specific processes precisely. The platform must stay open to custom extensions at any time.

At the same time, developers need to navigate the platform easily. They require access to the underlying source code to understand application behavior and make adjustments. Only then can custom requirements be implemented efficiently, and application maintainability secured over the long term. The integration of low code and custom development creates this space. It enables efficient realization of business processes without sacrificing the flexibility and control of custom code.

This makes one thing clear: low-code platforms must go beyond offering simple screens. They must deliver the flexibility and power to represent complex business processes effectively, while providing room for individual requirements. Custom development uses APIs to access platform functionality.

Client Meets Framework: Unified Design Meets Flexibility

Developers often ask how the development framework works. The client provides the central structure for both design and functionality. In the application model, screens and screen flows get defined—either purely through modeling or with custom implementations. A key requirement for a consistent user experience is that both custom-built screens and prebuilt engines rely on the same widget library. This ensures a uniform look and feel across the entire application.

Engines integrate as UI components and remain transparent to developers. Thanks to the shared widget base, appearance and behavior can be controlled centrally. Adjustments like fonts, font sizes, or button placement happen via configuration and apply equally to engines and custom screens (see Figure 4).

Additionally, extension points exist in both frontend and backend to enhance components. This allows features like barcode scanners to integrate into the Form Engine. For example, a special item field can be equipped with barcode scanner functionality and embedded directly within the Form Engine.

Using A12 Models Flexibly in Custom Development — Thanks to a Special API

A12 models don’t just serve during development; they can also plug directly into custom-built applications. A dedicated API lets developers load models and query specific model details. For instance, developers can use annotations—key-value pairs—to mark fields in the UI model. This lets them designate certain fields as item fields, automatically triggering a special widget, like one that interacts with a barcode scanner.

Data from the A12 document model also flows into custom applications. Developers can check whether a field contains currency or percentage values. Both frontend and backend access this information, using it flexibly for custom extensions or specific business logic. This way, model data integrates smoothly into custom solutions.

Low Code: Common Developer Concerns

Developers often raise typical objections to low-code platforms:

• Less Flexibility: Many fear low code restricts them, forcing them to write only code snippets like in early Visual Basic days.
  → With A12, the client feels like a classic React app—developers work in a familiar environment.

• Outdated Technology Stack: Concerns exist that low-code platforms use technology stacks that age quickly.
  → A12 relies on regular updates of libraries, including security patches and major upgrades.

• Artificial Separation of Tech and Domain: Some worry low code lowers technical involvement, splitting technical and business development.
  → In A12, technically skilled team members remain essential, especially for complex requirements, while simple cases get handled through modeling alone.

• Less Work for Developers: A common fear is that low code takes away developer jobs.
  → Reality differs: complex tasks and custom extensions remain. Low code simplifies simple use cases, freeing developers to focus on harder challenges. Meanwhile, business teams often supply plenty of new ideas.

The Future of Software Development Lies in Combining Low Code and Custom Development

Low code doesn’t signal the end of programmers. Instead, it expands opportunities for both developers and business experts.

With low-code models, domain experts with deep knowledge specify requirements precisely – no coding needed. Developers pick up those models, add custom extensions, and build complex features. This results in tailor-made applications perfectly aligned with company workflows and needs.

Separating domain knowledge from technology delivers clear benefits: teams work more efficiently, code stays well-structured, and maintenance becomes easier. Modelers and developers focus on their strengths without slowing each other down. Every extension grows a library of reusable models and components—both within and across applications.

The A12 framework focuses exactly here. It merges model-driven and custom development into one consistent technology stack. This allows flexible combinations of low-code and no-code approaches with custom code. Companies gain maximum creative freedom—without compromising performance or future readiness.

Last Updated on July 8, 2025 by mgm-marketing