Portals en SOA

Competence Center Infrastructural

Software Services

Meer informatie

Voor vragen over deze whitepaper of meer informatie

kunt u contact opnemen met Info Support door te

bellen naar +31 (0) 318 55 20 20 en te vragen naar

Sales Support & Marketing (Nederland) of te bellen

naar +32 (0) 15 28 63 70 (België). U kunt ook een e-mail sturen naar sales@infosupport.com.

Inhoudsopgave

1 INLEIDING ................................................................................................ 3

2 DOELSTELLING VAN EEN PORTAL .............................................................. 4

2.1 Geschiedenis van het portal concept ........................................................ 4 2.2 Portals vanuit verschillende perspectieven ................................................ 5

2.2.1 Eenduidige gebruikersomgeving ........................................................ 5 2.2.2 Informatie-integratie ....................................................................... 5 2.2.3 Aanpasbaarheid aan gebruikerswensen .............................................. 5 2.2.4 Samenwerking en kennisdeling ......................................................... 6 2.2.5 Dashboards .................................................................................... 6 2.2.6 Processen en workflow ..................................................................... 7 2.2.7 Ketenintegratie ............................................................................... 7 2.2.8 Ontwikkelomgeving voor webapplicaties ............................................. 7

3 POSITIONERING BINNEN SOA .................................................................. 8

3.1 Definitie ............................................................................................... 8 3.2 Visies vanuit de markt ........................................................................... 8

3.2.1 IBM ............................................................................................... 9 3.2.2 Oracle (en BEA) .............................................................................. 9 3.2.3 Microsoft ...................................................................................... 10 3.2.4 SAP ............................................................................................. 10 3.2.5 Liferay ......................................................................................... 10 3.2.6 SaaS portals ................................................................................. 10

3.3 Nederlandse Overheid Referentie Architectuur ........................................ 11 3.3.1 Gemeentelijke midoffice ................................................................. 13

3.4 Endeavour Referentiearchitectuur .......................................................... 14

4 STAPPENPLAN PORTAL IMPLEMENTATIE ................................................ 16

4.1 De weg naar succesvolle portal implementatie ........................................ 16 4.1.1 Stap 1 – Doelstelling ...................................................................... 16 4.1.2 Stap 2 – Business case & roadmap .................................................. 16 4.1.3 Stap 3 – Productselectie ................................................................. 17 4.1.4 Stap 4 – Proof-of-concept ............................................................... 17 4.1.5 Stap 5 – Realisatie ........................................................................ 17 4.1.6 Stap 6 – Implementatie ................................................................. 18

4.2 Aandachtspunten ................................................................................ 18 4.2.1 Portal adoptie ............................................................................... 18 4.2.2 Laagdrempeligheid tot onbeheersbaarheid ........................................ 18 4.2.3 Beveiliging en compliancy............................................................... 18 4.2.4 Koppeling met bestaande systemen ................................................. 19 4.2.5 Formele en informele samenwerking ................................................ 19

5 CONCLUSIES ........................................................................................... 20

BIJLAGE A: PORTAL DEFINITIES................................................................... 21

REFERENTIES ............................................................................................... 23

OVER INFO SUPPORT .................................................................................... 24

© Info Support, Veenendaal 2014 Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm of op welke andere wijze ook, zonder voorafgaande toestemming van Info Support. No part of this publication may be reproduced in any form by print, photo print, microfilm or any other means without written permission by Info Support.

Prijsopgaven en leveringen geschieden volgens de Algemene Voorwaarden van Info Support B.V., gedeponeerd bij de K.v.K. te Utrecht onder nr. 30135370. Een exemplaar zenden wij u op uw verzoek per omgaande kosteloos toe.

Whitepaper Portals en SOA Pagina 3 van 24

1 Inleiding De laatste jaren zijn er in verschillende verschijningsvormen portals ontwikkeld. De

grote hype omtrent portals lijkt er een beetje af te zijn. Dit wordt onder andere

bevestigd door Gartner. Gartner positioneert portals in zijn hype cycle als “climbing

the slope” [HYPE]. Dat wil zeggen dat de hype voorbij is, dat het de periode van

desillusie overleefd heeft en dat nu de tijd is gekomen dat er een duidelijk begrip

ontstaat van toepasbaarheid van de technologie en de bijbehorende mogelijkheden en

risico’s.

Deze paper beschrijft de toepasbaarheid van portaltechnologie door twee belangrijke

succesfactoren voor de implementatie van een portal in een administratieve

organisatie te bespreken en deze in een stappenplan te plaatsen.

Allereerst moet het voor de organisatie duidelijk zijn met welke doelstelling de portal

wordt ingezet. Portals kunnen voor heel verschillende doeleinden gebruikt worden.

Veel portals ontstaan vanuit pilots, bijvoorbeeld vanuit de behoefte kennis te delen, en

groeien hierna organisch verder. Andere portals ontsluiten verschillende backend

systemen waarvoor grote projecten of zelfs programma’s worden opgetuigd. In

hoofdstuk 2 worden een aantal perspectieven besproken waar vanuit organisaties

kunnen besluiten een portal in te zetten.

Een tweede succesfactor voor de implementatie van een portal is de positionering

binnen de technische architectuur. Veel organisaties zijn bezig met het inrichten van

een service georiënteerde architectuur (SOA). Binnen dit type architectuur wordt

onder andere flexibiliteit nagestreefd door verantwoordelijkheden te scheiden in

verschillende services. Omdat portalproducten steeds meer functionaliteit bevatten is

het de vraag welke verantwoordelijkheden een portal binnen een SOA dient te

vervullen. In hoofdstuk 3 wordt verder ingegaan op de positionering van een portal in

de SOA omgeving. Hierbij wordt onder andere ook gekeken naar een technische

definitie, hoe belangrijke marktpartijen een portal positioneren en hoe Info Support de

portal positioneert binnen de Endeavour softwareontwikkelstraat.

In hoofdstuk 4 wordt een stappenplan beschreven hoe organisaties het beste met

portals aan de slag kunnen gaan. Hierbij worden nog een aantal extra

aandachtspunten geformuleerd die van invloed zijn op het welslagen van een

implementatie.

Ten slotte volgt in hoofdstuk 5 de conclusie.

Whitepaper Portals en SOA Pagina 4 van 24

2 Doelstelling van een portal Welke behoefte hebben organisaties om met portals aan de slag te gaan? Hiervoor

wordt eerst gekeken naar de ontstaansgeschiedenis van portals.

2.1 Geschiedenis van het portal concept Navaneeth Krishnan1 schreef een samenvatting van de ontwikkeling van het portal

concept met de volgende strekking:

De ontwikkeling van het concept portal startte vanaf het begin van het world wide

web. In het begin van het web ging het om het beschikbaar stellen en dus delen

van content. De content was statisch van nature en bevatte onderlinge

verwijzingen middels hyperlinks. In deze periode ontstonden veel portals die als

