Der umfassende Leitfaden zum Produktlebenszyklusmanagement

At CLEVR, we believe low code isn’t just about speed anymore. It’s about delivering strategic value as it is fast, flexible, and effortlessly connects with both modern and legacy systems. Simply put, low code has all the elements you need to build software that’s not just important but absolutely critical to your business.

From Prototypes to the Core of Your Business 

Low code has come a long way. What started as a way to quickly prototype and build internal tools, has grown into a mature development approach. Today’s low-code platforms are robust enough to handle the complexity, scale, and security requirements of business-critical systems. With the right approach and mindset, it’s not only possible but proven to work.

But before we go deeper, let's lay the groundwork of what we actually mean by “business-critical software”.

What Is Business-Critical Software? 

Business-critical software refers to the systems that your organization simply cannot function without. These are the backbone of your operations and if they go down, the consequences are immediate and serious:

• Operational disruptions
• Economic loss
• Reputational damage
• Regulatory or legal risks 

Think about order processing, financial operations, supply chain planning, customer service—functions at the heart of your business. These are not just systems of convenience; they are essential.

Why Low Code Is the Smart Choice for Scalability and Simplicity

By 2025, Gartner predicts that 75% of all new enterprise applications will be built using low code technologies. That is no coincidence. 

With a growing need for faster innovation and a shortage of IT talent, low code serves as an accelerator. It enables businesses to develop software faster, iterate more quickly, and fosters better collaboration between IT and business teams.

At CLEVR, we have been working with low code for over two decades. We have seen it grow from a way to solve small-scale challenges to a strategy for managing systems that handle thousands of daily transactions, ensure compliance, and support critical customer-facing operations. 

However, building business-critical systems with low code is more than just plug-and-play. Success depends on doing it right.

The CLEVR Way: Building in Balance 

To meet these challenges, we have developed a proven methodology known as The CLEVR Way. This approach combines the speed and flexibility of low code with the discipline required for enterprise-grade applications.

The CLEVR Way focuses on creating the right balance between key aspects of your business:

• Speed & Control
• Agility & Scalability
• Flexibility & Security 

This is a collaborative process to ensure shared responsibility, which is especially crucial in Agile environments. From day one, we work closely with your team to define clear requirements and align them with your architecture.

What You Gain 

When implemented correctly, low code delivers significant advantages for business-critical systems:

• Faster Time to Market: New features and updates go live in days, not months, thereby enabling you to react quickly to change, even in high-impact systems.
• Lower Build & Run Costs: With visual development and reusable components, you reduce both development time and maintenance overhead.
• Seamless Integration: Modern low code platforms are built API-first and integrate smoothly with everything from legacy systems to modern cloud data lakes like Snowflake. We often pair low code with iPaaS integration layers for maximum impact.
• Better Business-IT Collaboration: Visual development bridges the gap between business and IT, which is critical when building complex, business-critical applications that demand deep mutual understanding.
• Cloud-Native by Default: With cloud-native platforms like Mendix, a globally recognized leader in low-code and trusted platform by major enterprises and corporations worldwide, you get unmatched flexibility in deployment, hosting, scalability (both vertical and horizontal), and high availability. All critical for handling business-critical workloads. 

At CLEVR We Leverage an Architecture-First Approach

Want to make low code a strategic pillar in your IT architecture? At CLEVR, we rely on two robust models to guide this process:

• Gartner’s BOAT Model: Positions low code as a front-end and logic layer, which is ideal for driving innovation while keeping your core systems intact.
• Gartner’s Pace Layered Model: An established framework that separates your IT landscape into systems of record, differentiation, and innovation. Low code excels in the top two layers, where speed and adaptability matter most. 

By thinking “architecture-first,” you ensure low code isn’t just a tool but a long-term enabler of innovation.

Pitfalls to Avoid

Low code is powerful, but it’s not immune to missteps. A common mistake for example? MVPs that quietly evolve into business-critical systems without the right governance in place. 

To avoid this, here are some lessons from the field: 

• Conduct a Business Impact Analysis (BIA): Understand the risks of downtime and define recovery strategies. 
• Use an Application Portfolio Matrix: Assess business value vs. technical health, and take action where needed.
• Don’t Ignore Non-Functionals: Performance, security, maintainability, they all matter just as much as features.
• Think Long-Term: Our solution architects are embedded in every project to ensure alignment with your target architecture.
• Document Thoughtfully: Agile doesn’t mean “no documentation.” For critical systems, clear documentation is essential. 

The Bottom Line 

Low code is no longer just a fast track to MVPs and small business applications. It’s a fully matured enterprise-grade technology. With the right architecture, governance, and collaboration model, you get the best of both worlds: agility and stability. 

At CLEVR, we help organizations implement low code as a strategic enabler, rather than a temporary fix. Together, we make it a fundamental part of a future-ready IT architecture.

Want to Learn More? 

We are hosting a series of breakfast sessions where our experts (and customers) can dive deeper into what it really takes to build critical systems with low code. 

