We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

To Whom Model-Driven Approach is Dangerous?

Vote 0 Votes

To Whom Model-Driven Approach is Dangerous?

According to Johan den Haan, we have to beware of Model-Driven Approach!

When I read his article, I have noticed two things:

1) almost a year ago, Johan den Haan's "8 gotchas of Model Driven Engineering" were used as one of the major arguments of prediction that Model-Driven Approach would fail. However, now the tone of Johan' article is different - we just have to be alerted. I take this as an evidence that failure had not happened but, on the contrary, Model-Driven Approach had extended its audience
2) I do not feel this danger.

A logical question comes up - who are those the Model-Driven Approach is dangerous to? To answer it, we need to list the states of danger (according to Johan den Haan) first; they are (the titles of the sections in the Johan's article):
1. MDD actually introduces a lot of rigidity
2. Models are only flexible where flexibility has been designed
3. The roles of project members are quite different
4. The modeling environment doesn't always support version control
5. The modeling tool/approach is "almost" finished at project start
6. The requirements team needs to understand what is allowed and what not
7. MDD is sold to the customer, but the team has no experience
8. Innovation distracts

Let's address the danger as it comes.

Point 1. Model-Driven Approach is not the same thing as Model-Driven Development (MDD). Also, development consists of, among others, design and implementation/programming; the design may be flexible while implementation rigid. But it is not the point. IMO, the Model-Driven Approach (MDA) has been created to chill out those who "used to programming everything by hand" and frequently creating what they wanted/could do instead of what they were required to create. One of the MDA goals is enforcing the modelled requirements into the implementation - nothing more but nothing less. Business requirements, architecture, modelling and design have become the leader of IT development acquiring this role from programming. There are no doubts that MDA is dangerous for the 'just developers'.

Point 2. I agree with the Johan's statement about flexibility but in the article he talks about different things. He sees inflexibility in MDA but refers to by the used tools and modelling language that are not flexible enough (yet). Well, this sounds like talking about apples but referring to oranges. In practice, you have a SW design as good as your designers can do. If your organisation does not have good designers, this is a danger to the management that cannot (or do not want to) find and pay for the expertise; methodology has nothing to do with this. "Doing more with less" can produce nothing but more 'lesses', as we know.

The MDA constitutes conceptually new approach to the entire development practice. It is not a surprise that traditional IT (which has proved its inability to provide for business requirements on multiple occasions) feels a danger in the MDA as well as in SOA and all other modern initiatives that aim to strength IT delivery capabilities.

Point 3. It is for sure - roles in MDA project have very little in common with traditional project roles. It is a danger only to those who does not want to evolve and improve. As Johan says: "Building the solution is done by so-called business engineers instead of programmers", and this is absolutely right thing to have if you deal with serious realisation of business tasks. Certainly, the MDA has to be applied to the right task. For example, UI design is not the right task for the MDA (because, so far, we use MDA for modelling technical entities, not human behaviour). However, the right tasks are big in the organisation. If an organisation moves with the MDA, only small things are not affected by the MDA and these small things become exceptions in the development practice, not other way around.

I take expression 'business engineers' as an accumulative term representing Business Analysts, Business and Technical Architects. These people are or can be qualified for modelling business needs (i.e. WHAT, WHY, WHO) for the purpose of realisation in Business and Technology, they have to have different set of skills than developers who are supposed to concentrate on the implementation aspects (i.e. on HOW part). If IT management wants to squeeze new 'guy' into old shoe, it is their problem; modern enterprise cannot operate efficiently without Business and Technical Architects - this is our reality (because in majority of industries the business is as strong as its technology is).

Point 4 and Point 5. These are the real danger. But such danger comes with any new approaches, environments and tools. The MDA tools have to mature, it is obvious.

Point 6. Practicality tells us that if Business wants to get results from IT sooner than later, it is business better to consider technical capabilities and this is the matter of tactical versus strategic approaches. It is and was true for many years; the MDA has not brought any new concerns in this area. This is why the Johan's comments to this point sound (to me) a bit like from a 'stone age'. Being a technical solution architect, I do not accept an idea that business has to adjust its requirements to technical capabilities of its IT. If particular tool does not provide for the business needs, the tool has to be replaced (otherwise, the business will replace us).

Point 7. This is another point that dangerous in its nature but is not specific to the MDA; this is a general point. Any new approach, methodology or tool given to the people who have no experience with it, constitutes danger to those who responsible for the results. So, why those responsible use inexperienced stuff? If a tool is bought in marketing hype and rush, there will be developers' blood, but do not blame the MDA for this.

Point 8. I have difficulties in understanding how Johan has tied the MDA with the destruction of innovations on the grounds of developers playing with new tool and forgetting about project constraints. This is a simple absence of development discipline in the organisation. The absence of development discipline directly leads to the distraction of innovations, no doubts, but it is not the fault of the MDA. If developers are more interested in 'new cool' features of new tool than in the job to be done, it only contributes to the tool creditability. If managers want a new tool in the development arsenal, they must allocate appropriate time and funds for the stuff to 'play and learn'. If the 'play' happens in the project for the cost of wasted development time, this just means that the project is poorly managed. Is this the MDA's fault?

Summarising this short observation, I have used a simple arithmetic: out of 8 cases pointed, three cases were common for any approach or tool in IT, two cases were relate to immature MDA/MDD tools, one case was trivial because it was a known fact that each new serious methodology required learning and suffered from the shortage of expertise in the market at its beginning, in one case the concept was substituted by the problem of immature tools but the methodology was blamed. Only in one case, the danger of the MDA was objectively outlined: this was the danger of the known concept that was finally got grounds in the form of new methodology, which definitely threatened representatives of the old methodology. All these allow me to say that the statement "MDA is dangerous" is just a contra-hype generated by those who have really recognised the power of MDA and its threat to their routine.

At the end, I would like to give you a historical example, which clearly illustrates the process hidden behind aforementioned hypes. So, about 90 years ago, factory workers (called proletariats) decided one day that they knew how to manage the production without white-collars and bosses. Surprisingly, this absurd (at a glance idea) did work that time: the production was purely mechanical and masters - senior workers - knew the process very well. In many years, when production became chemical and even atomic, the proletariat almost disappeared from the plants yielding the place to engineers (and bosses).

The same is happening now in IT - years ago writing good code was the master level skill and those who could do this imagined they were the Masters and decision makers of IT. Unfortunately to them, for the years, the business needs and complexity of the tasks grew up as well; they exceeded the level of even excellent developers. New skills were requires and they appeared in the roles of Business and Technical Architects, modellers and designers. Programming has become a commodity. This matter of life is called 'progress'; it is useless to fight the progress (IMO). We better learn (again) and become architects with programming background - the one of the most valuable combination of skills for IT nowadays.

Reference Lable.JPG


| Leave a comment

Hi Michael,

Thanks for your extensive reaction. I'm not going to react on all your points right now. Some first remarks:

In my article a year ago I didn't argue that MDE would fail for sure. From the conclusion:

We’ve seen eight reasons why model-driven approaches can fail to make their promises come true. It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE.

You conclude: the statement "MDA is dangerous" is just a contra-hype generated by those who have really recognised the power of MDA and its threat to their routine.

I don't fully agree with you on this. Yes, the goal of my article was to create some kind of a contra-hype, but with the aim to warn people not to just start using MDD because of the upcoming hype. As with each software development approach we shouldn't forget our lessons learned and use our common sense before we start with something new. If a company has a mature software development approach/process and understands the limitations and changes of MDD there is no reason to NOT start with MDD.

I don't see MDA/MDD/MDE as a threat to my daily routine, in fact, my daily job is to build a model driven development plaform ;)

Hi Johan,

thank you for such prompt response.

I do not say that you ever argued that MDA would fail, the reference in my text points to the Jean-Jacques Dubray's article, which used your "8 gotchas..."; I am clear with this.

Also, I am not saying that your statements are wrong or right, I am only trying to identify those who has to be afraid of MDA indeed.

I do agree with you that none of "MDA/MDD/MDE as a threat to my daily routine" (sorry for the clumsy grammar); my job is to use "a model driven development platform" but, first of all, to sell it to the business and IT management as a solution, which has capabilities (maybe not delivered by current tool offerings yet) to assure that requested business functionality is exactly the one that IT delivers (maybe in full or partially but not 'to some degree' :-) )

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives