Mendix and SAP Partnership

Mendix has been SAP’s main partner for low-code application development since 2017, and is the only low-code vendor that is an SAP Endorsed Apps partner and has passed the SAP Premium Certification. That means that SAP has officially certified and endorsed the use of Mendix alongside SAP solutions,

SAP Build makes sense as a starting point for customers who see low-code as a useful addition to complement traditional SAP development, but it is not more than that. Mendix makes more sense when the customer’s ambition is to replace most of their traditional development with a low-code way of working, not just for SAP but also for non-SAP systems and technologies (Oracle, Salesforce, Java, .Net, etc.).

Mendix is a single platform that focuses purely on application development, whereas SAP Build consists of four products that also do other things, such as Robotic Process Automation (RPA). Therefore, there may be situations where Mendix and parts of SAP Build can be used together. It’s difficult to make a direct comparison, but SAP and Mendix both see clear differences between the two offerings, and their ongoing partnership means customers can choose whatever best fits their requirements: Mendix, SAP Build, or a combination of both.

Use Cases

Mendix is like a Swiss army knife for SAP customers. It can be used when SAP lacks a certain functionality but also as a light alternative to SAP, when the standard SAP solution is too big for the problem it’s meant to solve.

Of course, you can use SAP BTP, including SAP Build, to fill these gaps, but you may need to use traditional high-code in addition to, or instead of, low-code. It will often be quicker and easier with Mendix, especially if they meet one or more of the following criteria:

1. Combining data and functionality from SAP and non-SAP systems: Like other ERP systems or Salesforce for Marketing, Sales and Service users. Mendix has strong SAP integration, but it’s not SAP-opinionated. The fact that it’s not SAP-branded also makes it likely to be accepted as an enterprise-wide platform by those working with other systems and technologies.
2. Combining standard workflow functionality with a purpose-built app experience: For example, in finance, procurement, master data management, and industry-specific processes. Unlike SAP Build, where workflow management and low-code development come in separate tools, Mendix has an embedded workflow engine that gives you the best of both worlds on a single platform.
3. Custom user experience: For example, customer and partner self-service apps, where company branding and a consumer-grade experience are required. It is also for internal users in sales, service, and other departments whose productivity is limited by the standard SAP user experience.
4. Mobile user experience: For example, a work order execution in maintenance and field service, warehouse scanning, and proof of delivery apps. Many customers have traditionally struggled to enable SAP on mobile devices, but it’s an area of strength for Mendix. Mendix apps are responsive by default, but they also be converted to Progressive Web Apps (PWA) and native mobile apps for iOS and Android. They can also work offline, which is often important for the use cases listed above.

The more of these criteria a use case meets, the more suitable it is for Mendix.

Customer Scenarios

“Keep the core clean” has been SAP’s mantra for custom code since they launched S/4HANA in 2015. We see customers doing this to varying degrees with Mendix, and broadly speaking, they fall into 4 different categories or scenarios.

Scenario 1: Connect to the Core

In this scenario, the customer has not necessarily articulated a strategy to “keep the core clean” (yet), but they are building Mendix applications with SAP integrations.

A good place to start is an “SAP pre-processing” application, where data needs to be collected and/or approved by different users before the complete and approved object or transaction is entered into SAP.

Examples include capex requests, purchase requests, master data changes, etc, and they are often done with shadow IT, like email, Excel, and Lotus Notes. Mendix is an ideal way to automate these use cases, especially when they also require non-SAP integrations and/or the user experience of a dedicated app rather than a standard workflow tool, like SAP Build Process Automation.

Over time, customers may build many apps with SAP integration, even though they’re not explicitly trying to “keep the core clean.” A good example is Siemens, which has many SAP instances and 800+ Mendix apps in production.

Scenario 2: Contain the Core

In this scenario, the customer treats SAP somewhat as a legacy system, with the intention to migrate it to S/4HANA or another ERP system at some unspecified time in the future.

These customers try to “contain SAP,” “put SAP in a box,” or even “freeze SAP” for all changes, except mandatory things like security patches and legal updates. New developments are nearly always done in Mendix, but enhancing and extending existing custom code depends on the size and scope of the change and the policy of the customer.

