Veel organisaties beschikken over een grote hoeveelheid gegevens, opgeslagen in diverse systemen. De uitdaging is om medewerkers de juiste informatie op het juiste moment aan te bieden, zodat ze hun taken optimaal kunnen uitvoeren. Portaltechnologie is hierop het antwoord. Het integreren van een bestaand extern content management systeem (CMS) in de portal ligt voor de hand. Maar is dit wel zo verstandig?
Elk werkproces waarbij medewerkers gebruik maken van informatie uit verschillende bronnen, kan worden ondersteund en geoptimaliseerd met portaltechnologie. Van meer gestandaardiseerde processen, zoals een sales- of HR-proces, tot ad-hoc projecten zoals de ontwikkeling van een nieuwe dienst of een nieuw product.
Afhankelijk van de toepassing kan een portal uiteenlopende functionaliteiten bevatten. Functionaliteit die altijd hoog op het verlanglijstje staat, is content management. Op deze manier kunnen gebruikers eenvoudig informatie als nieuwsberichten, interne memo’s kennis, procedures of best practices vastleggen, raadplegen en wijzigen in de portalomgeving. Veel organisaties beschikken over een volwaardig content management systeem (CMS) en kiezen ervoor dit bestaande, externe systeem te integreren in de portal: een voor de hand liggende en dus veelgemaakte keuze.
Het integreren van een extern CMS blijkt in de praktijk echter vaak een moeizamer en vooral ook kostbaarder traject dan verwacht. Een goed alternatief is dan ook om functionaliteit te gebruiken die het gekozen portalproduct standaard biedt, aangevuld met maatwerkfunctionaliteit. Content management kan zo ‘native’ worden uitgevoerd, vanuit de portal, wat veel gebruikersvriendelijker is dan via een aparte content-managementapplicatie. In eerste instantie stuit dit vaak op weerstand. Omdat organisaties al eerder hebben geïnvesteerd in een CMS, en zij het idee hebben dat zij anders onnodig geld weggooien, en/of omdat veel organisaties ervan uitgaan dat een extern CMS meer mogelijkheden biedt dan content management in de portal. Een portal wordt echter in de meeste gevallen gebruikt voor intranet- of extranet-toepassingen, waarbij traditioneel content management een veel kleinere rol speelt dan bij een internetsite. Een eenvoudiger oplossing volstaat dan. De ‘casual content contributor’, die in deze toepassingen belangrijker is dan de fulltime content manager, wordt in deze gevallen beter ondersteund door de geïntegreerde content-managementfunctionaliteit van de portal.
Achtergrond
De CMS-markt is een volwassen markt met heftige concurrentie. Leveranciers proberen allemaal een ‘best-of-breed’ content-managementproduct te bieden; de meest complete en onderscheidende oplossing op het gebied van content management. Het gevolg hiervan is dat deze producten steeds meer functionaliteit bieden en bovendien steeds verder buiten de traditionele paden van content management treden. Zo kunnen gebruikers complete websites publiceren, naast het beheer van de content en breiden CMS-leveranciers, onder de noemer ‘enterprise content management’, hun activiteiten uit naar documentmanagement, kennismanagement, zoekfunctionaliteiten, het toekennen van meta-informatie aan content (meta-tagging) en het aanbrengen van een ordening of taxonomie in de beschikbare content.
De opkomst van portals confronteert CMS-leveranciers met nieuwe uitdagingen. Vrijwel elke organisatie die een portal implementeert, heeft behoefte aan content-managementfunctionaliteit in de portal. De functionaliteit van een portal en die van een CMS overlappen elkaar echter. Betekent dit dat CMS-leveranciers moeten aansluiten bij de portalontwikkeling, hun producten moeten integreren in portals, of gaan zij zelf de portalmarkt op? De leveranciersmarkt lijkt er nog niet definitief uit te zijn.
Kern integratieproblematiek
Veel CMS-leveranciers volgen momenteel een defensieve strategie om hun product zoveel mogelijk te beschermen. Precies daar ligt de kern van de huidige integratieproblematiek: omdat leveranciers de waarde van hun CMS als best-of-breed product – om overigens begrijpelijke redenen – willen handhaven, zijn de huidige portal-integratieoplossingen die zij aanbieden verre van probleemloos. Hun oplossingen zijn niet gericht op het realiseren van een daadwerkelijk volledig geïntegreerde portal/content-managementoplossing, maar op het zoveel mogelijk pluggen van de vele functionaliteiten die hun CMS biedt. Dit gaat soms zelfs ten koste van de portal-functionaliteit. Want hierin ligt op dit moment hun onderscheidend vermogen.
Publiceren van content en personalisatie
Organisaties die kiezen voor de integratie van een extern CMS in de portal kunnen te maken krijgen met uiteenlopende technische en conceptuele uitdagingen.
Een eerste uitdaging is het publiceren van content. Een CMS voor het publiceren van content op een intranet- of website publiceert zowel complete pagina’s, opgebouwd uit afzonderlijke stukken content, als de samenhang tussen deze pagina’s: de menu- of navigatiestructuur. Een portal toont content of data via aparte portlets. Een in de portal gepubliceerde pagina kan meerdere portlets bevatten. Als gekozen wordt voor integratie van het CMS in de portal, moet de content uit het CMS in portlets getoond kunnen worden. CMS-leveranciers bieden vaak kant-en-klare portlets en/of een publieke Application Programming Interface (API) om zelf portlets te ontwikkelen.
Het gebruik van een kant-en-klare portlet voor het publiceren van content uit een CMS in de portal lijkt de beste en meest eenvoudige oplossing. Schijn bedriegt. Kant-en-klare portlets vormen een soort ‘black box’ voor de portal, met weinig flexibiliteit. Dit komt doordat de meeste CMS-leveranciers hun portlets zodanig ontwikkelen, dat deze zoveel mogelijk functionaliteit gebruiken van het CMS (hun eigen product). De functionaliteit uit het CMS wordt hierdoor geïsoleerd, in plaats van geïntegreerd. Dit is een probleem als content uit het CMS geïntegreerd moet worden met content uit andere bronnen, zoals een backend-systeem. Hierdoor is het lastig om informatie gebundeld, in de juiste context, aan te bieden aan gebruikers van de portal.
Zelf portlets ontwikkelen, op basis van de meegeleverde API, is een alternatief. Het is wel duurder, omdat er maatwerk moet worden ontwikkeld.
Een tweede uitdaging is de personalisatie, een belangrijk doel van een portal: het aanbieden van de juiste informatie aan de juiste persoon op het juiste moment. De meeste content-managementsystemen hebben hun eigen manier voor het vastleggen van gebruikersgegevens en autorisatieschema’s, die niet zonder meer aansluit op die van de portal. Het gepersonaliseerd aanbieden van informatie is een stuk lastiger te realiseren als gebruikersprofielen niet centraal worden vastgelegd en beheerd, wat afbreuk doet aan één van de belangrijkste voordelen van de portal.
Hyperlinks en organisatiestructuur
Een derde probleem c.q. uitdaging vormen de hyperlinks die bestaan tussen content in het CMS. Deze links worden namelijk niet herkend door de portal. Dit betekent dat de portal geen gebruik kan maken van de verbanden die zijn gelegd tussen de content in het CMS. Er moet dus een apart mechanisme worden bedacht om de links uit het CMS over te zetten naar links die in de portal werken. In portals wordt informatie vaak aan elkaar gerelateerd door meerdere portlets op elkaar te laten reageren: een link in de ene portlet wordt dan getoond in een andere portlet. Die links kunnen overigens ook verwijzen naar informatie die niet uit een CMS komt, maar bijvoorbeeld uit een backend-systeem.
Ten vierde is het ontwikkelen van een goede organisatiestructuur een horde die genomen moet worden. Zoals eerder aangegeven, heeft een CMS vaak niet alleen een content-managementfunctie, maar ook een publicatiefunctie. Hierbij wordt niet alleen de content gepubliceerd op aparte intranet- of internetpagina’s, maar wordt ook de samenhang tussen deze pagina’s gepubliceerd: de menu- of navigatiestructuur. Hiermee wordt in het CMS bepaald op welke manier de gebruikers door de content heen lopen of navigeren. De navigatiestructuur kan echter ook worden bepaald in de portal. Wat is de beste keuze?
Het vastleggen van de navigatiestructuur in het CMS, in plaats van in de portal, heeft een aantal nadelen. Allereerst ontstaat een ‘gebroken’ navigatiestructuur. Een deel van de structuur moet worden onderhouden in de portal en een ander deel in het CMS. Vanuit beheeroogpunt niet wenselijk. Bij de inzet van een portal-toepassing is het CMS bovendien nooit in staat de volledige navigatiestructuur te bepalen, omdat er via de portal, naast webcontent, ook andere informatie en functionaliteit aan gebruikers wordt aangeboden (denk bijvoorbeeld aan toegang tot e-mail en informatie uit backend-systemen). Tot slot is het lastig om content uit het CMS te integreren en op één pagina te combineren met informatie uit andere bronnen, terwijl de toegevoegde waarde van de portal juist is dat gebruikers worden voorzien van informatie in de context van het bedrijfsproces waaraan zij op dat moment bijdragen.
De navigatiestructuur kan dus het best worden vastgelegd in het systeem dat het meest ‘enduser facing’ is. En dat is de portal. Door de navigatiestructuur in de portal vast te leggen, kunnen de hiervoor genoemde problemen worden voorkomen.
De toekomst van CMS
CMS-leveranciers concurreren nu op features. Een verloren strijd wanneer een CMS wordt gecombineerd met een portal, door de overlap in functionaliteit tussen deze twee oplossingen. Naarmate de populariteit van portals groeit, worden leveranciers dus in toenemende mate gedwongen hun strategie te veranderen. Zij moeten ervoor zorgen dat hun content-managementsystemen echt integreren in portals, in plaats van ermee concurreren. Dit heeft grote gevolgen voor de functionaliteit en positionering van hun producten. Dat leveranciers hier nu nog niet aan willen, is begrijpelijk. Zij hebben immers grote investeringen gedaan en willen hun producten beschermen.
Momenteel zijn er wel ontwikkelingen die dit pad zullen vereenvoudigen. Zo is er in de J2EE-wereld een nieuwe standaard in de maak: JSR170. Door deze standaard na te leven, kunnen portal-leveranciers ervoor zorgen dat de portal de publicatiefunctie van content management vervult en de presentatie van content in de portal verzorgt, terwijl zij de onderliggende content-managementprocessen, zoals het maken en opslaan van content, zoeken, workflow en versiebeheer, kunnen overlaten aan elk willekeurig CMS dat de JSR170-standaard ondersteunt. Het is duidelijk dat deze ontwikkeling een geheel nieuwe positionering betekent voor CMS-leveranciers. Er zal een verschuiving plaatsvinden van complete, best-of-breed content-managementproducten, naar meer servicegeoriënteerde oplossingen.
Wel of geen extern CMS?
Totdat CMS leveranciers hun strategie aanpassen, heeft het gebruik van portals in combinatie met een extern CMS haar beperkingen. Organisaties die voor de combinatie kiezen, kunnen de publicatiefunctie van content management het best overlaten aan de portal en het CMS alleen nog maar gebruiken als een pure content management tool. De vraag blijft echter of het überhaupt wel verstandig is om een extern CMS te gebruiken. Het gebruik van bestaande content-managementfunctionaliteiten van de portal, aangevuld met maatwerkoplossingen, lijkt misschien kostbaar. Hierdoor worden echter wel veel van de genoemde problemen voorkomen, en dus kosten bespaard.< BR>
Dit artikel is gebaseerd op ervaringen met IBM WebSphere Portal, maar gaat grotendeels op voor elke portalserver die op de Java 2 Enterprise Edition (J2EE)-standaard is gebaseerd.
Sjoerd Kessels, werkzaam bij ict-dienstverlener e-office, portal consultant en gespecialiseerd in het ontwerpen van (J2EE-)portaloplossingen
