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.

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of
This entry was posted in Agile Teams, altnetconf, Architechture, Tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to Model Driven Architecture

  1. Evan says:

    I’m afraid I’ve already written this one off. One thing my BAs aren’t asking for, executable diagrams. They don’t want to write code, neither do they want to doodle pictures. Personally, I can type faster than I can drag and drop, so I’ll pass as well. Diagrams are great for communication, but I don’t really want to use them in any capacity beyond that. That’s doubly true if the tools don’t support roundtripping from the hidden abstraction when I have to modify it.

  2. Joe Ocampo says:

    @The Hoff

    I want to make things clear, I am not talking about executable diagrams. I am not to found of design tools magically creating code. This is where Rational failed.

    What I am talking about is the modeling exercise outside of any tool right now. We use index cards and create a pretty impressive colorful collage of a domain issue.

    The cards allow us to communicate in a tactile medium where all stakeholders have a common talking point that is evolutionary.

    Why the MS Tool or any other tool for that matter is important, is that it would allow for quick modeling of domain. This helps with remote customers that do not always have the luxury of being on site.

  3. Joe Reddy says:

    “What I am talking about is the modeling exercise outside of any tool right now.”
    What exactly are these tools doing that Visio can’t do?

  4. Joe Reddy says:

    Nevermind, I just F’n Googled it. I am not impressed…scared a little, but I think I have heard this song before.

  5. Joe Ocampo says:

    Yeah the song has been sung to many times before. Enabling communication between developers and analyst should be the fundamental guiding principle of these tools. We you start expecting the communication tool to produce code or production artifacts, this is where the crack meets the pipe.