Juha-Pekka from MetaCase started what could become an interesting discussion, triggered by a panel discussion on the recently held Code Generation 2007 conference. I also like Peter Bell's comment to it as it shows how reality often differs from the toolmaker's ideal scenario.
The issue: Should companies develop their own DSM languages (the scenario with the biggest potential win.... if the weather's nice, the beer is cold, the home team wins and you don't mind butchering the cow for the barby yourself), or....would DSM actually benefit from market players providing shrink-wrapped, ready-to-consume DSM languages, tools and generators that won't provide the 15-times faster "its-amazing-but-true" development cycle, but something a bit more modest.
My view from it now, is that the shrink-wrap approach might actually work better for DSM acceptance. A 40 to 100% faster cycle is still one hell of a business proposition and will get most companies adopting the approach without much worry, provided they can start working with it across the board within say a month. Leaving the "customize it further when you're up to it" part open to choice would of course be a big plus for those willing to venture that road.
I think that no matter how hard the tool vendors scream that building a DSM with their tool is really easy, the potentially interested:
a) in most cases do not have the time to start a DSM learning process
b) will always be worried about their DSM expert leaving, just the worry is enough to decline
c) rather leave the DSM evolution up to someone else and just get an update, for which they'll simply pay
d) would trust those updates better than their own developer's update work, if also many other companies use the same DSM
e) would appreciate if they could in some way influence (read: help) the DSM evolution process
Question for a DSM tool vendor would be: Where to start, what domain to take.
Well there's many candidates...Series 60, Symbian, Autosar, Qtopia, and what have you. It could make sense for DSM tool vendors to pick their niches and change their business model from trying to be something for everybody to being a no-brainer for most of the companies in just a single area. Let's face it, there's not going to be anything like Moore's tornado phase for DSM tools. Furthermore, the category is still in its very early lifecycle where only the tech enthusiasts look into it, nowhere near the early adopters. I believe it's the perceived difficulty of adopting it, the risks associated with that perceived difficulty and the fact that most decision makers simply do not see "maintaining your own language yourself" as a business proposition they should accept immediately, is what seems to be holding DSM back from being adopted better.
The issue: Should companies develop their own DSM languages (the scenario with the biggest potential win.... if the weather's nice, the beer is cold, the home team wins and you don't mind butchering the cow for the barby yourself), or....would DSM actually benefit from market players providing shrink-wrapped, ready-to-consume DSM languages, tools and generators that won't provide the 15-times faster "its-amazing-but-true" development cycle, but something a bit more modest.
My view from it now, is that the shrink-wrap approach might actually work better for DSM acceptance. A 40 to 100% faster cycle is still one hell of a business proposition and will get most companies adopting the approach without much worry, provided they can start working with it across the board within say a month. Leaving the "customize it further when you're up to it" part open to choice would of course be a big plus for those willing to venture that road.
I think that no matter how hard the tool vendors scream that building a DSM with their tool is really easy, the potentially interested:
a) in most cases do not have the time to start a DSM learning process
b) will always be worried about their DSM expert leaving, just the worry is enough to decline
c) rather leave the DSM evolution up to someone else and just get an update, for which they'll simply pay
d) would trust those updates better than their own developer's update work, if also many other companies use the same DSM
e) would appreciate if they could in some way influence (read: help) the DSM evolution process
Question for a DSM tool vendor would be: Where to start, what domain to take.
Well there's many candidates...Series 60, Symbian, Autosar, Qtopia, and what have you. It could make sense for DSM tool vendors to pick their niches and change their business model from trying to be something for everybody to being a no-brainer for most of the companies in just a single area. Let's face it, there's not going to be anything like Moore's tornado phase for DSM tools. Furthermore, the category is still in its very early lifecycle where only the tech enthusiasts look into it, nowhere near the early adopters. I believe it's the perceived difficulty of adopting it, the risks associated with that perceived difficulty and the fact that most decision makers simply do not see "maintaining your own language yourself" as a business proposition they should accept immediately, is what seems to be holding DSM back from being adopted better.
2 comments:
I think you raise a great point. Bootstrapping a start up via consulting we've taken the extreme opposite to a tools vendor approach by (a) creating and proving a collection of DSLs for generating rich, custom web applications and (b) providing a service of generating the sites (which programmers could then extend if they wanted).
This gives two benefits. Firstly it means we don't have to educate the market. We're not selling DSM - we're selling custom web apps - quicker and better than any Indian outsourcer can provide. Secondly, instead of charging maybe $1,000 for a license, we can make $50,000 - $100,000 a year per reseller by generating a bunch of custom apps for them - still faster and better than an outsourcer would be able to offer.
That said, such a model only scales so far and it's an inappropriate model for a MetaCase or Intentional, but I do thing that education, training, partnering with consulting firms and maybe even undertaking limited consulting engagements for key customer are going to be important to build the adoption of DSM.
Of course, Microsoft stepping into the field with its DSL tools should also help raise awareness and educate developers which should also make the sell a little simpler over time.
Learning from past mistakes of other modeling approaches, I've created ABSE, which targets the "mere developer mortal". ABSE is simple and tries to do a 1:1 mapping of the human brain, allowing the developer to model at any abstraction level. Wide adoption of modeling practices is one of ABSE's goals.
There is also AtomWeaver, an IDE that puts ABSE into practice.
Post a Comment