Model-Driven Design The model as core of major software projects

Software projects tend to involve systems with different technologies and shall be carried out efficiently by teams from several locations and companies. Therefore, it is worth (re-)considering and rethinking the idea of using models in software engineering.

Today, the modernization or engineering of a larger scale software system often involves numerous companies from different locations. Teams and processes must interact reliably across the globe and organizations. In addition, the system to be replaced usually has a heterogeneous architecture, as over the years different teams have worked on it and technologies and requirements have changed.

Managing diversity

To ensure the success of such projects, it is key to manage the diversity of the engineering tools, libraries, and programming languages used. This is best done by applying a stringent technology management and sharing an information and collaboration platform. This platform shall also allow organizing virtual, mobile teams and infrastructure-independent engineering – possibly even autonomous engineering in a local environment. Here, project setup and architecture play a key role. The platform shall also allow leveraging synergies, commonalities, and potential for automation.


For the implementation, a model-based approach is a good choice – which is not a new idea. In the past decades, Model-Driven Development (MDD) has been considered an option again and again. But usually, the effort has in no way justified the benefits. On the one hand, MDD – including the potential for savings – is limited to system development. On the other hand, organization, analysis, planning, testing, and operation cause considerable costs. At the same time, there were attempts to model the whole application, including the business logic, and generate it automatically. However, a model or a generator cannot provide the high flexibility required for the business logic. There will either be discrepancies between code and model, or too many implementation aspects will be included in the model.

A joint "project contract"

It is key to correctly define the scope of the model. In our approach of model-driven design, modeling and generation of code focus on the creation of the meta artifacts of a project. Based on the model, the generator can create the project setup, the build job configurations, and the packages. This results in a high degree of recognition. Engineers as well as integrators and operations are able to obtain, build, change, and install artifacts they haven't known before and understand arising problems. The joint "project contract" makes it possible to provide standardized carrying out of unit and integration tests, building and releasing of artifacts, and integration into continuous build and quality assurance tools across all applications. Once a new empty model for an application has been defined, the first generation not only produces the software artifact built, but also the continuous integration job and the ready to be installed package.

The modeling of services and data models with model-driven design is similar to model-driven development, while code generation is limited to data model, interface facades, and middleware integration. The aim is to provide a consistent basic structure, including the respective name conventions, that serves as a starting point. The business logic will then be implemented as usual by developers.

Documentation with real-time evaluations

The model also serves as a basis for a consistent documentation that may be generated at any time and reflects the software's current state. This allows, for example, generating service repositories and data model descriptions and to provide them online across projects, companies, and locations. If the model is versioned and stored in a database, documentation on various software releases is available, which allows comparisons between releases.

By standardized logging and tracing of events at applications' interfaces, it is in addition possible to generate evaluations automatically, for example of the performance of services within a system landscape. Evaluations can be directly generated into the online documentation, thus enriching static information with real-time evaluations. The answer to questions such as "Who uses my service when and how often?" or "How good is the performance of my service?" is only a few clicks away.

Focusing on what is essential

When modernizing or engineering software systems from scratch, the model approach may provide significant added value. The key point for the design of the model is to only generate project setup, build job configurations, and packages as well as the data model code, the interface facades, and the middleware integration – but not the business logic. When defining the features the model shall implement, it is advisable to adhere to the 80/20 rule, keep the model as lean as possible and to make the best use of the features. Used this way, model-driven design is a valuable option for engineering software systems that today are typically distributed and heterogeneous. This is particularly true when embarking on major or several similarly structured projects with re-use potential.

This article is a short version of our contribution published in inside it's series „In the Code" on April 7, 2015.