A roadmap for successfully introducing MDD into your organisation, in both concrete and human terms. Concretely measurable factors include the domain selection criteria, cost of getting started, and increased productivity when using. On the human level we will look at selling the idea, building mindshare, keeping momentum going, and managing organisational change. Drawing from our experience over the past fifteen years we pinpoint the key challenges organisations usually face during MDD adoption, and offer some practical solutions to overcome them. Tasks give you a chance to practise applying the ideas and ways of approaching and analysing, first to example cases and then to your own situation – past, present or future. * Is MDD right for this project? * Factors in tool selection * MDD Economics 101 * Language design for productivity * Getting the right people on your side Code Generation 2014, Cambridge, UK http://codegeneration.net/cg2014/sessions/index.php?session=30

1. Code Generation, Cambridge, UK
10 April 2014
10:45-12:15
Steven Kelly

2. © 2014 2© 2014 2
Contents
 Is MDD right for my project?
 Hard factors: MDD Economics 101
– Cost
– Time
– Productivity
 Soft factors: Fearless Change
– Selling the idea
– Mindshare
– Organizational change

3. © 2014 3© 2014 3
Domain-Specific Modelling: DSM
your language  your code
 Productivity increase: 5-10x
500 %
1000 %
750 %
600 %
900 %
500 %
600 %
0 %
100 %
200 %
300 %
400 %
500 %
600 %
700 %
800 %
900 %
1000 %
Embedded UI
applications
Mobile phone
software
Phone switch
features
Call
processing
services
Heart rate
monitor
J2EE web
application
Home
automation
Domains
Percent Increase
Compared to earlier practice
(typically hand-coding)
http://metacase.com/blogs/stevek/blogView?entry=3446309083

4. © 2014 4© 2014 4
Code ≈ UML ≈ MDA ≠ DSM
http://metacase.com/blogs/stevek/blogView?entry=3446309083

5. © 2014 5
Domain
Idea
Finished
Product
Model in
DSM
language
Easy!Normal
(many)
Done a few times before
Code
generator
DSM
language
Framework
code
What is needed for DSM:
put your expert in a tool!
Domain
Framework
Generate code
Expert
(few)

6. © 2014 6© 2014 6
Where to apply DSM?
 More than one developer doing similar tasks
– Or large portion of the work similar to earlier products
– Or several products made in parallel
 Domain expertise needed
– Non-programmers can participate
 Common cases include:
– Product Family
– Platform-based development
– Configuration
– Business rule definitions
– Embedded devices

7. © 2014 7© 2014 7
Choosing a good domain for DSM
 If you have more than one candidate, pick best
Organizational factors:
 Maturity of target business area in company?
 Many developers?
 Low coupling with external organizations?
 Related to other candidate domains?
 Extent of customization per customer?

8. © 2014 8© 2014 8
Choosing a good domain for DSM
Technical preparedness:
 Source code examples exists
– Offers a basis for the generator
 In-house framework in use
– Provide guidelines, programming model, best practices
(supported by the generator)
 Architect & expert developers available
– Never, ever try building DSM with summer interns!
 Software development process maturity?
– Should be mature, but not too locked down
http://tinyurl.com/ChoosingDomain Score your
domain(s)!

9. © 2014 9© 2014 9
Steps in DSM introduction:
proof of concept, pilot, deploy
 Effort and calendar time are different things
Proof of concept
Pilot
Deployment
Use
Time
~ Months ~
~ Weeks ~
~ Years ~

10. © 2014 10© 2014 10
Hard Factors: MDD Economics 101

11. © 2014 11© 2014 11
Limitations of less mature tools
 Single user
 Single modelling language at a time
 Simple metamodels
– Focus on objects, basic properties, binary relationships
 Simple notation
– Box + icon + labels
 Resulting modelling tool primitive
– Missing majority of functions users expect in such a tool
 Updating modelling language invalidates models
 Upgrading tool framework invalidates tool
 Hosted in IDE – benevolent integration or lock-in?
– Is the best UI design for coding also best for modelling?

