09/01/08 :: [MDE] The Model Driven Engineering Revolution (II) [permalink]

|

Nick liked my post about the Model Driven Engineering Revolution:

The metamodel is the conceptual information architecture that classifies the information that we can use to construct solutions, understand problem domains, and create practices that insure that we build the system that we should build.  As JJ points out, the terms matter.  As Gabriel demonstrates, those connections are valuable.

Nick, I have no idea why you got mad at WSPER last year, but WSPER is an attempt to create a SOA metamodel to help people with their SOA initiative. For me understanding the metamodel behind SOA is key to be successful with SOA.

Nick related what I wrote to a post from Gabriel Morgan. I like Gabriel's blog. It is actually not a blog, he deserves to call it a Journal since he publishes article quality posts, unlike us who just "post" a bunch of things.

In this post, Gabriel talks about the "Solution Model".

  • Describe the business problem. (concepts such as Business Process, Customer Scenarios and Requirements...)
  • Describe the solution. (concepts such as System Features, User Interfaces, System Interfaces, Data and Source Code...)
  • Describe how they are tied together.

The definition of a "solution model" is actually symptomatic about why Modeling approaches have not reached the level of attention they deserve. I just would like to reiterate what I have said in my earlier post in the light of Gabriel's post.

The way you model the problem may be unrelated to the way model the functional specification and yet unrelated to the way you build the solution. Modeling is good, but too much of it may prove difficult to get everyone involved.

That's why I wrote "focus on the metamodel with which you will build the solution". This is the biggest bang for the buck. You may use it for creating a solution model, but that may prove too much work. I am not trying to discourage you from modeling. I am just trying to carve a pragmatic path to successful model driven engineering.

I don't want to say that a metamodel is a collection of patterns that work together and that is complete enough to create entire solutions from them because I don't like the association metamodel - pattern. A metamodel is an (enterprise-wide) artifact in itself and not a "set of...". This is an artifact that can be reused across project and lifecycled precisely.

Basically, what I am advocating is that if you create a metamodel of your solution including "implementation" elements (which contain the solution behavior in relation to the metamodel), in essence, you have "coded" the solution model (for free). The implementation element should contain no platform specific library invocation. This is the key point you have to understand, if you create a metamodel without implementation elements and you try to bag the behavior in the metamodel itself, you will most likely fail. Now, I am going off the bitten path of Model Driven XXX here. Please be very conscious about that. This is what I would call Metamodel Driven Development.

For me you should be able to adopt these two steps without difficulty since they are simply better coding practices. Nothing more. Then you can decide if you want to continue managing your solution model as "code" or if it make sense to build tools (using EMF or Software Factories), repositories,... But this becomes a conscious productivity choice based on clear benefits. IMHO, starting there is like putting the horse before the cart. You can only address part of the metamodel and you can't really get behavior in. Don't get me wrong these technologies are extremely valuable and you will use them for sure but use them to optimize your productivity.

Then and only then you should start understanding how (and it) you can model the problem domain and possibly tie them together with the solution model. IMHO, here is the path to a successful Model Driven Engineering approach (steps 1 through 7):

Lots of people that start at step 4 have difficulty creating a meaningful metamodel and often give up there. The part that I don't like in Gabriel's recommendation is that he says you can do 6, 3 and 7 and you should see tons of value coming out of it. On paper yes, this is where you want to be, no question about that, but getting there is not that easy. The pragmatic approach it to spend a lot of time at step 1 and 2. That will help you understand how to create 5, 4, 3, 6 and 7. You might even realize that 1 and 2 are just enough to get to the right the level of productivity and never ever need to bother your business users with the construction of problem models.

Hopefully, Nick still agrees with me.