>> Announcer: From Boston, Massachusetts, it's theCUBE! Covering Cloud Foundry Summit 2018. Brought to you by the Cloud Foundry Foundation. >> Hi I'm Stu Miniman, and this is theCUBE's coverage of Cloud Foundry Summit 2018 in Boston, Massachusetts. Happy to welcome to the program another one the keynote speakers here at the show. Johan Den Haan, who is the CTO of Mendix. A company that handles, is in the low-code space. Had a nice demo they did yesterday. Thanks for joining me. >> Yeah great, great to be here, thanks for having me. >> Johan, first of all, tell us a little bit about your background, the company. We're here in Boston, there's connections to Boston for the company? >> Definitely, our headquarters is here in Boston. So if you look at Mendix as a company, we founded the company a while back, for the sole reason to solve the problem that application development and enterprise is still very hard and error-prone. I mean, if you think about statistics around enterprise software development, most of the projects fail because it's not fast enough, not aligned to do business, things like that. So what we do as a company is help other companies thrive in a software-driven world. To make sure that they can build software from initial idea to a working application with speed. So as quickly as possible in collaboration. Because if you build something, you want to involve business people and IT people, and let them collaborate on creating the right software solution, but also in control, because we're doing it for an enterprise so you want to make sure you can control the entire process and do it in a way that helps enterprises. >> Alright, so Johan, I think back to times in my career when you talk about a softer rollout. It's like oh we're going to do this big initiative, let's bring in the consultants, we're going to spend 12 to 18 months, which turns into 24 months, and we're going to spend a ton of money and we're going to bring this application that's for the enterprise, and going to do things great. Now I talk to some companies and they're like, "Oh hey, I'm doing my ERB rollout. "I thought it was going to take me six months, "I did it in three months because I spun it up in the cloud." That's kind of the infrastructure piece, but from the application side, there's this trend with Mendix, I see low-code in there. I think some people hear it, there's low-code, there's a more controversial term no-code out there. What does this really mean, because at the end of the day, I still have my application, I have my data, what am I building, or am I just taking components? Help us understand this trend and how it fits for Mendix. >> Maybe start with the infrastructure side, as you started there. If you look at infrastructure, what we've done there is basically abstraction and automation. That way, we moved up in the stack, and then automated all the things underneath. Which is valuable, but it's only a small piece of the application life cycle. And if you think about delivering an entire application, it's more than that. And in the development part of the life cycle, you can do the same thing. You can also do abstraction and automation because if you think about applications, then a lot of the elements are the same across applications. You think about an information system, you need to have some data, UI, logic of course, and the basics, and what you can do is abstract away to a higher level, maybe a visual level. That's what Mendix does, having visual models to define your data, your logic, the business processes, as well as the UI, dragging and dropping widgets, creating user interfaces across channels, so mobile web. And then turn these models into a working application automatically. But you don't have to worry about all the technical details like if I hit this button in my UI, will it actually properly call my beckons, and trigger an action and store something in the database. These are all things that can be automated. That's what the difference is across different applications. >> How does this relate to microservices architectures? >> That's a good question, because in a lot of cases if you hear people talk about lockout, or basically came from the whole model driven development movement, then people think that using visual models you extract from detail so you have less control, so you can only build simple toy applications. But that's not where we are nowadays. This is really a next generation of using models to drive software development, where you can have complex applications with the underlying architecture, to your needs. So instead of targeting a simple client server application, we target a microservices architecture. So you can quickly build these microservices, easily re-use data across these services, but all in a visual way. So instead of having to be an architect, and building all the cloud native elements in your microservices, you can just focus on the business functionality. And if you hit the button, it will generate this cloud-native microservice for you that can scale on, as we are on cloud foundation, on Cloud Foundry, for example. >> Great, maybe it might help if you walk us through it's tough to say a typical customer, maybe give me a customer example or two, as to the problem they were having, and how this helped them move faster, I'm assuming, as part of the outcome they're looking for. >> Let's start with a small example, so just to go through all the steps of creating an application. So one of our customers is this airline company, and they had an issue with productivity. Because the main thing for them is if you maintain an airplane, to get it back in the air as soon as possible. Because if it's on the ground, it costs you money, and if it's up in the air, it can bring you money, right? So one of the mechanics in this company came up with an idea for an application that would help him be much more productive. And that's, I think also, a core element of a lockout platform, is that this collaboration that we bring with the Mendix application platform is that you can involve these people in actually being part of the application delivery team. So this mechanic teamed up with somebody who knew Mendix and said whoa, my main problem is, when I lose time, is that I don't know where my equipment is. Because they have these large areas where they maintain these planes, and you have all this specific equipment that you need for different parts of maintenance. So the very simple thing of it is that they tax the equipment with IT beat-ons, and then you build a simple app that listens to all the locations projected on the screen, so what they did was build a simple data model. So, added some entities visually, like I have my equipment, there's a location to it, and I build a UI on top of that, so drag-and-drop some widgets, or google maps widgets, to visualize the location. And then some logic that if you hit a button, you want to look up in equipment, or you want to say you're using it so that somebody else knows that, and things like that. So in just six days, they've gone through this entire process, iterating quickly. And then, they had the app, and it saves them, I think on average, half an hour per day, per mechanic. So if you have a couple hundred mechanics, that's some real money on the table, with just six days of development but the key is that it's not somebody in the head office thought about how to solve the issue of maintainability and efficiency. But it was just somebody on the floor came up with a creative idea and had the tools to quickly experiment and get it into production. >> Great, so, we're here at the Cloud Foundry Summit, can you explain how Mendix fits with Cloud Foundry and then, what other solutions do you have out there because Cloud Native's a rather big environment these days. >> So if you look back, Mendix joined the Cloud Foundry foundation as one of the early movers. And the reason for that is that, when you start to look at this application life cycle and make it (mumbles) speed, calibration, and control do that's fast, then you start with development, but that's also just one piece. So, in the early days we had a customer that was building a work flow application, so automating a certain work flow for publishing magazines. And they were struggling in dot net's for six months already and they didn't have any tangible thing yet. So we came in, we were an early startup, via relations so they were like oh, you can try it. So six weeks later, we had this entire work flow automated, and then they said, we have to take this in production, because this will save us money on a daily basis. And then, okay, go talk with IT and they said well, Mendix we don't know what it is, and by the way, how do we learn this and we need to order hardware. That was the moment that we realized, it's not just about development it's about the delivery of the entire application. So it was called Cloud then, back in 2007 when we had this. We started to host application, made that do the same thing there so one click deployments to solve that issue as well, because you have the same thing that you need expertise to run applications. But instead of that we abstract away from the details and we just run it in the Cloud. And then in 2014, Cloud Foundry came up and we realized we should replace our home-grown past layer that we created with an open-source foundation so that we are completely portable because we want to offer our customers the freedom to deploy anywhere, whether it's on their private cloud running on one of the distributions of Cloud Foundry, on the IBM cloud, the SAP cloud. But I think it's a really happy marriage between Mendix, which is completely complimentary to Cloud Foundry. But both with the same philosophy about automating things, abstracting away from the details, and making it much more productive to develop application one handed but also to deploy and operate them. >> It sounds like a good fit for Cloud Foundry to handle certain things lower-level in the stack, while you're handling the upper-level in the stack. Is it only Cloud Foundry is Mendix supported on other Cloud solutions, or beyond Cloud Foundry? >> Our strategy is to be completely agnostic to underlying infrastructure, so we also run on any dock or base system. So Cubernitas, but also ECS from Amazon, for example. So yeah, whatever we can run a dock content on you can run Mendix and we can scale out because of our Cloud Native architecture. >> Who's the typical person that your company is working with? Is it the developer side that carries the business? Because developers often times do things but don't have the budget for them, and you mentioned some of the developer-operator challenges so I'm curious that Mendix is dynamic with companies. >> That's a great question, because if you look at the developer landscape, it's kind of widening. Because you don't have just the professional developer, that is able to build so far, but with low-card you have more business-oriented people that can join these teams as well. So if you look at the typical team that's building applications using the Mendix platform, I would call them Best Staff Ops teams. You have death ops joining operation development, but this is also joining the business into this same cross-functional team. So a typical team building software using Mendix is like if you have five people on a team, you often have one professional developer, but four people with a business background. They are tech savvy, they maybe have a background as a BI consultant or an SLP consultant or these kind of roles, but they don't have a computer science background, but they are involved in building the software. And a great advantage of course is that they are domain experts in the area they are building the software for. So you can be really enabling the business and being of value to the business. >> Last question, the company itself, how many employees, how many customers, just give us kind of a thumbnail of the company. >> So we have around a thousand enterprise customers. Company size is currently north of 350 people, growing fast. It's crazy hiring all the people that we need to, because the market is really hot. If you look at low-cord, I think it's really the next generation of application development becoming a main-stream option that any enterprise needs to have to deliver the applications they need. And slightly tied to your previous question, it's also solving the talent gap. You've seen all these rallying cries around, everybody needs to learn to code to solve the problem that we need more software than we can build. I don't think that is the solution. We will never have so many people that can develop software. We need a paradigm shift. And that paradigm shift will enable us to build software faster, 10 times faster than you're used to with traditional programming languages, but also with a much broader group of people. More business-oriented people, so a group of people that can use a low-code platform is minimally 10 times bigger than the professional developer group. And that's what we need to solve this problem in the software-driven world that we live in. >> Johan Den Haan, CTO of Mendix, thanks so much for joining me. I'm Stu Miniman, this is theCUBE Cloud Foundry Summit 2018. (upbeat music)