startpunt voor het Internet fungeerde door de verschillende Internet sites met

hyperlinks in categorieën te verdelen. Een portal was dus niet meer dan een

simpele wegwijzer naar content op het web. Een duidelijk voorbeeld van een

dergelijke portal is www.startpagina.nl.

Portal = content

Naar mate het aantal Internet sites explosief begon te groeien werd het steeds

moeilijker om deze sites handmatig te indexeren. Met de komst van

scripttechnologieën als CGI werd het web ook dynamischer en daarmee lastiger

de sites in te delen via statische links. In deze fase ontstonden zoekmachines die

de content van het internet doorzoekbaar maakte. Belangrijke (zoek)portals uit

die tijd waren www.yahoo.com en www.ilse.nl.

Portal = content + search

Door de dynamische mogelijkheden van het web werd het ook steeds

interessanter voor bedrijven om te zoeken naar business mogelijkheden op het

web. Bedrijven konden op het web op een goedkope en effectieve manier

communiceren met klanten, partners en stakeholders. Deze gebruikersgroepen

hebben zeer uiteenlopende informatiebehoeften waardoor het noodzakelijk werd

de gebruikersgroep alleen voor hen relevante informatie te presenteren

(personalization). Denk bijvoorbeeld aan de manier waarop funda.nl onderscheid

maakt in content voor particulieren en bedrijven.

Portal = content + search + personalization

Tegelijkertijd maakten bedrijven gebruik van deze zelfde technologie om ook

binnen de organisatie een intranet in te richten voor hun medewerkers. Zowel

voor interne nieuwsberichten, als bijvoorbeeld het beschikbaar stellen van

documenten of enquêtes voor het personeel.

Portal = content + search + personalization + organization

In de fase daarop werd steeds duidelijker dat het internet/intranet een krachtig

medium is voor samenwerking (collaboration). Er ontstonden verschillende instant

messaging netwerken en allerlei web-based communities. De portal ontwikkelde

1 http://weblogs.java.net/blog/navaneeth/

Whitepaper Portals en SOA Pagina 5 van 24

zich tot het ideale startpunt voor al dit soort samenwerkingsmogelijkheden.

www.viadesk.nl is hier al jaren een voorbeeld van.

Portal = content + search + personalization + organization + collaboration

Vandaag de dag zijn op het internet steeds meer diensten (services) te vinden.

Organisaties bieden hun diensten direct via het web aan, welke ook direct via het

web geconsumeerd kunnen worden. Vandaar dat portals nu meer nadrukkelijk

mogelijkheden hebben om te communiceren met deze services op verschillende

manieren en met verschillende technieken. Hierbij kan bijvoorbeeld gedacht

worden aan de persoonlijke startpagina van iGoogle, waarmee allerlei content van

Google, maar ook van andere leveranciers zelf samengesteld en op één

startpagina getoond kan worden.

Portal = content + search + personalization + organization + collaboration

+ (web) services

2.2 Portals vanuit verschillende perspectieven Zoals uit de ontstaansgeschiedenis van het portal concept duidelijk wordt, is de

functionaliteit van de portal in de loop der jaren uitgebreid. Daarbij komt ook nog dat

leveranciers van portalproducten veel extra functionaliteit aan de portals hebben

toegevoegd door bijvoorbeeld bestaande producten samen te voegen met het

portalproduct. Hierdoor kan een portal 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.

In de volgende paragrafen worden een aantal verschillende perspectieven besproken

waarvoor een portal ingezet kan worden.

2.2.1 Eenduidige gebruikersomgeving

Doordat organisaties voor verschillende bedrijfsfunctionaliteit verschillende applicaties

gebruiken, zijn werknemers vaak genoodzaakt om hun werk via verschillende

applicaties uit te voeren. Dit leidt er toe dat werknemers continue moeten wisselen

tussen deze applicaties en waarbij vaak gegevens van de ene applicatie naar de

applicatie overgenomen moeten worden. Daarnaast moeten de gebruikers voor deze

verschillende applicaties opgeleid worden.

Met een portal kunnen de gebruikersinterfaces van deze applicatie gecombineerd

worden in een eenduidige webomgeving. Belangrijk voordeel hiervan is dat gebruikers

het geheel als één systeem ervaren door bijvoorbeeld niet bij elk systeem opnieuw

hoeven in te loggen (single sign on).

2.2.2 Informatie-integratie

Informatie is vaak verspreid over verschillende applicaties of verschillende datastores

binnen de organisatie en niet alle informatie is gestructureerd vastgelegd. Daarom

worden portals ingezet om deze informatie centraal beschikbaar te stellen. Een

techniek die hiervoor gebruikt worden is onder andere enterprise search, waarbij

verschillende bronnen door de zoekmachine geïndexeerd worden.

2.2.3 Aanpasbaarheid aan gebruikerswensen

Portal technieken worden steeds meer gebruikt om de content van een website aan te

passen aan de doelgroep. Hierbij kan onderscheid gemaakt worden tussen

personalization en customization. Met personalization wordt de informatie op de portal

aangepast op basis van het profiel van de gebruiker, bijvoorbeeld gebaseerd op

expertise, afdeling, project of land. Met customization kan de gebruiker de portal zelf

Whitepaper Portals en SOA Pagina 6 van 24

aanpassen naar zijn eigen wensen, zowel de stijl als de informatie die er getoond moet

worden. Hierdoor kan de gebruiker een selectie doen van de beschikbare informatie en

beter aan zijn informatiebehoefte voldoen. Daarnaast kan ook sprake zijn van

meerdere talen en/of meerdere merken waar de portal rekening mee moet houden.

Content Management

Voor de verschillende gebruikersgroepen moet de content makkelijk beheerd kunnen

worden. Daarom worden portals vaak gecombineerd met Content Management

Systemen (CMS).

Self service

Een ander belangrijk gerelateerd onderwerp is de mogelijkheid om de gebruikers van

de portal inzicht te geven in hun eigen gegevens die bij de organisatie bekend zijn en

deze te laten onderhouden met behulp van elektronische formulieren. Hierdoor

ontstaat een self service portal die tot hogere kwaliteit van de data kan leiden (zeker

als gebruikers er zelf belang bij hebben dat hun gegevens correct zijn) en het beheer

van de data sterk kan versimpelen voor de organisatie zelf.

2.2.4 Samenwerking en kennisdeling

Een portal wordt vaak ingezet om kennis en informatie te delen binnen bepaalde

groepen. Denk hierbij aan een teamsite voor leden van een project, waarbij elk lid

documenten op de portal kan plaatsen en aanpassen, berichten kan posten en de

planning kan bekijken. Deze portals bevatten vaak mogelijkheden om blogs en forums

te starten. Door de combinatie met instant messaging technologie kan vanuit de portal

ook direct met elkaar gecommuniceerd worden en kan de portal aangeven wie

aanwezig is (presence).

Document Management

De portal kan ook gebruikt worden om dienst te doen als document management

