October 5, 2009. Talk. “Pragmatic model driven development”

Capgemini BAS, Faustlaan, Apeldoorn.

With Capgemini BAS joining Capgemini in 2009, some new initiatiaves in model driven development opened up, more particularly, hoping I’ve interpreted it correctly, based on naterual language. I discussed this initiative in June with Freek Bosch, manager of the unit where this natueral langauge based approach originated.


During the same inspriing conversation I illustrated the pragmaitc model driven development approach in our Accelerated Delivery Platform (ADP). Immediately Freek invited me to present our approach during one of his unit’s meetings. Unfortunately my agenda left little room until now. So I will drive to Apeldoorn in the morning, and discuss our approach during a one-and-a-half hour lunch meeting.

Think I will talk about the following subjects tomorrow:

  • Brief introduction of the Accelerated Delivery Platform.
  • Our agile requirements approach.
  • Modeling smart use cases.
  • Domain driven design – including value objects, enumerations, smart references, repositories and services.
  • Our appoahc to pragmatic model driven development, as used by a growing number of organizations.
  • How our code generator Tobgao MDA works – including templates and Tobago’s DSL.
  • And of course, last but not least – a demo. Buliding a fully working ASP.NET multi-layered web application.

Writing better software faster

Published in my Interesting Things column in SDN Magazine, November 2009.

Looking back on twenty years of software development, I must have spent most of that time trying to improve the quality and productivity of software development.

Ever since I started to write small applications in Turbo Pascal in 1988 I got infected with the writing-better-software-faster virus. Right after I finished the second of fourteen of these applications, I wrote my first framework. It took some effort, but writing the following twelve applications took me less time than building the first two.

Darkening perspectives

There are good reasons for increasing productivity and quality. First of all, we have to increase productivity by a hundred-fold to meet up with current demands, says Gartner. Furthermore, technology is becoming increasingly complex. Ten years ago I was working in both Microsoft and Java projects. Anno 2009, I’ve let go of the idea that I even have an overview of either one of them. It is hard enough working with a small subset of frameworks. A Silverlight designer is not likely knowledgeable in NHibernate. Being a Spring guru does not guarantee foxy JavaFX user interfaces.

Despite this darkening perspective, there’s techniques and technologies that might keep you from drowning, by simply raising the level of abstraction. Good frameworks help. Smart use cases certainly do. And even UML assists. And then there’s model driven development a.k.a. model driven architecture a.k.a. model driven engineering a.k.a. domain specific languages. Different names for generating code and other deliverables from a model. What model? To be honest, any model will do the trick. Business process models, use case diagrams, user interface models, domain models, and last but not least data models.

Empirical start

Eight years ago I was helping a customer set up the domain model for a help desk application. After that I started to build the software in ASP.NET. Having modeled all domain objects, their properties and their services, I was typing them out in C#. So, as any decent developer would do I wrote a code generator. That helped.

I suspect most code generation efforts have a similar empirical start. That’s probably why there are so many approaches to generating code. Some really high-brow, squeezing everything-and-the-kitchen-sink into a model, and then trying to generate the whole application. From front  to back. Or, at the very low and of the spectrum, inspecting the database, generating create-read-update-delete screens in a flat two-tier architecture.

Where’s the value?

Recently I was invited in a panel on model driven development, together with some academic and commercial experts. For starters, each of the panel members introduced their position briefly to the audience. This noteworthy event learned me two things. One: never allow four enthusiastic innovators talk freely on their innovations. The word brief isn’t in their vocabulary. Two: coming from a business background, I didn’t have a clue to what model driven development does in the academic world. A whole new spectrum of approaches met my eye.


So where’s the value in this? Following the good old Scrum adagio I’d say: it depends. Model driven development can be highly rewarding for projects. But I’ve also witnessed projects that made a terrible mess of it.

In my opinion, being successful at model driven development requires some preconditions to be met:

  • Embed approach. Successful model driven development projects share a single principle: it’s all in a day’s work. Model driven development is never a goal. It’s just a means to an end. Making better software faster. No guru’s, no heroes.

  • Allow changes. Projects go through changes. That’s a fact of life. Model driven development should never be blocking changes, but rather should stimulate creativity, by allowing projects to show quickly what effect new or changing requirements have.

  • Stabilize architecture. Knowing how to model, and where to generate what code is key. Set up a stable (layered) software architecture, pick frameworks that match it, and only then elaborate on code generation.

  • Be pragmatic. My general advice in life also holds for model driven development. Be pragmatic. Never overdo it. Don’t try to squeeze the whole world in your model. It’s not necessarily a bad thing to still have to write some code manually.


Having said all that, and having seen projects that very successfully apply model driven development, why is there still so much skepticism? After all, the paradigm really helps to deliver high quality at high productivity.

