bject-modeling methodologies have long held the promise of enabling development teams to deliver higher-quality software faster and with better code reuse. Sadly, traditional object-modeling solutions such as the Unified Modeling Language (UML) have largely failed to fulfill this promise because they can't deliver frequent, tangible results in today's environments, where changes are coming faster than ever before.

This article explores the shortcomings of traditional object-modeling methodologies and explains how Model-Driven Architecture (MDA) provides a solution to the object-modeling challenge.

Current Software Modeling Challenges
Developing custom software and applications has always been a necessity for enterprises. While small and midsized companies can quickly build custom applications without significant pre-development effort, large enterprises cannot. Developing a complex application for a large multinational company is like building a 40-story office tower: without a blueprint, skilled manpower, effective tools, and—most importantly—sound architectural design, the building's foundation will simply collapse.

During the 1990s, the concept of object-oriented analysis and design (OOA&D) emerged as a silver-bullet solution to the challenges of complex enterprise application development. In practice, OOA&D is the use of object-modeling techniques that analyze a system's requirements in order to design a solution. OOA&D methodologies utilize multiple UML diagrams for requirements, design, implementation, testing, and deployment. Many enterprises succeeded using OOA&D during this time.

Unfortunately, the initial effectiveness of object modeling has begun to erode for a number of reasons, chiefly because technology changes at a breakneck pace. Solutions that work now quickly become obsolete. This dynamic nature, along with the following factors, is especially troublesome for enterprise-level software development teams:

• Business models changing more rapidly—The changes brought by mergers, acquisitions, joint ventures, and divestments shake the foundation of the common business model. Change is the only constant in today's enterprise, but complex, multi-tiered application architectures are not easy to change—which means rework and refactoring for development teams. Without a sound architectural design that supports long-term maintainability, retrofitting an application may take longer than developing it did.
• The problem of productivity—Once software requirements are agreed upon and the baseline is set, architects typically do as they're trained. They hold multiple joint application development (JAD) sessions, discuss high-level design and analysis concerns, and decide on a development process and deadlines for completion. This is where the design begins to lose its value. Instead of having developers implement it directly, the team loses time and risks requirements change while the architect first heads to the whiteboard to create use case, sequence, and class diagrams for the design.

  This may have been sufficient in years past, but today's development mandates demand a higher level of productivity. Eventually, a team has to stop drawing pictures and start writing code.

Editor's Note: The author, Eric Lynch, is a solutions engineer at Borland Software, a vendor of tools that support MDA. DevX selected this article for publication because we believe it to have objective technical merit.