>> 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)