After witnessing both highly successful and extremely failing model driven development projects recently, I have given this some consideration. The vast majority of projects are in the middle of the wide spectrum of approaches. They run smoothly, being fairly practical. But it’s the failing projects at either end of the spectrum that draw the attention. Highly complex, slow moving, rigor projects on the one end, and oversimplified, bug-absorbing, underestimated projects on the other end. It’s no fun at either end.

No Jedi knight

My team and I have always adopted a highly pragmatic approach to model driven development, modeling smart use cases, applying domain driven design, run the model through our code generators (Tobago MDA) and we’re set to go. We do make better software faster.

Can life be this simple? It certainly can. We have applied this approach to all kinds of projects, and generated code in a variety of languages and frameworks, from Visual Basic to C#, from PHP and Java to Cobol. At the upcoming SDC, I’m going the check out a combination of Silverlight, .NET RIA Services, ADF and probably Fluent NHibernate. Should be fun!

To leave you with some words of wisdom (ahum). If there’s one thing I’ve learned from being successful at model driven development, it’s this: modeling and generating code should be everyday practice in your project. There’s no such thing as a “model driven development project”. There’s only software development projects. You don’t have to be a Jedi knight to steer a code generator. It’s all in a day’s work.

Pragmatic model driven development. Part I. Code generation scenario’s

Note. This series of posts is also published as a Capgemini group white paper and published in Software Release Magazine (in Dutch, in two parts).

With the economy at a low point in time, organizations and project are clearly resetting their goals. Long term multimillion projects are being halted, in favor of short, agile projects, with feasible goals and good time-to-target. To realize these stringent goals, projects are striving for lower costs and higher productivity. On the one hand these goals might be reached by outsourcing, on the other hand standardization, industrialization and reuse could also contribute.

A long term promise in the field of increasing productivity and reuse is to handcraft less code, but to generate code from the project’s design or model. In general this is called model driven development

When is model driven development effective?

Although many alternative strategies exist towards model driven development, we feel that a pragmatic approach works best. The more theoretical an approach gets, the harder it is to apply it to projects. In this paper, we present such a highly pragmatic approach to model driven development. We model and standardize smart use cases and the domain model for a project, and generate code and other deliverables from these models using a straightforward tool set. This approach has proven to be very effective in many projects.

Model driven development can be effective when code and other deliverables can be generated rather than written or hand coded. Thus tedious repetitive work is avoided, such as creating web forms, user interface panels, domain objects, table create statements, service interfaces and even writing use case documentation. Developers can now focus on developing business logic, or tuning the user interface. We have witnessed very high productivity in projects that apply pragmatic model driven development. For example, a recent project (.Net) at a large Dutch government agency was realized in 20% of the time the customer estimated the project.

As it is also fairly easy to create new types of deliverables simply by investigating your existing code and derive template from this, we can save time and effort in many scenario’s and development environments. Model driven development has proven to be successful in (partly) generating solutions for various types of projects, including ASP.Net, Silverlight, SharePoint, Visual Basic Window Forms, Java, service oriented applications (.Net and SAP), and even back end functionality.

Moreover, as code generation is based on proven templates, generated code is of higher quality then hand written code. Thus, model driven development also contributes to lowering maintenance costs of delivered software. This effect is further increased because the documentation as presented in the model is directly traceable to the application’s code.

Last but not least, in model driven development, analysts and designer actively participate in delivering working software, as the models they help creating, are now directly converted into code. Model driven development is a collaborative scenario, where, especially in agile projects even end-users can participate directly in software development. To illustrate this, we usually model the smart use cases and the domain model that, underlie the software we produce, during interactive workshops with the end users, and generate working software either in these workshops, or shortly after.


Code generation scenario’s

Generating code from a model can be done in a wide variety of scenario’s, and with a even wider range of goals and deliverables to strive for:

  • Proprietary techniques. Traditionally there’s tools such as Oracle Designer and Developer or Cool:GEN that host both the model as the coding environment. Using these environment high productivity can be achieved, because a lot of assumptions can be made on the target environment. In general such development environments deliver highly proprietary models and code.
  • DSL’s. Domain Specific Language (DSL) are textual or visual representations of custom domains, for which specific modeling language can be defined, think of web service definition or even a language for defining the mortgages or life assurance domain. With DSL’s again has the promise of high productivity, if and only if, the target environment can be clearly defined, for instance in the software architecture and framework that are used.
  • UML. The Unified Modeling Language (UML) provides a set of techniques for modeling behavior and structure of applications. These standardized techniques, such as use case or class diagrams are used in projects around the world, however in different variations and dialects. Generating code or other deliverables from a UML model is highly possible, again if the target environment is well defined.
  • Database. With proper modeling techniques lacking, many tools take the approach of generating (parts of) applications from the database structure. Although this approach seems appealing and fast, there are limitations. The generated application will mimic the database, and thus will be very data-centric, instead of providing support for the work processes to be automated. Besides that, in the current era of service orientation and cloud computing, many application do not even have their own database.