Vaak waarschuw ik dat een bepaald CMS prima geschikt is voor ’simpele’toepassingen, maar niet noodzakelijkerwijs voor ‘complexe’situaties. Dat is altijd een beetje lastig, want ’simpel’ en ‘complex’ zijn nogal subjectief.

Ter illustratie: een jaar geleden las ik de blogpost van Jon Marks: “Wanneer mensen CMS zeggen op Twitter, bedoelen ze WordPress, Drupal of Joomla! Dus ik raakte een beetje in paniek. Ik ken WordPress. Af en toe komen we Drupal tegen in een selectieproces, en Joomla! eigenlijk nooit. Ik heb nog nooit een van die twee geïmplementeerd. Zijn we dan echt zo out of touch?”

Ik weet zeker dat een heleboel mensen meteen zouden denken dat Jon Marks inderdaad heel erg out of touch is. Want er zijn miljoenen sites die op WordPress, Drupal, en Joomla! draaien. Als mensen überhaupt al weten wat een CMS is, dan zijn die drie de archetypische voorbeelden. Ze zijn er bijna een synoniem voor geworden. Zo zeer zelfs, dat een serieuze Engelse krant als de Guardian WordPress als het ideale CMS voor de stad Birmingham aanraadt, en de auteur zich verbijsterd afvraagt waarom WP nooit een eerlijke kans kreeg: “Waarom was het niet goed genoeg voor Birmingham? Het lijkt er op dat de heersende gedachte is bij de overheid dat als je je niet blauw betaalt (of eigenlijk, de belastingbetaler), je geen waar voor je geld krijgt.”

Ja, ho eens even.

Natuurlijk, miljoenen mensen gebruiken deze systemen en zijn er ontzettend blij mee. Sterker nog, ik heb al vaker geschreven dat bijvoorbeeld WordPress een van de weinige systemen is die mensen daadwerkelijk prettig vinden om te gebruiken. Dat is dan ook de reden dat ze in de reviews die we bij de Real Story Group over web content management systemen schrijven hoog scoren op “simpele” scenario’s. Want de meeste van die miljoenen sites vallen in die categorie.

Aan de andere kant zijn er nog steeds geen multinationals die alles wat ze online doen, draaien op simpele, open source PHP systemen. En dat is niet omdat ze tegen open source zijn, of omdat ze denken dat PHP niet goed genoeg is, of omdat ze zich blauw willen betalen. Het is omdat dat soort systemen gewoon niet zo goed werken in hun situatie. (Overigens wil ik hier niet meteen alle open source PHP-systemen generaliseren, want sommige – zoals TYPO3 – zijn tamelijk complex. Daarnaast is bijvoorbeeld een open source .NET systeem als DotNetNuke juist weer tamelijk rechttoe rechtaan.)

Ik krijg vaak tegengeworpen dat je “alles” kunt doen met een bepaald CMS. En tot op zekere hoogte is dat natuurlijk waar. Maar het is ongeveer net zoiets als zeggen dat een fiets de makkelijkste manier is om op je werk te komen, dus dan moet dat ook wel de makkelijkste manier zijn om naar de zuidpool te gaan. Ja, natuurlijk kan dat. Maar weet je zeker dat dat ook is wat je wil? En zelfs als je voornamelijk heel veel fietst, zou een reis naar de zuidpool dan niet een uitstekende aanleiding zijn om toch eens te kijken of andere vervoersmiddelen daar misschien beter voor geschikt zijn?

De vraag is dus eigenlijk wat een project ‘complexer’ maakt dan die ’simpele’ toepassingen. En daar kunnen we het lang over hebben (sterker nog, dat is wat we een groot deel van de tijd doen op de blog van de Real Story Group). Maar om toch een paar voorbeelden te geven van dingen die al snel complexiteit toevoegen:

• De schaal van de CMS-implementatie. Als er honderden of duizenden gebruikers zijn, en er tien- of honderdduizenden of soms wel miljoenen content items zijn.
  Als een CMS bijvoorbeeld gebruikers of contentitems simpelweg als een lijst weergeeft (nieuwste bovenaan of alfabetisch) kun je je voorstellen dat dat nogal problematisch wordt op zo’n schaal. Je hebt dan een veel beter beheersysteem nodig. Bijvoorbeeld een efficiënt zoeksysteem, ‘audit trails’ (wie deed wat, en waar?), of integratie met externe authenticatiesystemen zijn dan onontbeerlijk.

• De schaal van de gepubliceerde website. Een simpel PHP CMS draaien op een LAMP-server (= Linux, Apache, MySQL, PHP) bij een hosting provider is snel, gemakkelijk, en goedkoop.
  Maar wat werkt voor duizenden bezoekers schaalt vaak volstrekt niet naar miljoenen. Veel van de simpele systemen zijn in de praktijk lastig draaiend te houden voor intensief bezochte sites. Ze zijn er eigenlijk niet op berekend, en je moet er dan een flinke gereedschapskist aan trucs op los laten. Daarentegen hebben veel van de complexe systemen de functionaliteit voor het opschalen al ingebouwd.

• Content hergebruik: Als je dezelfde content in verschillende plekken van een site, of in verschillende sites of andere publicatiekanalen wil gebruiken. Vooral als het gaat om ‘placeless content’, die aan de hand van (metadata) criteria ergens automatisch wordt gepubliceerd. Niet alleen is daar een complexer systeem voor nodig, maar vooral ook interfaces die het nog enigszins begrijpelijk weten te houden voor de gebruikers.

• Globalisatie: Kijk maar eens naar de website van een vliegmaatschappij. Er is niet absurd veel content, maar vaak moet het beschikbaar zijn in tientallen talen, in verschillende sites voor verschillende landen. De content moet dan vertaald worden, maar ook aangepast aan lokale nuances. (Je zult Frans nodig hebben voor Frankrijk, België, Zwitserland, en Canada, maar de inhoud zal toch echt anders zijn.) Dat allemaal efficiënt beheren is tamelijk moeilijk, en met elke toegevoegde lokatie neemt de complexiteit exponentieel toe.

• Workflow: Meestal wordt het belang van workflow overschat. Een simpele ’save – review – publish’ is in veel gevallen al meer dan genoeg. Maar er zijn gevallen waar dat absoluut niet voldoende is. Als bijvoorbeeld alle content eerst door de juridische afdeling moet worden gecontroleerd, en alles naar meerdere talen moet worden vertaald. Dit dan liefst – om tijd te besparen – in een paralel lopend proces. In zo’n geval moet je ingewikkelde workflows met vertakkingen kunnen ontwerpen om daar mee om te gaan.

Natuurlijk kan ik zo nog wel een tijdje doorgaan; als je dit interessant vind, raad ik je aan eens een kijkje te nemen bij de Real Story Group. Maar het moge duidelijk zijn. Als ik zeg, “dit systeem is fantastisch voor simpele toepassingen, maar ga er niet van uit dat het net zo goed werkt voor complexe situaties” – dan bedoel ik ook echt complexe scenario’s. (En dat betekent niet dat ik tegen fietsen ben.)

Waar het uiteindelijk op neer komt is het juiste systeem voor de toepassing kiezen. Neem iets simpel en goedkoops voor een simpel probleem. Maar vergeet niet dat je voor complexe problemen soms complexe oplossingen nodig hebt. Het zou belachelijk zijn om een trein te kopen om boodschappen mee te doen. Maar het is net zo belachelijk om op de fiets een pallet bakstenen op te gaan halen.