In-Depth

Modeling in moderation

• By Robert L. Scheier
• March 1, 2005

Don't wait to finish the perfect physical model of an application before you generate your first line of code. Don't agonize over synchronizing every change to your requirements to every code tweak, either. And give up your dream that you can simply tweak the application model on your screen, "push the '"generate"' button, and out comes the modified system," Forrester Research Aanalyst Carl Zetie says. "In practice, it very rarely works that way. For most changes and most organizations, it's just too inefficient and too time-consuming."

Companies should model applications for only two reasons, Zetie says: "One is to increase our understanding of what we have to do. The other is to document what we decided to do for those who [succeed] us" in IT.

The companies that are most successful at modeling are those that take "a moderate and pragmatic approach," he says. They develop use cases only "when the requirement isn't obvious; when the flow of control is complex or obscure or hard to understand or crosses organizational boundaries."

It's unrealistic and unnecessary to synchronize every change made between a high-level model of the system down to the finished code, Zetie argues. "There are things you do in code that are simply not captured in the design, and things you do in the design that need to be compromised in the code." He suggests application modelers take a hint from data modelers, who accept that the models they create of databases often must change in the real world for performance or other reasons.

"Data modeling is hugely more successful and more widely accepted than application modeling has been," he says. "The data modelers are on to something with their pragmatism."

Back to feature: Visual Modeling's New Look