systeem. Immers, de portal biedt in veel gevallen mogelijkheden om documenten op

te slaan, te rubriceren en de onderhouden (inclusief versiebeheer).

Kennismanagement

Hetzelfde kan gezegd worden van kennismanagement. De portal kan ook dienst doen

om kennis te borgen (door vastlegging ervan in de portal) of om vast te leggen waar

kennis zich in de organisatie bevindt.

2.2.5 Dashboards

Vanuit managementperspectief kan de portal fungeren als dashboard voor

managementinformatie. Deze informatie kan dan uit een

managementinformatiesysteem (MIS) komen, maar door de portaalintegratie kan

informatie ook direct uit de primaire systemen komen. Dit geeft de manager de

mogelijkheid om (binnen één gebruikersomgeving) direct detailgegevens te bekijken

door via de portal het desbetreffende systeem te raadplegen.

Vanuit dit perspectief kan een portal dus fungeren als monitor en sturinginstrument

voor het management (steeds vaker spelen leveranciers ook concreet in op

management modellen zoals Balanced Scorecard).

Een portal kan natuurlijk ook als dashboard voor projecten fungeren (zie kader).

Whitepaper Portals en SOA Pagina 7 van 24

Project Portal: Dashboard van de Endeavour Softwareontwikkelstraat

Een softwareontwikkelstraat verbetert de kwaliteit en de snelheid van het

softwareontwikkelproces. Dat gebeurt in de eerste plaats door het proces inzichtelijk en

controleerbaar te maken. Het Project Portal speelt daarbij een cruciale rol. Dit is een

webportaal dat als informatieplatform fungeert voor projectleden, managers en eventuele

andere partijen. Een belangrijke bron van informatie is de dagelijkse rapportage. Deze zorgt

ervoor dat het team voordurend op de hoogte blijft van de kwaliteit en de snelheid van de

door hen ontwikkelde software. Zo ontstaat een geleidelijk en overzichtelijk projectverloop.

Zonder de stressvolle en arbeidsintensieve eindfase die de meeste ontwikkelprojecten nu

vaak kenmerkt.

De project portal bestaat onder andere uit: Informatie en communicatie, Testresultaten,

Trensanalyse en Documentatie. Daarnaast zorgt de Digital Coach voor alle informatie,

procedures, richtlijnen en componenten waardoor de ontwikkelstraat zorgt voor een

herhaalbaar proces.

Voor meer informatie zie http://www.infosupport.nl/Softwareontwikkelstraat.

2.2.6 Processen en workflow

Doordat in een portal verschillende applicaties geïntegreerd kunnen worden, is het ook

interessant om de processtappen over de verschillende systemen heen te managen.

Voor alle stappen binnen het proces waar handmatige handelingen nodig zijn, toont de

portal een scherm aan de gebruikers. Vanuit dit perspectief bevatten veel portals ook

functionaliteit voor human workflow (inclusief verderdeling, taakbakjes, etc).

2.2.7 Ketenintegratie

Samenwerkende organisaties maken gebruik van portals als extranet voor het

ontsluiten van informatie of functionaliteit voor hun partners. Maar sommige

organisaties starten ook gezamenlijk een portal waarbij functionaliteit van beide

organisaties gecombineerd wordt in één portal, zodat het voor de doelgroep lijkt alsof

ze met één organisatie te maken hebben. Dit kan bepaalde diensten voor de

doelgroep vereenvoudigen. Ook hier wordt gebruik gemaakt van portaalintegratie net

zoals in het perspectief van de eenduidige gebruikerservaring en ook hier is single sign

on een belangrijk aspect. Een verschil met gebruikerservaring is dat de

verantwoordelijkheid van de content en functionaliteit veel nadrukkelijker bij de

originele organisatie blijft liggen. Verder kan het ook zo zijn dat de organisatie op zijn

eigen website dezelfde functionaliteit en informatie wil kunnen tonen. Hergebruik komt

hier dan ook nadrukkelijker naar voren.

2.2.8 Ontwikkelomgeving voor webapplicaties

Een heel ander perspectief is dat vanuit ontwikkeling van applicaties. Doordat

portalproducten de laatste jaren veel aan functionaliteit hebben gewonnen kan de

portal ook als platform worden gezien waarin al heel veel standaard functies

beschikbaar zijn die in webapplicaties vaak handmatig gerealiseerd worden.

Leveranciers gebruiken hun portals dan ook vaak als ontwikkel/beheer front-end voor

hun serverproducten.

Whitepaper Portals en SOA Pagina 8 van 24

3 Positionering binnen SOA Waar het vorige hoofdstuk de doelstelling van een portal besproken heeft, bespreekt

dit hoofdstuk de positionering van portals binnen een service georiënteerde

architectuur (SOA).

In een SOA omgeving wordt flexibiliteit nagestreefd door functionaliteit onder te

brengen in herbruikbare services met een duidelijke scheiding van

verantwoordelijkheden. Hierdoor is de term applicatie niet meer goed toepasbaar. In

plaats hiervan wordt gesproken over een samengestelde applicatie (composite

application), oftewel de verzameling van services die gezamenlijk de functionaliteit

biedt. Moderne portalproducten kunnen ingezet worden om veel verschillende services

in een SOA te implementeren. Hoe moet een portal gepositioneerd worden om de

flexibiliteit van de SOA te kunnen blijven benutten?

Dit hoofdstuk gaat dieper in op deze vraag. Daarbij wordt gekeken naar de definitie

van een portal en naar de visies van marktpartijen, Nederlandse overheid en Info

Support.

3.1 Definitie Voor het begrip portal zijn een groot aantal definities te vinden (zie bijlage A). Waar

voorheen de definities nog sterk van elkaar konden afwijken, zijn deze meer naar

elkaar toe gegroeid omdat ze generieker zijn geworden door de toenemende

functionaliteit die aan een portal wordt toegeschreven.

Tot nu toe is in dit white paper gebruik gemaakt van de generieke term portal. In de

literatuur en in de markt worden ook wel specifiekere benamingen gebruikt om het

toepassingsgebied van de portal af te bakenen. Bij administratieve organisaties wordt

voornamelijk de term enterprise portal gebruikt (ook wel corporate of bedrijfsportal

genoemd). In [TRENDS] wordt de enterprise portal beschreven als:

Enterprise portals richten zich op het verlenen van toegang tot alle informatie en

processen die nodig zijn voor het verrichten van de werkzaamheden ongeacht

werkplaats of tijdstip.

Een ander veel gebruikte term is enterprise information portal (EIP). Dit legt echter

meer nadruk op informatie en beperkt daarmee de mogelijke portal perspectieven.

Binnen een SOA omgeving definiëren we een enterprise portal, in navolging van de

Gartner definitie, als:

Een web software infrastructuur die toegang biedt tot en interactie mogelijk

maakt met relevante informatie (waaronder informatie/content, applicaties en

bedrijfsprocessen), kennis en andere gebruikers voor verschillende doelgroepen

