Portals en SOA. Competence Center Infrastructural Software Services

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 [email protected].

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 ........................................ 4.1.1 Stap 1 – Doelstelling...................................................................... 4.1.2 Stap 2 – Business case & roadmap .................................................. 4.1.3 Stap 3 – Productselectie ................................................................. 4.1.4 Stap 4 – Proof-of-concept............................................................... 4.1.5 Stap 5 – Realisatie ........................................................................ 4.1.6 Stap 6 – Implementatie ................................................................. 4.2 Aandachtspunten ................................................................................ 4.2.1 Portal adoptie ............................................................................... 4.2.2 Laagdrempeligheid tot onbeheersbaarheid ........................................ 4.2.3 Beveiliging en compliancy............................................................... 4.2.4 Koppeling met bestaande systemen ................................................. 4.2.5 Formele en informele samenwerking ................................................

16 16 16 17 17 17 18 18 18 18 18 19 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.

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 3 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/


Pagina 4 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 5 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).


Pagina 6 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.


Pagina 7 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 8 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 documenten 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.


Pagina 9 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 JEEapplicatieservers, 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 10 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.


Pagina 11 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 12 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)


Pagina 13 van 24

De frontoffice kan goed ingericht worden met behulp van een portalproduct. Ondanks dat een aantal midoffice componenten (zoals documenten 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 Figuur 4 - Endeavour Het beschikbaar stellen van functionaliteit aan servicetypen 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.


Pagina 14 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 [email protected].


Pagina 15 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 16 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


Pagina 17 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 18 van 24



En wordt daarmee voldaan aan weten 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.


Pagina 19 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.


Pagina 20 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]


Pagina 21 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


Pagina 22 van 24

Referenties Code ENDLRA TRA EIP QUINT NORA PRPT MDFF HYPE MAGQ TRENDS PIP

Bron Endeavour Logische Referentie Architectuur. Endeavour Technische Referentie Architectuur Enterprise Integration Patterns, 2004, Gregor Hohpe, Bobby Woolf ISBN 0-321-20068-3. http://www.softwarekwaliteit.nl/ Nederlandse Overheid Referentie Architectuur 2.0, 25 april 2007 Proven Portals, Best Practices for Planning, Designing and Developing Enterprise Portals, Dan Sullivan, 2004, ISBN 0321125207. Het midoffice, elektronische dienstverlening tussen frontoffice en backoffice, Roovers, Kuiper en Keller, 2007, ISBN 9789012119900. Hype Cycle for Web and User Interaction Technology, 2007 Gartner, 13 juli 2007. Magic Quadrant for Horizontal Portal Products, 2007 Gartner, 24 augustus 2007. Trends in IT 2006/2007, P. Noordam, A. van der Vlist en B. Derksen, april 2006, ISBN 9012114896. Portaal technologie en PIP, Telematica Instituut, mei 2007. https://doc.telin.nl/dsweb/Get/Document-74829/


Pagina 23 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.


Pagina 24 van 24

Portals en SOA. Competence Center Infrastructural Software Services

Recommend Documents