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.

MDA Is the Next Step
Today’s enterprise needs a new approach to object modeling, one that addresses these challenges while shortening the development cycle and minimizing project risk. The Object Management Group (OMG) introduced just such an approach way back in 2001: Model-Driven Architecture. The MDA paradigm evolves modeling and addresses the increasing complexity in enterprise system design. MDA is a group of related technologies that extends UML to enable model-to-text and model-to-model transformations to ensure that models can be more efficiently and practically used as the sources of development efforts.

MDA starts with the notion that the architect can craft a model of the core objects in the enterprise’s business domain. These objects are business objects only?with no forethought of the technology that will be used to build them. Once the architect is satisfied that his or her electronic model accurately reflects the real-world business model, the architect invokes the transformation pattern of an MDA-enabled modeling tool.

Once invoked, the tool iterates through every artifact it finds in the business model. Using the conditional logic encapsulated in the transformation pattern, it takes certain actions based on the objects it encounters. The output of this transformation is executable source code that is ready to compile, deploy, and run. With the technical architecture in place and functioning properly, the enterprise’s developers are free to program the business features that the end users require.

MDA’s Perceived Barriers to Adoption
Today, MDA has both proponents and detractors, but all would agree that its adoption has been slow. An April 2007 report by Forrester Research titled “The State Of Model-Driven Development” highlights a few widely held myths that may be hindering MDA adoption, but the objections I’ve personally heard most often from customers and peers are:

• MDA is complex and academic.
• MDA is rigid.
• MDA is just about code generation.

My response is MDA does not have to be formal; it can be practical and flexible. In fact, MDA?and the tools that support it?have evolved. I tell those who’ve previously dismissed MDA to consider the following:

• MDA is not just about UML thanks to domain-specific languages (DSLs).?The most effective visual-modeling tools allow for simultaneous round-trip engineering: draw UML, the tool writes code; write code, the tool draws UML. However, UML is often perceived as complex and restrictive, yet the alternative of “free flow” modeling often doesn’t provide the essential context and guidelines that UML does. Enter DSLs. In contrast to UML, a general-purpose modeling language, DSLs allow you to create model notations representative of application architectures and business processes within the context of your own business domain. DSLs help you overcome the complexity of UML models, and they improve the usability and applicability of modeling across the entire business.
• Proprietary pattern and transformation lock-in is a thing of the past.?At the core of MDA is the transformation pattern?the set of instructions that a tool can follow to make code out of the business model. Whereas MDA users once risked being locked into a vendor’s proprietary transformations, today a standard language called Queries/Views/Transformations (QVT) provides flexibility with patterns and transformations by enabling MDA to transform UML, Business Process Modeling Notations (BPMN), data models, and custom model types.
• Model-to-text transformations can save you from documentation and artifact hell.?You passed on MDA because you don’t want to generate your source code? Fine, but what about the additional artifacts that you need to develop (e.g., documentation, deployment descriptor files, tests, and so on)? MDA’s model-to-text transformations can automatically generate these items from existing design models?freeing you up for more important (and interesting) work.

MDA: Worth Another Look
As the complexity of applications and business processes continues to rise, so does the importance of effective modeling solutions. Modeling solutions help ensure a common visual representation of the important decisions impacting architectural design. Models provide blueprints for not only business-process, application, and enterprise architectures, but also for data structures. They are essential for communication among project teams and for assuring sound architectural design and long-term maintainability. The evolving MDA?and the tools that support it?are the next step in effective modeling, and all enterprise development organizations should give them a second look.