The Object Management Group (OMG) is trying to revive modeling within the software development community with their Model Driven Architecture (MDA) vision. Although this is a laudable goal, I fear that they're trying to take the industry in a direction that the vast majority of us don't need to go. Ready to plunge into some alphabet soup? Here goes … MDA is based on the idea that you should develop a platform-independent model (PIM) that's translated via your toolset into platform-specific models (PSMs) that reflect the realities of your technical environment. To accomplish this, the PIM(s) are highly detailed, comprising detailed Unified Modeling Language (UML) diagrams and platform-independent business logic code written using the OMG's object constraint language (OCL) or some form of action semantic language (ASL) or business rule language (BRL). Similarly, the PSMs are fleshed out with details, ideally with your modeling tool via a combination of diagrams and code. Whew! Have I used enough three-letter acronyms (TLAs) for you?
I do think MDA succeeds in a limited number of organizations –- it's had a few successes and will continue to have more, but I suspect that it will, at best, gain a 5–10 percent adoption rate in the IT industry. Why such a low success rate? MDA suffers from several challenges that are difficult to overcome:
1. A lack of comprehensive modeling skills within the IT community. You need to be an expert modeler to succeed at MDA, and there frankly aren't very many people with this skill set or the desire to gain it.
2. UML is still insufficient for real-world business applications. It still lacks a standard way to model user interfaces and databases, for example, and is still struggling with capturing business rules effectively. Until these gaping holes are filled, I don't anticipate it being applicable within many environments.
3. Many tool vendors claim to support MDA, yet few seem to do it well. A tool that still requires you to write the last 20 percent of the code, which always seems to be 90 percent of the work, isn't sufficient.
4. Interoperability between tools is virtually nonexistent. I still can't find a combination of two MDA-compliant tools that allows me to import/export models between them without information loss.
5. How do you test MDA-developed systems? Does the OMG really expect the industry to discard all the benefits we've gained from test-driven development (TDD)-based approaches?
6. How can we remain agile with MDA? Although Project Technology is doing some good work in this direction, I'm not seeing much movement elsewhere. Are the vendors beginning to realize that many of their tools don't support agile software development very well?
7. Most business stakeholders don't have the ability to understand complex PIMs, let alone actively participate in their creation. Are we to put ourselves at risk by erecting yet another barrier to communication between developers and business stakeholders? I'll explore this further.
The PIM concept is similar to the idea of logical models from the 1970s, and arguably, Constantine and Lockwood's essential model concept from the 1990s, which posit that you explore fundamental business requirements without taking technology concerns into account because implementation changes much faster than fundamentals. If you can find a way to abstract out the fundamentals, you'll have a valuable asset that you can maintain and leverage over time. There is significant merit to this tenet, although I question the MDA implementation of it.
In my experience, business stakeholders are, in the main, intelligent people who understand the business well. Because they're the experts, it makes theoretical sense that they be actively involved with the identification and analysis of their requirements. However, in practice, stakeholders typically lack the skills to do this by themselves -- they often can't see the big picture, nor are they trained in modeling techniques. Therefore, you must work closely with your stakeholders to get the job done.
In the 1980s, the user-centered design community clearly showed that the modeling techniques popular at the time, process modeling and data modeling, were too complex and abstract for most business stakeholders, who couldn't provide accurate feedback about the models' sufficiency. Almost 20 years later, I don't see how this has changed -- modern UML-based models are even more complex than their predecessors, often to the point where modelers -- let alone stakeholders -- struggle to understand them. Do you know any modeler who could list all of the UML 2 diagrams? How many business stakeholders do you know who are comfortable with UML activity diagrams, UML sequence diagrams or OCL? How many could even tell you what they are?
Granted, it's reasonably easy to teach people how to read simple versions of UML diagrams, but complex diagrams and their implications are beyond most stakeholders. Furthermore, UML-based techniques are complicated enough that it's unreasonable to expect stakeholders to become proficient at them without significant training -- even if they were interested in doing so. Worse yet, even most developers struggle to use UML-based CASE tools effectively. In short, MDA-based tools and modeling techniques seem to prevent business stakeholders from being actively involved with modeling. In this way, MDA promotes an exclusive approach to modeling that elevates modelers and excludes stakeholders within the overall development process. This might be good for modelers, but is it good for your organization? I don't think so.
If the MDA vision of PIMs isn't realistic, what is? In my experience, business stakeholders can be actively involved with requirements and analysis modeling, but to achieve this, we need to adopt simple tools and techniques that they understand. We must adopt an inclusive, rather than exclusive, approach to modeling. By doing so, we increase the chance of understanding the true requirements of our stakeholders because we actively involve the experts in a manner that they understand.
What modeling tools are accessible to business stakeholders? The simpler, the better: paper-based tools such as flip charts, sticky notes and index cards. Whiteboards are another favorite tool of mine, and if you need to retain your sketches, you can either transfer them to paper via hand or use a capture tool such as a digital camera or Mimio ( http://www.mimio.com ).
What modeling techniques are stakeholder-accessible? Once again, the simpler the better. The most common models that I've ever seen are free-form sketches drawn on whiteboards or with diagramming tools such as Visio ( http://office.microsoft.com/home/office.aspx?assetid=FX01085798 ). These types of diagrams seem to come naturally to people, so it makes a lot of sense to use them -- why teach people a complex modeling notation when they already know a perfectly good approach? Other techniques, such as essential user interface modeling, essential use cases, user stories, feature definitions and class responsibility collaborator (CRC) cards, are easy to teach, yet very effective.
The PIM concept has merit, but I question the MDA version. At a meta level, MDA is effectively a PSM that reflects an environment based on complex modeling tools used by very sophisticated modelers. If you have access to these tools and people, perhaps MDA is for you. However, this isn't reality in most organizations. A far more realistic "meta PSM" for modeling is based on an environment using inclusive modeling tools and techniques that enable your business stakeholders to take an active role in your project. You may choose to adopt a sophisticated modeling tool such as Together ( http://www.borland.com/together/ ), OptimalJ ( http://www.compuware.com/products/optimalj/ ) or ERWin ( http://www3.ca.com/Solutions/Product.asp?ID=260 ); these tools are "close to the metal," enabling evolutionary detailed design. It's best to give complex tools to developers and simple tools to your stakeholders -- just as my grandfather always said: Use the right tool for the job.
When it comes to modeling, I suggest that you step back and ask yourself what actually works in practice. Requirements modeling is best done with simple, stakeholder-inclusive techniques that everyone can understand.
RECENTLY ON THE AM MAILING LIST
>>The Bridge-Building Analogy
The classic "building software is like building a bridge"
debate rages on. Although there are some parallels in that
both include modeling and construction activities, there are
some significant differences: Software is much more malleable
than steel, requirements for software are more likely to
evolve, and requirements evolution is easily supported in
software development (if you choose to work that way). Other
analogies were suggested, such as Darwin's theory of
evolution and the creation of a theatre production, but it's
clear that the bridge analogy isn't going to be replaced
soon. I suspect that this is unfortunate for the software
profession.
>>Putting the Blame on Design
This ongoing conversation explored the differences between
traditional, often serial approaches to modeling and the
evolutionary approaches to modeling taken by agile project
teams. Many of the misconceptions that people have about
agile techniques, such as "you don't do requirements or
design on an agile team" or "agilists are anti-modeling,"
were discussed. Obviously, we need to more clearly
communicate the value of modeling on agile projects to the
development community.
>>Requirements Rarely Change, but Your Understanding Often Does
I floated this idea in response to an e-mail that I received
regarding some of my older writings. A few years back, I wrote
that requirements rarely change, that our inability to get them
right in the first place was the real problem, and that we
needed to get better at requirements modeling. This seems
to contradict Agile Modeling's principle of Embracing Change
(adopted from Extreme Programming), but I argued that it
doesn't. Clearly, change happens. However, most of the changes
to requirements reflect a growing understanding of the
requirement, and not an actual change -- we just didn't get
the requirement right to begin with. A highly iterative and
incremental approach that reduces the feedback loop is an
effective way to ensure that you get the requirements right.
HOT LINKS
The Agile Alliance home page is the best starting point for
anyone interested in learning more about agile
software development.
http://www.agilealliance.org
"Agile Enterprise Architecture" describes agile techniques
and philosophies for enterprise architects.
http://www.agiledata.org/essays/enterpriseArchitecture.html
Check out the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm
Get agile modeling training resources at
http://www.agilemodeling.com/training.htm
"Agile Models Distilled: Potential Artifacts for Agile
Modeling" provides links to pages that offer an overview
of various modeling artifacts, including inclusive ones
that business stakeholders can easily learn.
http://www.agilemodeling.com/artifacts/
"Examining the MDA" takes a hard look at Model Driven
Architecture (MDA), discussing its advantages and disadvantages.
http://www.agilemodeling.com/essays/mda.htm
Find the FAQ page for Model Driven Architecture (MDA) at
http://www.omg.org/mda/faq_mda.htm
Project Technology's home page for MDA is a great place to
learn more about "Agile MDA."
http://www.projtech.com/info/mda.html
Want to know more about Test Driven Development (TDD)? Go to
http://www.agiledata.org/essays/tdd.html
Not a hyperlink, but still worth a look: Check out Larry Constantine and Lucy Lockwood's Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design (ACM, 1999).
