You have model-driven development [MDD] and then you also have model-driven architecture [MDA]. MDA is actually trademarked by the OMG [Object Management Group], which is sort of a consortium of vendors and end users that is developing standards for implementing MDD. MDD is comprised of being able to visualize code, and the MDA specification that does that is the Unified Modeling Language , or UML. MDD is also comprised of the ability to visualize the domain, such as a business domain, and the generation of implementation artifacts. Basically, you can have a single repository holding a model of your application and systems environment that allows all the stakeholders to participate in the development process. Does MDD allow non-developers to take part in the development process as well?
The Holy Grail is to allow business analysts to directly contribute to a model, and have architects and developers contribute to the model. For instance, you would have platform and infrastructure developers create models of the framework APIs that those business developers [could then use] to create business applications. That really is the Holy Grail, especially when you talk about Business Process Modeling and the ability for business people to do workflow-based process coordination using tools. Is MDD platform independent?
The model [itself] should be platform independent, which basically decouples you from underlying technology and buffers you from changes in the technology. And it allows you to redeploy on different technology, like the ability to deploy onto Java or .Net. Then you bind that platform independent representation to a specific technology and you create a platform-specific model.
It's basically to graphically represent code syntax and code concepts or domain concepts and structures. A picture is worth a thousand words. It's much better to see a UML diagram with a bunch of boxes with lines connecting them than to try and read through source code. Domain visualization is basically going beyond the code to model more abstract concepts, such as 'what is a customer,' 'what is a purchase order' and 'what is an address.' The idea is to come up with a domain-specific language. This is a specialized notation that enables you to have the business analyst communicate in a very intuitive fashion. For instance, you wouldn't use UML to prove a calculus theorem; you would use the domain-specific language of calculus. Is there anything else you want to say about the definition of MDD?
The other definition of model driven development is to have model portability, to be able to bridge a model between different meta-modeling languages. This would include the ability to take an XML-schema model definition and bring that into a UML environment. That is what the MDA Meta Object Facility, otherwise known as MOF, is supposed to allow you to do. How, if at all, does MDD relate to the concept of service-oriented architecture (SOA)?
The big thing is MDD is kind of the generic term and MDA is like Kleenex, where it's a specific trademark specification that everybody uses when they talk about MDD. Now, SOA is not really related much at all. SOA is basically a design paradigm, a design pattern. SOA is sort of a philosophy and mind set. SOA is all about exposing your application interfaces as services, and that those services should be exposed in a manner where you can bind and connect to them in a loosely coupled fashion. So, you aren't really tied to having symmetry between the technology stack of the consumer and the technology stack of the provider of that service. And SOA is all about having a machine-readable contract of that service interface. There is an interception between [SOA and MDD] because while you're modeling in a platform neutral manner, you should be able to generate a service contract that describes your interface, as well as all the implementation artifacts that would be necessary to deploy a service. Is MDD being adopted at a fast rate?
That really depends on whom you ask. Microsoft would tell you that MDA hasn't really taken off, although they're jumping on the MDD bandwagon with their DS.NET 2005 product incorporating a technology code-named White Horse. They're going to be rolling out a SOA and a deployment designer. [The SOA designer] is going to allow you to model connecting Web services, and [the deployment designer lets you] model how you can deploy your Web applications to certain servers, or deploy databases to certain servers. But [Microsoft is] taking a totally different approach. They aren't following the MDA specification. There is a lot of controversy out there and a lot of talk between the MDA proponents and [proponents of Microsoft's approach] about whether Microsoft should be using should be following the MDA specifications, or whether it's true that [Microsoft] believes that the MDA specifications don't go far enough for them and that they need to create their own. Does MDD fit into a code reuse strategy?
Most definitely. From a MDA perspective, it all is about creating usable models that allow you to know about your code assets because it's very easy to inventory and visualize them. And then you can extend those assets through creating inheritance and derived models. SOA is all about sharing and reuse of services. You create the business logic once, expose it as a service and then every application that desires to use that business logic can connect to it, regardless of the platform, language or operating system. This is great for a few reasons. One, you reduce duplicated code and redundant code, which reduces your maintenance cost and increases the consistency of the execution of business processes. You don't have three different versions of the truth out there. Also, if you have to make a change to that algorithm, it's all centralized and there is one place to go to make the change. What advice do you have for developers who are starting to look at MDD?
Focus on finding tools that have an open architecture, especially in the generation and implementation of code artifacts. [For example,] you should be able to generate unit tests and you should be able to generate not only source code but also deployment descriptors and documentation. The generation aspect is a huge win. You can use MDA to basically remove the monkey-coding that you're otherwise sending offshore. And I think a lot of people who are looking at offshore strategies as a cost savings reduction should also be looking at MDA and MDD and seeing the big cost and efficiency savings that can be made there.
Also, you need to realize that UML itself doesn't go far enough. You really need to tailor it with your own domain concepts and models. A lot of people really use UML out of the box when they really should be customizing it first to provide a framework that targets the type of applications that they're building.