Agile Modeling Logo

Approaches to Agile Model Driven Development (AMDD)

For the sake of simplicity, there are three different categories of approaches for applying AMDD on teams:

  1. Manual Modeling
  2. Agile CASE
  3. Agile MDA

To bring a bit of reality to the modeling conversation, something that has been sorely missed the past few decades, I've gathered some actual usage statisticsaround modeling and documentation strategies.

1. Manual AMDD

Figure 1. Manual AMDD.

2. Agile CASE

  • Figure 2 overviews this approach
  • Inclusive models are used to explore requirements with stakeholders, and to analyze those requirements
  • Sophisticated modeling tools are used for detailed design
  • Tool integration/interfacing may not be very good - object developers may use tools such as OptimalJ when creating their object schemas whereas Agile data engineers may use tools such as Erwin or Oracle Designer to developer their data schemas.
  • The modeling tools should support "round-trip engineering" with the code - developers should be able to model or write code and have the corresponding code/models updated automatically.
  • This approach can be taken by any type of agile team, including XP teams.
  • This approach is common for Feature Driven Development (FDD) teams.
  • Ideally the modeling tool should work with your unit testing tool(s) so that detailed design information can be captured as executable specifications .
  • Documents are still created, the team should still travel lightly, although more documentation is likely to be written because the tool "makes it easy" to do so. This may not be a good thing, so be careful and ensure you can justify every document that you create.
  • For years I suspected that this represents what 20% of all development teams do, but as Figure 4 shows this guess was a bit high (although not too far off)
Agile Modeling

Figure 2. AMDD with a sophisticated design tool.

3. Agile MDA

  • Figure 3 overviews this approach
  • Sophisticated, MDA-based modeling tools used to create extensive models from which the working software is generated
  • Inclusive models are used to explore requirements with stakeholders, and to analyze those requirements
  • The inclusive models must be translated into PIMs by the agile modeler
  • This approach is described in detail in Roadmap to Agile MDA
  • At best, I suspect we'll see roughly 5% of development teams achieve this vision, and frankly I'm being very generous with this estimate (Figure 4 appears to bear this out). And it'll mostly be embedded/real-time developers, not business developers.
MDA Distilled

Figure 3. An AMDD approach to MDA.

4. Industry Usage Statistics

The DDJ 2008 Modeling and Documentation survey explored how people approach modeling and documentation. Figure 4 summarizes the results of the question that looked into the primary approach to modeling, and regardless of development paradigm sketching was the most common approach to modeling (SBMT = Software Based Modeling Tool, my term for CASE).

Figure 4. Primary approaches to modeling.

Primary approach to modeling

I invite the research community to do some ethnographic research into the issues surrounding how development teams model in practice so that we can get solid figures around the issues that I explored in the DDJ survey. I'd really like to put an end to the incredibly naive modeling strategies that the modeling theory wonks keep trying to foist on us.