It's 2023, and we are about to send people to Mars. If this is the future, why we still mostly code our apps manually? Everything that can be automated, should be automated in application development. We are moving towards software factories.

Model driven development (MDD) is an approach that uses models as a specification of software and transformations of those models to get the runnables and/or source code. The idea behind is that, it is possible to create models of a system that can then be transformed into a real thing [MacDonald et al., 2005] [Mellor et al., 2003]. Or simply: Feed your app definitions into the magic box, and out comes the working application.

Model contains your idea of the application to be built. You can think models as a requirement specification: You tell what kind of data your app handles, what processes the app implements plus some other details that shapes the resulting application. Transformations are a collection of processes, algorithms, logic and AI that examine your models, and then convert them into desired outputs; The most important being the working application.

MDD can be applied to any field of development, like hardware design or embedded systems, but LeBLANC focuses on line of business (LOB) applications, the apps that are essential to run a business.

Studies have shown that MDD reduces the effort of creating applications by 40-70% and made it possible to implement more features with fewer resources [Parviainen et al. 2009] [Domingo et al. 2020]. The findings are aligned with our experience from real world projects - we typically expect ~50% reduction in effort.

Where MDD fits

The best potential is in medium to large size apps, suitable for both greenfield development and app modernizations. Typical apps of this genre include system-of-records, billing, payments, inventory, marketing, CRM, content management, customer support and call centers, product management, ERP and such larg(ish) apps.

The productivity quantum leap

So the MDD really shines on the big ones where the effort is big. In real life, we tend to use MDD for all projects - big and small - to automate repetitive tasks. The key strategy using MDD is to focus on the essentials, and automate the rest. After defining the model, we usually expect to get 80% of the application done without writing single line of code. The essential 20% is where we put our effort.

Essentials

The essential 20% is the functionality that brings in the money, the reason the app exists. Things that have real business value. Things that are truly exceptional in your application. Things that deserve human attention. Such tasks include (but of course aren't limited to) tailoring personalized dashboards to each user role. Implement the behind the scenes back end logic and operations. Make the non-trivial integrations to your other systems, maybe even utilize an external API service or two.

Supplementals

The supplementals 80% we automate. These parts mostlly deal with the non-functional requirements (the ones that don't bring in any money, but have to be implemented anyway), like basic input/output operations, user and app management, logging, attachement, multilingual implementation, things that aren’t used often, or used by only few. And lots of other modern business app standard features.

Benefits

• Typically 80% of the application is automatically created from model and other definitions.
• Quality improvement, as the resulting code is error free. You only need to test the parts that involve human code, which inevitably leads to reduced effort.
• System is more easy to understand and communicate to others. Transformation is deterministic and code is coherent. The code has no alternating developer opinions on how the same task should be solved this time. Requirements defined in model result in same exact implementation when the tranformation is reapplied.
• Reduced design effort: Application architecture, patterns and idioms are implemented by industry best practices and encapsulate decades of experience on how to build business applications. This relieves you from dealing with details, and focus on the essentials.

Summary

Should we utilize MDD in our projects? Short answer is Yes. A bit longer one: The benefits are significant. Try MDD on a real life project, observe, measure and asses the results objectively. The decision is a business decision, not that much a technological one. And don't just take our word for it, read what Finnish State Treasury (Valtiokonttori) had to say about us! (in Finnish).

Let's keep this introduction short. If you'd like to hear more, just drop us a line!

References

• [MacDonald et al., 2005] MacDonald, A., Russel, D., Atchison, B., Model-driven Development within a Legacy System: An industry experience report, in Proceedings of the Australian Software Engineering Conference (ASWEC’05), 2005
• [Mellor et al., 2003] Mellor, S. J., Clark, A. N., Futagami, T., Model-Driven Development, IEEE Software, IEEE Computer Society, 2003
• [Parviainen et al. 2009] Parviainen, P., Takalo J., Teppola S., Tihinen M., Model Driven Development, Processes and Practices. VTT Working Papers 1459-7683, ISBN 978-951-38-7175-8, VTT 2009
• [Domingo et al. 2020] Domingo Á., Echeverría J., Pastor Ó., Cetina C. (2020) Evaluating the Benefits of Model-Driven Development. In: Dustdar S., Yu E., Salinesi C., Rieu D., Pant V. (eds) Advanced Information Systems Engineering. CAiSE 2020. Lecture Notes in Computer Science, vol 12127. Springer, Cham. https://doi.org/10.1007/978-3-030-49435-3_22