Why Agile MDA?

To some, the notion of putting "agile" and "modeling" in the same sentence makes no sense. The modelers worry that "agile" is a synonym for "hacker" in its most pejorative sense, while the agilists see lumbering heavyweight processes (and quite possibly lumbering heavyweight methodologists) that deliver the wrong system late at great expense.

The conflict between the modelers and agile programmers is perceived to be fundamental and large, partly because of differing technical focus "extreme" is an explicit reaction to deliberate processes and partly because of hype. Yet in reality the gap is quite small. Many of the good ideas of the Agile Alliance and XP (such as Sustainable Development, Estimate to Improve, and, especially, Customer on Site) are equally good in the context of models, and we can simply replace the word "code" with "executable model." Enough, anyway, that one of your authors could become a signatory to the Agile Manifesto in good conscience.

One root cause for this disconnect is the recognition of the verification gap. This gap comes about when we write documents that can't execute. Certainly, we can review them and draw conclusions about their correctness, but until we have something that runs, we can't know for a fact that they really do exactly what is needed. Moreover, in the time it takes to deliver a solution, the market and the technology may have moved on, which might make the delivered system, even if it's correct, irrelevant. Worse, some systems are "wicked," in that the existence of a solution changes the (perception of the) problem, which makes the effort to produce a complete and detailed specification document somewhat futile.

Agile methods propose to address these problems by delivering small slices of working code as soon as possible. This working functionality is immediately useful to the customer, and it can be interacted with, which might result in improved understanding of the system that needs to be built. As these delivery cycles can be short (say, a week or two), the systems' development process is able to adapt to changing conditions and deliver just what the customer wants. This eliminates the verification gap.

Because the language of a model is closer to the language of the customer, this enables deeper involvement of customers in reviewing the models. While you can't accomplish much of anything useful by having customers stare at code, you can get them to find flaws in your abstractions by explaining to them the models you're using to represent their world.

Agile MDA employs executable models, not code, as the primary artifact. Executable models are more abstract than code, though, which means that these models enhance communications with customers and improve the ability to interact with the customer's domain. Code does that too that's a primary reason for the focus on it within agile methods but even high-level languages involve consideration of concepts of little interest to a customer: list structure, distribution strategies, the niceties of remote procedure calls, and the like.