Approaches to Agile Model Driven Development (AMDD)

Recently reviewed

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

  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 real-world statistics around modeling and documentation strategies.


1. Manual AMDD

  • Overviewed in Figure 1
  • Simple tools and inclusive models are used for modeling
  • "The code is the design" philosophy is prevalent
  • Documents are still created, but the team is likely to travel very lightly
  • Drawing tools such as Visio may be used to create "clean" diagrams, although digital photos of whiteboard sketches are also common
  • This approach is basically what the Extreme Programming (XP) community follows
  • For years I suspected that this represents the approach taken by 70-80% of all development teams, and as you can see in Figure 4 this appears to be true (the light blue and dark blue colours represent this strategy)

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 DBAs 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. Real-World 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.

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.