Smaller changes can be made in the core, but larger changes may be an opportunity to move the whole functionality to Mendix. Customers in this category include the health, beauty, and nutrition firm DSM-Firmenich and the energy retailer Enexis.

Scenario 3: Clean the Core

In this scenario, the customer is systematically removing custom code from their core and rebuilding it with Mendix.

There is a misconception that they are rebuilding the same functionality like-for-like, but of course, they also take the opportunity to modernize it with new functionality and a better user experience, including full mobile support, for example. In this sense, cleaning the core is not just an IT project to reduce technical debt but also provides real value to the business.

SAP has provided detailed guidance on how to clean the core in a document called “Custom Extensions in SAP S/4HANA Implementations – A Practical Guide for Senior IT Leadership”. The document dates from 2021, but it is still the most detailed guidance SAP has provided, and it’s relevant to customers staying on SAP ECC, as well as those migrating to S/4HANA. Although it’s not a step-by-step guide, it does outline the key steps you have to take:

• Start upskilling your SAP architects and development teams on the new technologies you want to use as soon as possible if you haven’t already done so. The document assumes you are using SAP BTP technologies, but Mendix is much simpler in this regard because it’s a single platform, technology, and skillset.
• Remove all obsolete code from your ERP system. SAP says this is typically 30% of the total and sometimes up to 50%. To find out which code is obsolete, you can activate a built-in SAP feature for custom code usage monitoring, as explained in the document.
• Disregard code that will be obsolete if you move to S/4HANA, because it can be replaced by standard functionality and therefore makes no sense to rebuild. This step requires functional and technical SAP knowledge, so you may have to work with an SAP partner to do this. SAP says that, after this step, you may only have 10% of your original custom code left to clean from your core.
• Use a tool called SAP Custom Code Analyzer to analyze the complexity of the remaining code and prioritize it for cleaning and rebuilding. Aside from business priorities, SAP advises customers to prioritize complex code and “orphaned code” to start with. Complex code leads to the most issues and changes and, therefore, the highest maintenance cost, whereas “orphaned code” has no owner of proper documentation, which means it’s a risk to the business.

For each modification you need to rebuild, use the detailed guidance in section 4 of the document to evaluate the options in order of preference:

• In-app extensions (only available in S/4HANA)
• Side-by-side extensions on the new platform
• On-stack extensions (only available in S/4HANA)
• Do nothing (stick with your current ABAP code, now known as “classic extensions”)

A good example of a customer who systematically cleaned the core of their SAP ECC system is the agribusiness Cosun Beet Company. They launched a program called “SAP 2 Standard” to clean up their ECC system and reskilled their existing ABAP and Fiori developers to use Mendix. As a result, they doubled their development capacity, achieved 7x more than they would have done before, and even helped increase the company’s crop yield by €1.8M per year.

Scenario 4: Keep the Core Clean

“Keep the core clean” implies that your core is clean to begin with, either because you’ve cleaned it, you are doing a greenfield re-implementation, or you are new to SAP altogether.

In a sense, it’s easier if you’re new to SAP because you can onboard your architects and developers directly onto Mendix without first having to ween them off older SAP technologies. Good examples of such customers are the mining company Sibelco and the HVAC, bathroom, and kitchen wholesaler Van Marcke.

For many more examples of customers using Mendix in combination with SAP, see our customer stories featuring SAP.

Joint Partners

Mendix has consultants who can help you build apps, but they are not SAP consultants. If you also need SAP domain expertise, we can help you find a partner that has both Mendix and SAP experience. This could be a global system integrator who has both a Mendix practice and an SAP practice, or it could be a smaller partner that specializes in the combination of Mendix and SAP. We have many of these and are happy to help you find one in your region.

Support Strategy Between Mendix and SAP BTP

Mendix applications are developed and deployed to run onto SAP BTP using the Mendix Cloud Foundry build pack. Our customers may sometimes run into unwarranted issues. As part of our SAP-Mendix partnership, we have a clearly laid-out support strategy, as detailed in our support guide.