Model Driven Architecture

I was really excited to read about Microsoft’s recent exploration into the MDA arena!  This is something I have been wanting for quite sometime but I am very hesitant to get too excited.  Microsoft has a tendency to create bloat ware and this may kill the tool from being adopted (Think Rational Rose).

If it works as Microsoft envisions it, model driven development would bridge the gap between business analysts and IT and deliver on the SOA promise to align application development with business needs.

I can definitely speak from experience on this subject that it does definitely bridge the gap between all stakeholders.  The key is to not look at MDA like failed attempts of the past that have attempted to capture the architecture in a model.  The reason these attempts failed is because they took a Waterfall approach to creating software, where the model was the technical spec on which the development team was expected to produce software.  This model proved to be like all specification documents, useless, by the time the development team actually coded the system.  For one, the models where created by analyst who had no clue about software engineering!  They believed that if it looked good on paper then it must work this way in the code.

Utilizing a Model driven approach to creating software in an Agile environment forms a synergistic bond between  stakeholders.  Story cards are great but models speak volumes to elucidating greater concepts about the domain that may have been overlooked otherwise.  In an Agile environment the models are never complete. 

• They evolve with the software as you move from iteration to iteration. 
• They are not a contract but a mere representation of thoughts and ideas to a domain solution. 
• Modeling sessions participants are facilitated by a modeler who has very good soft skills in communicating the architecture as it relates to the domain (Always a developer)! 
• The Product owners take an active role, in that they drive the session at is relates to the business domain. 
• The Testers use the model the gain an understanding on testing strategies they will use to validate the domain against the code. 

From a modeling session you can easily decompose a business domain into manageable stories and you have a working reference from where the stories originated from if you need to come up with a strategy on how the implement the story.

I have been thinking of an idea for pursuing yet another OSS tool around modeling and this just kick starts that even more.  More to come on that later.