Agile Model Driven Development (AMDD)

Table of Contents Overview Initial modeling Requirements Architecture Model storming Reviews Implementation How is AMDD different? Why does this work? Approaches to AMDD

1. Overview

As the name implies, AMDD is the agile version of Model Driven Development (MDD). MDD is an approach to software development where extensive models are created before source code is written. A primary example of MDD is the Object Management Group (OMG)抯 Model Driven Architecture (MDA) standard. With MDD a serial approach to development is often taken, MDD is quite popular with traditionalists, although as the RUP/EUP shows it is possible to take an iterative approach with MDD. The difference with AMDD is that instead of creating extensive models before writing source code you instead create agile models which are just barely good enough.
Figure 1 depicts a high-level lifecycle for AMDD for the release of a system. First, let抯 start with how to read the diagram. Each box represents a development activity. The initial modeling activity includes two main sub-activities, initial requirements modeling and initial architecture modeling. These are done during iteration 0, iteration being another term for cycle or sprint. ?a href="http://www.ambysoft.com/essays/agileLifecycle.html#Cycle0">Iteration _fcksavedurl=""http://www.ambysoft.com/essays/agileLifecycle.html#Cycle0">Iteration" 0?is a common term for the first iteration before you start into development iterations, which are iterations one and beyond (for that release). The other activities ? model storming, reviews, and implementation ? potentially occur during any iteration, including iteration 0. The time indicated in each box represents the length of an average session: perhaps you抣l model for a few minutes then code for several hours. I抣l discuss timing issues in more detail below.

Figure 1. The AMDD lifecycle: Project Viewpoint.

2. Initial Modeling

The initial modeling effort is typically performed during the first week of a project. For short projects (perhaps several weeks in length) you may do this work in the first few hours and for long projects (perhaps on the order of twelve or more months) you may decide to invest two weeks in this effort. I highly suggest not investing any more time than this as you run the danger of over modeling and of modeling something that contains too many problems (two weeks without the concrete feedback that implementation provides is a long time to go at risk, in my opinion).

2.1 Initial Requirements Modeling

For the first release of a system you need to take several days to identify some high-level requirements as well as the scope of the release (what you think the system should do). The goal is to get a good gut feel what the project is all about. For your initial requirements model my experience is that you need some form of:

Usage model. As the name implies usage models enable you to explore how users will work with your system. This may be a collection of essential use cases on a Rational Unified Process (RUP) project, a collection of features for a Feature Driven Development (FDD) project, or a collection of user stories for an Extreme Programming (XP) project.

Initial domain model. A domain model identifies fundamental business entity types and the relationships between then. Domain models may be depicted as a collection of Class Responsibility Collaborator (CRC) cards, a slim UML class diagram, or even a slim data model. This domain model will contain just enough information: the main domain entities, their major attributes, and the relationships between these entities. Your model doesn抰 need to be complete, it just needs to cover enough information to make you comfortable with the primary domain concepts.

User interface model. For user interface intensive projects you should consider developing some screen sketches or even a user interface prototype.

2.2 Initial Architecture Modeling

The goal of the initial architecture modeling effort is to try to identify an architecture that has a good chance of working. On the architecture side of things I抣l often create:

Free-form diagrams. I抳e found that 99% of the time we simply need to create some free-form diagrams on a whiteboard to explore how we think we抣l build the system. It抯 important to remember that you will still need to prove that the architecture works through code.

Change cases. An optional, and very interesting technique, at this point is to identify change cases which are potential architecture-level requirements which your system may need to support. Change cases allow you to test the long-term viability of your architecture without requiring you to overbuild your system because you can think through the impact of likely changes to ensure yourself that your system will still work.

