In the 1965 movie The Flight of the Phoenix, a plane crash leaves a small group of survivors stranded in the Sahara desert. After abandoning all hope of being rescued, and with their water rations dwindling, the survivors resort to an unlikely plan proposed by one of the passengers, a German aircraft designer: they will build a small plane out of the remains of the original.

The other day, I came across an interesting article entitled "MDA: Nice Idea, Shame About the ... " [1]. Its author Dan Haywood is an experienced professional developer with particular expertise in modeling, so his critique of Model Driven Architecture (MDA) has conviction. While conceding that "MDA has at its heart some laudable objectives," Haywood poses the following six questions:

The Object Management Group's Model Driven Architecture (MDA) is slowly but surely gathering momentum. It's gaining adherents for several reasons, but probably the most important is that every large company faces serious enterprise application integration (EAI) problems, and MDA offers a solution. In essence, the solution lies in making various metamodels conform to a common meta-metamodel (the Meta-Object Facility, or MOF) so that specific metamodels can easily arrange to exchange data. Each specific metamodel defines a mapping to MOF.

I spend a lot of time looking at data and/or object class models. That's what you do if you consult in data warehousing and the large application space. These models come in one size -- wall chart. Some of them look like wiring diagrams for a Pentium 4. They are big, they are complex, and they are difficult to validate -- really difficult to validate.

Model Driven Architecture (MDA)1 is a broad church covering several approaches to Model-Driven Development (MDD). People often think of models as blueprints that are filled in with code. MDD automates the transformations among these several models. That is, MDA is commonly viewed as supporting "heavyweight" process-heavy modeling techniques.

Software modeling is getting more fashionable, but it has a long way to go before it becomes as respectable as writing code. Which is funny in a way, because code is just one particular kind of model! Too many people get hung up on the graphical nature of modeling techniques such as the Unified Modeling Language (UML), forgetting that they have underlying textual representations as well.

Software modeling is getting more fashionable, but it has a long way to go before it becomes as respectable as writing code. Which is funny in a way, because code is just one particular kind of model!

Over the past 30 years, more and more things have become digitized as very fast computers and very fast communication continuously change the world in which we live. However, digital riches are creating a new generation of digital problems, including digital asset management, which is the focus of this Executive Report.

Over the past 30 years, more and more things have become digitized as very fast computers and very fast communication continuously change the world in which we live. However, digital riches are creating a new generation of digital problems, including digital asset management, which is the focus of this Executive Report.

The capability to out-innovate the competition is becoming increasingly critical to business success. Taking innovation risks can lead to spectacular success, such as the Japanese DoCoMo mobile network, Google, and personal computers. But sometimes attempts at innovation become catastrophic failures and rise to the surface of public awareness. Examples of disastrous innovations include obsolete satellite networks and vastly overpaid-for new-generation mobile network licenses.