Model-driven development (MDD) differs from model-based development and asks for agile development practices. It requires a standardized architecture to guide modeling and implementation, and specialized tools for defining modeling languages, transformations, and generating code. MDD leads to new roles for meta teams who build modeling tools and project teams who use these tools to develop applications. It has the potential to better align business and IT but also faces resistance due to the costs of learning and maintaining modeling tools.

1. 10 things you should know about
Model-Driven Development
Johan den Haan
Blog:
http://www.theenterprisearchitect.eu
Twitter:
@JohanDenHaan
@ModelDriven

2. Model-Driven Development
 Differs from model-based development
 Is still a software development approach
 Asks for agile development
 Needs a standardized architecture
 Asks for different tools
 Leads to a change in roles
 Can lead to business-IT alignment
 Needs another business model
 Is not enough
 Leads to resistance

3. Model-Driven
Development?

4. Automation

5. Abstraction

6. Productivity
 Short term: more functionality
 Long term: less sensitive for changes in
– Personnel
– Business requirements
– Development platforms
– Deployment platforms

7. It’s still software development
 Experience with approach and tool?
 Is the tool finished on time to start project?
 Abstraction vs. Rigidity: know your
limitations
 Version control

8. The law of leaky
abstractions

9. Innovation
distracts?

10. Asks for agile development
 Iterative modeling
– Iteration planning
– Model storming
– Test-driven executable model specification
 Knowledge crunching
 Stakeholders actively participate
 Requirements evolve troughout project

11. YAGNI also holds
for modeling

12. Asks for agile development
 DDD based DSL development
– Capture domain knowledge in a metamodel
– Communicate using an ubiquitous language
– Let the metamodel drive the implementation
– Isolate the domain
– Refactor continously
– Maintain metamodel integrity
– Use a people-oriented approach

13. Needs a standardized architecture

14. Needs a standardized architecture
 Functional principles
– Guide function design
– Are reflected in the DSLs
– Condition the model validations
 Constructional principles
– Guide construction design
– Are reflected in the generator
– Condition the domain framework implementation

15. MDD really enforces
architecture

16. Asks for different tools

17. DSL tool
 Workbenches:  Tool user activities:
– DSL workbench – DSL definitions
– Transformation workbench – Transformation rules
 Input: – Architecture definition
– DSL definitions – (Domain) framework
– Transformation rules implementation
 Output:  Examples:
– Solution workbench – openArchitectureWare
– Generator – MetaEdit+
– Microsoft DSL Tools
 Tool vendor activities:
– JetBrains MPS
– Meta language definition
– Transformation language
definition
– Workbench
implementations

18. Model-Driven Software Factory
 Workbenches:  Tool user activities:
– Solution workbench – Application modeling
 Input:  Examples:
– Functional specification – Mendix
 Output: – Mod4j
– Working application
 Tool vendor activities:
– DSL definitions
– Transformation rules
– Architecture definition
– Domain framework
implementation
– Solution workbench
implementation

19. Leads to a change in roles
 Meta team
– Building the Model-Driven Software Factory
– Using DSL tools
 Project team
– Building end-user applciations
– Using a Model-Driven Software Factory

20. Meta team:
domain expert

21. Meta team:
language engineer

22. Meta team:
transformation specialist

23. Meta team:
implementation / platform expert

24. Meta team:
software factory architect

25. Project team:
business engineer

26. Project team:
application / solution architect

27. Project team:
test engineer

28. Can lead to Business-IT alignment
 Specify software with domain-specific
concepts
 Domain experts really involved in
development process
 MDD makes software development more
agile
 Explicit connection between organization
models and models of the IT system?

29. Can lead to Business-IT alignment

30. Needs another business model
 Benefits
– Faster time-to-market
– Increased quality
– Involving domain experts leads to fit-for-purpose
– Follow fast changes in business requirements and
technology
 Costs
– Learn MDD
– Develop MDD tool
– Maintain MDD tool

31. Time = money?

32. Is not enough!!

33. Is not enough
 Integrating model and code
 More focus on changing applications
 Runtime flexibility
 Configuration vs. Model-Driven Development
 Adaptive modeling

34. Leads to resistance

35. Model-Driven Development
 Differs from model-based development
 Is still a software development approach
 Asks for agile development
 Needs a standardized architecture
 Asks for different tools
 Leads to a change in roles
 Can lead to business-IT alignment
 Needs another business model
 Is not enough
 Leads to resistance

36. 10 things you should know about
Model-Driven Development
Blog:
http://www.theenterprisearchitect.eu
Twitter:
@JohanDenHaan
@ModelDriven