What Model Driven Development can learn from Content Management Systems
I don’t know what you do, but I am using a Content Management System (CMS) to manage this blog. I didn’t type any HTML tag to produce this post. Lots of websites nowadays are managed using WordPress, Joomla!, Drupal, or other CMS systems. Did you ever wonder why Content Management Systems are so successful and widespread?
Comparing CMS to MDD
A while ago I wrote "8 reasons why Model-Driven Development fails". Paolo Predonzani posted a comment on that article in which he stated (among other things):
Having said this, let me bring your attention on a particular type of framework: content management systems. It may be a bit of stretch to call them frameworks, but CMS’, with their plugins, configuration and architecture, look like the result of a software factory approach too. Certainly, CMS’ are no longer simple website building tools – they are proper software platforms. A team is responsible for the reusable / configurable plugins, another team is responsible for the end application development. There is rigidity and flexibility is possible only where allowed (even in GUI’s). Roles, skills, and project dependencies have to be structured in a certain way to make the project successful.
Certainly CMS’, unlike MDD, are very popular and I think they don’t suffer much form dangers 6 and 7, which are related to understanding and perception. So is this an area where MDD can improve? I don’t have an answer myself. My comment originates from the fact that CMS enjoy an often disproportionate acceptance / popularity compared to their technical merits, while MDD suffers from lack of acceptance, despite the benefits it can provide.
I think Paolo made an interesting observation. Content Management Systems can indeed be compared to Model Driven Development (MDD) frameworks. A CMS is used to create and change a website by defining elements (pages, navigation, content, etc.) on a high(er) level. The actual implementation (HTML, JavaScript, CSS, etc.) is generated from this high-level definition.
The compelling question is now: why are Content Management Systems so successful and widespread, especially in comparison to Model Driven Development?
CMS success factors
Let’s look at a couple of success factors of CMS systems and see what we can learn from them to make MDD more successful and widespread.
- Ease of use: a CMS system really abstracts away from web development. You have flexibility and ease of use at the points you want to have it: updating and changing content. Everybody can do it, no dependency on specialists.
Lesson: MDD should really abstract away from programming languages. Make it easy for non-programmers to define the models! - Quality: a CMS (if you select the right one) ensures compliance with web standards and provides search engine optimization. It will take a lot of time to reach the same result by hand.
Lesson: MDD should result in a software application complying with standards and the target architecture you expect from the delivered type of application. - Room to grow: start with a simple website and add features as you need them: forums, RSS feeds, social media integrations, multi-media, etc. A CMS makes this quite simple and manageable.
Lesson: MDD should not only focus focus on building the first version of an application as fast as possible, it should also provide ways for easily updating and extending applications. - Multiple views: a CMS has a code mode to switch instantly between code view and WYSIWYG view.
Lesson: MDD should provide multiple views (projections) of the same model. - Extensibility: a popular CMS has a plugin mechanism and provides an extensive set of plugins.
Lesson: MDD frameworks should be extensible. - Integrations: a CMS provides multiple build-in integrations for services which are use very often in websites. It for example integrates out-of-the-box with flickr, twitter, google analytics, etc.
Lesson: MDD frameworks should provide integrations with standard services in the solution domain of the target applications. - Community: a popular CMS has a vivid community who delivers support, plugins, and spread the word.
Lesson: MDD should not only focus on technology, but also on building a user (!) community.
CMS problems
When I was writing this article I stumbled upon this article which describes a list of problems a content management doesn’t solve and how to overcome them. I think MDD can learn from the problems of a CMS too.
- Lack of editorial control: everybody can use it, somebody needs to ensure quality and accuracy.
Lesson: in an MDD project somebody needs to ensure quality and accuracy. Ease-of-use means that more people can create a mess. - Uncommitted contributors: if anybody can do it, that doesn’t mean they will. Within an organization responsibilities and time should be appointed to make sure the CMS receives the attention it needs.
Lesson: it’s nice that MDD enables domain experts to be involved in software development, but do they want it? Do they have time? - Bad copywriting: not everybody can write good web copy. Provide structure, training, and templates. Guide people in using the CMS.
Lesson: even if people can understand the models, this doesn’t mean they can create meaningful, maintainable models. MDD should be accompanied with tooling, training, and templates. - Focus on tool selection: not enough focus on change management and production processes.
Lesson: introducing MDD is more than selecting the right tool. Roles will change, responsibilities will change. - Bloated websites: by removing barriers you encourage people to add more. More is not always better. Focus on users and remove!
Lesson: by making it easy and fast to build functionality, MDD also encourages people to add more. YAGNI also holds for modeling!
You will probably come up with a lot more success factors, problems, and lessons for CMS and MDD. Please share them!
Photo by AhavatHaEmet
7 Comments Added
Join DiscussionTo me, the most important success factor is that CMS are targeted at a clear platform, solve a clear problem and have a clear domain (you cannot build any web-app). Those are the main reasons why clear and ease-to-use abstractions can be made.
So in addition to the mentioned ones, another lesson would be to define a clear and limited domain for your model, because it is very tempting to keep extending the model until it supports almost every situation.
Just a quick thought. CMS’ have good fallback: if the simple approach fails, there is a more complex but still manageable approach ready to be adopted. Elaborating on your list:
– Easy to use: if basic skills fail, bring in readily available CMS experts
– Quality: first focus on the application at hand, then focus on reuse.
– Room to grow: start with a small project, make it grow.
– Multiple views: start with the simplest WYSIWYG editor, then move to the more technical HTML editor, then move to the even more technical code editor.
– Extensibility: start with built-in features, then create plugins.
– Integration: start standalone, then address integration. CMS’ don’t demand to be the overarching architecture. They play well even as components in a larger architecture.
This is so reassuring for somebody who is about to adopt a CMS! Even if everything is not perfect upfront, it can be fixed later.
Again, perception plays a big role.
Also the switch from simple to complex can happen much later in the project compared to MDD. This gives time to become familiar and confident with the tools.
Very good comparison. Ease of use seems to be a strong point in the story. The key, at least for me, would be a very good toolset that helps to develop as easy as possible.
Michel,
> “So in addition to the mentioned ones, another lesson would be to define a clear and limited domain for your model, because it is very tempting to keep extending the model until it supports almost every situation.”
Good advice! It’s one of the pitfalls of DSL design. Most DSLs start simple and focused, but end up as some sort of a general purpose language.
Great post on great topic.
I was also wondering some time ago about the relations between the two worlds.
I fully agree with all your points, and also with Michel that the purpose of CMS is much more focused than MDD.
I think one aspect to be considered is also the TARGET of CMS and MDD: the former is basically for an end user (and it tends to go for a no-hassle solution, where you get your cms up and running in seconds), while the latter is definitely for the analyst/designer.
CMSs are more spread because setup/config is (or should be) trivial, while usage is the core task, and this is what is perceived as adoption.
MDD is intrinsically a niche product because it’s useful at design time and then, once the final outcome is out, nobody cares any more about the fact that MDD was used.
Some attempts have tried to close the gap between the two worlds (e.g., see app2you.com, a startup from UCSD), but they ended up in the land of nobody. My feeling is that the same fate can be foreseen also for all the “programming for the people” approaches (and also the visual mashup builder approaches, if you think about it: they are not accepted neither by the end users nor by developers, that want to have their hands on code and details). And also approaches based on “modeling as a service” will not move the balance.
At the very end, what people (=users) like is a WYSIWYG interface; what geeks (=developers) like is programming.
What is the target of MDD?
(and I’m quite sad while asking that, being a strong believer in MDD)
Hi Marco,
>MDD is intrinsically a niche product because it’s useful at design time and then, once the final outcome is out, nobody cares any more about the fact that MDD was used.
I don’t agree. MDD should not only focus at the design or development phase. It should aim to automate and abstract the full application lifecycle. That’s were the real value is. See also my post about MDD and deployment: http://www.theenterprisearchitect.eu/archive/2010/02/11/why-model-driven-software-development-isnt-fast-enough-and-how-to-fix-it
>And also approaches based on “modeling as a service†will not move the balance.
I think it will make a difference. Platform-as-a-Service (PaaS) solutions are quite successful nowadays and heavily rely on visual modeling tools or specific languages to create or customize applications. See also my post about the need for MDD in PaaS: http://www.theenterprisearchitect.eu/archive/2010/04/27/multi-tenancy-and-model-driven-engineering-necessary-assets-of-a-platform-as-a-service
>What is the target of MDD?
That depends. MDD tools can target developers and try to improve their productivity. MDD tools can also aim at ‘users’ by providing Domain-Specific Languages which can be used by domain experts.
Hi Johan,
I perfectly agree on your first point. I didn’t mean MDD should not be used after deployment. Actually, e.g. we experience huge benefits in using MDD in the maintenance and evolution phases. However, this is not exposed to the user: advantages are granted because we are able not to break the virtuous cycle of modeling and model transformations, but the user only sees the effect of this (that is, quick response to change requests). What I meant was that what the user typically does not want to _experience_ the actual modeling, he only appreciates the result. It’s not a technical nor a methodological issue: the point is that users prefer to interact upon a running prototype instead of on a model (and we see this also in BPM). Fortunately, MDD is great in supporting this.
About the PaaS discussion: I’m not sure, I agree that modeling could bring advantages, but I think that PaaS are (and will be) disguising modeling as an enriched WYSIWYG interaction paradigm.
This is not necessarily bad, it could be a first step towards full fledged MaaS (Modeling as a Service).
To make a parallel: we are witnessing the same thing in several fields, e.g., in web search (a much broader and adopted paradigm, for sure:). Search engines are getting enormously more complex and structured _underneath_, including entity recognition, structured data extraction, and so on. But they don’t dare change the user interaction, because _the habit of the user is hard to change_. So we will see the Google 3-4 keyword search around for a while, and changes will be added _very_ slowly (see e.g., google instant or the new google images result visualization). Probably something like this may happen to MDD too.