Advocating Model Driven Software Development

Replies to This Discussion

Permalink Reply by Ed Merks on January 16, 2009 at 2:26

Use reverse psychology. Tell your manager that modeling is stupid (even stupider than the manager) and suggest they watch this video so that they'll be well armed to deal with any naive people who might suggest there is a better way:

The Unbearable Stupidity of Modeling

• ▶ Reply

Permalink Reply by Michael Osmond on January 20, 2009 at 18:28

Our experience is a little different the champion for MDSD in our organisation (a small firm) was one of the directors. In this case most of the resistance came from the technical people (programers and analysts).

I think it comes down to a paraphrase of Machiavelli, the creator of a new system will face the enmity of all those who would loose from the new system and have only the luke warm support of those who might stand to gain from it.

From my view of it, getting MDSD working properly, to fully deliver working projects is hard and not necessarily guaranteed to succeed. People can be comfortable in current thinking and current processes and don't want to change, or see change (in a companies direction) as being risky.

The best form of advocacy in some ways will be successful projects, or more importantly successfull companies that people can reference too.

• ▶ Reply

Permalink Reply by Mark Dalgarno on January 27, 2009 at 21:09

Reposting:

Vlad Varnica wrote:

Hi Michael,

I agree that selling modeling should be explained at management level.

My selling speech was on how to sell UML to technical teams and it is really not easy.

I believe that many IT architects/engineers/developers prefer to keep control of the whole project and don't let management to have a look.

I have seen so many dead java projects just because the architect or even one member of the team left the company. This would have never happened if using a model driven approach !!
Using UML is a guarantee for companies to control what is really done and be independent of any other team members, integrators or consulting team.

If the company has the model and a generated code, it means they control their IT projects.
If not, they are depending on others companies or employees and this is a real risk in our today's business.

This is a risk because integrators and consulting team goals are to sell as many as possible days and team members can leave the company.

Could you imagine that I have seen a company relying and trusting just one architect.

I have also seen company not having anymore their full source code (just the jar) and seeing competitors launching new projects with the entire source code :-)

This is another selling reason why companies should use UML and MDD.

Companies should always ask for a model, and source code respecting the architecture and a back up. Doing that will save their projects investment and confidentiality.

• ▶ Reply

Permalink Reply by Michael Osmond on January 27, 2009 at 12:02

Hello Vlad,

All good points for using MDD, and we have seen the benefit of these, although I have not seen some of the theft/control issues myself.

My main point though, was not that it is rational or reasonable to do MDD, but that in fact it does not mater how good your arguements about the benefits are, these benefits are theoretical or possible only. For those benefits to be realised people have to take risks, they have to put MDD into practice on real projects that may or may not succeed for all sorts of reasons. And that is the hurdle to overcome, and for a lot of organisations they will not move, until others have proven that the approach works and creates successful projects and businesses.

Michael

• ▶ Reply

Permalink Reply by Andrew Shapton on February 3, 2009 at 12:31

Maybe showing them a paper by a respected Industry Analyst (in this case the Butler Group)

http://ca.com/files/IndustryAnalystReports/the_benefits_of_model_dr...

This paper is centred around CA Gen, but the broad principles around MDD are contained therein.

• ▶ Reply