en op een gepersonaliseerde manier.

3.2 Visies vanuit de markt De markt voor portalproducten concentreert zich rondom een kleine groep van grote

software leveranciers zoals Microsoft, Oracle/BEA, IBM en SAP. Over het algemeen

bieden deze leveranciers een gehele technologiestack van producten waar een portal

een onderdeel van is (ter illustratie zie Figuur 1). Het portalproduct speelt zodoende

een belangrijke strategische rol in de technologiestack van een leverancier. Zo

gebruikt SAP bijvoorbeeld haar NetWeaver portalproduct als interface voor de overige

Whitepaper Portals en SOA Pagina 9 van 24

SAP applicaties.

Naast deze groep van software aanbieders is er een groot aantal open source

portalproducten, waarvan LifeRay veruit de grootste en bekendste is.

3.2.1 IBM

IBM biedt een portalproduct aan binnen de WebSphere productlijn. De WebSphere

Portal wordt in verschillende varianten aangeboden. Elke variant heeft als basis

WebSphere Portal met daaraan toegevoegd extra functionaliteiten zoals document- en

workflowmanagement, collaboration producten of services voor mobiele

communicatie. Veel van de server producten van IBM hebben componenten die in de

WebSphere Portal gehangen kunnen worden, zoals de combinaties met de WebSphere

Process Server voor Human Workflow, WebSphere Business Monitor voor de business

dashboard.

Figuur 1 - Mapping van IBM producten of de IBM SOA referentie architectuur.

3.2.2 Oracle (en BEA)

Voor het realiseren van SOA omgevingen heeft Oracle de Fusion Architectuur

gedefinieerd. Daarbij definieert Oracle een Enterprise Portal als het gezicht van deze

architectuur. In de visie van Oracle worden alle standaard pakketten (zoals PeopleSoft

en JD Edwards) ook doorontwikkeld om als portal applicaties in een portal

geïntegreerd te worden.

Na de overname van BEA heeft Oracle een uitgebreide portfolio van portalproducten,

waarmee deze Enterprise Portal gerealiseerd kan worden:

Oracle WebCenter Suite (onder andere bestaande uit WebCenter User

Interaction, voorheen BEA AquaLogic User Interaction);

Oracle WebCenter Services;

Oracle WebLogic Portal (voorheen BEA WebLogic);

en Oracle Portal.

Whitepaper Portals en SOA Pagina 10 van 24

De WebCenter Suite en Services positioneert Oracle als zijn strategische oplossingen

voor het realiseren van zogenaamde “Enterprise 2.0 enabled” portals, samengestelde

(composite) en web applicaties. Met de WebCenter Suite is er een uitgebreide collectie

van componenten voor gebruikersinteractie die gebruikt kan worden om een

Enterprise Portal vrijwel out-of-the-box te realiseren. De WebCenter Services biedt

services die elke webgebasseerde interface (en dus ook Portals) kan verrijken met

communicatie, webanalyse, content management en social networking functionaliteit.

Oracle WebLogic Portal en Oracle Portal zullen verder ontwikkeld en ondersteund

worden, maar zullen naar verwachting in de toekomst ook in de WebCenter Suite en

WebCenter Services opgaan.

3.2.3 Microsoft

Microsoft zet zijn portal technologie in de markt onder de noemer SharePoint Products

and Technologies. Hierbij verwijst het "product" onderdeel naar Microsoft Office

SharePoint Server (MOSS) en het "Technologies" deel naar Windows SharePoint

Services (WSS). WSS is beschikbaar als onderdeel van Windows Server 2003 of hoger

en kan gebruikt worden om teamsites te hosten. MOSS daarentegen is een complete

collaboration server die voorziet in samenwerking, zoektechnologie2, formulieren,

contentmanagement, business intelligence en een externe portal.

Ook Microsoft positioneert SharePoint veelvuldig in combinatie met andere server

producten. Zo wordt SharePoint (met Windows Workflow Foundation) in combinatie

met BizTalk Server gepositioneerd als BPM & Human Workflow oplossing.

3.2.4 SAP

SAP NetWeaver Portal draait op het SAP NetWeaver platform. SAP NetWeaver is SAP's

service georiënteerde applicatie en integratie platform. Op dit platform draaien alle

SAP applicaties, maar het kan ook gebruikt worden om eigen bedrijfsapplicaties op te

integreren.

iViews, de portal componenten in SAP, leveren bedrijfsinformatie aan de

portalgebruiker via views op back-end systemen. De portal ondersteunt uiteraard

toegang tot SAP's eigen applicaties, maar iViews kan ook gebruikt worden om data uit

andere externe systemen en databases te aggregeren.

3.2.5 Liferay

Liferay Portal is een populaire open source portal. Qua features richt Liferay zich

voornamelijk op collaboratieve aspecten zoals het bouwen van gemeenschappen en

sociale netwerken. Uniek aan Liferay Portal is dat het overal kan draaien: in een

lightweight servlet container als Jetty of Tomcat, maar ook in volledige JEE-

applicatieservers, zoals WebSphere of WebLogic.

3.2.6 SaaS portals

Een recente trend laat zien dat er ook steeds meer portalproducten (gedeeltelijk) in

SaaS vorm aangeboden worden. Deze producten zijn er met name op gericht om

kleine teams samen te laten werken en benaderen het portal concept dus vooral

vanuit het samenwerkings- en kennisdelingsperspectief.

2 De zoektechnologie is sinds vorige maand een zelfstandig product geworden genaamd 'Microsoft Search Server'. Deze is in de express editie gratis te downloaden en als uitbreiding op WSS te installeren.

Whitepaper Portals en SOA Pagina 11 van 24

In februari 2008 is Google gestart met Google Sites, een dienst waarmee bedrijven

eenvoudig een eigen website voor teamprojecten kunnen opzetten. Google Sites is

een uitgeklede versie van Jotspot, een wiki service die in 2006 door Google

overgenomen is. De dienst maakt het mogelijk een verscheidenheid aan informatie,

zoals presentaties, kalenders, documenten en video's binnen een teamsite onder te

brengen en vervolgens te delen, zodat de informatie kan worden geraadpleegd en

bewerkt door meerdere gebruikers.

Google Sites wordt volledig gehost op de servers van Google.

Microsoft biedt ook een dergelijke op WSS gebaseerde dienst aan onder de noemer

Office Live Workspace (OLW). Microsoft spreekt echter niet van SaaS, maar van

Software + Services. Dit houdt in dat in Microsofts visie client tools altijd belangrijk

zullen blijven. OLW integreert dan ook met de Microsoft Office applicatie. OLW is met

name geschikt voor kleine teams om samen te werken aan projecten en documenten

te delen.

Interessanter voor grotere organisaties is de online variant van SharePoint die

Microsoft geïntroduceerd heeft als onderdeel van Microsoft Online Services (MOS).

Hiermee biedt Microsoft de mogelijkheid om serversoftware (deels) naar haar

