Model-Driven Architecture?

I have mixed reaction to some of the current enthusiasm on Model-Driven Architecture (MDA). Some of it is good stuff but much of that is actually just new names on long established ideas. Some of it is arcana that I can't make heads or tail of and this part seems to have little impact or benefit to practical systems development.

For example, a prominent element in Model Driven Architecture (MDA) is the difference between the Platform Independent Model (PIM) and the Platform Specific Model (PSM). Conveniently, these terms mean pretty close to what you would guess from the words. They are also very similar to the definitions of an "analysis" model versus a "design" model in the guidebook for my first job out of college... over 20 years ago. So, good ideas about the benefits of having levels of a distinction between "what" is to be built and "how" it gets built....but hardly novel.

It is also valuable to have a model because "model" conveys the expectation of completeness. It allows one to impose a little more engineering rigor than is common in free-text narratives of the system behavior. For example, in a model, you can do things like test for the logical correctness of a system based upon all the combinations and permutations of system inputs. You can check for race conditions and boundary conditions.... good stuff as well. It is valuable to be able to go from "dumb" pictures in Visio, to a systems engineering model in Rational Rose, and from there to "executable UML" (another MDA) buzzword that lets you run your model to observe the behavior and validate the results. Again, cool but several real-time engineering tools like Rose RealTime, Rhapsody, and Popkin System Architect with the appropriate plug-in) have supported this functionality for years. There is also a pretty long history out there for related simulation tools (e.g. Simulink)...though more common in other industries (e.g. defense or telecomm).

So, there are good parts to MDA but I'm at a loss to see how many are innovative. It is handy to have a new buzzword and to have some new enthusiasm for some old ideas. It also seems to be an effective vehicle for popularizing into general business systems development some ideas from real-time, mission-critical, etc. systems development....which is appropriate given the increasing complexity and criticality of modern software-intensive business systems in a highly connected world.

There are also some parts of MDA that strike me as impractical and I just don't get why people spend so much time writing papers or going to conferences on these ideas.

The first is the idea, or the expectation, about how automated the translation should be from the platform-independent model to the platform-specific model. This is an idea we (humanity and specifically the IT community) have been chasing around for years.....what a waste of time. It sounds good, that with a "click-click" and "drag-drop" we will be able to express our business functionality and the technical specifics of generating code, configuring servers, etc. will happen for us automatically (at this point speakers on this topic are usually making a dismissive hand waving gesture). There is a germ of a good idea here (see analysis v. design above) but taken too far it is just impractical. Products and technologies in a competitive capitalist society necessarily differentiate themselves and we (hopefully) deliberately select the elements of the technical architecture (language, database, rules engine, web app server, etc.) on those differences. So, when MDA zealots ignore this then they fly in the face of huge amounts of human endeavor....and continue to lose.

Another way of looking at this problem is that there is a vast set of tools that are proceeding nicely to be used for all sort of projects....and there are no mechanisms to support these tools within any significant MDA toolkit.Kennedy-Carter is a pretty popular MDA influenced tool (supports C++) but neither it nor any other tool supports web services.....which would limit the utility of this approach for very large web-based B2C systems (like It gets worse from here. Say "metamodel" three times and the typical technical executive has fallen asleep or left the room for a fresh coffee.

Object Constraint Language (OCL) isn't really an MDA idea but the OMG is trying to give it new life thru MDA. OCL is valuable as a means to logically specify system behaviors. Years ago business analysts studied logic in college or used some formally defined pseudo-code - either imposes a little rigor into our normally sloppy usage of the English language. As 3rd and 4th generation language got more friendly, using pseudo code fell out of favor but the idea is a good one. I often use OCL subversively (use it, just don't make a big deal about it). Some MDA folks take OCL too far, are impractical, when they dismiss the differences between languages (see point above - there is likely a reason to choose C#/.Net over Java/J2EE). To me this is reminiscent of the Esperanto - a cool idea but you still can't speak Esperanto anywhere and expect to find directions to the local train station.

- Brian