benrobb

Model Driven Architecture (MDA) is one of many buzzwords you’ll hear in software development circles. It’s actually more than one word, but nobody ever says buzzphrase, we’re much more excited by buzzwords. This article is by no means meant to be a comprehensive resource, it simply represents my attempt to wrap my head around the concept.

Model driven architecture is an attempt to focus information systems on business problems rather than on the technology itself. The idea is that by defining our data and our processes in a certain way, that applications can be written by computers instead of programmers.

The models we are talking about here are significantly more complex than a class diagram or a sequence diagram, but at heart are really providing some of the same information. You can define the types of data your application must represent and you can define how different entities in your system should interact. Then if you define everything properly, a super special computer program can actually generate a functioning application for you.

The main standards behind MDA are mostly developed by the Object Management Group (OMG) which they seem to produce at an astonishing rate (see this list if you want to be impressed). In reality, these computer generated applications are probably better used as a starting point rather than a polished final product, but a good deal of the time investment in creating a new application can be done for you.

Principles
There are a few principles that underpin the model driven architecture. From an IBM article on the subject:

• Models expressed in a well-defined notation are a cornerstone to understanding systems for enterprise-scale solutions.
• The building of systems can be organized around a set of models by imposing a series of transformations between models, organized into an architectural framework of layers and transformations.
• A formal underpinning for describing models in a set of metamodels facilitates meaningful integration and transformation among models, and is the basis for automation through tools.
• Acceptance and broad adoption of this model-based approach requires industry standards to provide openness to consumers, and foster competition among vendors.

If that made any sense, then good on you. Here’s the benrobb version.

• Defining your data makes it easier to understand, especially when there’s lots of it.
• Our really cool MDA tool lets you turn your model into different types of applications in different languages.
• This will get even cooler if we can get lots of people to do it.

Value Proposition
The main value I see is that it allows you to seperate the design from the architecture, the business from the technology, or in the words of CARE Technologies (OptimalJ creator), the “what” from the “how.”

Compuware (OlivaNovA creator) lays out these values:

• accelerate productivity—cut development time by 40 percent or more
• enhance maintainability—simplify maintenance and refactoring tasks, reducing time and cost
• increase flexibility—respond rapidly to business and technology change
• ensure quality—promote and enforce best practices and industry-proven code standards
• streamline integration—leverage and optimize existing technology investments
• synchronize requirements with code—trace business requirements to application code implementation

We all know that technology changes faster than most business processes, and MDA provides a way to allow you to keep your business processes, but also keep up to date on your technology.

Vendors
OMG maintains a list of vendors of MDA products. Of the vendors on this list, I’ve actually heard of a few:

• CARE Technologies – OlivaNOVA The Programming Machine
• Compuware – OptimalJ
• IBM – Rational
• TenFold – BusinessTransformation & TechnologyTransfer

Criticisms
These are simply coming from Wikipedia, but there are a few that I think are important to mention here.

Vendor Lock-in: Although the idea behind MDA is to free you from the worry of technology and code, using it does lock you into a specific vendor, because at this point in time, none of them are interoperable.

Incomplete standards: some of the technical standards involved have yet to be implemented in standard way, and some have not even been defined yet.

Expertise scarcity: Modellers/MDA Architects are in much scarcer supply than your average (or even above average) developer.

Conclusions
Well, that’s all the time I’ve got now since the baby needs her shower. Part 1 has really focused on what MDA is, what it does, and who is doing it, but in Part 2 we’ll take a look at some of the things you might want to take a look at if you (or your organization) is looking into doing something with MDA.

This entry was posted on Wednesday, March 14th, 2007 at 8:17 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.