Interested? Let’s talk. 
Reach out directly to svddeijssel@clevr.com or call +31 6 52601544. 

FAQs

{% module_block module "widget_1007a03c-c537-4fdf-8a88-df29d95643ba" %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "colors" is_json="true" %}{% raw %}{"background":"light-blue","text":"darker-blue"}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "faq" is_json="true" %}{% raw %}[{"content":"Yes. Mendix offers the speed of low-code development combined with enterprise-grade performance, scalability, and reliability—making it ideal for business-critical use.","title":"Is Mendix suitable for business-critical applications?"},{"content":"Mendix supports microservices, API-first, and event-driven architectures with built-in tools for integration, orchestration, and modular deployment.","title":"How does Mendix fit into modern IT architectures like microservices or API-first?"},{"content":"Absolutely. Mendix connects seamlessly with systems like SAP, Salesforce, and Ortec using REST, OData, and events—enabling fast innovation without disrupting the core.","title":"Can Mendix integrate with existing ERP and CRM systems?"}]{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"colors":"group","faq":"group","padding":"group","squeeze":"choice","squeeze_position":"choice","structured":"boolean"}{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}61963180038{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"/clevr/modules/clevr_faq"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}[]{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "squeeze" is_json="true" %}{% raw %}"s"{% endraw %}{% end_module_attribute %}{% module_attribute "structured" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Since actions are the main way of using many app store modules, it is worth investing some time and thought in designing good actions. Here are eleven best practices that I have for anyone who is writing a java(script) action, either for use in a project or as a part of a reusable module.

1. Use descriptive parameter names and suffix them with an underscore

The name of a parameter should be descriptive and not redundant. That is general advice for naming that also holds true here. So avoid names like object, parameter, data. Keep in mind that action parameters are not only used in Mendix when the action is invoked, but also in java(script) code as variable names. This causes a slight problem when the parameter name is a reserved word in the respective language e.g. Object. To deal with this, Mendix would suffix the variable name in code with Parameter1 etc. This has been reworked in newer Mendix versions, which actually makes the problem worse. Now the same action code might work fine on an older Mendix version and fail to compile on a newer Mx version because of the different ways variable names are generated.

By using an underscore suffix all conflicts with reserved words that I am aware of can be eliminated and is actually not even visible when the action is invoked, as seen in the screenshot below. Perfect!

2. Add a new action instead of making signature changes.

We have all been there. Even the most well though-out action will need to change. Some of those changes will inevitably involve changing the signature, for example because a new parameter is added or a return type is changed. This is very disruptive, since all respective action calls throughout the project need to be updated.

The old action should internally call the new one and pass a default value for the new parameters or ignore a return value if one was added. Make sure to give both actions a logical name, perhaps the old action should include the word deprecated somewhere. A supplemental practice to avoid too many signature changes is described next.

3. Bundle flags, enums and integer settings into a single "Options" object.

Many times an action will have several flags or different settings that can be tweaked and therefore need to be exposed somehow. It is best to bundle all of these as a single object parameter, often called Options, Settings or Configuration.

By using an "Options" object multiple problems can be tackled at once: 1) adding a new setting does not change the signature; 2) default values can be defined in the object and do not pollute the constant space; 3) documentation for each flag has a clear place to live without overwhelming the action dialog; 4) the action parameter list can be shorter making it faster and cleaner to invoke the action (remember each parameter has to be explicitly set).

An example of an "Options" object from the parallel execute app store module.

4. Always use a facade instead of calling third-party libraries directly.

This one is for all who use third party dependencies in the form of jar files or javascript modules. I wrote a separate detailed blog post with the best practice for this. By using a facade we avoid hard coupling and make it possible to swap the library without too much hassle. Also, it is best to use a language specific dependency management and build tool such as maven or gradle for java, and npm or webpack for javascript. These tools offer easy management of transitive dependencies, test integration into the build process and packaging for the desired platform.

5. Guide the user in constructing object hierarchies with a builder pattern

In some cases arguments for an action are not a simple number or an object with a few parameters. Instead, an entire hierarchy of objects is needed, and it has to be associated in a specific way that is expected by the action. This is impossible to enforce at design time, so a clever way is required to guide the user in constructing the right hierarchy and setting the right associations.

In the case of medium-sized hierarchies, i.e. one or two associations, I prefer to use a builder pattern to help the user prepare the data. The builder pattern allows complex hierarchies to be built with simple steps, one step at a time. Additionally, each step is constrained using types often only obtainable from other steps. In an ideal world, it would be possible to entirely prevent manual instantiation of some builder objects, thus forcing the user to create them using an action.

Example of builder pattern used in my "Web push notifications" module. In step1 a notification object is constructed using a java action. Then in step2 a NotificationAction object is created and associated to a Notification, but instead of doing this directly again a java action is used which requires a Notification object as a parameter. This makes it impossible to confuse the steps order and call step2 before step1 or to forget setting the association.

6. Use the most specific and constraining types as possible.

