Model Driven Development and 9 reasons why Model Execution is a Different Ballgame than Code-Generation
Hans de Visser
on July 2, 2014
If you are looking to rapidly build, integrate and deploy web and mobile applications, there is a diverse spectrum of aPaaS (application platform as a service) solutions to consider, ranging from platforms focused on coding to high-productivity platforms focused on model-driven development (MDD).
In the high-productivity aPaaS category, targeted at rapid developers, you find multiple offerings that apply MDD principles in some form or shape.
Some vendors combine MDD with Code Generation with the goal to increase developer productivity. Others use MDD for simple apps and mix that with coding in a programming language for more complex parts of the application. All these approaches end up providing incremental productivity gains but miss the real opportunity that comes with MDD.
MDD’s true potential comes to light if it is not merely addressing the productivity issues of traditional coding methods. The key is to solve a way more fundamental issue: closing the gap between Business & IT and addressing the App Delivery Challenge.
The App Delivery Challenge
According to the Standish Group, 94% of large IT projects are either “challenged” (i.e., over budget, behind schedule or didn’t meet user expectations) or fail together. Of those that fail, 71% do so because of poor requirements management, notes CIO magazine.
History has shown that improving developer productivity alone has only marginal impact on the success of IT projects. To deliver better software faster—particularly those innovative apps dependent on knowledge residing in the business—organizations must finally make IT/business collaboration a reality.
This calls for an approach where MDD becomes part of the full app delivery cycle, starting with capturing the requirements, followed by iterative design, development and deployment. Modern application platforms do not only support the development phase of an app project, but go all the way and make the model the application, by combining MDD with Model Execution.
The Mendix Low-Code Platform is uniquely designed to close the gap between business and IT and foster collaboration throughout the whole app delivery lifecycle. As a consequence, we have made some key architectural choices, for example model-driven design and execution to support rapid change cycles, flexible application monitoring, controllable app extensions and built-in security meeting the most stringent standards.
In order to involve the business in the design and development of applications to a level where users can actively participate, we have fully adopted a Model-Driven Development (MDD) approach. MDD provides an excellent communication mechanism to align business and IT stakeholders, thereby ensuring greater quality and more successful outcomes.
Model-Driven Development has emerged as one of the leading approaches for enabling rapid, collaborative development. Because it uses visual models for defining data models, application- and process logic, user interfaces, etc., MDD empowers both developers and business users to rapidly build applications, without the need for labor-intensive, low-level coding. Consequently, it’s significantly faster than traditional programming languages like C# and Java.
Not all Modeling is Equal
The Mendix approach to MDD is to ensure that the graphical models can be understood and co-designed by business stakeholders. This is critical for the success and adoption of apps. In this context, choosing the right level of abstraction for the models is of the essence. On the one hand, business stakeholders should be able to really understand the models and influence the design. On the other hand, developers should be able to extend the models for the technical implementation to make them work. One example would be binding REST services to the process model to leverage a cloud based data service. This is why Mendix adopts industry standards like BPMN to model application and process logic. It’s a standard that is widely adopted in our industry.
The risk is that if MDD is applied on too low of an abstraction level with a proprietary modeling notation, it basically only supports developers to be more efficient, and still requires deep technical skills, including extensive knowledge about SQL to approach databases, defining transaction scope, and more.
Model Execution: What you model is what you execute
A key differentiator is that the Mendix Platform executes the models in the runtime. This contrasts to the approach of generating code (e.g. Java or .NET) from the application model in order to run the app. The challenge with code generation is that it’s inflexible and results in maintainability challenges and causes more hassle to cover security, scalability and performance requirements.
The Model is the Application: 9 Key Advantages
- Faster changes: Changes in the model don’t require an explicit regeneration, rebuild, retest, and redeploy step. This leads to a significantly shorter turnaround time.
- Controlled extensions: Extension of the model with custom code is controlled more elegantly as the model is aware of custom code through the API layer in the platform.
- Cloud deployment flexibility: A runtime environment (such as the Mendix Business Server) provides an additional layer on top of the infrastructure. Everything underneath is abstracted away—the essence of PaaS. Mendix is built for the cloud.
- Better portability: It’s easy to port a runtime environment like the Mendix Business Server to run on multiple platforms (e.g. multiple OS, multiple cloud platforms).
- Easier to deploy: For deployment, you just have to start the runtime server and put the model into it. Mendix automates this process with single-click deployment.
- More flexible to monitor: Monitoring of the application can be set up more dynamically and flexibly vs. defining monitor parameters beforehand, required for generated code.
- Easier to update: It is easier to apply changes to the runtime engine and restart it with the same model. You do not have to generate the code again using an updated generator.
- It’s more secure: You only need to upload your model on a (cloud) environment; there is no need to access the file system or other system resources. Only the code in the runtime server can access system libraries. Developers do not need to think about security other than configuring access control in the model.
- Analyze at runtime: As the model is available at runtime, it is possible to debug your models by stepping through them at runtime (e.g. you can add breakpoints at model level). Hence, domain experts can debug their own models and adapt the functional behavior of an application based on this debugging.
Considering that a significant portion of the Total Cost of Ownership (TCO) of applications actually comes after initial go-live, the Mendix approach to MDD and Model Execution translates to substantial savings and gains in agility and flexibility for application change cycles.
Prominent industry analysts recognize the advantages of model execution. Below is Forrester’s view on the evolution of development tools / platforms from classical coding to metadata (model) execution.
“Most of the new productivity platforms employ an underlying technology we call metadata execution to provide great flexibility in designing and maintaining applications. Simply put, the tools output definitions, not code, and the definitions are then interpreted by the platform to create the running application. Metadata definition is far more flexible than code generation, the productivity technique that preceded it.”
Forrester Research, The New Productivity Platforms – Your Solution To The AD&D Crunch
Business & IT Collaboration
Looking at the advantages of MDD and model execution, you may wonder how this translates to business benefits. Fundamentally, we believe that this approach helps to bring business and IT together. Too many IT projects fail due to the lack of business and IT collaboration, not so much because of lack of productivity.
Our focus is to actively involve business stakeholders in the process of design and development through models that can actually be understood and co-designed by non-technical people. Collaboration also calls for a highly iterative approach and instant feedback mechanisms in every stage of the lifecycle.
This is essential to build better applications faster.
Mendix is the only application Platform as a Service provider that supports the full app delivery lifecycle natively in the platform.
The “no lock-in” myth of code generation
Vendors that come from a more traditional approach, and haven’t made the step towards model execution, will want to make you believe that model execution in the runtime leads to vendor lock-in.
The truth of the matter is that every application platform, except for the most primitive technologies, has lock-in aspects. Application development teams are making a technology choice and are committing resources and know-how to this technology – effectively locking the team into the use of that technology for a period of time. Generated code, for example, is dependent on multiple libraries that the vendor adds for platform services. Should you want to migrate off these offerings, are you really able to maintain and extend applications that no developer has actually “developed” and takes ownership in? And how would you deal with generated code for the non-functional aspects of an application like security, scalability, performance and monitoring without the supporting platform? Just getting access to your code is not a remedy to avoiding lock-in as you’ll probably end up with a “don’t touch” black-box application.
From that perspective, it’s more relevant that vendors adopt open standards, so that migration becomes easier and lock-in is addressed at the source. For instance, Mendix does the following:
- Offers customers freedom of choice for public cloud, private cloud and on-premises deployment, including multiple options for public cloud infrastructure providers.
- Guarantees customer ownership of data, including transparency of the data model.
- Focuses on adoption of open standards for interchangeability. For example, the domain models to define the entities and their relationships are based on UML and can be imported and exported as XSDs. The microflows in which process and application logic is defined are stored as BPMN flows. The UI models are based on CSS3 and HTML5.
- Delivers inherent documentation. Because Mendix supports the full app delivery lifecycle, including requirements capture and linking user stories to design artifacts, apps developed in Mendix have built-in documentation and are fully transparent from a structure point of view. Since the model is the application, by definition the documentation cannot be out of date.
Should a customer want to move away from Mendix, there’s no better starting point for re-platforming than taking the model as documentation and exporting design artifacts. They’re guaranteed to be complete, accurate, and up-to-date.
While code generation has its merits, it is a legacy approach that offers only incremental productivity gains for programmers, without addressing the fundamental app delivery challenges that have plagued companies for decades.
Model execution, supersedes code generation, and represents an entirely new way to build and deploy applications that actively involves the business throughout the entire app delivery lifecycle. When the model is the application, companies can focus on solving business problems, without getting bogged down in technical details. The result is faster time to market, greater business agility, and immediate and lasting business impact.
Mendix has been designed from the ground up based on the principle that the Model is always the Application. The best way to explore the power of Mendix is to start using it by signing up for our free Community Edition.