MDD tool vendors differ in many aspects but they have one thing in common. They all (well, all those I’ve interviewed or I’ve discussed with, which I do believe are a representative sample) agree that the cost of customer acquisition is really high.
Roughly speaking, you must first attract their attention (e.g. sponsoring this site 🙂 ) in a market full of noise (by noise I mean that many tools market themselves as MDD tools, code-generation tools, model compilers,… while offering many different features so for a potential customer it´s difficult to separate the wheat from the chaff). But, more importantly, then you must earn each client’s trust before being able to sell a software licence to him/her. This means that you basically have to first participate in one development project together with the client (for free or just covering your costs) to show him the benefits of using the tool. And, then, if you’ve managed to convince him you can hope to sell him a license to use in his future projects. IMHO, the main reason for this is that MDD is not a cool technology.
Whatever the reason, this fact shed some doubts about the scalability of the business model of MDD tool vendors. With such a high customer acquisition cost, growth of these companies can only be limited, unless people get more educated on MDD (so we don’t need to justify ourselves all the time) or some of the vendors manage to get enough visibility and brand awareness to inspire enough confidence to potential customer so that they decide to give the tool a try by themselves.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. Â More about me.
Isn’t this true for all tool vendors, especially for “immersive” tools like IDEs and modeling/language workbenches that tend to permeate the whole development process? The only reason that it might affect MDD more (comparatively speaking) is that MDD itself is still a bit of a niche and that it permeates the development process even more than a “mere” IDE. (If you can integrate MDD with the IDE-du-jour there’s probably not much to do for the tool vendor.)
I’m with you on the noise level: there’s a lot of MDD(-like) tools out there, many of which of the UML-to-{some kind of runtime architecture} kind which tend to not completely solve the customer’s problem but are neither flexible enough to fit to the target architecture that’s actually required.
@Jordi One of the things you point out is something our company realized years ago it was a must-do: we do participate in projects with our prospects.
Our advice for them is to pick a not-so-big, not-so-critical project first.
This makes the prospect feel more comfortable with the risk level (not that we cannot accomplish big, complex projects) on the one hand.
On the other hand, we do not incurr in as many expenses: since we typically participate at a low cost in first projects, we cannot afford devoting people for many months to one project just covering expenses if we have other paid projects where we’d rather allocated those resources.
Then, when the project completes successfully, the customer feels more comfortable to move on to bigger, more complex projects and only then you can truly teach developers how to leverage your tools/technology (they will have realized their benefits by then and will be more willing to approach the “new beast”).
@Meinte I agree with you: if the MDD product does not solve your problem or is not flexible enough to fit the target architecture of choice, don’t use it. Pick another one (if there’s such another one that is fit for you). But even if it doesn’t *completely* solve your problem but does solve a great deal of it (say 70% or 80%), there may still be a case for it, don’t you think?
Hi Jordi,
I agree with you on the acquisition cost and adoption of MDD. I guess you actually refer also to what you know about our experience with WebRatio.
@Juan Carlos: I think the issue is not about how to start with MDD with customers, I perfectly agree that a non-disruptive, gradual introduction is the best strategy.
The problem is even before: trying to sell an advanced MDD product is a hard job, very expensive by its own.
I think this is due to the fact that vendors necessarily need to play also the role of evangelists first, to convince customers that there is the need for an better management of software projects, and to show them that MDD can respond to their needs.
This leads to extremely long selling cycles. Advanced MDD is not something people are ready to do out of their wish (e.g., as you buy books on Amazon).
Obviously, I’m leaving out of this picture the basic UML tools or the just-drawing tools.
“The problem is even before: trying to sell an advanced MDD product is a hard job, very expensive by its own.
I think this is due to the fact that vendors necessarily need to play also the role of evangelists first”
That’s so true, Marco! And one good way to do it is by showing how your approach can be leveraged in real projects. We all know that canned examples always work (demo-effects and Murphy laws aside) so we must excel at demonstrating with “real” cases. Trouble is finding prospects willing to let you use your product with a project of theirs but when you do find one, then you either win a customer or lose a prospect… but also learn ways in which your offer can be improved.
@Marco, in fact the WebRatio experience is a common one. In two days, I discussed with the people behind three different MDD tools and all explained me a similar story!
@Juan Carlos: The 80/20% rule says that that remaining 20% will take about 80% of the time/effort, so I’d say you need to aim either for a higher percentage or a way-of-working that integrates really well with “both sides” – i.e., the modeling tool which takes you a large part of the way and the tool you need to do the rest, e.g. an IDE.
In my experience, that takes quite a bit of effort and skill – experience helps as well. On one of my bigger projects we discovered along the way that you actually need to separate the modeling effort from the manual code effort: new/changed models are published separately to the developer tier in a very controlled manner (fixing the intersection as part of the publishing process), instead of it being all in one big space so that everything that happens on the modeling side is very likely to break something on the coding side. It can certainly be done, but takes a disproportional amount of effort compared to the pure MDD approach and doesn’t empower the modelers on the remaining part which is a risk in itself. (The drawing-only approach is a waste of everyone’s time, obviously.)
–
The advantage of participation in projects with prospects/customers is that you actually see what they want. It’s probably safe to say that too many tools have been implemented in a total vacuum. I know of one domain workbench which sits squarely in the “rocket science” category but requires the meta developer to have about 3 brain halves and 2 PhDs to actually be able to use it proficiently. Philosophies like Lean (Startup) apply equally well to MDD tools as to everything else. After all, meta software is software as well.
@Meinte “I know of one domain workbench …”
Can we have a hint?…
I already gave 3 hints! Plus it’s fun to keep you guessing intentionally 😉
OK, got it!
@Meinte, I could not agree more with you on the 80/20 rule (and we’ve been through that many times)… but that is not what I actually meant when I said that a solution might be fit for a customer if it solves a great deal (70-80%) of her problem. I actually meant “it saves a great deal (70-80%) of the effort needed to solve her problem”.
Otherwise, as you rightly put it, makes no sense 🙂
I do believe that the pareto rule applied to MDD (see https://modeling-languages.com/pareto-principle-applied-mdd/ ) that I rephrase as:
20% of the modeling effort suffices to generate 80% of the application code
can be useful to introduce people to MDE showing them that with little effort they can save a lot of time on the coding of the boring parts of the system.
Then, of course, we need to convince them that we can also use modeling to take care of the most complex aspects of the system-to-be