MDSF：访谈Mendix研发负责人Johan den Haan

　　之前写过一篇文章对Mendix进行了介绍，这是我非常看好的一个MDD厂商，它提高工具和基础设施来加速设计、继承、部署下一代商业门户和云应用。最近Jordi Cabot对Mendix的研发老大Johan den Haan做了一次访谈。

• Mendix成立的目的就是为了自动化不断重复的开发过程，他们希望通过一些工具和平台针对业务专家而不是开发人员来达到这个目的。
• 最重要的是提供可视化模型，只有这样才能更好的让业务专家使用它
• 不采用代码生成技术，而使用的是模型解释方法，这样可以做到一键部署和运行，而不需要再编辑、编译和运行
• 通过Mendix Cloud，可以部署模型到云端，还可以在App Store中销售
• 通过使用Java语言编写Java action，扩充micorflow来使用定制代码，解决复杂业务问题
• 使用敏捷方法来应用工具进行模型开发
• 最小模型为领域模型和GUI模型，如果有更复杂业务，可以使用microflows和business rules，如果要继承外部应用，还可以使用提供的DSLs来调用web services和外部数据源等
• 会实现一个特定的领域框架，这个应该不是业务人员需要关注的，他们关注的应该是业务功能、规则和流程等
• 经多年的应用，使用MDD比以往会快5倍以上
• 可以添加安全DSL、扩充自定义控件来解决安全性、可用性等非功能性需求
• 使用.Net开发Mendix工具，领域框架是JAVA平台，app store和 the cloud infrastructure等是使用Mendix本身来开发的
• 构建一个成功的工具最关键的是一个优秀的团队

 

　　以下为访谈内容，我直接转载于A coffee with Johan den Haan (Mendix)，对MDD刚兴趣的很值得看看。

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 a 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 of 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 get 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 model 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 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 afterwards 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 to reflect the new domain model

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 in 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 for us. 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 user interface 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 hundred of projects with the tool and runtime engine with constant improvement based on the feedback of all projects. In fact, this is one of the advantages of having company that focuses on delivering a product and not services because you really focus on improving the tool and including all feedback from partners using it.

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, is 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 have some competitors?
JH – We are unique in our focus on simplicity, in making it easy for domain experts to build applications.

JC – And moving to the cloud is another step towards this simplicity?
JH – If you look at software development, deployment and evolution are much longer phases than development. That’s why we move to cloud environment because then you can also abstract from this part of the process.

JC – And what’s the idea behind the Mendix App Store?
JH – Every Mendix developer can access the app store from the modeling environment (like with the iPhone app store). In our case, you can download model parts (i.e. generic patterns), widgets for your user interface (e.g. integration with Google Maps, twitter,…) or plug-ins to ingrate with other systems like SAP. This way we can make application development even simpler because you can start from 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 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 coffee with Johan den Haan (Mendix)

An Enlightening Interview with our Head of Research and Development

 

欢迎转载，转载请注明：转载自周金根 [ http://zhoujg.cnblogs.com/ ]