Talk at Ecole des Mines de Nantes: In this talk I will tell you my story of developing a successful Model Driven Software Factory with a fast growing user base. I will cover topics like selecting a domain, designing DSLs, growing a DSL (evolution), generating the application, quality and testing, release planning, and creating a user base. I will also tell you how I came to the conclusion that there is no future for Model-Driven Development.

1. Why there is no future for
Model Driven Development
Johan den Haan
Head R&D Mendix
@JohanDenHaan

2. “It’s not the strongest who survive,
nor the most intelligent, but the
ones most adaptable to change.”
- Charles Darwin

3. Increasingly, the stability of an enterprise
is rooted in its ability to be dynamic, to
move fast and change quickly.
- James McGovern

4. Enterprise Systems, I mean. And not just a
little bit, either. Orders of magnitude
wrong. Billions and billions of dollars worth
of wrong. Hang-our-heads-in-shame
wrong. It’s time to stop the madness.
- Tim Bray

5. How to align dynamic
organizations and software?

6. Let me tell you the story of trying to
fix this problem with MDD…
1. Context
2. Domain analysis
3. Designing and growing DSLs
4. How I came to the conclusion:
“there is no future for MDD”

7. 1. Context

8. Who is our
target user?

9. How to support our target users?
 Model should be easy to
– Read
– Browse
– Search
– Keep consistent
 Deployment
– Should be easy / non-technical
– Model execution / interpretation

10. Browser
Styling & user interaction
CSS, HTML, JavaScript
Client-side logic
Server communication
JVM
Java
Flows & actions API & connectors
Access rules
ORM
Database
SQL
Data

11. Browser
Styling & user interaction CSS
Client-side logic
Rich Forms DSL
Server communication
JVM
Microflow DSL
Flows & actions API & connectors Mapping DSL
Access rules Security DSL
ORM Domain model
Database
Data

12. 2. Domain analysis

13. An MDSF is a product,
product development starts
with a customer need

14. Growing a user base
 Light-house projects
 Make it easy to start
– Documentation
– Templates
 Make a clear choice about your target user

15. Think about a methodology early
Process UI Information
Information Information UI
UI Process Process

16. 3. Designing and growing DSLs

17. How to prevent a property explosion?
 DSLs as declarative as possible
 Take time to understand the user’s problem
– 5 Whys
– Sounds easy, but it’s easier to forget
 Take time to come up with a feasible design
and implementation
 Create flexibility with action language
extension points

18. Example 1

19. Example 2
 Security metadata in database
– Employee may only edit fields of Customer if it is a
Customer of his own Company
 Metadata needed in e.g. UI
 Retrieving metadata can be slow on large
datasets

20. How to ensure
quality?

21. How to ensure quality?
 Be always backwards compatible
 Learn from reported bugs.
 Do not only test the technical implementation,
but also:
– Backwards compatibility
– Usability
– Productivity
– With new users frequently

22. Applications build with
an MDSF will suffer
from a double release
cycle

23. We need an
extension mechanism

26. Sounds like a nice success
story for MDD right?

27. 4. How I came to the conclusion:
“there is no future for Model Driven Development”

28. Example 1: let the customer sign-off the UI
design before starting the implementation

29. Conclusion 1
 If your MDD tool reaches a certain level
– Development isn’t the difficult part
– The challenge is to turn ideas / business problems
into a solution (model)
 Important elements outside tool
– Requirements gathering
– Project management
– Methodology
 Benefits of MDD strongly connected to Agile
– a mindset change!

30. Example 2: trying to arrange a server
to deploy a newly build application

31. Conclusion 2
 If your MDD tool reaches a certain level
– development isn’t the slowest part of developing
software
– Deploying and taking it in production is
 Automate
– Builds
– Deployment
 Cloud deployment
– Model-Execution-as-a-Service (MEaaS)

32. Example 3: building a
sales support system

33. Conclusion 3
 “Increasingly, the stability of an enterprise is
rooted in its ability to be dynamic, to move fast
and change quickly”
– Agile business asks for agile software
– We do not build software once, we evolve and grow it
during it’s full lifetime.
 Being able to change software is more important
than building it in a fast way
 Model-Driven Evolution needed in addition to
Model-Driven Development

34. Example 4: proportion of software
maintenance costs > 90%

35. Conclusion 4
 Development costs only comprise the smaller
portion of the total cost of software
ownership
 Maintenance / evolution costs are the bigger
portion
 Hence, pure Model-Driven Development
doesn’t matter that much

36. Example 5: selling an MDD tool

37. Conclusion 5
 Why do customers want to pay for MDD?
– Who is your customer?
– How big is your market?
 MDD
– is a solution for a software development problem
– is a technology enabler, no value itself
 Business agility is value, but not reached by
MDD alone

38. The story of trying to fix a business
problem with MDD
1. Context
2. Domain analysis
3. Designing and growing DSLs
4. How I came to the conclusion:
“there is no future for MDD”

39. Model Driven Development:
necessary, but not sufficient

40. 1. Gather requirements
2. Model your application
4. Gather feedback
3. Deploy
model version

41. 1. Gather requirements
2. Model your application
Agile Application
4. Gather feedback
Lifecycle Management
3. Deploy
model version

42. Why there is no future for
Model Driven Development
Credits to the full team at
Read more: www.theenterprisearchitect.eu
Connect: @JohanDenHaan