DSM it yourself or not?

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.

Still connected to DSM

It's been a while since my last blog posting. Reason is a change in job focus from software development to performance & business process management while changing MetaCase for QPR Software Plc. While catching up it was nice to see the overwhelming interest in the annual DSM workshop at OOPSLA forcing the organizers to make it a 2-day event. I suppose that with even the OMG now seriously interested in DSM the organizing committee should now seriously start to consider transforming the DSM workshop into a DSM conference: I believe we're close enough to critical mass to get enough sponsors in, provided all is well organized and thought-through.

Although my job responsibilities have turned me toward a significantly different community, it's nice to be still involved with DSM, if some of your hard-core DSL aficionados would still consider BPMN a true DSL. It's been designed-by-committee after all...yuk! But then, in the area of describing business processes I believe the need for a company-specific BPL becomes less of a core requirement for being able to generate something that will actually execute it. I bet that for the bulk of enterprises BPMN will do just fine whereas UML falls terribly short for anyone wishing to do MDD.

IT-Director on MetaEdit+

Philip Howard of the Bloor Research analyst group posted his vision on using domain-specific modeling languages in the IT world on IT-Director.com. It involves the use of MetaEdit+ for improving the practice of event processing.

Next Big Language

Steve Yegge talks about the inside information he obtained about the Next Big Language, providing details about all its features and must-have's without revealing its name. Aside from the - in my opinion - friggin' boring discussion he triggered (I didn't make it to the end of the thread, not even close), he makes some solid remarks:

"I want to encourage people to make their own languages, because doing it makes you a world-class programmer. Seriously. Not just a better programmer, but a best programmer. I've said it before, and I'm sticking with it: having a deep understanding of compilers is what separates the wheat from the chaff."

It may well be that Steve is right in all or many of the desires he has for the next big programming language. Personally, I do not see much need for the next big language (NBL) as I think the next small language (NSL) makes a hell of a lot more sense.

The NBL will be a generic monster. Sure, it may be a face-lifted version or remake of a current big language, but there is no way you will make a lean, agile, expressive and performing language out of it. The B in the acronym inevitably leads to compromise, to general-purpose and therefore to a lack of rise in abstraction. Bill Gates already spoke about abstraction rise and the lack of it only leading to ugly things at the Gartner Symposium in 2004:

"The key breakthrough in coding is to write less code. I mean, there's nothing magical that's ever going to make a million lines of code a pretty thing. Corporations, governments need the platform to move up to be so high level that with these modeling tools the amount of code they're writing -- and let's take an ambitious target -- over a decade we should be able to reduce the amount of code the write by at least a factor of five."

And to achieve that, we need small languages that are more expressive, more abstract and domain specific so that specifications in it can be automatically transformed into specifications in, well, we won't care really in what. For all I care in specifications in the next big language....we're not going to touch them anyway.

Missed opportunity

Angelo Hulshout had - in my opinion - an excellent idea: do an online workshop on defining a domain-specific modeling language. It's a shame no one responded to the challenge - due to as he puts it himself - too few readers of his blog.

One idea could be to organize such on the dsmforum though and possibly have people like GarethJ, Alan Cameron Wills, Steven Kelly and Markus Völter provide advice, as I believe it would be best for developers with little experience in DSM creation to take on the challenge!

Having such discussion and documentation online would provide valuable information for many and provide a great platform for different views on the DSM creation process.

Webcasts: Modeling with domain-specific languages

Have a look at these webcasts: They go from providing a simple but very clear introduction to modeling with and generating code from domain-specific modeling languages to where the technology currently is in making your own DSL editors a very agile task. "Defining modeling languages and code generators in MetaEdit+" clearly shows the necessity of having your models and tools update automatically with language changes.

The API example shows a nice example of what it means to integrate your DSL supporting environment with 3rd party tools, such as an emulator for testing purposes: model-based debugging.

The final webcast shows one of the new features in MetaEdit+: graphical metamodeling, which is helpful during the early stages of language definition, especially when you're working with several language designers in your team. Naturally, MetaEdit+ supports such a multi-language engineer way of working.

Code Generation 2007 - Program

The organizers of the Code Generation 2007 conference in Cambridge UK now put the program available on their website. It's going to be damn interesting.

It's great to see so much interest from vendors and media in this event, which is a first on this size I believe. I hope the interest-level will be similar from enterprises whose developers can benefit so much from the sessions. £350 for three days of knowledge-packed sessions seems very reasonable. One thing is clear: Pedro Molina, Andrew Watson, Markus Voelter, Steven Kelly, Tony Clark, Danilo Beuche, Alan Cameron Wills and Juha-Pekka Tolvanen are big names in this area and personally, when it comes to learning, I choose to learn from the best minds out there.

MetaEdit+ Microsoft DSL tools comparison

Steven did a "blitz-comparison" of MetaEdit+ with the Microsoft DSL tools. The topic: Creating your own visual representation for you modeling language and updating existing models with this new representation.

The whole thing is a bit comical, depending on who your employer is I guess. On the other hand I think it also likely blows the socks of some people who use Eclipse frameworks (GMF, EMF etc.) to build their own graphical editors. Something what Steven does in less than 10 seconds would take them something in the order of a day or two.

A bit strange to see people even struggle with immature DSM alternatives when an industrial strength solution is available for just €150 / $190.

DSM at DevWeek 2007

Juha-Pekka will be providing a conference session on defining Domain-Specific Languages and code generators at the DevWeek 2007 conference in London at the end of this month.

I know I keep on hammering on the significance of this topic :)