12. © 2014 12© 2014 12
DSM Solution Implementation
Time
63 language concepts
XML generator
60 language concepts
C, HTML, script generators
36 language concepts
Assembler generator
77 language concepts
Python generator
Java generator for
simulation
143 language concepts
J2EE generator
Man days
http://metacase.com/blogs/stevek/blogView?entry=3446309083

13. © 2014 13© 2014 13
Independent tool comparison:
El Kouhen et al. 2012: language
12
6
0.5
5
25
0
5
10
15
20
25
30
RSA GME MetaEdit+ Obeo GMF
Days to implement BPMN
http://tinyurl.com/gerard12

14. © 2014 14© 2014 14
Co-opetition tool comparison:
LWC 2013: generators & framework
Ensō Más
SugarJ
Whole
Platform
MPS Onion
MetaEdit+
Rascal
Xtext
Spoofax
0
500
1000
1500
2000
2500
3000
20 30 40 50 60 70 80 90 100
SLOC
% Feature Coverage
Total SLOC vs. Coverage
Below/right of curve = better
http://erdweg.org/publications/language-workbench-state.pdf

15. © 2014 15© 2014 15
How to solve vendor lock-in?
 Use only tools that have interfaces!
– e.g. API, file-based (XML, or better)
 Language workbenches usually can’t lock you in
– Can make generators to export data to other tools
– Tools should also allow you to access the metamodels

16. © 2014 16© 2014 16
Economics
0
10
20
30
40
50
60
70
80
90
100
0 1 2 3 4 5 6
Cost
Repetitions
Current MDD

17. © 2014 17© 2014 17
Return on investment: Elektrobit
 10 days for 1st version of language & generators
– Estimate 1 more week for later improvements
 Product development with:
– Old way: 10 days
– DSM: 1 day
0 5 10 15 20
DSM
Coding
Days
Creating DSM solution
Test suite 1
Test suite 2
Test suite 3
Test suite 4
Test suite 5
www.thinkmind.org/download.php?articleid=valid_2011_5_20_40049

18. © 2014 18© 2014 18
Return on investment: Panasonic
 15 days for language and generator
– Apps into touchscreen device
 Product development with:
– Old way: 17 days
– DSM: 4 days
0 5 10 15 20 25 30 35
DSM
Coding
Days
Creating DSM solution
Product 1
Product 2
Product 3
Product 4
Product 5
www.dsmforum.org/events/DSM07/papers/safa.pdf

19. © 2014 19© 2014 19
Return on investment: Polar
 7½ days for language and generator
– Apps for sports computers
 Product development with:
– Old way: 23 days
– DSM: 2.3 days
www.dsmforum.org/events/DSM09/Papers/Karna.pdf

20. © 2014 20© 2014 20
Economics of DSM
ramp-up productivity
 Current practice:
– 6 developers
– 1 man-month per unit of application
 Month 1-4: Creating language and generators
– 1 creates the language and generators
– 5 continue to develop applications in old way, 1 unit/month
– 20 application units ready (cf. 24 with the old approach)
 Month 5: DSM deployment
– 5x more productive
– 1 maintains language/generators
– 5 use DSM, make 5 units/month/dev
– 45 application units ready (cf. 30)
 Month 6
– 70 application units ready (cf. 36)
App units in month
0
5
10
15
20
25
30
1 2 3 4 5 6
Month
Appunits
Current MDD
Current MDD

21. © 2014 21© 2014 21
Economics of DSM:
costs of tool & modeling work
 Value of app unit = 10.000
– Total effort costs
 Developer more productive:
– 50.000€ of value / month
– 40.000€ extra value / month
 Tools cost per developer:
– 250€ / month for tools
– Only needed after month 4
 Cost per unit down over 75%
– From 10.000€ to 2.450€
– Includes tools and language/
generator development
Months: 6 12
Extra app units 34 148
Extra value 340 000 1 480 000
Extra cost 2 500 10 000
Cost of 6 developers / month 60 000
Cost of tools / month 1 250
Total cost /month with MDD 61 250
Units / month with MDD 25
Cost / unit with MDD 2 450
Plug in your
own figures!