This is another general advice, that also applies to actions and is tightly related to the previous best practice. Instead of strings "Yes" or "No" use boolean. Use enums and dates in place of strings where applicable. Avoid overloading nulls or other special values to convey information, instead use specific types or enums for that. For example, if the response is an error message or null (terrible idea btw, see 11) use an object with a boolean "HasError" and an error message instead.

7. Only use code for things that can not be done in Mendix natively.

If something can be done in Mendix then do it in Mendix. Especially for retrieves and/or changing objects. It is much easier and safer to call a flow from the middle of the action to do a retrieve natively in Mendix than to construct the XPath and retrieve with code.

When changing object attributes, remember that renaming the attribute, does not automatically rename existing calls to getter/setter methods on the respective proxy. So again, only use code when there is no alternative to doing the same natively in Mendix.

8. Do not add unnecessary coupling to Mendix runtime and core methods.

Avoid coupling code with Mendix APIs, especially for java actions. Mendix often makes changes to the runtime and core methods, just see this huge list in Mendix 8 version. So to avoid headaches, do not rely on Mendix runtime libraries or core methods unless absolutely necessary. It is clear that some coupling is unavoidable the goal here is to limit this to the absolute minimum.

If you follow the other best practices this one should come naturally. As an added benefit, if at one point you decide to move this part out of Mendix and into a separate server then having fewer dependencies will make it easier to migrate that part of the functionality.

9. Validate the number and types of parameters for microflow parameters.

This only applies when using microflow as parameters. Unfortunately, Mendix still does not allow to restrict the parameter number and types when used in an action. Until that is implemented the next best thing is to check the input and output types at run time. This is not trivial, please check the parallel execute module for a good implementation which also covers inheritance.

10. Use json as intermediary for communicating with actions.

Builder pattern was already mentioned as a way of dealing with medium-sized object hierarchies. But what about large object hierarchies? In this case it is best to resort to json. This gives users complete freedom to map their own entity diagram to/from json using an export/import mapping. Mappings are natively supported in Mendix which means they come with type safety and allow for easy renaming of entities, associations and attributes. This in contrast to code where any such rename would cause a compilation error.

To take it to the next level I suggest using JSON schema to validate the incoming/outgoing json. A free bonus that you get by using json is that it makes actions easier to test. No need to build an object hierarchy for every test case, simply paste a test json.

11. Let exceptions propagate instead of swallowing them.

If an exception occurs inside code, best to let it propagate to Mendix. Then the caller of the action can decide on how to best handle it. There is rarely a good reason to swallow exceptions.

Sometimes it might be useful to re-throw an exception with a simpler error message and log the actual message on a level other than error. For example, "NumberFormatException in line 192*"* is much less informative compared to "Amount is not a valid number".

''I hope you enjoyed reading this post and that it helps you design better Mendix code actions!''

AMERSFOORT, NETHERLANDS – July 29, 2021 – CLEVR, the company that helps enterprises accelerate their digital transitions through the enormous power of low-code and no-code development solutions, today announced the launch of an international expansion of the CLEVR brand and the company’s unique business model.  

When Mansystems and Flowfabric, two leading Mendix partners, merged to create a superpower in services and software development, they named the combined company CLEVR. The company now employs a hybrid business model, equal parts solution and services, that it calls Software with a Service (SWAS). The model is designed to assist the legions of people around the world involved in the daunting task of digitalizing enterprises: CIOs and enterprise architects, product owners, medium-sized-business owners and IT service providers.  

Developing with low-code and no-code platforms is among the hottest trends in tech, and widely recognized as a way to dramatically accelerate and simplify software development. The CLEVR team relies on the Mendix platform, recognized by research firms Forrester and Gartner as a world leader in low-code and no-code. Not only has CLEVR accumulated years of expertise creating problem-solving software apps with Mendix, but the company now employs more expert Mendix developers than any other. Despite the hype surrounding so-called citizen developers, these experts supply the knowledge, experience and creative thinking enterprises need to realize the full benefits and value of low-code and no-code tools. 

“There is a silent revolution happening in software development, hiding in plain sight,” said Angelique Schouten, who took over as CLEVR CEO in March. “And that’s the rise of low-code and no-code, a visual approach to software development with the power to accelerate the world’s digital transition. However, I believe many of the low-code and no-code companies are selling a false promise. Low-code and no-code by itself is not the solution to all your challenges because you still need to consider security, architecture, infrastructure and performance when developing software applications. If you use low-code and no-code solutions and don’t consider these areas, you’ll run into enormous problems when apps become more complex, start to scale and support business-critical processes.”  

Part of CLEVR’s business is offering professional services and assisting companies – in financial services, energy, government and manufacturing – to create dynamic and useful applications that advance at a high velocity their own or their customers’ digitalization efforts. CLEVR helped the City of Rotterdam build greater functionality around a video-call application that enabled residents to communicate with their local government digitally during the pandemic. With CLEVR’s assistance, the service eventually featured a document exchange, payment services and tools that allowed citizens to transact business, such as register births and marriages, by enabling them to identify themselves through DigiD, the Dutch government’s digital ID system.