Anyone who has heard by now about how DSL's are replacing UML there where UML is proving to make no sense (most cases where you wish to generate usable code from models), also needs to realize that if you are going to walk the DSM-walk, you need to learn how to create your own modeling language.

Of course, having a vendor-supplied modeling language "can" make sense as well - at least, that is my opinion - especially in cases where you do not expect to be able to generate all code anyway. This mostly holds true for cases where the problem domain is difficult to define and changes very regulary, for example web-services as a horizontal domain. In many vertical domains however (e.g. vendor-specific car infotainment, navigation, operator-specific telecom services, building automation, industrial automation, robotics, mobile phone apps, medical device electronics and so on) the problem domain is clearly and cleanly narrowed down, for example by an intensively reused underlying software platform. In this case: DO expect to generate 100% of the code you now write manually, at least if you have defined a modeling language that fits completely (i.e. you have to define it yourself).

I have not seen any other speakers touching this subject at conferences - most just tackle the MDD topic on a conceptual level, merely introducing those interested in "what's out there". I do hope to see more recognized experts pick up on the "how to" topic.

MetaCase Job Offer

MetaCase is looking for a Product Marketing & Sales Manager. If you feel you have the right entrepreneurial attitude and like to work in a dedicated team, looking to evangelize DSM and MetaEdit+ as the most advanced model-driven development solution, then I recommend you send in your application.

With MetaCase you get an opportunity to work with some of the industry's most recognized thought leaders in the field of model-based development. We don't need you to be an expert in this area, we DO need you to be genuinely interested and a fast learner with sharp thinking skills. You are skilled in relationship building and know how to "do a room" whenever a networking opportunity presents itself. You are a good negotiator, capable of seeing the big picture even in stressful situations and able to bring new ideas to our team to further promote our product.

If you believe you can provide a healthy contribution to MetaCase then we are ready to provide you with an inviting work environment, a fun team of people to work with and a competitive compensation package.

Send your application to jpt[at]metacase.com

OOP 2007: Vendors step into DSM

OOP 2007 showed me that now more vendors see DSM as the way to go.

Gentleware, known for their UML tool Poseidon promoted DSL-based editors built on top of the Eclipse GMF platform. When I asked Marko Boger about what happens when the customer needs the inevitable change to the supported DSL language his answer was: "Well, then we make more turnover". He could also have mentioned that the customer loses all models made previously and that the customer has to wait until Gentleware makes the new editor available to them. Not exactly the most flexible solution if you ask me, which might have been a reason for him not mentioning it. Still it is nice to see that someone who earlier concluded that UML profiles are sufficient now agrees that in order to generate code, developers need to work with domain-specific languages.

