Management management Over probleem dat CMS selectie heet

Op verzoek van een klant heb ik onlangs moeten werken met een vooraf, door de klant bepaald, content management systeem (CMS). Veel ervaring met 'grote' CMS'en had ik eerlijk gezegd niet, dus het leek mij ook wel weer interessant om het uit te proberen. Het gaat in dit geval om een middelgroot bedrijf waar ongeveer 100 medewerkers in dienst zijn. Het CMS dat zij graag geïmplementeerd zagen was Drupal. Blijkens de keuze van het Witte huis voor dit CMS, waarschijnlijk toch geen slecht CMS. Hoe dan ook, mijn ervaring met het Drupal CMS bleek een grote reclame stunt te zijn voor simpelere CMS'en. Nu ben ik al een week bezig met inrichten, om de defaults goed te krijgen. Maar waarom toch? Waarom zijn heeft het systeem niet gewoon goede defaults? En nee, ik zou dit betoog hier niet schrijven wanneer er geen idee bestaat van wat goed is.

Het web is gebouwd op simpele technieken, die samen overigens erg complexe gehelen kunnen vormen. Maar in essentie is de techniek overzichtelijk.

Het web draait allemaal rondom bronnen, resources. De term URL staat voor Uniform Resource Locator, de uniforme manier om de locatie van een bron aan te duiden. Content in een content management systeem is een typische 'resource', een bron, en heeft daarom een ook een adres. Content kan hiërarchisch, of niet hiërarchisch zijn. Netzoals URL design. Waarom zijn er dan systemen die deze vanzelfsprekende koppeling negeren, en zelfs expliciet willen doorbreken... waarom dwingen dat er handmatig een URL gekoppeld moet worden aan een 'content item'?

Pagina's hebben titels. URL's bevatten namen. Zoekmachines zien graag titels van pagina's terug in de URL's. Waarom is er hanteren zoveel CMS'en standaard een adres die niet aansluit bij de inhoud van de pagina?

Naast pagina's met concrete inhoud, zijn er ook pagina's die dynamischer zijn. Ze bestaan bijvoorbeeld uit delen van content van andere pagina's, zoals zoekpagina's en veelal hoofdpagina's. Maar toch hebben allemaal een locatie in de totale site hiërarchie (hoe plat deze ook moge zijn) Waarom kan ik ze niet op de zelfde plek beheren als content pagina's?

Terug naar Drupal. Na het installeren van meer dan 15 modules heb ik nog niet alles werkend, en al deze modules moeten ook nog eens geconfigureerd worden. Voegen extra complexiteit toe voor de eindgebruiker en waarom? Omdat er mensen zijn die af willen wijken van wat gangbaar zou moeten zijn. Omdat er mensen zijn die graag onleesbare URL's willen maken. Omdat er mensen zijn... Zadel zij die af willen wijken dan op met de problemen, niet de simpele ziel die gewoon een goede site met zo min mogelijk moeite wil.

Het is frustrerend dat er keer op keer weer gekozen wordt voor moeilijke technologie. Moeilijke technologie zal ook wel geavanceerd zijn. Terwijl de meest succesvolle technologieën simpel zijn. Vreemd genoeg hebben mensen de neiging om bij het maken zich te spiegelen aan zij die groter zijn dan hen. Wanneer je geen enterprise hebt, hoef je ook geen enterprise solutions te nemen! Kleinere organisaties zouden veel beter snel kunnen handelen. En grotere organisaties? Ik vermoed dat zelfs zij hun oplossingen kunnen versimpelen. Door niet te kiezen voor één, allesomvattende en geavanceerde, totaaloplossing, maar te kiezen voor een slimme combinatie van simpele oplossingen die precies die problemen oplossen waarvan de impact te groot is. Zo zou in plaats van een 1 groot content management systeem met geavanceerd rechten management, zou gekozen kunnen worden voor meerdere cms'en met de simpele lezer, auteur, administrateur rechtenindeling die per afdeling wordt opgezet, iets waar daarboven, indien gewenst, wordt samengevoegd tot 1 geheel. En dat kan best 'op maat' geprogrammeerd worden. Is dat duur? Het is maar hoe je het ziet. Configuratie van complexe software is ook niet eenvoudig, en duurt misschien wel net zo lang. Maar nog belangrijker is dat configureerbare systemen beperkend werken, terwijl programmeerbare systemen eigenlijk geen beperkingen kennen.