Veel vragen bij portalimplementatie
Tegelijkertijd is het aantal leveranciers van portalproducten teruggegaan naar vier grote spelers en een aantal open-sourceproducten. De leveranciers lijken ook consensus te hebben bereikt over de definitie van een portal. De producten zelf worden steeds uitgebreider, bevatten steeds meer out-of-the-box-functionaliteit en vormen veelal een onderdeel van de SOA-productstack van de desbetreffende leveranciers.Vanwege de vele features lijkt het bijna een wondermiddel voor het inrichten van alle webtoepassingen in een SOA-omgeving.Het is hiermee bijna een vanzelfsprekendheid geworden om een portal binnen een organisatie in te richten. Echter, vanwege de uitgebreide functionaliteit die geboden wordt, kunnen portals vanuit heel verschillende perspectieven benaderd worden. Dit leidt tot begripsverwarring en maakt het voor organisaties erg lastig om te bepalen of en hoe zij een portal in hun organisatie moeten positioneren.Ook vanuit de techniek gezien kan het lastig zijn om een portal te positioneren. Portalproducten bevatten vaak functionaliteit die ook in andere producten van de SOA-stack vertegenwoordigd zijn. Vanuit leveranciers gezien is dit een logische manier om hun producten breed toepasbaar te maken. In een SOA wordt echter flexibiliteit en herbruikbaarheid nagestreefd door het scheiden van verantwoordelijkheden. Dit betekent dat er heel bewust gekozen moet worden welke features van het portalproduct ingezet worden.We stellen dat voor een succesvolle portalimplementatie de volgende twee vragen beantwoord moeten worden:1. Vanuit welk(e) perspectief/perspectieven (zie kader) heeft de organisatie behoefte aan een portal?2. Hoe positioneert de organisatie een portal in haar technische architectuur zodat de flexibiliteit en herbruikbaarheid van een SOA gewaarborgd blijven?Kern van deze vragen is dat bij de implementatie van een portal bewuste keuzen gemaakt moeten worden. Op dit moment worden portals echter te pas en te onpas binnen organisaties geïmplementeerd. Sommige ontstaan vanuit pilots, bijvoorbeeld vanuit de behoefte kennis te delen, en groeien organisch verder. Andere portals ontsluiten verschillende backendsystemen waarvoor grote projecten of zelfs programma’s worden opgetuigd. Wanneer niet eerst de bovenstaande twee vragen worden beantwoord, bestaat het gevaar dat de organisatie tijdens de implementatie of het vervolg tegen problemen aanloopt. Het is daarom ook belangrijk om altijd een aantal stappen (zie kader) te doorlopen waarin deze keuzen gemaakt en getoetst worden.Het gekozen perspectief en de positionering in de technische architectuur zijn van grote invloed op de inrichting van de portal, bijvoorbeeld voor de plek waar informatie opgeslagen wordt. In een portal waarin ‘informatie-integratie’ centraal staat, is de informatie voornamelijk opgeslagen in externe bronnen. In een portal gericht op ‘samenwerking en kennisdeling’ is de plek waar informatie opgeslagen wordt echter minder van belang. Er zou voor gekozen kunnen worden de informatie in de portal zelf op te slaan. De uiteindelijke keuze hangt af van een aantal factoren zoals toegankelijkheid, beheer en eigenaarschap van de informatie.Een ander voorbeeld waarbij de positionering in de technische architectuur van grote invloed is op de inrichting van de portal, is wanneer de portal ingezet wordt voor ondersteuning van ‘processen en workflow’. Veel portalproducten bieden tegenwoordig procesondersteuning in het product zelf. Hierdoor concurreert het portalproduct met andere producten in de organisatie, zoals met businessprocess- en workflowmanagementproducten. Er moet duidelijk gekozen worden waar welke proceslogica ondergebracht wordt, en of de portal hier een rol in speelt. Een dergelijke overlap geldt ook voor systemen voor content- en documentmanagement. Ook hier biedt de portal out-of-the-box-functionaliteit. Vaak is de contentmanagementfunctionaliteit van een portal niet zo uitgebreid als die van een gespecialiseerd contentmanagementpakket. Zo is het niet altijd mogelijk om vanuit de portal content te beheren die in hele andere omgevingen gepubliceerd moet worden.Naast het beantwoorden van de twee hoofdvragen is het evenzo belangrijk om aandacht te besteden aan aspecten buiten de IT. Er zijn vaak veel partijen betrokken bij de implementatie van een portal. Het is daarom belangrijk dat er een manier gevonden wordt om effectief besluiten te nemen, bijvoorbeeld door voor verschillende delen van de portal verschillende eigenaren te benoemen. Zo kan voorkomen worden dat alles centraal besloten moet worden.Een portal gaat meestal samen met een nieuwe manier van werken in de organisatie. Het is daarom van belang de doelgroep te overtuigen van de toegevoegde waarde van de portal. Het is belangrijk dat er een duidelijke aanleiding is om een portal te gaan gebruiken en dat men aandacht besteedt aan punten die belangrijk zijn voor de eindgebruikers. Een goede manier om eindgebruikers zich meer verantwoordelijk te laten voelen voor het uiteindelijke product, is om ze in een vroeg stadium (bijvoorbeeld in de fase van proof-of-concept) bij het project te betrekken.Sommige perspectieven lijken heel laagdrempelig, waardoor er over dit soort factoren niet goed van tevoren nagedacht wordt. In de praktijk kan de portal dan weliswaar in een korte periode worden opgeleverd, maar blijkt het lastig om dit initiële succes een vervolg te geven. Vanwege de grote hoeveelheid aan functionaliteit die portalproducten tegenwoordig bieden, is het essentieel in het voortraject goed na te denken over de doelstelling en de positionering in de technische architectuur. En het is daarbij maar de vraag of een portalproduct wel de oplossing is.Hidde Andriessen (hiddea@infosupport.com) en Alexander Molenkamp (sanderm@infosupport.com) zijn IT-consultants bij Info Support.