« The Process Centric v… | Home | Why Model Driven Soft… »

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

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

4 comments:

To 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.

Michel Weststrate (URL) - 27 01 10 - 09:59

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.

Paolo Predonzani () (URL) - 27 01 10 - 10:21

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.

Stephan Hochdoerfer (URL) - 27 01 10 - 12:03

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.

Johan den Haan () (URL) - 28 01 10 - 17:21