22. © 2014 22© 2014 22
Soft Factors: Fearless Change

23. © 2014 23© 2014 23
Organizing for DSM
 Building a DSM solution requires few resources
– Quality not quantity: Nokia, Panasonic, Polar 1-2 persons
– For lower-level DSM tools, need to add 3-5 coders
– May be best to start high-level, go low later if needed
 Team needs both domain and code expertise
– Best candidates are normally expert developers
 All must balance elegance with pragmatism
 Look for people who build macros and templates:
– For the whole team, not just themselves
– Prepared to maintain and document them
 Start looking for pilot DSM use project early

24. © 2014 24© 2014 24
Proof of concept
 Implement core subset of DSM solution
– Modelling language, generator, model for simple app.
 Shows concrete results to management
– Not just glossy brochures, books – or slide sets!
 Preparation:
– Outline scope for DSM, and part to be covered now
– Pick DSM creation team
– Add internal/external DSM expert, if possible
– Set workshop time (2 days), meeting with managers
• Ideally meeting is straight after
• Hard deadline focuses group on making concrete results

25. © 2014 25© 2014 25
Presenting things to managers
 Polish the presentation
– Nice looking models, animation, simulation
 Generated stuff follows known structures
– Documents are in company’s template
– Deployment guides/test etc. look like today’s
 Demo creating a model from scratch
– Shows what MDD looks in practice
– Also show larger, pre-made cases
 Discuss integration with existing processes/infra
 Describe opportunities that MDD makes possible
 Describe how it supports management’s goals

26. © 2014 26© 2014 26
Defining the DSM solution
 The PoC went well, management was happy, you
have a good handle on what to do next...
 Danger: pitfalls ahead!
– As Machiavelli put it:
"…thereis nothing more difficult to carry out,
nor more doubtful of success,
nor more dangerous to handle
than to initiate a new order of things."
 Beware of excesses, combat them with "let's see"
– Enthusiasm from managers
– Doubt, worry, conservatism from developers
 Take PoC as "build one to throw away"

27. © 2014 27© 2014 27
Organizational Change
“Fearless change: Patterns for Introducing New Ideas”
 Corporate Angel
– Support of high-level manager
 Local Leader
– Support of immediate boss
 Dedicated Champion
– DSM included in your job description
 Personal Touch
– Change happens one individual at a time
 Energizer
– Encourage those involved to share experiences
“Yes: 50 Scientifically Proven Ways to Be Persuasive”
Who’s who in
your case?

28. © 2014 28© 2014 28
First things first:
preparing for pilot project
1. Modelling language
– Concepts and inter-relations
– Rules
• Resist tendency to add too many to "protect" modellers
– Notation
• Simple for now, easily distinguishable
2. Example models and use scenarios
– Try the language out on (semi-) real applications
– Start thinking about clearest model reuse cases
3. Generators and domain framework
– Resist temptation to jump in early here
4. Integration to the rest of the process
– Minimum necessary at this stage

29. © 2014 29© 2014 29
Pilot project
 When language & generators ready for 1st real case
– Also need prototype documentation and training
 Separate team to test DSM solution
– Must be on a real application (not time critical)
– DSM solution creation team work "over the wall"
 Opens up modelling language to change again
– Modelling language was stable when making generator
– Grit your teeth and listen to criticism of your baby!
 Prepare for versioning nightmare
– All parts of DSM solution will be changing on the fly
 Gather rough productivity statistics and opinions
– They prove nothing, but are evidence nonetheless

30. © 2014 30© 2014 30
DSM deployment
 Learn about organizational change (Machiavelli!)
– Talk to IT department for tool roll-out experience
– Talk to old-time developer for process change experience
 Polish the DSM solution
– Decent symbols
– Generated code, framework, autobuild fit your standards
– Refactor generators for smooth evolution
– Learning material and training for modellers
– Documentation of solution for later evolution
 Introduction and evolution process
