Use Mendix to build an ERP application

Hi there Mendix community, hopefully I can ask your advice/opinion about the following: my company is making plans to rebuild our main ERP application. This is a custom built application (Windows Forms, VB.NET), VERY rich of functionality. It has a CRM module, insurance module, finance module, amongst others.  The maintainability of the application is getting worse, partly due to the architecture of Windows Forms. Lets say insufficient seperation of the MVC layers. It has been decided it will become a web application, which makes a lot of sense. As we have some Mendix applications, we also look in that direction. The idea is to build the View (MVC) in Mendix, with presentation logic (MVC). All business logic will be in the model (MVC). The model will have a Service Oriented Architecture, consisting of WCF (C#) web services on top of a SQL server stack.  I myself have doubts about the suitability of Mendix for this kind of enterprise application, regarding its size and complexity. My doubts are based upon: maintainability: the number of modules and components needed in Mendix will be enormous; even for the smaller applications we have, this is already a challenge, although there is a good modular and folder structure scalability: although there will be a max of 80 users, Mendix does not offer a lot of scalability performance: a Mendix front end with a SOA architecture backend might pose threads to performance?! reuse: I strongly believe a modern web application should have an as pure HTML/CSS front end as possible, using a Javascript framework (like Angular f.e.) as “the front end Javascript world” still evolves quickly, it is important to be able to adapt new frameworks easily, reusing old HTML/CSS as with Windows forms, the front end does not have clear MVC layers, and none of this code is reusable (Mendix only) vendor lock: the technology and its licensing will depend upon Mendix, code is not reusable and hosting opportunities are limited   Don’t get me wrong, I’m very enthousiastic about Mendix, and low/no code technology. But especially for smaller/simpeler web apps where time-to-market should be as quick as possible. Thanks in advance for any thoughts you would like to share on this topic! Kind regards, Harro de Vos
2 answers

Here my 2 cents:


If you split up your application into different Mendix applications you can solve this (microservices). So let your core modules be their own environments. This way you can have one team building the Insurance app and the other the CRM app etc.


Microservices would also help for this. Because each enivironment can have a different size depending on how much use it is getting.


Hmm, reuse is more then just HTML. Code reuse is also part of this. With a microarchitecture you do need to think about which microservice needs which data from the other services. And the theming can be reused over the multiple applications. Might need some  more discussion about this topic.

Vendor lock

Yes you have the API but indeed this might be an issue. And do note the microarchitecture approach probably needs an enterprise license. You need to do some calculations here.

Hope this helps a bit.





Hello Harro,

I think Ronald has answered the questions about usabillity of Mendix well.

I was triggered by your question because of the idea of using the Model View Controller (MVC) pattern. Using a pattern like this is not common in the Mendix world, although it can help a lot to make your application more stable and maintainable. The focus of Mendix developers is often to deliver the functionallity as fast as possible. Using a layer-pattern like MVC slows down the initial development a bit. But as soon as your application grows, you will be very happy to have a structured way of building your application.

It will be to long to explain the whole MVC pattern for Mendix here (I might write a whitepaper about it some time). But the idea is to split the business logic in validations and operations and have all the commits done in one place, only after all validations are met. This single place to call all business logic (the controller) can be used from the view, which can be a responsive or mobile form, an API or a batch process. Have one place to  call all business logic is also ideal for automatic testing.

If you send me an email I can explain it some more if you like. My mailaddress is

Best regards, Diederik