Approaches to Agile Model Driven Development (AMDD)

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

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 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 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)

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.

Figure 3. An AMDD approach to MDA.