Houtje-touwtje CMS

In de Computable van 18 februari (pagina 10) schrijft Sjoerd Kessels over de mismatch tussen portals en Content Management Systemen. Belangrijk voor deze discussie is om te beginnen met de definitie van een CMS - en niet te vergeten Digital Asset Management (DAM), Enterprise Content Management (ECM), Web Management systemen, et cetera - stelt consultant Gerhard Peper.

Er is een zeer groot verschil in de perceptie van wat een CMS is tussen de eindgebruikers en de ict'er. De gebruiker zal het portal gedeelte zien als zijn CMS, terwijl een ict'er geneigd is om meer de repository als het CMS te zien.
Een rondgang bij organisaties als bijvoorbeeld CMS-Watch (http://cmswatch.com/) en Gilbane Report (http://gilbane.com/) laten al zien dat er meer dan vijfhonderd commerciële en meer dan tweehonderd open source oplossingen bestaan die pretenderen iets als CMS te zijn. Hierdoor blijkt eigenlijk al dat er geen sprake kan zijn van een 'volwassen' markt.
Het mag duidelijk zijn dat deze oplossingen sterk van elkaar verschillen van functionaliteit.
Uitgaande van een standaard 3 tier model ( presentatie - bussines - storage/repository) bevinden de oplossingen zich op een of meer van die lagen.
Verder zijn er veel producten die op een of twee van de lagen oorspronkelijk zijn ontwikkeld en via aankoop van bestaande externe producten doorgegroeid zijn naar het volledige drie lagen model. Dit leidt in bijna alle gevallen echter tot houtje-touwtje oplossingen. D is ook het geval in de top van de markt.
Wat Kessels terecht opmerkt , is dat er duidelijk onderscheid gemaakt moet worden tussen de functionaliteit van het portal gedeelte en de core van het CMS (de repository). Daarom is het interessant dat hij de JSR170 ( Java Content Repository API, http://www.jcp.org/en/jsr/detail?id=170) noemt. Hier ligt mijn inziens ook exact de scheidslijn tussen de portal en het CMS. Ideaal gezien zou het CMS dus alleen in de storage/repository laag moeten zitten, via een dunne schil bereikbaar vanuit de business laag. Hier kan de JCR API in voorzien.
Het is dan ook spannend om te zien wat de grote CMS aanbieders die betrokken zijn bij het opzetten van de JCR API, nu gaan doen. Wanneer deze partijen de JCR gaan implementeren in hun CMS kunnen grote delen van hun product makkelijk vervangen worden voor bijvoorbeeld een portal product van een conculega of kan de repository eenvoudig migreren naar een andere oplossing.
Conclusie is dan ook dat een CMS wel degelijk nuttig is en zelfs noodzakelijk om niet te vervallen tot houtje-touwtje oplossingen. Echter een strikte scheiding tussen de portal en het core CMS is daarbij wenselijk.

 
Gerhard Peper, Xlexit Consulting