I've been pretty harsh with respect to the Model Driven Architecture (MDA) in recent writings.  I still question the viability of the MDA for most organizations, although respect the fact that many people are still going to attempt it within their organization.  This begs the question "how do you take an agile approach to the MDA?"  Figure 1 summarizes what I believe to be a realistic "agile MDA" approach which applies the concepts of Agile Model Driven Development (AMDD) to the MDA. It's important to note that you need to look beyond MDA-based modeling tools to make MDA work.  Figure 1 depicts one of three basic AMDD approaches, the most complex one in this case.

Figure 1. An AMDD approach to MDA.

Below are some point-form thoughts which I will flesh out in the coming weeks.

Critical Success Factors:

• You should apply the principles and practices of Agile Modeling (AM)
• The primary goal is to produce working software which meets the needs of your stakeholders otherwise you're not really doing MDA.
• Active stakeholder participation is crucial to your success, so you need to find ways to work with your stakeholders effectively (see below).
• Testing is a critical issue throughout the entire development effort.  Acceptance tests should be included in your PIMs and technically-oriented tests in your PSMs.
• Take an evolutionary (iterative and incremental) approach.  Serial/traditional MDA isn't a very good option as the focus is often on the models/documents and not on the working software.
• Developers need to learn fairly sophisticated skills.  People/communication skills are critical, luckily agile developers are focused on these skills, but so are modeling skills (which few developers seem to focus on).
• You'll need a wide range of model to make this work.  Figure 2 maps the MDA model types to various modeling artifacts.  You don't need to create all of these artifacts, but you will need some.

Figure 2. Artifacts for Agile MDA.

Working with stakeholders:

• To work effectively with stakeholders, you need inclusive modeling techniques as Figure 1 indicated.  These techniques are simple and use simple tools, see www.agilemodeling.com/artifacts/ for a list, as well as Figure 2.
• Inclusive techniques foster Active Stakeholder Participation.
• Stakeholders don't understand complex diagrams, something we learned in the 1980s.
• Figure 2 includes inclusive modeling as part of the overall MDA vision (I've had to add this concept to the overall MDA picture).

Thoughts about UML & MDA:

• If you want to do the full tool-based MDA thing, you should use the inclusive techniqiues to gather info then capture the information in your tools.  Not ideal, but at least you have a bridge to your stakeholders.
• The MDA seems to be missing the concept of inclusive modeling.
• The transformation between inclusive models and PIMs is manual, requiring skill on the part of the modeler.
• The PIMs and PSMs require a sophisticated modeling tool, few are out there.  Bridgepoint, TogetherCC, and OptimalJ are leading candidates.
• The UML models seem to be oriented towards PSMs, not PIMs (hence you need to extend the UML to really support MDA, something we see the tool vendors do all the time).
• You'll likely need to go beyond UML even if you do take a visual approach.
• Figure 3 maps the model categories to various modeling artifacts, indicating which techniques are inclusive, which are complex, and which are "in between".
• We need to extend the UML beyond object and component technology.

Thoughts about Tools:

• I prefer to use simple tools for "up front" requirements/analysis activities, more complicated tools (e.g. CASE) for design.
• For MDA to work, PIMs (the up front models) need to be captured in the tool.
• You'll still need to code, either in a high-level action language from which program code is generated, or program code itself.  Depends on your tool choices.  Pick the approach that works best for you.
• Many tools seem to claim to be MDA, few really seem to achieve this goal.
• There is far more to succeeding at the MDA than just tools.
• It's doubtful that the tools will work together effectively, integration through XMI will fail in practice, so pick your poison and move forward.

Conclusion:

• MDA is still going to be hard -- you need the modeling skills, you'll become tied to your tool vendor, and so on (see the list of challenges).
• Most developers prefer text-based, not visual, approaches to "modeling" in my experience.  This makes me question a diagram-based approach for many shops.

Figure 3. Techniques for each modeling category.

Recommended Resources

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.