datacenter te verplaatsen tegen een abonnementsvergoeding. MOS is beschikbaar in

twee vormen, MOS Standard en MOS Dedicated. Bij MOS Standard worden alle MOS

services op afstand beheerd, maar eindgebruikers zien geen verschil tussen de

bedrijfs- en de Online-versie van de software. MOS Dedicated is gericht op grote

bedrijven die een toegespitste architectuur vereisen.

Een ander voorbeeld van een SaaS portal omgeving is Salesforce.com. Salesforce.com

biedt een online CRM pakket dat door de gebruiker zelf aangepast kan worden. Sinds

2005 is hier het AppExchange platform bijgekomen. AppExchange biedt een online

marktplaats voor applicaties die zowel door Salesforce.com zelf als externe

ontwikkelaars, klanten en partners zijn ontwikkeld. Deze applicaties kunnen door de

gebruiker geïntegreerd worden in zijn omgeving.

3.3 Nederlandse Overheid Referentie Architectuur Door het kenniscentrum van de e-overheid is een referentie architectuur opgesteld

voor overheidsorganisaties, de NORA [NORA]. Hierin wordt beschreven hoe de

enterprise architectuur van overheidsorganisaties ingericht dient te worden zodat de

overheden gezamenlijk invulling kunnen geven aan elektronische dienstverlening aan

de burger en het bedrijfsleven. De referentie architectuur bespreekt zowel hoe

organisaties zich intern dienen te organiseren als hoe de organisaties onderdeling

dienen samen te werken. Eén van de belangrijkste uitgangspunten van de NORA is

een service georiënteerde architectuur.

Whitepaper Portals en SOA Pagina 12 van 24

Figuur 2 - NORA architectuur.

De NORA maakt onderscheid in frontoffice, bedrijfsprocessen en dataopslag. Deze

driedeling wordt gepositioneerd op verschillende niveaus, zowel overheid breed, op

sectoraal niveau als binnen de organisaties zelf. De kaders en principes die de NORA

stelt worden echter niet alleen door overheidsorganisaties, maar ook steeds vaker bij

organisaties uit andere sectoren toegepast.

De NORA doet geen specifieke uitspraken over de inrichting en of positionering van

een portal. Toch past een portal goed binnen het frontoffice concept dat de NORA

beschrijft. Er zijn veel NORA principes goed toe te passen met behulp van een portal.

Voorbeelden hiervan zijn [NORA]:

Multichanneling en “no wrong door” principe en de stimulatie van het internet

kanaal (NORA principes 1, 2 en 3).

One stop shopping, waarbij de overheid zoveel mogelijk als één organisatie

opereert en de klant ook slechts één identiteit heeft (NORA principes 4 en 5).

Dit komt overeen met het perspectief ketenintegratie. Dit geldt ook voor

principe van “eenmaal uitvragen van gegevens, meermalen gebruiken” (NORA

principe 8) en het principe voor “integraal opererende en als eenheid

optredende overheid” (NORA principe 17).

Het ontsluiten van informatie (wetgeving, besluitvorming en status van lopende

processen) voor bevordering van transparantie van de overheid (NORA

principes 12, 14 en 15).

Proactieve dienstverlening, waarbij de overheid burgers en bedrijven

attenderen op voor hen relevante diensten, rechten plichten en mogelijkheden,

bij voorkeur geïndividualiseerd (personalization/customization) (NORA principe

16).

Het waar mogelijk gebruiken van generieke bouwstenen (NORA principe 19).

Binnen de overheid zijn er verschillende initiatieven waarbij het frontoffice concept ook

daadwerkelijk met behulp van een portal wordt gerealiseerd, zoals:

Whitepaper Portals en SOA Pagina 13 van 24

Het Digitaal Klant Dossier (DKD), het loket voor klanten binnen de SUWI-keten

(UWV, CWI en de gemeentelijke sociale diensten). Zie http://www.werk.nl/.

Persoonlijke Internet Pagina (PIP), de persoonlijke Internet pagina van de

overheid voor elke burger. Zie [PIP].

3.3.1 Gemeentelijke midoffice

Vanuit het subsidiariteitsbeginsel hebben lagere overheden (zoals provinciën en

gemeenten) op basis van de NORA hun eigen referentie architecturen opgezet.

Specifiek in de gemeentelijke sector heeft het programma Elektronische Gemeente

(EGEM) een referentiearchitectuur uitgewerkt voor de elektronische gemeente. Net als

bij de NORA wordt onderscheid gemaakt in drie lagen [MDFF]: front-, mid- en

backoffice, zie Figuur 3.

Figuur 3 - Het EGEM Referentiemodel Midoffice

[MDFF] beschrijft dat de frontoffice uit een specifiek aantal componenten bestaat die

gezamenlijk één loket naar de klant dienen te vormen:

Vraaggeleiding (Product Dienst Catalogus, beslisbomen)

Authenticatie (DigiD, betalen)

Webintake (e-formulieren)

Personalisatie (persoonlijke internetpagina/’mijn gemeente’)

Geo-informatie (GIS)

Achter het frontoffice wordt een dunne of dikke midoffice gepositioneerd die zorgt voor

de afhandeling van het proces en de aansluiting met de backoffice. Het dunne

midoffice bestaat uit:

Gegevensmagazijn

Zakenmagazijn

Broker (BPM)

In het dikke midoffice aangevuld met:

Documentmanagement (DMS) en workflowmanagement (WFM), waarbij het

DMS ook verantwoordelijk is voor DIV-taken als archivering

Relatiebeheer (CRM)

Whitepaper Portals en SOA Pagina 14 van 24

De frontoffice kan goed ingericht worden met behulp van een portalproduct. Ondanks

dat een aantal midoffice componenten (zoals document- en workflowmanagement)

ook goed gerealiseerd kunnen worden met behulp van een portalproduct heeft EGEM

er voor gekozen om deze functionaliteit logisch te scheiden van de frontoffice.

3.4 Endeavour Referentiearchitectuur Info Support maakt binnen de Endeavour software

ontwikkelstraat in de logische referentiearchitectuur

onderscheid in 4 servicetypen:

Business Service

Bevat functionaliteit die minimaal nodig is

voor het bedrijf om de core business uit te

kunnen voeren. Zonder dit kan het bedrijf niet

functioneren. Typische business service is de

registratie van bepaalde gegevens.

Process Service

Aaneenschakeling en besturing van core

functionaliteit of deelprocessen om zo de

bedrijfsprocessen goed te ondersteunen.

Interaction Service

Het beschikbaar stellen van functionaliteit aan

eindgebruikers (front-end services) of

andere partijen (integration services).

Platform Service

Facilitaire diensten die vanuit de andere service gebruikt kunnen worden.

Bijvoorbeeld communicatie diensten tussen de services.

Binnen de referentiearchitectuur wordt een portal gedefinieerd als een software

platform waarop front-end services gehost kunnen worden. Hierdoor is het mogelijk

