"MDA Explained" is an easy to read introduction to model-driven architecture (MDA). The book does however seem a bit dated. It does not take into account service-oriented architecture and how it enables execution of higher-level business models. Still, it is well worth the few hours it will take to read and if you anyway are not in a position where you are concerned about how your system fits in with the business, it might be all you need.
The book is of interest by managers wanting to know what MDA, developers wanting to use MDA in developing applications and to aspiring MDA specialists. The introduction tells you what chapters are of interest to you. The book consists of an overview of MDA, a case study of MDA in action and some information on developing MDA tools.
Model-driven architecture is an approach to development championed by the Object Management Group (OMG), the people behind UML. The realisation that it is useful to work on multiple levels of abstraction when solving a computing problem is the foundation of MDA. We already do this without thinking much about it when we program in high-level languages. Our source code is just a model of the actual program - an abstraction of the machine code in the executable to be generated by the compiler.
MDA practitioners work with models divided into three level of abstraction above the source code, they are in descending order of abstraction:
1. the computationally independent model (CIM) which describes the business independent of computer systems,
2. the platform-independent model (PIM) which describes a computer system independent of technical architecture, and
3. the platform-specific model (PSM) which describes how the computer system is to be implemented using the chosen technical architecture.
Typically, you will have different people working on different levels of abstraction. The business analyst will concentrate on the CIM - drawing up models of the organisation, business processes, terms and rules. These serve as input for the system analyst who develops the PIM, which describes the behaviour (use cases) and structure (classes) of the system. Then, the system designer models how to implement a system satisfying the requirements documented in the PIM with the chosen technical architecture. The PSM captures this technical design.
The problem is apparent; we have many different people thinking differently about the problem that must somehow communicate in a way that reduces the chance of misunderstandings and requirements falling through the cracks.
Using standardised, formal models and tools that can validate them is a step in the right direction. The models give us a common, precise language, which reduces the chance for misunderstandings. Having tools validating the models help further. They ensure consistency and improve completeness. However, using standardised models at the various levels is still not what is meant by model-driven architecture.
For MDA to be in place you must have tools in place to transform a model on a higher lever of abstraction to a model on a lower one. Just as a compiler takes your source code and transforms it into machine code. You should have transformation tools in place to transform your PIM into a PSM, and PSM into source code. Unlike what is the case with modern compilers, these transformation tools cannot currently do the whole job for you. You have to adjust and complete the model yourself, but since the information captured at the higher-level models has already been put into yours, there is less room for errors.
The latter transformation, from PSM to PIM, is nothing new. It is what CASE-tools and modern IDEs have been doing for quite a while. The PIM to PSM transformation is appealing, as it would bridge the functional/technical gap.
Interestingly, the book dismissed the idea of having a transformation tool that takes the CIM and generates a PIM. It is here I believe the book shows its age, it was first published in 2003 and four years is a long time in IT. In the meantime, we have had the advent of SOA, which has allowed us to execute at least parts of the CIM through for instance business process management and business rules management. Just as part of the code generated in the final transformation from PSM to source code is SQL to be executed on an RDBMS, you can go from the CIM to BPEL code to be executed on a business process management system. The OMG shows an interest in modelling on the business level and is in the process of developing a suite of standard models for the CIM.
As you probably have gathered I do not subscribe to the idea that MDA is DOA because of SOA. A revised edition of this book taking into account recent development would be compelling reading. As it stands it is merely interesting.