It was encouraging to see so many people participating both the MetaCase vendor session and Juha-Pekka's conference session. Especially the fact that some intelligent discussions took place about defining domain-specific modeling languages among the audience showed me that the audience has matured in this area. Where 3 years ago we had to explain to nearly each and every one what DSM meant now people we more interested in the "how to do it". They got the idea and agree with the benefits it offers, now they want guidance in how to get started with it. I see it as a big step forward.

Some of the best hitting comments I got from attendees were: "MetaEdit+ is the reason why Rational invented UML as their tool could support only one modeling language", "MetaEdit+ is MDA done right, 10 years ago" and "These people are the only ones who know how to do model-driven development correctly"

Webcast: Modeling with a Domain-Specific Language

We published a 12-minute informative webcast on domain-specific modeling. In it, Juha-Pekka directly compares UML with a DSM language-based approach. This makes the difference between them very clear.

Have a look here.

DSM Focus on Code Generation Event

Code Generation 2007 promises to have a significant focus on domain-specific modeling for model-driven development. With Microsoft and MetaCase already signed up as sponsors, I believe we can be quite sure of this.

The event organizers have managed to get some influential speakers in the area of MDD: Axel Uhl from SAP, Markus Völter, Steven Kelly (MetaCase), Andrew Watson (OMG) and of course the people from the Microsoft DSL team.

If I understand correctly, the program promises to give attendees a valuable learning experience with a rich mixture of sessions from 75 minutes up to well over 3 hours.

DSM growing, UML slowing

The number of hits on Google for the string "domain-specific modeling" is clearly showing exponential growth. Today Google treated me with 88,100 results, making the graph I created 2 days ago (above) already outdated (darn...it has that same characteristic UML models also have).

I was interviewed by the German magazine "ComputerZeitung" for their focus on modeling and model-driven development, the article is available here.

Reading it myself, it surprised me to have the magazine report Bran Selic talk about a new wave of UML:
"Wir bauen substanzielle semantische Definitionen ein. So wird die Sprache ausdrucksstärker und zu einem besseren Kommunikationsmittel."

Translation: We're building substantial semantic definitions into UML. This way, the UML will become more expressive and a better vehicle for communication. In other words, it seems the OMG thinks it a good idea to make it even more complex and even less suitable for code generation: Adding precise semantics to a general-purpose modeling language, leads you to some sort of ehr... general-purpose-domain-specific modeling language (hmmm try to market that).

UML is poorly suited for generating anything else from it than simply a copy of what it represents. Normally this means documentation. Adding precise semantics to the UML means the committee of tool vendors (all with their own agendas) need to agree on those precise semantics, which is impossible, period. The precise semantics will most likely end up being very loosely interpretable precise semantics, that you then can probably extend with semantic profiles of something like that. The end: a 160,000 page UML specification with the "U" clearly meaning "universal". Great idea Bran, let's add some more stuff to the UML.

The OMG seems to struggle with its mammoth specification, a new wave is needed because competing, disruptive technologies (domain-specific modeling) is eating away at the base. The only thing to do: move upmarket, add more stuff to your product (read this thought leading book on it).

A mark on the wall of UML's demise, is Telelogic, which now offers its UML tool for zilch, all you need is register and download. Their sales team will then no doubt hunt you for costly add ons. The UML tool market is under heavy stress, with hundreds of free tools which are perfectly fine for UML since you cannot generate all that much useful stuff from the de-facto modeling language anyway. Some tools claim they do however, and therefore cost mucho, you'll need to fork-out a substantial budget. Then, according to a Compuware-sponsored laboratory test (wow, must be very reliable) you could achieve a productivity increase of 35%. According to the Compuware marketing professionals this is a real "Landmark".

Funny that you do not see so many more of these studies isn't it? After all, MDA and UML are already so widely applied if you listen to the MDA tool vendors and OMG honcho's. Really, where are all the success stories of UML? Care to share one?