Markus Voelter has defined model driven development as “a software development approach that aims at developing software from domain-specific models. Domain analysis, meta modeling, model-driven generation, template languages, domain-driven framework design and the principles of agile software development form the backbone of this approach.”
MDD is quickly moving from a novel concept to a pragmatic business necessity in large corporations. The change is due in no small part to the advent of Eclipse. MDD requires tools. Prior to Eclipse, creating tools was an expensive proposition. One needed either to build the entire tool set from scratch or to commit to a particular vendor’s proprietary solution. Neither choice was particularly appealing. Now, with Eclipse, the best tool platform available on the market is free and open source. More importantly, it is designed with the specific intent of extending and customizing. With Eclipse, creating tools is down right cheap.
I will not go in to detail on the various ways of implementing MDD. Instead, I want to share some of the strategic objectives and advantages that I have seen first hand with implementing MDD.
There are several common strategic objectives for using MDD. The seven most common objectives that I have observed are as follows:
- Lower the overall cost of building large internal applications
- Speed time to build large applications
- Lower the risk of large applications
- Simplify development
- Lower the required skill level needed to work on large applications
- Expand the pool of resources that can work on large applications
- Leverage open source
The first three objectives should sound exceedingly familiar. What organization does not claim to want lower costs, faster delivery and lower risk? The other four objectives may sound new, even controversial. Some software professionals take exception to the objective of lowering the skill set necessary by contributors. Nevertheless, these objectives are inherently interdependent. Figure 1 shows a conceptual graph of the interdependencies of these seven strategic objectives. An organization will not achieve the objective of lower cost through MDD unless it embraces also embraces the objective of lowering the required skill set of contributors.
[img_assist|nid=3039|title=Figure 1 Seven objectives of MDD|desc=|link=none|align=undefined|width=411|height=375]
In pursuing these seven objectives, I have observed that MDD:
- Enables scripters to contribute to enterprise development
- Reduces both direct and indirect development efforts
- Increases the flexibility of reassigning team members
- Enables task-oriented management of development
- Enables advanced developers to focus on the hard stuff
- Manages complexity by displacing it to appropriate points.
These six advantages are concomitant with pursuing the seven objectives. I will discuss each of these advantages in sequence.
- MDD expands the talent pool available for enterprise software development
[img_assist|nid=3040|title=Figure 2 The inverted pyramid talent pool|desc=|link=none|align=undefined|width=489|height=199]
The supply of software talent becomes tighter with each year. Companies demand more and more automation. The talent pool is growing, but not growing as fast as demand. We have to import talent into the United States. We have nearly consumed the capacity of India to the point where it is no longer the cost advantage it once was. We have expanded off shoring into Eastern Europe, Southeast Asia, even China.
MDD enables us to move development effort higher on the inverted pyramid. Through MDD, scripters can contribute to enterprise software development.
- MDD increases speed of development by reducing both direct and indirect coding efforts.
MDD generates hundreds, sometimes thousands of lines of code through the automated application of templates to models. There are immediately obvious savings to generating redundant code rather than typing it out by hand and debugging mistakes.
What is not immediately obvious is how much is saved in indirect efforts. The templates define much of what would otherwise be arbitrary decisions that would have to be made by individual developers. MDD eliminates a great deal of meetings between developers to discuss how an interface is implemented, how it will be named, and how it will integrate with other interfaces. As one senior engineer stated to me,
“The game is not the tool; it’s the consistency.”
MDD enforces consistency. Arbitrary decisions that have to be made are made once and then replicated.
- MDD increases the flexibility of reassigning team members.
The code consistency provided by MDD enables developers to cooperate more easily and readily. First, much of the significant information is stored in the models, which provide an abstract representation that is easier to process and understand. Second, one developer can easily navigate another developer’s code, because it is organized in the exact same manner as his own. Third, exceptional code such as critical business logic is placed in predefined locations that are easily located by the developers.
All these factors lead to the flexibility of reassigning team members. One developer can pick up where another left off due to vacation or sick leave. Extra developers can be moved to sections of code that are falling behind or have expanded requirements.
- MDD enables task-oriented development such as the Agile methodology.
Agile development methodology relies on sound tasking of developers. The development team must be able to break work down into discrete tasks with specific estimates of effort. If you do not breakdown the tasks well, then you cannot manage well.
MDD helps with task breakdown in three ways. First, MDD facilitates working top-down. One model leads to sub-models which lead to artifacts. Second, the model components represent a predictable set of artifacts that are generated or customized. Third, MDD enforces greater consistency that enables direct comparison of time and effort across tasks.
In one project I saw, the MDD tools were wizard based. The wizards walked the developer through the questions and then generated a dozen or more artifacts. The wizard also generated a task list of things that the developer had to complete by hand. How hard would it be to have that task list feed into an agile software management tool?
- MDD enables advanced developers to focus on the hard stuff.
The initial reaction of many advanced developers to MDD is negative. Some see it as a threat to their job. Some see it as “dumbing-down” their work. Some see it as tying their hands and limiting what they can do. Negative initial reactions soon dispel as the advanced developers begin to use the tools.
MDD tools accelerate development and increase productivity for advanced developers as well. In MDD, advance developers do far less repetitive typing of code. They focus instead on the creative aspects of their work. Most advanced developers end up serving one or more of the following roles in an MDD effort:
• Building the tools themselves
• Modifying the framework to implement new patterns
• Mentoring junior developers
• Serving as a SWAT force, taking on the particularly hard tasks
Far from a negative experience, MDD makes the work of advanced developers even more rewarding. It also makes their work more valuable to the organization.
- MDD manages complexity by displacing it to a manageable point.
Hurst's Law states, “Complexity can neither be created nor destroyed; it can only be displaced.” One might also call Hurst's Law the Law of Conservation of Complexity. A corollary to Hurst’s Law would be, “Pay attention to where you are displacing the complexity.”
Hurst's Law is very important in information technology where new technologies claim to “greatly simplify” a complex business problem. These technologies are not making the problem simpler; they are instead displacing the complexity from one place to another. The new technology is beneficial if it displaces complexity to a point where it is more manageable than it was before.
If an organization does not pay attention to Hurst’s Law, then its information technology efforts can devolve into a game of “whack-a-mole”. The team pushes down on a problem here only to have a new problem pop up over there.
MDD works because it inherently embraces Hurst’s Law. The pattern developers solve the complex part once and place it in the shared framework. The tool developers identify the best practice once and incorporate it into the tools. The rest of the developers gain access to these solutions automatically through the generated code.
Like the strategic objectives, the strategic advantages of MDD are interdependent. Figure 3 shows conceptually how these six advantages reinforce one another.
[img_assist|nid=3041|title=Figure 3 Linkages between MDD advantages|desc=|link=none|align=undefined|width=363|height=327]
One cannot ignore the importance of Eclipse in achieving the advantages of MDD. Without Eclipse, large companies would have to either build the whole tool set themselves or tie themselves into a vendor’s proprietary solution. Without Eclipse, creating the tools for MDD would either be cost prohibitive or strategically impractical.
The strategic objectives and advantages of MDD are very compelling. Many large companies have already begun to deploy applications built using MDD techniques. The knowledge of the success from these projects is spreading. With each new success, MDD proves itself to be not only a novel concept but also a pragmatic business necessity.