Model Driven Architecture (MDA) pushes beyond the original bounds of the Unified Modeling Language (UML) by providing open specifications that support the formal modeling of all aspects of the software life cycle. These range from business processes, software architectures, data warehousing, metadata repositories, tool integration and even the software development process itself. Major players, including IBM, HP, Borland and Sun, are endorsing MDA. A group of professional service providers has emerged to help companies use MDA to provide business value.
This piece is a guide to the use of these firms, which the OMG calls Qualified Service Providers (QSP).
The underpinnings of MDA date to 1996, when the OMG introduced the Unified Modeling Language (UML) as its primary specification for modeling software systems. At that time, UML was essentially an expansion of data modeling to support the more complex relationships involved in modeling an entire application. Since then, nearly every software development shop has incorporated some form of UML-style modeling into its development process, and the number of UML tools and professional services has mushroomed.
MDA, which the OMG introduced in 2002, has sometimes been described as “UML on steroids.” MDA pushes beyond the original bounds of UML by providing open specifications that support the formal modeling of all aspects of the software life cycle — business processes, software architectures, data warehousing, metadata repositories, tool integration, and even the software development process itself.
Probably the most common application of MDA today involves “driving” the development of applications from formal models in standard UML or an extension of UML. MDA provides a set of specifications that support the modeling of functional aspects of a business application in the form of a platform-independent model (PIM). As its name implies, a PIM is a formal model that is independent of any specific implementation technologies. So the same PIM ultimately could be used to develop an implementation based on J2EE, or .Net, or any other platform.
MDA then provides a systematic way to map a PIM to one or more platform-specific models (PSM). As its name implies, a PSM is targeted for a particular computing platform, such as J2EE or .Net. Using other features of MDA, the resulting PSMs then can be used to generate code, test scripts, messaging formats, communications protocols, data structures, configuration information and the like, as necessary for the chosen deployment technologies.
Platform, middleware and messaging technology already supported in this way by MDA specifications include W3C’s XML, Sun’s J2EE and EJB, Microsoft’s .Net, and, of course, OMG’s own CORBA. Extensions and variants of these are available from different vendors to cover an even wider variety of technology targets.
Using MDA to drive application development has several advantages, including:
1. The business logic for PIMs can be developed — and validated — by business analysts with little or no technical background. Some MDA tools even let you “run” a PIM on a virtual machine to test it.
2. There is full traceability from PIM through PSM and the ultimate deployed software. This provides a great deal of quality assurance.
3. Subsequent changes in either the business model or the technology platform can be gracefully accommodated. Changes in the technology don’t require changes to the PIM. Changes to the PIM can be traced to determine their likely impact on the PSM and ultimate deployed implementation.
In a similar way, MDA can be used to integrate legacy applications, even where they are running on different platforms. In this case, a PIM is developed that covers the functional space to be integrated — for example, a particular set of business transactions. A PSM and “wrapper” implementation is generated that is targeted to the integrating platform. Then, for each legacy system, wrapper components are created to map the relevant components of the PIM to that legacy platform. In short, all the wrapped applications now communicate through a single wrapper implementation of the PIM. This “hub and spoke” approach to system integration — with the PIM-based wrapper in the center — eliminates the “spaghetti” code typical of multiple ad hoc, point-to-point integrations.
The Growing MDA Market
MDA already has been applied to all kinds of business problems and integrated with a wide array of other common computing technologies. Because of its broad applicability, MDA itself is not packaged as a single standard like UML. Instead, MDA is more like an umbrella over a growing family of standards that now includes the UML V2.0, the Meta Object Facility (MOF), the Common Warehousing Model, and the Software Process Engineering Metamodel (SPEM), among others. Therefore, depending on your needs, you can pick the standards you need for specific purposes, or you can use them all in an integrated way to streamline your software development in a very integrated way.
Since its introduction, interest in MDA has grown very rapidly. This is partly because MDA systematically builds on earlier widely accepted computing technology standards, including UML and XML. Therefore, MDA already has received strong endorsements from major systems and software vendors such as IBM, HP, Borland and Sun, which have effectively used MDA to expand their previous commitments to UML-based modeling and XML-based messaging . At the same time, a significant number of smaller vendors already have “bet the farm” on MDA as the backbone for their new product sets.
In particular, many popular existing UML-based modeling tools and Java-based interactive development environments (IDE) already have been adapted or extended to support MDA, giving MDA a kind of instant market share. Major examples include IBM’s Eclipse and Rational Rose XDE, Borland’s Together, and Compuware’s Optimal J. Even Microsoft is using an MDA-like approach for its next-generation “Whitehorse” suite of development tools. A number of powerful MDA-centric tool suites also are now available from smaller vendors, such as Interactive Object’s ArcStyler, Kennedy-Carter’s iUML, Codagen’s Architect, Adaptive’s Framework, and Metanology’s MDE, to name just a few.
As a result, many end users are already getting benefit from MDA — even without knowing it — simply because it is embedded in their favorite development tools. For example, new users of IBM’s popular Eclipse IDE might not realize that it sits on top of an MDA-based MOF repository and exchanges information among its various tools using a version of MDA’s XMI/XML message format. But, as a result of MDA, new tools can be integrated into the Eclipse framework seamlessly and provide a real boon for both tool providers and end users. This stealth invasion of embedded MDA technology into the mainstream is already well under way.
MDA Leverages UML Investments
Of course, the new MDA standards will be of most direct interest to those organizations already using UML and looking for new ways to expand and leverage their existing investment in UML-based modeling skills and tools. At a minimum, these organizations will want to upgrade to UML 2.0, and probably also explore some of the other MDA standards.
For example, some UML tools already provide MDA-based technology that automatically generates programming code, XML message formats, and/or service interfaces. Clearly, such new MDA-based tools and related professional services will find a ready market among the enormous current base of UML users. They will attract more traditional programmers to UML.
However, since MDA is positioned to ultimately support a much broader audience than current UML users, it is also creating a new market of users who may not yet be acquainted with UML and need to learn about formal modeling from the ground up. These new users may not necessarily ever want or need to learn UML itself, and may be looking for direct assistance in adopting other MDA tools and techniques directly.
For example, there is a growing interest in MDA-based tools and techniques that support the modeling of business processes directly by business end users. MDA supports the creation of Domain Specific Languages (DSL) that facilitate such modeling without requiring the end user to master all of UML or MDA. MDA then supports “mapping” these DSL models into UML models, which ultimately can be used to generate working software systems. Using MDA, both the DSL and UML models can be managed and coordinated using MDA’s MOF technology.
Therefore, we can readily envision an organization that provides one or more MDA-based DSLs (but not necessarily UML itself) to its business analysts to create formal business-process models, while upgrading its software developers to MDA’s UML 2.0 to better support turning those business models into working software. Moreover, this new MDA-based software development process could itself be formally modeled in MDA SPEM (and tracked by a SPEM-based process tool), while the various resulting artifacts are stored in an MDA-based MOF repository.
How to Plan for MDA Use
As industry awareness of MDA continues to build, more and more end users are beginning to ask, “What is the best way for us to adopt MDA and MDA tools?” While there is clearly no “one size fits all” answer to this question, a number of professional services organizations already have begun to provide MDA offerings to help their clients determine the best approach to introducing MDA into their own particular environment.
Most of these MDA experts agree that the end-user organizations that ultimately benefit the most from MDA will be those that consciously and systematically apply it across the software life cycle — modeling business processes, designing and deploying new applications and supporting services, integrating and evolving legacy systems and databases, and the like. Such organizations will use MDA as a way to bring order to the increasingly complex and often fragmented world of enterprise computing.
The ultimate result of fully leveraging the MDA standards should not only yield numerous tactical improvements in the software development process, but also deliver an overall strategic improvement in the whole software life cycle. In short, the proper application of MDA makes it possible to develop and deploy better business processes, support software in less time and for less money, and to evolve and redeploy the resulting businesses processes and software gracefully over time. This means that MDA is not only a tactical IT problem-solver, but potentially also a strategic business problem-solver.
So MDA may start out in a particular application design team, in the chief architect’s office, the business process-modeling group, in data warehousing, or in the Web services group, but ultimately it has the potential to find its way around the whole organization. This may initially start to happen by some form of informal osmosis, but eventually an organization’s best bang for the buck will be realized by having business and IT management proactively plan and manage the MDA transition process.
This certainly doesn’t mean that everyone in an MDA user organization has to understand all aspects of MDA all at once. This kind of firehouse approach to introducing new technology seldom works very well, and it definitely won’t work for something as comprehensive as MDA. Instead, it means that management — both IT and business — needs to develop a systematic, organized approach to rolling out MDA over a period of time to a number of different constituencies.
OMG’s MDA FastStart Program
To help organizations begin the process of adopting MDA, the OMG has created a special MDA FastStart Program (
www.omg.org/faststart/). The FastStart Program maintains a list of QSPs who are OMG members offering expert professional services to help end-user organizations get started in MDA. End users can contact FastStart QSPs directly, or they can go through an OMG-sponsored referral service to help them find the QSP that is best for them (
see sidebar, “Plugging into FastStart Referral Service”).
Different FastStart QSPs focus on different MDA target audiences. For example, some are MDA tool vendors who provide a FastStart service offering specifically geared to their particular tool set. Other QSPs have a team of MDA generalists who offer consulting and training that can be adapted to many different applications and tool sets. Still other QSPs focus on applying MDA to specific vertical markets, such as government, defense, and financial services, or to specialized technologies, such as embedded systems, real-time systems or systems integration.
With these differences in mind, all QSPs still have the same basic goals — to rapidly familiarize an end user’s IT and business professionals with MDA concepts, and to start integrating the MDA approach into mission-critical software development activities as soon as possible.
During a FastStart engagement, highly qualified MDA consultants and trainers provide an integrated set of assessment, planning, executive seminar and technical practicum activities targeted to top executives and technical staff. The key goals of a FastStart engagement are to help key end-user decision-makers:
- Clearly analyze and plan how MDA can best be introduced and applied to most benefit their organization and its key business drivers.
- Decisively demonstrate how MDA can provide clear-cut business value sufficient to justify further investment in MDA-related activities
- Attain sufficient knowledge of MDA to confidently initiate further MDA-related activities.
Challenges Facing MDA Adoption
MDA has entered the market at an interesting time. On one hand, IT budgets remain tight, making the introduction of any new technology a challenging sell. At the same time, many IT organizations are still reeling psychologically from the excesses of the 1990s and the following bust. On the other hand, the need for better and more cost-efficient approaches to software development and systems integration — the key areas that MDA is designed to address — is more critical than ever.
