Skip to Content

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.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Eduardo Chiocconi
    Hi Holger,
        I really sympathize with your posting. Indeed I have been a strong believer that modeling driven tools help think on an abstraction layer that is above code. This usually helps think in the what before the how. I also believe that it would be naive to think that one tool can solve all the problems at hand. It is actually a combination of tools and each one being very good at what they do that can make the magic happen. Obviously, it is imperative that from a vendor tooling perspective, these tools can also seamlessly integrate together in the broader lifecycle that goes from design, implementation, deployment and maintenance AND on again into design to allow refinement of the application.
    It is true that it is very hard to find the silver bullet and the stronger your team is the higher the likelihood of success.
    In my view, each iteration (in each decade) has move the ball forward.
    In this decade, there has been a strong case for business process management and also application composition. Tools in these are have indeed offered abstractions to focus on models first. And they are good at this, but the hand over needs to go over to the next layer. In the case of BPM for example, it would need to integrate well with a Service Orchestration layer that can surface services that need to be orchestrated by a process simplifying the interface and interactions. The success on this layer, also translate into success to the upper layer. If we add Business Rules to this context, then we can start making this process centric application more dynamic and allow the owners of the applications to make changes without always relying on IT.
    As with every approach and methodology, you will need to learn the patterns and general guidelines on how to construct these types of applications.
    But it should be obvious at this time, that the bar is moving higher and not necessarily needing hard core developers to creating the business processes, workflows and rules. As you move down the stack, you will need more IT expertise, but this is always to be expected.
    I think there is more to improve moving forward, but MDA and the new incarnations are really helping us get to the next level.
    Great posting !
    1. Holger Stumm Post author
      Hi Eduardo,
      big cudo for your long reply. I never paid attention to the fact of MDA advancing through the decades, but it is obviously true. And it is also true that the skill focus moves from mere IT to Business analyst. I am looking forward to what is developing around SAP BPM in the near future.

      Thanks for your dialogue and time


Leave a Reply