For the past six months, I’ve harshly criticized the Object Management Group’s Model-Driven Architecture (MDA) vision (www.omg.org/mda). I haven’t been alone: At OOPSLA 2003, Dave Thomas of Pragmatic Programming fame virtually flayed MDA alive, and even Microsoft has questioned MDA’s underpinnings. Why the criticisms? We’ve seen similar visions fail miserably in the past. Also, many correctly believe that MDA could take IT organizations seriously off track if they don’t navigate the software process waters effectively. Until now, I’ve complained loudly about MDA; now I present a viable, albeit challenging, vision for making it work.
From Generic to Specific
MDA separates the specification of system functionality from the specification of its implementation. To do this, MDA defines two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs). As the name implies, PIMs don’t take technology-specific considerations into account, a concept that’s equivalent to logical models from the structured methodologies of the 1970s and to essential models within modern usage-centered techniques. PSMs bring technology issues into account and should be transformations of PIMs that reflect platform-specific considerations.
There’s far more to MDA than just PIMs and PSMs—it defines guidelines for automated transformation between these models based on metadata-defined mappings. Basically, you should be able to define the business requirements and your analysis of those requirements within a PIM, select the target platform(s) for your system and then automatically translate the PIM into one or more PSMs. Necessary details are added to the PSMs, which are then translated into source code. Ideally, 100 percent of the code would be generated; realistically, you still must write some complex logic that the tools can’t model fully—most modeling tool vendors claim that they’ll generate around 80–90 percent of the code.
The transformations are bidirectional—changes to your code should be captured within the PSMs, and any business-related changes in the PSMs translated back into the PIMs. These “reverse” transformations allow you to work on any artifact at any time.
If realized, MDA promises to increase developer productivity dramatically—but I have several reservations. Here’s my vision for agile MDA.
How to Take an Agile Approach
[click for larger image]
An Agile MDA Overview
Simple diagrams, tests and iterative development are key to making MDA work.
First, you must extend MDA to include modeling activities with your stakeholders. Agile modelers insist on active stakeholder participation—stakeholders should be available to provide information, make decisions and even model the business requirements. To do this, developers need to adopt inclusive modeling tools and techniques: simple tools such as whiteboards and paper that are easy to use, and simple modeling techniques such as essential user interface models and class responsibility collaborator (CRC) cards, which stakeholders can easily grasp. We learned the hard way in the 1980s that stakeholders neither understand complex diagrams nor want to take the time to learn them. This suggests that the models typically supported by MDA-based tools will hinder communication with stakeholders rather than foster it. In the 1980s, we also learned that stakeholders can be active participants in modeling if developers are willing to use inclusive tools: Therefore, you need to extend your MDA modeling efforts with inclusive modeling techniques if you want to be agile. The simple nature of inclusive models often requires agile modelers to manually translate them into their modeling tools; you may be sketching at a whiteboard with stakeholders one minute and then sitting at your workstation translating the information into your CASE tool the next.
Second, the creation of working software is crucial, as it’s the primary goal of software development. Furthermore, agile modelers take a highly evolutionary approach, delivering working software on a regular basis, and with MDA, you’ll generate it from your models. The secret is to model in small increments; don’t try to create the all-encompassing PIM and then generate the all-encompassing PSM. I’d be worried if I modeled for several hours without producing working software, let alone several days or even weeks. Tighten the feedback loop to increase your effectiveness. Agile modelers will focus on a few requirements, generate the PSM for those requirements, and then create the software that fulfills those requirements. The goal is to validate the models with code and obtain feedback from stakeholders as quickly as possible. Never forget that your stakeholders are primarily interested in a system that meets their needs.
Third, you’ll need several models to get the job done. Although the diagram on page 52 indicates a wide range of available models, only a subset may be required. Your modeling tools must support an effective combination so that you can apply the right artifacts for the situation. PIMs and PSMs require sophisticated modeling tools, and luckily, a few such as Bridgepoint, TogetherCC and OptimalJ are available. A good tool is a start, but without skilled developers, it will quickly become shelfware.
Fourth, you must continually test—this is why tests are included in the diagram as potential modeling artifacts. Tests become critical models for you: Acceptance tests capture the fundamental requirements to which your system must conform, and technically oriented tests (unit, system and so on) validate your software’s “innards.” I firmly believe MDA tools must include extensive support for testing.
Fifth, accept the fact that you’ll still need to write some source code. The diagram indicates that you’ll need some form of action language in your PIMs and programming source code in your PSMs to implement functionality not generated by the MDA tools.
Is MDA For You?
For MDA to work in your firm, you must answer yes to each of these questions:
- Do you currently have on staff highly skilled modelers or people who could become so; if not, can you hire some?
- Can you retain these highly skilled modelers once you have them?
- Are your stakeholders sophisticated enough to actively participate in the creation of inclusive models—or can they understand the PIMs that you create?
- Can you find a modeling toolset that fulfills your actual needs?
- Are you willing to tie your fortunes to that of the tool vendor?
I’m still leery when it comes to MDA, although I recognize that a small number of organizations will be able to succeed with it. Stay agile by actively collaborating with your stakeholders, creating working software on a regular basis, integrating testing into your modeling efforts, and adopting tools that support these concepts. It won’t be easy to succeed with MDA.
Recently, in my Agile Modeling newsletter, I expressed several frustrations with MDA that you’ll need to overcome regardless of how agile an approach you take. These concerns are:
If you’re interested in learning more about MDA, start with MDA Distilled by Steve Mellor, Kendall Scott, Axel Uhl and Dirk Weise (Addison-Wesley, 2004) or Model Driven Architecture by Dave Frankel (OMG Press, 2003). For more thoughts about agile MDA, read Steve Mellor’s paper. A more detailed discussion of my ideas is posted at here.
Scott Ambler is a senior consultant with Ronin International Inc. His latest book is Agile Database Techniques from Wiley Publishing.