Strategies for Transitioning to Generative / MDA

1
Strategies for Transitioning toGenerative / MDA
Technology

• David Frankel
• Nicolas Farcet
• Tao Lu
• Ed Willink
• JP Tolvanen

2
Topics

• Assessing readiness of an organization
• Maturity Levels of an Organization
• Risks of adopting/not adopting MDA
• Identifying good/bad startup projects
• Scaling the approach up

3
Assessing Readiness

• Means to measure readiness maturity of the
  organization re generative techniques
• Experience with and attidude toward modeling
• Sketching vs. formality vs. code generation
• Architecture skills
• Obstacles/favorable conditions
• Legacy
• Culture of disciplined architecture

4
Maturity Levels of an OrganizationExtension to
CMM?

• Using models as documentation or instructions for
  humans
• Individual?collaborative
• Informal?formal
• Using models for code generation
• Adhoc generative techniques?Reusable generative
  techniques
• Informally specified transformations
• Formally specified transformations
• Implicit semantics ? explicit semantics
  (divergence of opinion)
• (Formal vs. informal)
• Isolated vs. compound transformations
• Use of generative techniques through entire life
  cycle
• Testing, deployment, management

5
Risks of Adopting / Not Adopting Generative/MDA
Technology

• Adoption risks
• Lack of clear roadmap for this technologhy
• Standards immaturity
• Tool immaturity
• Lack of tool interoperability
• New defacto/dejure standard suites appearing
• Inability to scale up
• Unrealistic expectations
• Skills deficit
• Risks of not moving at all
• Not allowing enough time for cultural change
• Missing commerical opportunities when maturity
  comes due to lack of readiness
• Missing opportunities now from customers looking
  for awareness

6
Identifying Good/Bad Startup Projects

• Criteria
• Tractability
• Small, short pilot project or
• Limited intervention within a project
• Some concern about this
• Lay a basis for future expansion
• Embarking on new projects or architecture revamps
• Resources devoted
• Pain points exist
• Stability and lifetime of functional requirements
  or of platform
• Identifiable family of systems for ROI on
  investment
• Serial than rather parllel repitition
• Architecture review delineation
• Mentoring the architects

7
Scaling the Approach Up

• Size
• Small size?large size?small size
• Scope of the adoption along dimensions of
  different communities
• IT functions
• Corresponding to lifecycle
• Domain engineers vs. application engineers (may
  be same in pilot)
• Business units (subject matter domain experts)
• Roll out over an organization
• Personnel orientation/training
• On IT side and on business side
• Minimize disruption as much as possible
• Make things familiar if possible
• Larger marking models early, smaller later