om een geïntegreerde gebruikerservaring te bieden. De portal kan daarnaast in de

vorm van platform services een aantal standaard functionaliteiten bieden waarvan de

front-end services gebruik kunnen maken, zoals services voor collaboration, presence,

integration, document management en content management. Een specifiek type

process service, de workflow proces service, biedt de mogelijkheid om human

workflow in de portal te ondersteunen. Let wel, het gaat hier om de ondersteuning van

handmatige handelingen en niet de automatisering van een bedrijfsproces. Dit laatste

is de verantwoordelijkheid van de (business) process service.

Figuur 4 - Endeavour servicetypen

Whitepaper Portals en SOA Pagina 15 van 24

Figuur 5 - Endeavour Referentiearchitectuur voor portals

Info Support heeft de logische referentiearchitectuur voor portals verder uitgewerkt in een

Architectuurconcept – Portal. Dit is onderdeel van de Endeavour ontwikkelstraat. Voor meer

informatie neem contact op met Sales Support & Marketing, telefoon 0318 - 55 20 20 of

stuur een mail naar sales.nl@infosupport.com.

Whitepaper Portals en SOA Pagina 16 van 24

4 Stappenplan portal implementatie In de vorige hoofdstukken is besproken vanuit welke perspectieven portals benaderd

kunnen worden en hoe de portal gepositioneerd kan worden in een SOA omgeving.

Maar wat zijn nu de stappen die genomen moeten worden om tot een succesvolle

portal implementatie te komen? En wat zijn belangrijke aandachtspunten hierbij?

4.1 De weg naar succesvolle portal implementatie In deze paragraaf worden zes belangrijke stappen besproken die genomen moeten

worden om tot een succesvolle portal implementatie te komen. Er worden per stap

geen richtlijnen gegeven ten aanzien van de te besteden tijd gezien de diversiteit aan

organisaties en doelstellingen. Het is echter zeer belangrijk dat geen enkele stap

wordt overgeslagen en dat stappen bewust genomen worden.

4.1.1 Stap 1 – Doelstelling

De eerste stap is het bepalen van het doel dat de organisatie wil bereiken. Bovenal

moet aan de doelstelling gevalideerd worden of een portal inderdaad de beste

oplossing is om het gewenste doel te behalen.

De doelstelling is gerelateerd aan één of meerdere perspectieven, zoals besproken in

hoofdstuk 2. De perspectieven sluiten elkaar niet uit. Sommige van deze

perspectieven zijn echter makkelijker in één portal te realiseren dan anderen, vooral

wanneer op een later moment een portal uitgebreid moet worden. Zo kan het moeilijk

zijn om een portal initieel gericht op samenwerking door te ontwikkelen naar een

portal waarin portaalintegratie belangrijk is, omdat de perspectieven redelijk veel van

elkaar verschillen.

Het is mogelijk dat er voor verschillende doeleinden verschillende portals worden

ingericht in de organisatie. Hierbij is het belangrijk dat dit bewust gebeurt en er geen

wildgroei aan portals ontstaat, aangezien dan geen voordeel meer behaald kan

worden uit het centraliseren van gegevens.

4.1.2 Stap 2 – Business case & roadmap

In stap 2 moet een business case gemaakt worden waarin aangetoond wordt hoe een

portal oplossing bijdraagt aan het behalen van de doelstelling. Hierin moet duidelijk

gemaakt worden welke toegevoegde waarde de oplossing levert ten opzichte van de

kosten.

Tegelijkertijd moet aan de IT kant gekeken worden hoe het portalproduct in het

huidige systeemlandschap gepositioneerd gaat worden en wat de relaties zijn met

bestaande systemen. Dit moet leiden tot een roadmap (of plateauplanning) waarin de

implementatie van de portal in fases wordt opgedeeld. De roadmap zelf is geen

statisch document, maar kan op basis van voortschrijdend inzicht in de

vervolgstappen doorgroeien. Dit betekent dat begonnen kan worden met een

projectstartarchitectuur (PSA).

De plateaugewijze opdeling is belangrijk omdat het vaak niet realistisch haalbaar is

om een portal voor veel verschillende gebruikersgroepen in één keer te introduceren.

Een stapsgewijze implementatie heeft als voordeel dat er snel resultaten geboekt

worden en er tijdens het project de mogelijkheid is om per fase bij te sturen. In elke

fase van de implementatie moeten alle relevante aspecten worden meegenomen:

Whitepaper Portals en SOA Pagina 17 van 24

Management en organisatie

Processen

Infrastructuur

Mensen en cultuur

4.1.3 Stap 3 – Productselectie

Zodra de doelstelling, business case en roadmap bekend zijn kan er gekeken worden

naar de verschillende portalproducten die er in de markt beschikbaar zijn. Hierbij kan

gebruik gemaakt worden van long en short lists die opgesteld kunnen worden op basis

van een programma van eisen. Bij het opstellen van het programma van eisen moeten

ook kwaliteitscriteria meegenomen worden. Hierbij kan gebruik gemaakt worden van

het Extended ISO 91263 kwaliteitsmodel (ook wel Quint2-model genaamd). Dit is een

hiërarchisch model dat zes basiseigenschappen kent die onderverdeeld zijn in een

aantal subeigenschappen waarmee de kwaliteitseisen gestructureerd vastgelegd

kunnen worden. Het Quint2-model beschrijft ook een aantal eigenschappen die zeer

geschikt zijn voor portalproducten, zoals aanpasbaarheid en herbruikbaarheid.

De meeste portal leveranciers zijn begonnen met een portalproduct vanuit één

bepaald perspectief. Dit perspectief is vaak nog steeds hun kracht ten opzichte van de

concurrentie. De gekozen doelstelling heeft daarom ook belangrijke invloed op de

short list van producten.

4.1.4 Stap 4 – Proof-of-concept

De proof-of-concept is bedoeld om de tot nu toe gemaakte (theoretische) beslissingen

in de praktijk te toetsen. Een proof-of-concept biedt een aantal voordelen:

De belangrijkste risico’s kunnen worden weggenomen door middel van testen.

Er kan in een vroeg stadium gecontroleerd worden of de proof-of-concept

voldoet aan de wensen en verwachtingen. Indien het programma van eisen

aangepast moeten worden is dit goedkoper in het begin van het traject dan

aan het einde.

Het biedt de mogelijkheid gebruikersgroepen vroegtijdig bij het traject te

betrekken waardoor ze meer gecommitteerd zijn aan het uiteindelijke product.

Afhankelijk van het resultaat van stap 3 wordt de proof-of-concept gebruikt ter

onderbouwing van de keuze voor een geselecteerd portalproduct of juist als laatste

beslissingsstap bij de productselectie.

4.1.5 Stap 5 – Realisatie

In stap 5 wordt de portal gerealiseerd. Bij de realisatie van de portal zijn verschillende

expertises benodigd op gebied van onder andere informatieanalyse, grafisch ontwerp,

