Agile Model Driven Development (AMDD)

Agile Model Driven Development or AMDD is the agile version of MDA (model-driven architecture). AMDD drops the requirement that models be formal and complete. Instead, models only need to be good enough to reach the real goal: the next release. AMDD often eschews using CASE tools in favor of a digital photograph of a diagram drawn on a whiteboard.[1]

With MDD, the goal is typically to create comprehensive models and then ideally generate software from those models. This is a great vision that may not be possible for all development teams. AMDD takes a much more realistic approach: its goal is to describe how developers and stakeholders can work together cooperatively to create models which are just barely good enough. It assumes that each individual has some modeling skills, or at least some domain knowledge, that they will apply together in a team in order to get the job done. It is reasonable to assume that developers will understand a handful of the modeling techniques out there but not all of them. It is also reasonable to assume that people are willing to learn new techniques over time, often by working with someone with those skills. AMDD does not require everyone to be a modeling expert; it just requires them to be willing to try. AMDD also allows people to use the most appropriate modeling tool for the job, often very simple tools such as whiteboards or paper, because you want to find ways to communicate effectively, not document comprehensively. There is nothing wrong with sophisticated CASE tools in the hands of people who know how to use them, but AMDD does not depend on such tools.[2]

Approaches to Agile Model Driven Development (AMDD)[3]
There are three different categories of approaches for applying AMDD to projects:

  • Manual Modeling: 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.
  • Agile CASE: Inclusive models are used to explore requirements with stakeholders and to analyze those requirements. Developers then use sophisticated modeling tools 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.

Core and Supplementary Principles of Agile Model Driven Development (AMDD)[4]