In later iterations both your initial requirements and your initial architect models will need to evolve as you learn more, but for now the goal is to get something that is just barely good enough so that your team can get going. In subsequent releases you may decide to shorten iteration 0 to several days, several hours, or even remove it completely as your situation dictates. The secret is to keep things simple. You don抰 need to model a lot of detail, you simply need to model enough. If you抮e writing use cases this may mean that point-form notes are good enough. If you抮e domain modeling a whiteboard sketch or collection of CRC cards is likely good enough. For your architecture a whiteboard sketch overviewing how the system will be built end-to-end is good enough. I cannot say this enough: your goal is to build a shared understanding, it isn抰 to write detailed documentation. A critical success factor is to use inclusive modeling techniques which enable active stakeholder participation.
Many traditional developers will struggle with an agile approach to initial modeling because for years they抳e been told they need to define comprehensive models early in a project. Agile software development isn抰 serial, it抯 iterative and incremental (evolutionary). With an evolutionary approach detailed modeling is done just in time (JIT) during development iterations in model storming sessions.

My newsletter When is Enough Modeling Enough? addressed this concept in general. A more detailed discussion to come in the new year!

3. Model Storming

My experience is that the vast majority of modeling sessions involve a few people, usually just two or three, who discuss an issue while sketching on paper or a whiteboard. These ?a href="http://www.sdmagazine.com/documents/s=9346/sdm0410f/sdm0410f.html">model _fcksavedurl=""http://www.sdmagazine.com/documents/s=9346/sdm0410f/sdm0410f.html">model" storming sessions?are typically impromptu events, one project team member will ask another to model with them, typically lasting for five to ten minutes (it抯 rare to model storm for more than thirty minutes). The people get together, gather around a shared modeling tool (e.g. the whiteboard), explore the issue until they're satisfied that they understand it, then they continue on (often coding). Model storming is just in time (JIT) modeling: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before. Extreme programmers (XPers) would call modeling storming sessions stand-up design sessions or customer Q&A sessions.

You will model storm to analyze requirements. For example, a user may tell you that the system you抮e building must display a chart representing the bonus schedule for sales people. Together you create a sketch of what the screen will look like, drawing several examples until you come to a common understanding of what needs to be built. Sketches such as this are inclusive models because you抮e using simple tools and modeling techniques, this enabling the Agile Modeling (AM) practice of Active Stakeholder Participation.
Agile developers, including XPers, don抰 always go straight to code once they抳e chosen to work on a requirement (contrary to what detractors of agile development will tell you). This is because model storming is also very common for architecture and design. Java programmers will often work through complex code by sketching a quick UML sequence diagram, XPers will create Class Responsibility Collaborator (CRC) cards on standard index cards to explore detailed structural design problems, and Visual Basic programmer may choose to draw flow charts to model a complex business rule.
How do you support model storming within your environment? First, the more whiteboard space the better. Some companies are reluctant to put up whiteboards, apparently interior decorating concerns such as having attractive prints on the wall is far more important to them than making software development teams effective. My advice is to not only have a lot of whiteboard space available to people, you also need to ensure that it抯 visible to people once they抮e back at their workstations so that they can easily work from them. You抣l need to develop a protocol for working on the whiteboards, particularly when it抯 ok to erase something. Your team culture is also critical to your success, it must be acceptable to ask people for help and in turn to be asked to model with others. You need to recognize that this is a normal and effective way to work. I can抰 remember a project where we didn抰 model storm, yet I also can抰 remember reading a book or article which talked about this technique in any great detail. Wouldn抰 it be nice if the IT industry could start talking about what we actually do in practice, instead of what we think we should be doing? Call me na飗e.
It's important to understand that you don't require a whiteboard to model storm, you just need a shared, inclusive tool that people can work with easily.
Why does model storming on a JIT basis work much better than trying to model everything up front? First, like it or not, the requirements are going to change throughout the project. Second, by waiting to analyze the details JIT, you have much more domain knowledge than if you had done so at the beginning of a project. For example, if a requirement is to be implemented three months into a project, if you explore the details of that requirement at that point you have three months more domain knowledge than if you had done so at the beginning of the project, therefore you can ask more intelligent questions. Third, if you've been delivering working software on a regular basis your stakeholders now have three months worth of experience with the system that you've built. In other words, they can give you better answers. Fourth, modeling everything up front appears to result in significant wastage.
Having said that, sometimes you'll need to model complex requirements, or model legacy assets, a bit ahead of actually implementing them. This is actually a rare occurrence, regardless of what traditional modelers may hope for, but it does happen every so often.

4. Reviews

