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 onlywith 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, MDAand the tools that support ithave 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 patternthe 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 modelsfreeing 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 MDAand the tools that support itare the next step in effective modeling, and all enterprise development organizations should give them a second look.