Examining MDA’s Value Proposition

Model Driven Architecture (MDA) is marketed as the all-encompassing solution for your company’s CIO (http://www.omg.org/mda/executive_overview.htm). It is meant to solve age-old industry problems faced by Systems Analysts and Engineers. It is a means of rapid system design, development and implementation. These systems will be platform independent and will be able to communicate with past, present, and future information systems. It will also offer maximum flexibility for making changes to the system’s model which will then be automatically translated into all parts of the operating system.

As an Information Systems professional, I agree that this would be ideal. Being able to implement a system purely from a higher level design seems to be the utopia for supporting the technical functions of a business. After all, every large-scale system must have a well thought out design including a data model, business processes, use cases, interfaces, etc. The success of an information system relies heavily on the design that precedes the implementation.

MDA seems to be wonderful in theory and I recently saw the OlivaNova Model Execution System in action, which was quite impressive I must say. However, I have my doubts that MDA is the silver bullet that will solve all systems related problems.

One weakness that I see in the MDA approach to software creation is that it seems to remove a lot of the human element of software creation. Although OMG states that one of the core benefits of the MDA is that it focuses on business processes, it seems that “The problem with software development is that there is too much ambiguity in the problem statement and in the design description…” (Alistair Cockburn, Humans and Technology).

Alistair Cockburn, the author of several books on Agile Software Development and Crystal Clear, has written an awesome article titled, “Characterizing people as non-linear, first-order components in software development,” which identifies two main problems with trying to fit people into systems or models.

  • Problem 1. The people on the projects were not interested in learning our system.
  • Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.

Alistair talks about a tool, which resembles MDA characteristics, that was rejected by the technical team. Here is an exerpt:

I shifted over to tool development, working in an ethnocentric fashion as far as possible. I watched the designers of communications protocols, and discussed with them what might be their problems. My colleagues and I decided that, “The problem is that the people are still drawing at the whiteboard. Things will go better if we give them special tools so that they can draw directly into the computer and give them early execution of their designs.”

We spent several years developing an inference engine that would convert time-flow, interaction diagrams into a software architecture and rule system. Many groups were and are working on a similar agenda, e.g., Harel’s executable finite state machines.

We completed the prototype after several years and showed it to our would-be user group, and were shattered to hear them say, “No, thanks, we actually like drawing on the whiteboards. We don’t want to take the time to put the drawings into the computer. Um, may we use the drawing editor portion of your tool suite?” Listening to other tools vendors, we heard the same experiences, usually ending up with, “they use just the drawing editor portion.”

In my experiences with software development, I have found this to be true. Teams prefer to draw on whiteboards, and quickly implement the designs that they have produced. This process works well as the system is broken into small portions and worked on in manageable pieces. Close communication with people who will actually be using the system is vital during this process. End users think of the system in terms of interfaces, rather than the data model that sits behind it to support the interface.

It might be that I don’t have enough experience with MDA to give it a fair judgment. I would be interested in seeing more of it in action. MDA might just be the level of abstraction that brings the technical world to a new level of productivity. I am a big fan of working at the higher-level. That is probably why I enjoy building web software in Ruby, on the Rails framework. Perhaps I will be even more satisfied with the even higher-level development capabilities that MDA wishes to offer.