You may optionally choose to hold model reviews and even code inspections, but as I write in Model Reviews: Best Practices or Process Smells? these quality assurance (QA) techniques really do seem to be obsolete with agile software development.

5. Implementation

Implementation is where your team will spend the majority of its time, something that Figure 1 unfortunately doesn抰 communicate well. During development it is quite common to model storm for several minutes and then code, following common coding practices such as Test-First Design (TFD) or refactoring (Test driven design, TDD, is TFD+refactoring), for several hours and even several days at a time. You may even want to "visually program" using a sophisticated modeling tool such as Borland's TogetherCC or Rational Software Architect (RSA). Why does this work? Because your model storming efforts enable you to think through larger, cross-entity issues whereas with TDD you think through very focused issues typically pertinent to a single entity at a time. With refactoring you evolve your design via small steps to ensure that your work remains of high quality.
There are several interesting implications of Figure 1 is that it doesn抰 make sense to have people who are just modeling specialists on your development team any more. What are they going to do, model for a few minutes and then sit around for hour or days until they抮e needed again? What is really needed is something I call a generalizing specialist, someone with one or more specialties as well as general skills in the entire lifecycle, who can both code and when they need to model as well.

6. How is AMDD Different?

From a design point of view the AMDD approach of Figure 1 is very different than traditional development approaches where you create a design model first then code from it. With AMDD you do a little bit of modeling and then a lot of coding, iterating back when you need to. Your design efforts are now spread out between your modeling and coding activities, with the majority of design being done as part of your implementation efforts ?in many ways this was also true for many traditional projects, the developers would often do significantly different things than what was in the design models, but the designers would often blame the developers instead of question their overly serial processes.

AMDD is different from techniques such as Feature Driven Development (FDD) or the use case driven development (UCDD) styles of EUP and Agile Unified Process (AUP) in that it doesn抰 specify the type of model(s) to create. All AMDD suggests is that you apply the right artifact but it doesn抰 insist on what that artifact is. For example FDD insists that features are your primary requirements artifact whereas UCDD insists that use cases are. AMDD works well with both an FDD or a UCDD approach because the messages are similar ?all three approaches are saying that it抯 a good idea to model before you code.

7. Why Does This Work?

AMDD works for several reasons:

You can still meet your "project planning needs". By identifying the high-level requirements early, and by identifying a potential architecture early, you have enough information to produce an initial cost estimate and schedule.

You manage technical risk. Your initial architecture modeling efforts enable you to identify the major areas of technical risk early in the project without taking on the risk of over modeling your system. It's a practical "middle of the road" approach to architectural modeling.

You minimize wastage. A JIT approach to modeling enables you to focus on just the aspects of the system that you're actually going to build. With a serial approach, you often model aspects of the system which nobody actually wants.

You ask better questions. The longer you wait to model storm a requirement, the more knowledge you'll have regarding the domain and therefore you'll be able to ask more intelligent questions.

Stakeholders give better answers. Similarly, your stakeholders will have a better understanding of the system that you're building because you'll have delivered working software on a regular basis and thereby provided them with concrete feedback.

8. Approaches to AMDD

There are three basic approaches to applying AMDD on a project:

Manual. Simple tools, such as whiteboards and paper, and inclusive models are used for modeling. This is likely 70-80% of all business application modeling efforts.

Design Tool. Inclusive models are used to explore requirements with stakeholders, and to analyze those requirements. Developers then use sophisticated modeling tool for detailed design, (re)generating source code from the models. This is likely 20-30% of all business application modeling efforts.

Agile MDA. Very sophisticated, MDA-based modeling tools used to create extensive models from which working software is generated. At best this approach will be used for 5-10% of business application modeling efforts.

9. Translations

Spanish

10. References and Suggested Reading

Agile Architecture Modeling

Agile Enterprise Architecture

Agile Model Driven Development (AMDD) PPT Slides (Free Download)

Agile Requirements Modeling

The Agile Software Development Lifecycle (SDLC)

Comparing the Various Approaches to Modeling in Software Development

Examining the "Big Requirements Up Front (BRUF)" Approach

Examining The Model Driven Architecture (MDA)

The "Model a Bit Ahead" Pattern

When is Enough Modeling Enough?

		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.

10. 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.