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