– Initial installation and upgrades for various DSM parts
 Get it right before you “ship”
– Bad early experiences colour opinions for a long time

31. © 2014 31
Europe:
MetaCase
Ylistönmäentie 31
FI-40500 Jyväskylä, Finland
Phone +358 14 641 000
Fax +358 420 648 606
USA:
MetaCase
5605 North MacArthur Blvd.
11th Floor, Irving, Texas 75038
Phone (972) 819-2039
Fax (480) 247-5501
info@metacase.com
www.metacase.com
Thank you!
Questions?
"Very practical and highly recommended"
Computing Reviews
"Excellent", Amazon review

32. © 2014 32© 2014 32
Literature and references
 Kelly & Tolvanen, Domain-Specific Modeling, Wiley, 2008
 Panasonic: Safa, L., The Making Of User-Interface
Designer: A Proprietary DSM Tool, Procs of DSM’07,
OOPSLA, 2007.
 Polar: Kärnä et al., Evaluating the use of DSM in
embedded UI application development, Procs of DSM’09,
OOPSLA, 2009.
 Elektrobit: Puolitaival, O.-P., et al., Utilizing Domain-
Specific Modeling for Software Testing, Procs of VALID,
2011
 MetaCase, Nokia case study, 2000
 Weiss, D. M., Lai, C. T. R., Software Product-line
Engineering: A Family-Based Software Development
Process, Addison Wesley Longman, 1999.
 Manns & Rising, Fearless Change, 2004
 Goldstein, Martin & Cialdini, Yes! 50 Scientifically Proven
Ways to be Persuasive, Free Press, 2009
See also URLs / references on slides

33. © 2014 33© 2014 33
Engineer testimonials
“I could define a domain-specific language in
about six hours - design, testing and one
failed trial included,” says Laurent Safa
“Modeling with MetaEdit+ was indeed quite
convenient and a lot easier to accomplish than
trying to achieve the same results with Eclipse
GMF,” Ulf Hesselbarth
“MetaEdit+ is by far the most advanced tool
in DSL category,” Markus Voelter
“MetaEdit+ was the most flexible tool,
allowed us to define own language syntax
quickly,” David Narraway
“MetaEdit+ is the most sophisticated DSM
tool,” Scott Ambler

34. © 2014 34© 2014 34
Asking developers opinions
 Survey results by Polar of 6 developers in
pilot phase (scale 1-5, 5 best)

35. © 2014 35© 2014 35
How to get data?
 Must balance cost of data vs. quality of proof
– 3 main ways to get data:
 Feedback from multiple colleagues
– Show your samples, or ask them to use MDD
– Effort needed: man-hours
 Laboratory study
– Implement a small, typical feature
– Several developers, several implementations
– Effort needed: 1-2 man-days
 Pilot project
– Implement whole product or large portion of product
– Usually by several developers
– Effort needed: man-months

36. © 2014 36© 2014 36
Important features in MDD tools
 Survey by MediaDev, 2007
0 %
5 %
10 %
15 %
20 %
25 %
30 %
35 %

37. © 2014 37© 2014 37
DSM as a continuous process
 Keeping the DSM solution team
– Staying with this domain for near term
• Minor consultation to parallel DSM projects
– Later some can become roving internal DSM experts
 Evolutionary forces
– Evolution of the domain
– Improvements to the DSM solution
– Broadening the scope of the domain
 Sunsetting the domain
– Make sure you mothball all tools and components
 Identifying new candidate domains

38. © 2014 38© 2014 38
How is DSM different from MDA?
 Same idea on using models and transformations,
but...
 DSM is always full code direct from models
– Not OMG MDA (elaborationist)
– Simpler in terms of versioning and management
 DSM = domain-specific language and generators
– MDA is UML-based*
 No reverse- or round-trip engineering in DSM
– We want a real lift in the level of abstraction
– How often do you reverse engineer assembler to code?
 Separation of concerns
– You are the experts in your domain and code (not the
vendor)
 DSM is agile: as much or as little as you want
* official definition, www.omg.org