Johan den Haan is the Head of the Research and Development department at Mendix , a company that delivers the tools and infrastructure to simplify and accelerate the design, integration and deployment of next-gen business portals and cloud applications
This focus on the business side and on cloud computing (topic in which we are also working on ) and, especially its motto no code just glory definitely attracted my attention (and, to be honest, Johan is interesting enough to justify an interview by himself!) so I scheduled an interview with Johan to talk about Mendix and his work there.
This is the result of the interview (once transcribed and edited to shorten some of the questions/answers), hope you enjoy it! (And don’t forget to check the previous episodes of the “a coffee with” series )
Jordi Cabot (JC) – Welcome Johan. Maybe you can start by introducing yourself AND your POSITION IN the company?
Johan den Haan (JH) – I work FOR Mendix as a head of research and development. This means that I’m in charge of product development and also of the community part of our products. This includes our app store and the way we approach the community.
JC – It’s not common to find a research department in an MDD company.
JH – Our R&D IS mostly focused on product development but the things we are building are innovative and we try to use the latest insights from universities and other research companies
JC – How big is Mendix?
JH – We started five years ago and now we have around 60 people. We are growing fast and we have also an office in the USA which is growing fast.
JC – It seems that Mendix has two different branches: the product and the services you offered on top of that. Am I right?
JH – Yes the company is split in two branches, one is product development and the other is the services department.
Product development is our main focus. We don’t sell the modeling environment but licenses for the runtime environment (the modeling tool is free of use). Our services department uses the tool to deliver projects to clients but we focus on delivering the tool to partner companies that use the tool to build business solutions. In this sense, Mendix services is just one of the partners OF Mendix technology.
Of course, you need this service branch to start, to get some first customers to get some traction in the market and some stories that you can show to future potential customers.
JC – Your focus on the tool differs from other companies in which the tool is just the excuse to sell services. Instead, you believe you can make money just by selling the tool.
JH – Yes, it is possible but you need the service department to start. In fact, the modeling tool is free but the runtime environment that interprets the models can only be used during development. When you want to put it into production you have to pay licenses
JC – When did you start developing the tool? Was developing the tool the goal of Mendix from the very beginning?
JH – Five years ago we started the company but before we were already developing the tool. The owners started the company because AT SOME point they realized they had something they could sell.
JC – And what was the initial motivation to create a completely new tool?
JH – The first motivation was trying to automate the development activities they were doing over and over again, this is one of the main reasons for MDD. But afterward we saw that CURRENT MDD tools were oriented to developer productivity and in our opinion, one of the main benefits OF MDD can be, if you create the right tool, that domain experts can be involved in the development projects. Communication with users could be much easier.
Therefore, the main motivation is to create a tool aimed not to developers but to business engineers (people with analytical skills but not necessarily with a background in IT) who can model the application and add customer value.
JC – This way you can have a direct communication WITH business stakeholders and avoid a lot of misunderstandings. And also make sure that the application satisfies their real needs. How does the tool manage to involve these business people? What are the necessary features/modeling languages for this?
JH – The most important thing is to provide visual models. I know there is a lot of discussion on textual vs graphical DSLs but visual models are easier to grasp for non-technical people. The second thing is that you split the application specification in several models, each one written in a specific domain specific language (a DSL TO model the user interface, another to model the workflow, etc.). This way you have small languages, with 3 to 5 concepts each, that are really easy to learn. Each person, depending on his/her role, can use one or more of these modeling languages.
We call each view of the application a feature . Each feature is backed up by a DSL. Main features are the domain model, the user interface, the microflows (business logic), and the business rules. Then, depending on the project you have additional features as internationalization or connections with external services.
JC – And these models are expressive enough to cover all aspects of the system and execute/interpret it at runtime?
JH – We don’t generate code. The model is stored in a model repository which is then read by the runtime environment that interprets the model. You don’t need to add anything. The tool performs consistency checks on the model and once the model is consistent you can click deploy and run and open your application immediately in the browser.
JC – What are the main benefits of interpreting models instead of generating the code?
JH – We really aim at bringing software development to a higher abstraction level. We target domain experts. We don’t generate code that then needs to be edited, compiled, deployed… We just want to model and run. People do not need to know anything about software development to build an application. It’s just one click deploy.
JC – And the system evolution is almost for free, you just need to change the model and redeploy the system
JH – Yes. And soon we will launch a public version of the Mendix Cloud. This means you can directly deploy your model from your modeling environment in the mendix cloud. You can just deploy your model and run it.
JC – Is the migration of data part of your automatic evolution process?
JH – Yes, if you change the domain model, when redeploying, the database schema and its data is automatically migrated.
JC – And what are the disadvantages of your model interpretation approach when compared TO code-generation? Have you tested the performance of your running systems?
JH – We did some tests (not in a scientific way) but in most cases, in aprox. 95% OF them, we were as fast as native Java code (which by the way is also interpreted). You have to do the interpretation in a smart way of course but you can get the same efficiency.
JC – If users cannot customize the code, because there is no code to customize, this means they should be able to express everything at the model level, even the most strange things. How do you deal with this?
JH – This is a well-known issue for most tools. We give the possibility to add Java actions to your model. You can define an activity in a microflow model (low-level models of the application logic) that is a Java action in which you define the input and output of the action and then use free Java code TO fill in the action. It’s nicely integrated with the model. You can use the domain entities to retrieve and manipulate data but code everything you want (even reference your own Java libraries). These java actions are then deployed together with the model.
JC – Do you enforce any specific development process?
JH – In principle you are free but we of course also have created a methodology in our service department to show people what is the best way to work with the tool. Our methodology enables you to develop the project in an agile way but of course, this also forces you to manage the project in a certain way.
JC – What is the minimal set of models the user must define to be able to deploy the system?
JH – The bare minimum is the domain model and the GUI model. With this you can build your simple administrative application. If you want more business logic, then you can add microflows and business rules. And if you want to integrate your application with external systems you can use our DSLs for calling web services, external data sources,…
JC – I guess that your runtime environment is implicitly enforcing a specific software architecture
JH – In principle, we have chosen an architecture which is the way the runtime environment is implemented. This environment is implemented in Java so you can run it in any environment but you cannot change the architecture of your application. However, this is not something you want. You want to think in terms of business functionality, business rules, processes,… How this is implemented is abstracted out of the way.
JC – You mention on your web page that with Mendix you can develop applications 5x faster and for half OF the price. How have you validated this?
JH – We compare our offers WITH that of our competitors. Also, the way we do our sales is approaching customers and asking them to build in two weeks a proof of concept for one of the applications they need. This way we can show our productivity.
JC – How do you deal with non-functional requirements (usability, security,…)?
JH – This is an important part of application development. We can define very precisely what kind of actions on the domain entities (or in the workflow process) can be performed by each user role (using the Security DSL). For the usability part you can internationalize the applications and present the GUI in different languages. You can also add all kind of custom widgets to the UI to create a rich web experience.
JC – Could your tool be used for the development of critical systems (e.g. downtime periods) ?
JH – I think that right now we are very mature. We have done hundreds of projects with the tool and runtime engine with constant improvement based on the feedback. In fact, this is one OF the advantages of having company that focuses on delivering a product abd bit services because you really focus on improving the tool.
JC – How Mendix itself is being developed?
JH – The modeling environment is built in .NET technology because .NET has stronger user interface capabilities for Windows environments, but a lot of the other products around the main tool, as the app store, the cloud infrastructure and the applications to get feedback or requests from our partners, are built using Mendix technology.
JC – What are the main challenges WHEN developing a tool like Mendix?
JH – The single most important thing in building a successful tool is having a great team. If you can work with great people that care about every detail then the product can become really successful. The real challenge is creating such a team. From a more technical perspective, the challenge is creating the DSLs, to make them expressive enough to interpret them directly but also to make them simple enough to be used by non-programmers.
JC – I guess creation OF DSLs has been an iterative process
JH -Of course. When we build a new DSL we work in an agile way. Every week we have iteration meetings with people using the tool.
JC – Do you believe Mendix is a unique tool in the market or do you think you have some competitors?
JH – We are unique in our focus on simplicity, in making it easy for domain experts to build applications.
JC – And what’s the idea behind the Mendix App Store?
JH – Every Mendix developer can access the app store from the modeling environment. You can download model parts (i.e. generic patterns), widgets for your user interface (e.g. integration with Google Maps or Twitter) or plug-ins to integrate with other systems like SAP.
This way we can make application development even simpler because you can start with complete models and we can innovate even faster because we can release new plug-ins separately FROM the main product. We also allow partners to develop their own app for the store (we opened our API) and sell them or give them for free to get some visibility.
JC – Can you comment on the evolution of Mendix over the next couple of years?
JH – Simplicity will always stay KEY. We will move up in the abstraction level. We will try to define even higher level models to bridge the gap between process documentation, the requirements and the actual executable models. We will also focus on simplifying the deployment and other aspects of the tool through our cloud-based initiatives.
JC -And what do you think the evolution of the model-driven market is going to be? Will we witness a wider adoption of MDD by big companies?
JH – There will be a growing adoption of MDD but people won’t call it MDD. It’s more a movement that includes, what I see as the three main trends in the evolution of software development: cloud (avoiding infrastructure issues), MDD and app stores (in a broad sense: building an application from scratch but by combining prebuilt components from other sources)
A very interesting interview that I hope you all have enjoyed. Visit Mendix web page for more information.