email article printer friendly more resources

Moving to Modeling
Don't expect your development team to look the same when building applications through models
by Peter Varhol

July 19, 2005

The rapid adoption of Java and object-oriented programming techniques, coupled with advances in software technology, has brought about application development techniques that were the stuff of imagination only a decade ago. Today it is at least theoretically possible to draw a structured diagram of an application solution, and generate that solution as source code, or even a full executable application. That application could run on multiple systems, as a distributed application, with the software components appropriately partitioned.

Much of this innovation was accomplished under the support of the Unified Markup Language (UML), and its prodigy the Model-Driven Architecture (MDA). UML enables developers to use diagrams to precisely specify the characteristics and activities of a software system. MDA moves past that to enable business analysts to specify a solution to a business problem using UML, and then apply transformations to automatically produce the software implementing the solution. Both of these technologies are standardized under the auspices of the Object Management Group (see Resources).

There are other modeling approaches, including some that are based on a formal, well-defined syntax and semantics. Whichever one you may use, it is likely that you adopted it because of the promise of bringing application development closer to the business problems it tries to solve.

The advantages of such a move are readily apparent. By tying the business problem closer to the technology solution, it becomes more likely that you successfully address that problem. There is less a chance that the problem and solution veer off in different directions because of poor communication. Modeling should also help speed up the development process, which gets solutions into the business more quickly, and modeling should also improve application quality—a problem that continues to plague enterprise applications. Because models can be tested for accuracy, and because the presumption is that code generation can produce higher-quality (though not perfect) code, applications should be more reliable.

A Rocky Road
If you are typical, the move from a code-based development process to a model-based one has been rocky. In all likelihood, you started with a pilot project that used either MDA or a similar UML-based approach to defining the application, coupled with code generation to implement the application. The project you chose was important, but not particularly demanding or time critical.

In many cases, the problems started almost immediately. If you look across different development teams, projects, and organizations, the problems can seem random in nature. In some cases, the modeling and code generation tools don't seem to work properly. In others, the pilot project selected didn't seem to fit well into the tools they acquired for the project. Sometimes the learning curve was too long, and didn't result in the promised improvements in productivity.

The ability to define applications using models and generating code is not a panacea. First, the syntax and semantics of the diagramming language of choice is complex and can be difficult to learn and use. Second, the types of applications you can write will be limited by the expressiveness of the solutions available from modeling languages. While these will likely expand over time, there will always be application architectures that can't be replicated easily through a modeling approach.

There can be many possible causes of problems in adopting modeling tools and techniques, such as insufficient training or poor project definition. But many such problems can be traced back to a team that was organized for the last project, which was done in the traditional way, by writing code to implement requirements described in text. Developing applications using models rather than code is a significant break from past practices, and many development teams don't do enough to prepare for those changes.

Last, and possibly most significant, enterprise IT groups aren't well-structured to take advantage of the efficiencies of modeling, which isn't a knock on enterprise IT, but rather a recognition of the reality that different skills and development processes are needed in an age of application modeling. This kind of organizational change can be difficult for many to grasp.