The Model Driven Software Network

Raise your level of abstraction

Let me refer and recommend the interesting article by our colleague Peter Bell, discussing on the challenge of providing MDD as a service business. Even though it is a common issue for consulting firms, I want to remark his assertions on supporting the process for reaching and sustaining a customer.
Peter have published his insights today at http://appgen.pbell.com/2010/06/25/the-economics-of-mdd-for-consult...
Being Peter a member of this network, indeed it could give us a good discussion on that subject.

Views: 34

Reply to This

Replies to This Discussion

As Angelo said as a comment to that post, selling a MDD-based product through consulting isn't everything.

IMHO, being a *consultant*, it makes more sense to help the customer develop their projects on their own, and the consulting service is there to help him reduce the time to get up to speed with MDSD. This packs more value to the customer than "sub-contracting" a development job.

Otherwise MDD will just be an internal thing to the consultant, where the price would be once again, the differentiator.
I think Peter’s article is an excellent summary of the problems facing using MDD when selling software. The question is how do you turn your investment in MDD and code generation into money through the door. I think Peter has covered many of the issues of why it’s not as simple as cutting your costs. We have run into many of the same issues.

We now sell applications, which we develop and customise using MDD. We don’t really talk about the MDD to the customer, which as Peter said is very hard. So, the value to the customer is in the applications we sell. That removes the discussions of hourly rates etc from the table. However it means we have to act like a product firm not a services firm.

Michael Porter in an article on competitive advantage talked about the difference between operational efficiency and competitive advantage. A competitive advantage is something that it is difficult for competitors to emulate, where as an operational efficiency is something that is well known to all players in a market.

Consulting in this market is providing services to a software system to specification. In this scenario MDD of its self seems to be more an operational efficiency. It is simply a tool in the process of creating software. And if I see that you are using MDD to cut your costs and you are consistently undercutting my prices, then I will use MDD too. What happens in this case is that competition can become a war of attrition, with MDD just one more technique to cut costs. The problem with this is that the investment in MDD does not pay off. Porter makes the comment in his article that if some technique is merely an operational efficiency, then the winners are generally the tool suppliers.

Thanks Jorge for raising the question.
"Porter makes the comment in his article that if some technique is merely an operational efficiency, then the winners are generally the tool suppliers."

Not bad at all, from my (tool vendor) perspective!...

RSS

Badge

Loading…

© 2017   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service