softwareontwikkeling en infrastructuur. Hierbij valt op te merken dat juist bij dit soort

middleware producten er vaak geen scherpe scheidslijn is tussen deze expertises.

Door de verschillende benodigde expertises en de verschillende (on)mogelijkheden

van het geselecteerde portalproduct is het belangrijk tijdens de realisatie te werken in

multidisciplinaire teams.

3 http://www.softwarekwaliteit.nl

Whitepaper Portals en SOA Pagina 18 van 24

4.1.6 Stap 6 – Implementatie

Zoals voor de roadmap in stap 2 is benadrukt moeten per plateau alle relevante

aspecten meegenomen worden. In productie name is dus niet alleen een technische

aangelegenheid. Er moet ook aandacht besteed worden aan bijvoorbeeld een

communicatie plan, opleiding van de eindgebruikers en inbedding in de organisatie.

Stappen 5 en 6 zullen voor elk plateau van de roadmap herhaald worden.

4.2 Aandachtspunten Bij het doorlopen van de hierboven beschreven stappenplan zijn een aantal

aandachtspunten te onderscheiden die bepalend zijn voor het succes van de

implementatie. Dit zijn typisch punten die ofwel in het projectplan of in de

projectstartarchitectuur onderkend moeten worden.

4.2.1 Portal adoptie

Een portal vraagt meestal om een nieuwe manier van werken. Het is daarom

essentieel dat van te voren genoeg aandacht wordt besteed aan de aspecten buiten de

IT.

In [PRPT] wordt een aantal best practices genoemd waarmee portal adoptie bevorderd

kan worden:

Zorg voor gedeelde beslissingsbevoegdheid. Portals raken al snel veel

organisatorisch en technische beslissingen, voorkom dat alles centraal besloten

moet worden.

Een portal moet zorgen voor flexibiliteit bij wijzigende business requirements.

Zorg voor een goed gevuld communicatieplan, het lanceren van een portal is

zoals het lanceren van een product. Je moet de doelgroep laten weten wat de

portal te bieden heeft en waarom ze het zouden moeten gaan gebruiken.

Zorg voor een duidelijk aanleiding om de portal te gaan gebruiken. Om de

doelgroep te overtuigen van de toegevoegde waarde van de portal, is het

belangrijk dat de portal aandacht besteed aan punten die qua tijd en attentie

belangrijk zijn voor de gebruikers.

4.2.2 Laagdrempeligheid tot onbeheersbaarheid

Sommige perspectieven zijn (lijken) heel laagdrempelig, waardoor hiervoor snel een

portal neergezet en in gebruik genomen wordt. Doordat over aspecten zoals schaling,

gebruikersbeheer en contentbeheer dan vaak niet genoeg nagedacht wordt, is de

portal vervolgens niet gemakkelijk uit te breiden met nieuwe functionaliteit. Hierdoor

kan aan het initiële succes lastig een vervolg gegeven worden. Dit gebeurt veel met

collaboration portals, die in een pilot fase worden ingericht en vervolgens rechtstreeks

in productie worden genomen. Na verloop van tijd is alle informatie ongestructureerd

in de portal opgeslagen en wordt het lastig dit alsnog te structureren.

4.2.3 Beveiliging en compliancy

Door de integratie van veel verschillende informatiebronnen en applicaties is het

essentieel dat alle benodigde autorisaties worden ingeregeld. Hierbij moeten minimaal

een aantal vragen beantwoord worden:

Blijven de benodigde functiescheidingen nog wel intact?

Wordt de privacy van klanten nog wel gewaarborgd?

Is nog wel te achterhalen wie welke informatie wanneer heeft gemuteerd of

gezien?

Whitepaper Portals en SOA Pagina 19 van 24

En wordt daarmee voldaan aan wet- en regelgeving (denk aan IFRS, Basel,

SOx, maar ook de archiefwet of privacy wet)?

Het gaat hier om aspecten die moeilijk gefaseerd of achteraf gerealiseerd kunnen

worden en daarom een gedegen aanpak vereisen.

4.2.4 Koppeling met bestaande systemen

Een ander aandachtspunt is de positionering van de portal ten opzichte van de

bestaande systemen binnen de organisatie. Veel organisaties hebben al een

contentmanagementsysteem of een documentmanagementsysteem. Hoe kunnen deze

systemen nu gekoppeld worden aan de functionaliteit in de portal? Probleem hier is

dat deze systemen niet ontsloten hoeven te worden, maar geïntegreerd moeten

worden met de functionaliteit van de portal zelf. Hiermee dient rekening gehouden te

worden bij de positionering van de portal in de technische architectuur.

4.2.5 Formele en informele samenwerking

Maak onderscheid tussen formele en informele samenwerking. Deze vormen hebben

heel verschillende requirements. Door een logische scheiding aan te brengen tussen

de samenwerkingsvormen kunnen duidelijke keuzes gemaakt worden over

bijvoorbeeld de verhouding tussen documenten in de portal en publicatie in het

documentinformatiesysteem. Ook kunnen dan de compliancy aspecten beter

ondervangen worden.

Whitepaper Portals en SOA Pagina 20 van 24

5 Conclusies In deze paper zijn twee belangrijke succesfactoren beschreven voor de implementatie

van een portal in een administratieve organisatie.

Ten eerste moet het voor de organisatie duidelijk zijn met welke doelstelling de portal

wordt ingezet. De functionaliteit van portals is in de loop der jaren flink uitgebreid. De

eerste portals werden met name gebruikt om informatie alleen te aggregeren.

Tegenwoordig biedt een moderne portal veel uitgebreidere functionaliteit, zoals

zoeken, personalisatie en gereedschappen voor samenwerking.

Deze uitgebreide functionaliteit zorgt ervoor dat portals vanuit heel verschillende

perspectieven benaderd kunnen worden. In hoofdstuk 2 zijn acht van deze

perspectieven behandeld.

Ten tweede dient nagedacht te worden over de positionering van een portal in de

technische architectuur, zoals is besproken in hoofdstuk 3. Het aantal leveranciers van

portalproducten is inmiddels teruggegaan naar een viertal grote spelers en een aantal

open source initiatieven. De leveranciers lijken consensus te hebben bereikt over de

definitie van een portal die aansluit bij de door Gartner gebruikte definitie. Bij de

marktleiders vormt het portalproduct veelal een strategisch onderdeel van de SOA

productstack. De producten zelf worden steeds uitgebreider en bevatten steeds meer

out-of-the-box functionaliteit. Hierdoor zijn er verschillende manieren om de portal te

positioneren binnen een SOA. Binnen de markt is tevens een trend gaande om steeds

meer portalproducten (gedeeltelijk) aan te bieden als SaaS oplossing. Salesforce.com

laat zien dat dit een zeer succesvol model kan zijn voor de leveranciers.

De NORA en EGEM, die beiden ook uitgaat van een SOA omgeving, doen geen

specifieke uitspraken over de positionering van portals. Wel zijn veel principes goed

