Making Model-Driven Software Development live up to its promises
Model Driven Development proponents see a lot of advantages of using MDD techniques. Higher development speed, increased quality, more cost-effective, empowering less-experienced developers, just to name a few. If you look at these promises the question arises why the whole world isn’t using MDD right now? Why don’t we hear a lot of MDD success stories?
In a recent article I wrote about some of the main concerns which prevent people to use MDD, as mentioned in this StackExchange thread “Why aren’t we all doing Model Driven Development yet?”. This article triggered quite some discussion and you should definitely read the comments! I wrote this article as a warming-up for the fishbowl discussion session I hosted at Code Generation 2011 two weeks ago. In this session, titled “Making Model-Driven Software Development live up to its promise”, we discussed the future of MDD in four sections, to cover subjects like popularity / marketing, creating alignment between programming and MDD, focusing on domain experts, and education. It was a great session with lively discussions and I want to share some “sound bites” with you in this post.
- We need to convince developers to start using MDD.
- It’s a social change: we need to move to a separation between language designers and language users.
- The success stories of MDD are not shared because of the competitive advantage. Real success stories are often very domain-specific.
- Generate the boring stuff, make developers happy!
- As the market grows all current developers can move to language design. Language users can be a new group of people.
- MDD is too hard to explain in one sentence. Complexity is a barrier.
- The message of MDD needs to be mapped to business bla, but it should be different than other tech messages.
- XP (eXtreme Programming) is successfully marketed by connecting it to incremental development / agile.
- We need a different name. Nobody will buy MDD, it’s already dead from a marketing perspective.
- Focus on agile, that’s the value proposition of MDD!
- We need metrics to measure the success of MDD.
- MDD supercharges Agile and Lean!
Alignment with programming
- In certain communities it makes no sense to distinct between modeling and programming.
- There is no difference: just a language at the right abstraction level.
- MDD is only useful to bridge the time between steps in 3GL languages.
- The mainstream feeling about language design is that it is very complicated. People don’t know that the tools have evolved.
- Are we as an MDD community our own biggest enemies? All “old” discussions will always come along, e.g. textual vs. visual languages, etc.
- API is a model, a DSL. People are creating abstractions all the time.
- Building linguistic abstractions IS different (a lot of discussion about this statement).
- There is a projection possible from an API to a language, but they are not isomorphic.
- We are good at language processing, so there is a case to create a language instead of just an API.
- Using or creating a language asks for a different skillset. Be aware of the difference and approach developers with a different story.
Focus on problem domain
- Move languages to the language of requirements.
- Make languages specific.
- Involve domain experts, use the existing notations of a domain.
- Do domain experts want to have a tool to build software? No, they don’t want to specify all details. They have no time for it. They only want to say yes or no.
- Programmers / analysts need to translate words to models and focus on the exceptions.
- It can be important that domain experts can READ models.
- Domain experts DO want to have a tool to build software… focus on the domain experst who are working as analyst or consultant.
- Fast feedback cycles are important. “Is this what you want?”
- New job title: configurators.
- Focus on the middle man! The one inbetween business and IT.
- There is not enough critical mass to be successful when we focus on domain experts who want to “program”.
- Focus on the ones who understand the domain (not only the ones in the domain / the customers).
- The biggest problem is to have a domain expert available to build the language. You need someone with a very deep understanding of the domain to design a domain-specific language.
- We as an MDD community failed: we didn’t bridge the gap between business and IT… we need a new role now? (the middle man).
- Universities don’t teach MDD or modeling. There are people leaving universities who are not able to read a UML diagram.
- Or it leaves a bad taste because of the mandatory waterfall use cases.
- The problem is a generation gap. The renew time of professors at a university is 25 years, so you can only innovate every 25 years.
- Universities shouldn’t just focus on preparing for the job market. They should look further.
- People need to learn more than one programming language to understand the concepts as grammars and trees much better.
- We need to improve productivity, hence problme domain languages are needed.
- Universities should create open minded people who will accept new languages.
- You cannot create a simple DSL on top of complex UML.
- De-empasize UML education.
- The more human languages you learn, the more open you are to new languages. Minds will open!
Thanks to all attendees for the great discussions! I guess you also have a meaning about these subjects? Post them in the comments and keep this discussion going!
8 Comments AddedJoin Discussion
The mentioned StackExchange thread can be read here:
Worth a read!
I don’t know the difference in scope between a DSL and MDD, but I can tell you the former is a popular topic. Even Martin Fowler dedicated a book to Domain Specific Languages, and that gives it a potential appeal as a “next big thing”.
I agree that business software success it’s not about what technology your’re using to achieve the business goal, but how to use business knowledge and build from it the programs you need to success. That’s why I use GeneXus technology. I don’t run all the time about the “last” programming language. I do run to have from my customers their business knowledge and produce automatically their programs. If interested visit this: http://su.pr/2HGZSFa
In almost all cases MDD is done using DSLs (albeit that domain-specific is a broad term). The key idea of MDD is to raise the level of abstraction of the used languages. To do so you need to focus your language on a specific domain, which enables you to carefully analyze the variability in the domain, leading to a focused language on a high abstraction level.
How do you express the business knowledge of your customers? I guess you use DSLs?
See this whitepaper:
It’s a pdf which kind of theoretically explain that Tool (GeneXus), which I am using.
This is s an approach and I think is very practical and it works for me !.
The first comment is, I love everything about this site. Excellent content. I do have some recommendations.
First, a holistic enterprise needs integration of both process and data; especially data. The rapid generation of an app makes the app inexpensive but not cost-effective to the Enterprise. However, if there was a data quality service layer that all apps used (apps need to share data not propagate it)then I would be much more excited. Simple rule set: data is an enterprise asset and independent of any app; Business Process is designed to accomplish business product/result; Business Process is enabled with information technology to use views of enterprise data.
Second, the enterprise process modeling has to be more business oriented and not application oriented. Also, the meta-model needs to evolve from code orientation to enterprise business systems that produce enterprise business products/results (not screens and reports). Screens and reports are accessory byproducts to the real system.
Thirdly, and again from the point of view of ‘enterprise’ not app, DSL is not necessary and not helpful. Data Modeling is full of ‘DSL’ data so at the enterprise level we have accumulated incredible redundancy and disparate and complexity; therefore no interoperability and no real integration. The Enterprise needs a single, shared database of less than 20 forms of business objects. These stable data structures can be defined and leveraged for re-usability, enterprise integration, and therefore real agility with ROI. The Enterprise needs clean data and a holistic Information Architecture.
Thanks for your kind words!
It is interesting to see how you focus on a holistic view on the enterprise instead of an app focus. However, how realistic is it to have such a view in place? Isn’t that too complex? Doesn’t it change too much?
Don’t get me wrong: I believe in a holistic approach, but only if we are able to focus on the essence of an enterprise, see: http://www.theenterprisearchitect.eu/archive/2011/02/22/the-quest-for-business-agility-emergent-architectures Can you maybe explain in the comments on that article how this compares to your views?