Valio.fi deep dive #5: Content Management Systems as platforms
After a brief hiatus, it’s time to look at the Valio case again. This time, I’ll explain a few decisions behind our content management model. I’m sure some of this sounds familiar to almost every web site developer, although most won’t probably dive as deep as we did.
The setup
So you’re developing an ASP.NET MVC web application. You whip up Visual Studio and crank out a few controllers, views and whatnot. Ka-zoom, you have the working skeleton version available in a day or so. At this point, what you’re actually doing is that you’re exposing your key business objects – typically the database – through a server and a browser.
A few days or weeks later you ship the app, and immediately a business user tells you that “Actually, that segment of text is wrong. The correct one is…”. You quickly update a view. Two weeks and thirty updates later, you grow tired. Not only do they want to change the text, but they also want to swap in new images. And one day, you’ll get a mail asking you for a chance to slip in an additional information page. At a specified URI, of course. “Can I have it added to the navigation, too?”
At this point, you’re likely to have a few content delivery related customizations across your codebase. Your route table has a handful of entries specifically for campaign and info pages. Your version control history for the Views directory shows an increasingly high percentage of checkins related to one-off customization requests.
There will be a day when you find yourself asking: Should I just have started with a content management system (CMS), using extensibility hooks to implement your business functionality?
The problem
All web sites require some kind of CMS functionality: the ability to edit typical fragments of web content. Because of this, almost all web sites are based on a CMS. And there are so many of them; see the Wikipedia list.
At the other end of the spectrum, most web applications have very limited needs for content editing. Almost all have some requirements in this regard: even the most closed warehouse management tool often has a small area reserved for administrative announcements.
Most web projects fall between these two extremes. A typical e-commerce application is mostly an application, but it definitely needs content input: product descriptions, images, special offers etc. all need to be designed, tested and typed in on the go, without needing a developer’s input. A complex and diverse collection of content (such as Valio) is by definition a site and needs to be editable, but it also has a huge load of functionality – some of which may be considerably easier to implement using plain programming tools, not a CMS framework.
Picking our sides
When planning the technology strategy for the Valio project, we knew we were in trouble no matter what we picked.
There were requirements for considerable application-like functionalities including user-produced complex content (recipes), APIs for third parties, and demanding search rules. Simultaneously, we knew we would have to entertain a diverse group of content producers, from experienced web editors to amateur moderators.
| If we chose a CMS… We would have at least a stub implementation for most of our CMS functionalities.
We would implement all our logic using the CMS’s extensibility API. This might range from being moderately acceptable to extremely painful, but we probably wouldn’t know before we tried. We would have an authentication / user profile system available out of the box. However, most profile systems are not designed to be very well extendable. In particular, most don’t support complex integration to external directories. |
If we wrote a custom application… We would have a relatively straightforward task implementing all the custom things. Hard things are still hard, but we’d be able to estimate them with reasonable confidence.
We would have to write all the CMS tools by hand. Given our reasonably complex set of requirements (page previews, limited versioning, web part –like composability, customizable URIs, page templates), we knew this was going to be quite a few lines of code. We could do whatever we want with the authentication. Of course, that meant doing it all by hand, from square one. |
As you probably know by now, we picked the custom application route. The CMS side had its perks, but we decided against it for the following reasons:
- The client had a fairly particular vision of the content management model. While they didn’t have stated requirements for the administration UI, we knew there were quite a few practical requirements, particularly regarding bulk moderations, that were not typically sufficiently implemented in CMS packages.
- While we had lots of CMS experience, we also had the requirement of using Microsoft technology, and an inner desire to use MVC to enable very fine-grained HTML output management. We also preferred an open source approach to ensure we could deliver everything we wanted. That left us in a situation where none of us had experience on a CMS that would match the requirements. Since evaluating CMS extensibility is very time-consuming, we didn’t want the additional risk of eating our precious days.
- On the other hand, having lots of CMS experience (including developing two of them) gave us a head start on designing the necessary infrastructure. Thus, we felt less intimidated by the challenge of creating our own tooling.
At the crossroads?
If you’re facing the same choice, I wouldn’t blindly recommend following us. We have been met with plenty of criticism and surprised faces when telling this story. Many people consider custom app writing a symptom of the NIH syndrome, particularly on a field as well established as CMSes. Also, it is a non-trivial exercise even if you have a good idea on what you’re doing.
The key lesson here is to play to your strengths, and choose by the project type. If you have a team with experience in a particular CMS and you have complex content management requirements, that particular CMS is likely to be a good idea. Then again, if all your users need is a single bulletin board for announcements, taking on a CMS framework is probably a hugely unnecessary piece of extra baggage.
However, one important thing is schedule predictability. If custom code and a CMS seem equally strong, consider any pre-baked system a risk in terms of change management: you quite likely cannot predict all its design constraints in beforehand.
For example, the requirements for Like button throttling in the Valio case were discovered reasonably late in the project, as was the moderation workflow for user's recipes. Most CMSes don’t offer smooth customizability in scenarios like this, and thus a small requirement can suddenly result in a larger refactoring, perhaps writing a module that replaces a part of the CMS itself. You would also be excessively optimistic in thinking that relatively obscure elements such as community content workflows would – or even could – be defined before the project.
The diagram below illustrates some of the design aspects and their weight in a totally customized scenario as well as a CMS-based one.
Not all CMS platforms are equal. The right end of the axis represents the versatile but hard-to-extend CMS solutions like SharePoint. The middle section of the chart represents CMS stacks that are more like toolkits for do-it-yourself site development; there are plenty of open source CMSes that are unfinished enough to be called such.
The conclusion
We picked what we picked because of 1) the requirements we had and 2) the people we were. Neither is irrelevant, and this is a key takeaway: A different team might pick an entirely different solution for the same requirements, and they might quite well be right.
You won’t have an easy time deciding on this: it’s a complex architectural choice, and estimating the actual impact of either option is reasonably hard. In the next post, I’ll discuss the key technical choices of our CMS implementation (on class/table level) to give you an idea on what sort of challenges you might be facing and help you in the process of gauging your cliff.
October 20, 2011
· 
Jouni Heikniemi · 
3 Comments
Tags: CMS, valio.fi · Posted in: Web
3 Responses
Heikniemi Hardcoded » Valio deep dive #6: Features of our custom CMS - November 7, 2011
[…] the last post, I touched on the choice of using a CMS product or writing your platform yourself. We picked the […]
Tuomas - January 25, 2012
Sometimes you could also have an option to use CMS (or something like that, maybe Windows SharePoint Services) just to expose content through WebServices to your custom application(s).
Pro: You won't be so dependend on CMS.
Con: Management interface won't be so WYSIWYG.
Betty Dawson - September 18, 2021
Students, it would be best if you read this: brillassignment experts are not worth your trust. Don’t let their first order discount trick you: the quality of your finalized paper will disappoint you for sure. https://scamfighter.net/review/brillassignment.co.uk
Leave a Reply