Core Principles:

  • Model With A Purpose. Many developers worry about whether their artifacts — such as models, source code, or documents — are detailed enough or if they are too detailed, or similarly, if they are sufficiently accurate. What they’re not doing is stepping back and asking why they’re creating the artifact in the first place and who they are creating it for. With respect to modeling, perhaps you need to understand an aspect of your software better, perhaps you need to communicate your approach to senior management to justify your project, or perhaps you need to create documentation that describes your system to the people who will be operating and/or maintaining/evolving it over time. If you cannot identify why and for whom you are creating a model, why are you bothering to work on it all? Your first step is to identify a valid purpose for creating a model and the audience for that model, then, based on that purpose and audience, develop it to the point where it is both sufficiently accurate and sufficiently detailed. Once a model has fulfilled its goals, you’re finished with it and should move on to something else, such as writing code to show that the model works. This principle also applies to a change to an existing model. If you are making a change, perhaps applying a known pattern, then you should have a valid reason to make that change (perhaps to support a new requirement or to refactor your work to something cleaner). An important implication of this principle is that you need to know your audience, even when that audience is yourself. For example, if you are creating a model for maintenance developers, what do they really need? Do they need a 500-page comprehensive document, or would a 10-page overview of how everything works be sufficient? Don’t know? Go talk to them and find out.
  • Maximize Stakeholder ROI. Your project stakeholders are investing resources — time, money, facilities, and so on — to develop software that meets their needs. Stakeholders deserve to invest their resources in the best way possible and not have resources frittered away by your team. Furthermore, they deserve to have the final say in how those resources are invested or not invested. If it was your resources, would you want it any other way? Note: In AM v1, this was originally called “Maximize Stakeholder Investment.” Over time we realized that this term wasn’t right because it sounded like we were saying you needed to maximize the amount of money spent, which wasn’t the message.
  • Travel Light. Every artifact you create and decide to keep will need to be maintained over time. If you decide to keep seven models, then whenever a change occurs (a new/updated requirement, a new approach is taken by your team, a new technology is adopted, …), you will need to consider the impact of that change on all seven models and then act accordingly. If you decide to keep only three models then you clearly have less work to perform to support the same change, making you more agile because you are traveling lighter. Similarly, the more complex/detailed your models are, the more likely it is that any given change will be harder to accomplish (the individual model is “heavier” and is, therefore, more of a burden to maintain). Every time you decide to keep a model, you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. Someone trekking across the desert will benefit from a map, a hat, good boots, and a canteen of water. They likely won’t make it if they burden themselves with hundreds of gallons of water, a pack full of every piece of survival gear imaginable, and a collection of books about the desert. Similarly, a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code.
  • Multiple Models. You potentially need to use multiple models to develop software because each model describes a single aspect of your software. “What models are potentially required to build modern-day business applications?” Considering the complexity of modern-day software, you need a wide range of techniques in your intellectual modeling toolkit to be effective (see Modeling Artifacts for AM for a start list and Agile Models Distilled for detailed descriptions). An important point is that you don’t need to develop all of these models for any given system, but depending on the exact nature of the software you are developing, you will require at least a subset of the models. Different systems, different subsets. Just like every fixit job at home doesn’t require you to use every tool available to you in your toolbox, over time, the variety of jobs you perform will require you to use each tool at some point. Just like you use some tools more than others, you will use some types of models more than others.
  • Rapid Feedback. The time between an action and the feedback on that action is critical. By working with other people on a model, particularly when working with a shared modeling technology (such as a whiteboard, CRC cards, or essential modeling materials such as sticky notes), you are obtaining near-instant feedback on your ideas. Working closely with your customer to understand the requirements, analyze them, or develop a user interface that meets their needs, provides opportunities for rapid feedback.
  • Assume Simplicity. As you develop you should assume that the simplest solution is the best solution. Don’t overbuild your software, or in the case of AM, don’t depict additional features in your models that you don’t need today. Have the courage that you don’t need to over-model your system today; you can model based on your existing requirements today and refactor your system in the future when your requirements evolve. Keep your models as simple as possible.
  • Embrace Change. Requirements evolve over time. People’s understanding of the requirements changes over time. Project stakeholders can change as your project progresses, new people are added, and existing ones can leave. Project stakeholders can change their viewpoints as well, potentially changing the goals and success criteria for your effort. The implication is that your project’s environment changes as your efforts progress and that, as a result, your approach to development must reflect this reality. You need an agile approach to change management
  • Incremental Change. An important concept to understand with respect to modeling is that you don’t need to get it right the first time; in fact, it is very unlikely that you could do so even if you tried. Furthermore, you do not need to capture every single detail in your models; you just need to get it good enough at the time. Instead of futilely trying to develop an all-encompassing model at the start, you instead can put a stake in the ground by developing a small model, or perhaps a high-level model, and evolve it over time (or simply discard it when you no longer need it) in an incremental manner.
  • Quality Work. Nobody likes sloppy work. The people doing the work don’t like it because it’s something they can’t be proud of, and the people coming along later to refactor the work (for whatever reason) don’t like it because it’s harder to understand and to update. The end users won’t like the work because it’s likely fragile and/or doesn’t meet their expectations.
  • Working Software Is Your Primary Goal. The goal of software development is to produce high-quality working software that meets the needs of your project stakeholders in an effective manner. The primary goal is not to produce extraneous documentation, extraneous management artifacts, or even models. Any activity that does not directly contribute to this goal should be questioned and avoided if it cannot be justified in this light.
  • Enabling The Next Effort Is Your Secondary Goal. Your project can still be considered a failure even when your team delivers a working system to your users – part of fulfilling the needs of your project stakeholders is to ensure that your system is robust enough so that it can be extended over time. As Alistair Cockburn likes to say, when playing the software development game, your secondary goal is to set up to play the next game. Your next effort may be the development of the next major release of your system, or it may simply be the operations and support of the current version you are building. To enable it, you will not only want to develop quality software but also create just enough documentation and supporting materials so that the people playing the next game can be effective. Factors you need to consider include whether members of your existing team will be involved with the next effort, the nature of the next effort itself, and the importance of the next effort to your organization. In short, when working on your system you need to keep an eye on the future.

Supplementary Principles:

  • Content Is More Important Than Representation. Any given model could have several ways to represent it. For example, a UI specification could be created using Post-It notes on a large sheet of paper (an essential or low-fidelity prototype), as a sketch on paper or a whiteboard, as a “traditional” prototype built using a prototyping tool or programming language, or as a formal document including both a visual representation as well as a textual description of the UI. An interesting implication is that a model does not need to be a document. Even a complex set of diagrams created using a CASE tool may not become part of a document. Instead, they are used as inputs into other artifacts, likely source code, but never formalized as official documentation. The point is that you take advantage of the benefits of modeling without incurring the costs of creating and maintaining documentation.
  • Open And Honest Communication. People need to be free and perceive that they are free to offer suggestions. This includes ideas pertaining to one or more models; perhaps someone has a new way to approach a portion of the design or has a new insight regarding a requirement; the delivery of bad news such as being behind schedule or simply the current status of their work. Open and honest communication enables people to make better decisions because the quality of the information they base on is more accurate.

See Also


Further Reading