van toepassing op portals.

Binnen Info Support’s Endeavour referentie architectuur wordt de portal

gepositioneerd als het platform voor de front-end services en eventueel ook

(workflow) process services indien de portal human workflow ondersteunt.

In hoofdstuk 4 is op basis van de twee succesfactoren een stappenplan gepresenteerd

om het gemakkelijker te maken om tot een portal implementatie te komen. Deze

stappen zijn aangevuld met een aantal aandachtspunten die bepalend zijn voor een

succesvolle implementatie.

Whitepaper Portals en SOA Pagina 21 van 24

Bijlage A: Portal definities Hieronder volgt een greep uit de verschillende definities die voor portals geformuleerd

zijn:

“A portal is a web based application that –commonly- provides personalization,

authentication, content aggregation from different sources and hosts the

presentation layer of Information Systems. Aggregation is the action of integrating

content from different sources within a web page. A portal may have sophisticated

personalization features to provide customized content to users. Portal pages may

have different set of portlets creating content for different users.”

– Java Portlet Specification 2.0 (JSR 268)

“An enterprise portal, also known as an enterprise information portal (EIP), is a

framework for integrating information, people and processes across organizational

boundaries. It provides a single point of entry, often in the form of a web-based user

interface, and is designed to aggregate information through application-specific

portlets.”

– Wikipedia

“A portal is a Web software infrastructure that provides access to and interaction with

relevant information asset (such as information/content, applications and business

processes), knowledge assets and human assets by selected target audiences,

delivered in a highly personalized manner. Enterprise portals may face different

audiences, including employees (B2E), customers (B2C) or business partners (B2B).

B2E portals are the most relevant type of enterprise portal to the high-performance

workplace, but portals serving other audiences also play important roles.”

– Gartner [HYPE]

“Web portals allow partners, employees and customers to chose their user experience,

with personalized applications based on role, context, actions, location, preferences

and team collaboration needs. IBM WebSphere Portal software provides a composite

application or business mashup framework and the advanced tooling needed to build

flexible, SOA-based solutions, as well as the unmatched scalability required by any

size organization.”

– IBM website

“Portal sites connect your people to business critical information, expertise, and

applications. Microsoft Office SharePoint Server (MOSS) is a world class Enterprise

Portal platform that makes it easy to build and maintain portal sites for every aspect

of your business.”

– Microsoft website

“Een portal (of portaal) is een toegangspoort voor diverse doelgroepen. … Bij portals

kan onderscheidt gemaakt worden tussen enterprise portals en internetportals.

Enterprise portals richten zich op het verlenen van toegang tot alle informatie en

processen die nodig zijn voor het verrichten van de werkzaamheden ongeachte

werkplaats of het tijdstip. Een internetportal biedt juist toegang tot alle informatie en

processen voor een bepaald aandachtsgebied of diverse aandachtsgebieden. Dit wordt

ook wel een marketplace genoemd.”

– Trends in IT 2006/2007 [TRENDS]

Whitepaper Portals en SOA Pagina 22 van 24

“A portal is a web-based gateway for users to locate relevant content and use the

applications they commonly need to be productive.”

– Liferay

“… a bottom-up definition that was derived from looking at the evolution of the Web:

A Portal is a door or gateway. It provides access to specialized and focused

information and links.

A Portal is a filter. It eliminates from our path information that is not relevant.

A Portal is ad hoc. This allows its definition to occur at time of use rather than

at design time. Its definition is specified by the user.

A Portal is customized. A user can specify its behavior, appearance and

content.

A Portal is individualized. A portal is a one-to-one channel between the provider

and the audience.

The Portal of the future will be:

User Centric. Content, its delivery and access needs to move from the control

of the site providers and intermediaries. Users must be the determiners of

content and organization. The portal concept will move away from being a door

to providers’ or intermediaries’ sites to being a window from the user’s

environment.

Business Process Oriented. The real value of information is in its use. Web

content needs to seamlessly fit into the work of users.

Integrated. Almost every business situation that can benefit from Web content

requires information from the local environment too. These information sources

must be integrated in a seamless fashion.

Adaptive. The Portal must be sensitive to changes in the user’s environment as

well as changes in the Web.”

- Web Portals: History and Direction

http://ltl13.exp.sis.pitt.edu/Website/Webresume/WebPortalPaper/WebPortals.htm

Whitepaper Portals en SOA Pagina 23 van 24

Referenties

Code Bron

ENDLRA Endeavour Logische Referentie Architectuur.

TRA Endeavour Technische Referentie Architectuur

EIP Enterprise Integration Patterns, 2004, Gregor Hohpe, Bobby Woolf

ISBN 0-321-20068-3.

QUINT http://www.softwarekwaliteit.nl/

NORA Nederlandse Overheid Referentie Architectuur 2.0, 25 april 2007

PRPT Proven Portals, Best Practices for Planning, Designing and Developing

Enterprise Portals, Dan Sullivan, 2004, ISBN 0321125207.

MDFF Het midoffice, elektronische dienstverlening tussen frontoffice en

backoffice, Roovers, Kuiper en Keller, 2007, ISBN 9789012119900.

HYPE Hype Cycle for Web and User Interaction Technology, 2007

Gartner, 13 juli 2007.

MAGQ Magic Quadrant for Horizontal Portal Products, 2007

Gartner, 24 augustus 2007.

TRENDS Trends in IT 2006/2007, P. Noordam, A. van der Vlist en B. Derksen, april

2006, ISBN 9012114896.

PIP Portaal technologie en PIP, Telematica Instituut, mei 2007.

https://doc.telin.nl/dsweb/Get/Document-74829/

Whitepaper Portals en SOA Pagina 24 van 24

Over Info Support Info Support is opgericht in 1986 en is met ruim 350 medewerkers in Nederland een

vooraanstaand IT-dienstverlener op het gebied van IT-consultancy, software -

ontwikkeling, opleidingen en beheer. Info Support is niet beursgenoteerd en financiert

de verdere ontwikkeling van de organisatie op basis van een beheerste groei uit eigen

middelen.

Onze drive achter de oplossingen die wij realiseren voor onze klanten is er sterk op

gericht bedrijfsprocessen sneller en beter te maken. Info Support ontwikkelt en

beheert solide en innovatieve softwareoplossingen die organisaties ondersteunen bij

het realiseren van hun doelstellingen.

De kernwaarden Soliditeit, Integriteit, Vakmanschap en Passie typeren onze

werkwijze, waarin we sociaal en solide management belangrijker vinden dan

omzetmaximalisatie. Ons hoogste doel is dat we met opdrachtgevers en medewerkers

willen bouwen aan langetermijnrelaties. Daarbij houden we ons aan gemaakte

afspraken. Dit maken we in de praktijk waar, getuige de jarenlange relaties die we

met onze klanten hebben. Info Support mag zich al 16 jaar op rij TOP-IT-werkgever

van het jaar noemen.

Zie voor meer informatie www.infosupport.com.