Model Driven Architecture – a story from Real Life

Model driven architecture (MDA) will be more and more important in the future IT, because it allows to structure, design and fulfill complete software lifecycles on a process level as well as a controlled development level and in the maintenance phase.

I am glad that Thorsten Franz wrote his article Model-Driven Development in ABAP”), because I believe that we need these tools in development and use them as a way of structuring, planning and fulfilling applications. The “lonely wolf” ABAP-developer will have difficulties in the new world of Web Dynpro, eclipse and collaborative design.   

Model driven architecture (MDA) is the ideal method to implement a IT-wide  “Think first, then code”.  Actually, this is not new and a mantra that reappears every 10 years. In the 70’s, MDA first appeared with mainframes, in the 80’s, MDA was reborn with relational databases (James Martin and Associates), in the nineties with IBM Rational and in 2000 it found its ways with Java, .NET and eclipse. And every time it appears on the radar screen of IT project leads, it failed and vanished for the next decade.

I can report first hand why it failed. It is not because of the tools and it is not because of the idea itself. I strongly belief that Model Driven Development is the best way to think, to structure and to lead a project, up to the maintenance phase of the development. My role was that of an architect for a large project to develop an Internet-based procurement platform.

There are a lot of books written on MDA and the underlying method of patterns that are strongly tied to the needs of MDA and the ability to think in abstraction layers and to think in processes. There is a whole school around the famous “Gang Of Four” and their patterns: “Gamma, Helm, Johnson, Vlissides: Design Patterns – Elements of re-usable Object Oriented Pattern”. There is also a ERP-Version of this book: “Arlow Neustadt: Enterprise Patterns of MDA”

We used a great tool, eclipse-based, Windows-based and affordable and where the learning curve was acceptable. Development started and developers where presenting their models, talking about the round trip design and the database design.

The twist was discovered later: These models where all “Potemkin Villages”. While presenting the graphical models to the project lead and the board, the implementation was done “by hand”. The group had tremendous difficulties to translate the process and the design abstraction layers and relate them to generated code. It was not their way of coding, it was too formal and prohibits shortcut and hacks. They teamed up internally, did their work like they always did and pretend to do MDA. They started a “bunker” of hand-coded work.

After the cover-up was busted, the head developer left and sooner or later the others did as well. We replaced them with developers who had a proven MDA record, but they were really hard to find and it was late in the game.

The lessons learned for me is that MDA lives by design and people who can think in abstracts, patterns, processes and who are great developers in one person. You can imagine that no development department can stuff a full blown project with this kind of sill set.

But not the required skill set alone is an issue. MDA is expensive, especially in the beginning, regardless of the price tag of the tool. It is the learning curve and the implementation of the organizational framework. The payback is very late, in the maintenance phase and that is often not in the focus of the project and the budget.

If I talk to other MDA groups, it turned out to be similar stories: If it is a small group, a lighthouse-project, it probably works. But you will not be able to implement this in large cross-country (offshore) projects with some dozen’s or 100’s developers.

But all people who did a serious MDA project do belief, that MDA is the best structured way to do development and lifecycle management.