This document discusses how model-driven development (MDD) can help balance architectural integrity and rapid delivery for agile projects. MDD uses models to represent problem and solution knowledge, provide a common lexicon, and serve as the basis for conversations about system relationships. Models and transformations can automate implementation knowledge to continually increase development velocity. The document provides examples of how to structure models and transformations simply and integrate MDD into agile processes and continuous integration/delivery practices. Case studies demonstrate how MDD rescued a failed project and bootstrapped a new development team.

1. Model-Driven Development for Agile Projects

2. Objectives
• Drive down development time and costs and increase product
quality
• Proactively head off technical debt and ensure architectural
integrity
• Jump start development projects with proven conventions
• Attain solution space knowledge continuity
• Drive down maintenance costs
• Enable platform-level refactoring

3. Balance Concerns
Architectura Rapid
l Integrity Delivery

4. Why Model?
• Models provide a representation of problem and solution
space knowledge that is portable and persistent
• Common lexicon for communicating concepts and building
understanding across all developers
• Picture is worth 1000 words
• Basis for conversation about the relationships of key
abstractions in a system

5. Software is Executable Knowledge*
• Books and similar media contain static knowledge
• Software encapsulates knowledge about how to solve a
problem in such a way that the application of that knowledge
can be automated
• Model-driven development allows us to use software to
automate our knowledge about how to implement software
systems
* Of Zeppelins and Jet Planes; Phil Armour

6. Model-Driven Architecture Theory
• A methodology wherein system functionality is defined as a
platform-independent model, using an appropriate
specification language and then translated to one or more
platform-specific models for the actual implementation
• The executable software is an output of a system which takes a
technology-independent description of the solution as an input

7. Not Just Code Generation
• A way to continuously encapsulate new development
knowledge in ways that can automate development
• Retain key business knowledge across heterogeneous
technologies
• Allow developers to focus their creativity on parts of
the system that matter the most to users
• Not just point-in-time activity

8. Types of Models
• Platform-Independent Model (PIM)
– Describes the business concerns of an application in a technology-agnostic
way
– Bridges between problem and solution spaces
– Holds true regardless of what technology is used to implement the system
• Platform-Specific Model (PSM)
– Describes how the PIM will be realized using a specific set of implementation
technologies (e.g. Java, .NET, Ruby, Objective-C, etc.)
– Describes the implementation mechanisms of a system
– PIM can be implemented using any number of PSMs

9. Keep Models Simple
• Pick a terse domain-specific language for the PIM
• The more complex the modeling language and
conventions, the less effective it will be in
communicating the essential information
• Don’t try to model everything
• “Advances” like UML 2.0 actually went the other
direction
– Made modeling less accessible
– Irony is the goal was to better enable MDA

10. Example DSL For Software Systems
• Entities
– Things that have state
• Controls
– Things that orchestrate interaction between entities to realize
some functionality
• Boundaries
– Sit between external actors and the system
• Enumerations
– A fixed list of values
• Primitives
– Simple, atomic types

11. Example Model

12. Codify Implementation Patterns
• Implementation patterns are platform-specific
• Architectural mechanisms
• Where do patterns come from?
– Previous development projects
– Prototypes
– Other peoples’ projects
• Encapsulate pattern knowledge into transformation
templates
• Defines the development conventions

13. Keep the Transformation Language Simple
• Minimum specification needed to access model
elements
• Minimum utilities needed to handle string functions
like capitalization
• Simple decision structures

14. Example Transformation Template

15. PIM + Transformations = Source Code

16. Benefits of MDD
• Improve developer productivity
– Automate development of “plumbing” code
• Increase the value of each manually developed line
of code
• Improve code quality and maintainability
– Convention-based approach limits entry points for manual
development
– Code generation drives up code consistency

17. Benefits of MDD
• Spend more time understanding user needs!
• Rapidly adapt to changing needs
– Refactor the templates to use new conventions or even
new programming languages
– Preserve platform-independent aspects of design
• Build systems that are self-documenting
• Spend less time starting new projects
• Decrease time to onboard new developers

18. Blending MDD and Agile
• Treat models as development artifacts not
documentation artifacts
• Keep it simple
• Model and generate code continuously
• Make implementation knowledge executable to
continually increase velocity

19. Minimize Waste & Keep it Simple
• Only model parts of system needed to implement current
iteration’s stories
• Don’t try to model everything
– Focus on key abstractions
– Too much detail leads to models that are overly complex and
difficult to maintain
• Don’t try to generate all the code
– Doing so can lead to technical debt in the transformation
templates
– Only generate code for architectural mechanisms you actually
need
– If figuring out how to generate something seems tortured
maybe it shouldn’t be generated!

20. Continuous Model Transformation
• Integrate model transformation into every build
• Ensures code and model are always in sync
• One-time or infrequent model transformations
– Same negative effects as not doing CI with source code
– Undermines value proposition of MDD altogether

21. CMT Implementation Strategy
• Put boilerplate code in
immutable base classes
– Re-generate immutable code
every build
• Put hooks for manual
development in leaf nodes
– One-time generation of
modifiable code, don’t re-
generate

22. Balance Rigidity Against Flexibility
Rigidity Flexibility

23. Putting It Together
Structural key abstraction changes
PIM Non-Modifiable Code
Value added behavioral and
Architecturally significant changes user experience changes
TT
T
Transformations
Modifiable Code

24. MDD + Testing
• Enable test developers to focus on test logic
development
• Use MDD to generate test helper components
– User interface element finders
– Access server components
• Do not generate verification logic

25. Atlas MDD Toolkit
• Open source (http://atlas-mda.org)
• Specifies a very simple DSL for describing systems
• Supports any modeling tool whose model representation
can be adapted to the Atlas DSL
• Model transformations developed using Velocity open
source template language
• Simple configuration of transformation target attributes
– E.g. output path, overwrite, etc
• Easily pluggable into common build environments
– Maven, Visual Studio, command line, etc

26. Support for PSM Guidance
• Platform-specific guidance when all the information
needed to generate code doesn’t exist in the PIM

27. Simple Configuration

28. Atlas Maven Configuration
• Plugs into the generate sources target

29. Case Study 1 – Failed Project Rescue
• Previous vendor:
– Took 3 years to deliver base functionality with unsustainable
technical debt
– Cost tens of millions of dollars
• Using MDD, our team:
– Re-implemented base functionality and established new
conventions and templates in 4 months
– Added several new high-value features
– Attained a 70/30 generated/hand-coded ratio
– Cost less than one million dollars
– Left the client with a model that described the system and a
development platform to add new features

30. Case Study 2 – Bootstrap Development Team
• Initial agile seed team formulated conventions and
architectural mechanisms during development of initial
stories
– Majority of technical complexity driven out
• Less experienced developers added to multiply
development throughput
– Conventions and plumbing already established
– Most development was “between the braces”
– New developers immediately productive
• Seed team detached and left less expensive, self-
sufficient team in place
• Led to multi-million dollar follow-on award to add
incremental functionality on product base