In 2000, the Object Management Group (OMG) published "Model Driven Architecture" (OMG 2000), a white paper that described a vision for software development that relied on linking object models together to build complete systems. This model-driven architecture (MDA) approach would employ existing technologies that support existing and future OMG standards, and thereby support model-driven development so that object models would become assets instead of expenses.
Today, however, models are precisely that: They're expenses. Once a model has been built, it must be transformed into code, and this is a tedious, error-prone, and above all, expensive process. Furthermore, once the interesting abstraction work has been done, only the transformation from code to an executable is automated. Once again, we find that the cobblers' children have no shoes.
MDA is the result of the recognition that interoperability is a Good Thing and that modeling is a Good Thing, too. MDA allows developers to build models without knowledge of other models in the system and then combine those models only at the last minute to create the system. This prevents design decisions from becoming intertwined with the application; it also renders the application independent of its implementation so the application can be recombined with other technologies, as well as other application subject matters, at some later time. This is a kind of design-time interoperability of models; the result is that models become assets.
Does this sound too good to be true? Possibly. However, MDA doesn't require a one-step leap from a code-driven process to one driven by modeling. Instead, it offers features that allow the progressive adoption of the technology. You'll likely find that some of the technologies are in place in your organization already MDA simply fits them together and organizes them into a coherent whole.
This book describes the current state of the art in MDA. It's targeted to developers and their managers who want to understand more fully what MDA is, and how it might affect their development activities and their organization. It's not intended to describe all of the nitty-gritty detail of MDA.