Architectuur. Enterprise Portal

Architectuur enterprise portaal v 1.0

Architectuur Enterprise Portal

Auteur : Versie : Status : Documentdatum :

Architectuur

© 2014

Ivo Huurdeman 1.0 Final 11-02-14

Pagina 1 van 20


Inhoudsopgave

Inhoudsopgave 2 Inleiding .......... 3 1 ..................... Enterprise portal architectuur .................................................... 4 1.1

Inleiding............................................................................................. 4

1.2

DLWO ................................................................................................. 4

1.3

Wat is een portal suite ? ................................................................. 6

2 ..................... UM architectuur............................................................................... 10

Architectuur

2.1

Architectuurprincipes ........................................................................... 10

2.2

Vormen van integratie met het enterprise-portaal ................................. 15

2.3

Back office integraties UM portal.......................................................... 16

2.4

De “ any device” propositie .................................................................. 18

© 2014

Pagina 2 van 20


Inleiding

Dit document beschrijft de soll situatie van de logische portaal architectuur van de UM. Het vormt daarmee een belangrijke leidraad voor allerlei keuzes die gemaakt moeten worden bij het opzetten en verder ontwikkelen van de verschillende doelgroepportalen van de UM. Deze architectuur moet in samenhang worden gezien met de integratie architectuur en de I&AM architectuur van de UM. Afwijking van de geformuleerde architectuurprincipes is mogelijk indien hier een goede schriftelijke onderbouwing voor beschikbaar is. Een dergelijke afwijking moet door de UM (CIO-ICTS overleg) formeel worden goedgekeurd alvorens deze ten uitvoer te brengen. Het eerste hoofdstuk geeft een algemen beschrijving van wat een enterprise portaal is en hoe deze zich verhoudt tot, de digitale leer en werkomgevng (DLWO), een web content management systeem en een electronische leeromgeving. In het tweede hoofdstuk wordt de daadwerkelijke UM architectuur beschreven.

Architectuur

© 2014

Pagina 3 van 20


1

Enterprise portal architectuur

1.1

Inleiding

In dit hoofdstuk wordt een beschrijving gegeven van de gewenste architectuur van de UM enterprise portal. Aangezien de enterprise portal een belangrijk onderdeel is van de Digitale Leer en Werk Omgeving (DLWO) van de UM zal eerst kort worden stilgestaan wat wordt bedoeld met een DLWO en welke positie de enterprise portal daarin inneemt. Vervolgens wordt gespecificeerd wat een enterprise portal is en hoe deze zich verhoudt tot een Content Management Systeem en een Electronische Leeromgeving (ELO). Na deze algemene inleiding volgt in hoofdstuk 2 de daadwerkelijke UM architectuur.

1.2

DLWO

Een definitie Een DLWO kan als volgt worden gedefinieerd : “het geheel van digitale diensten ter ondersteuning van het dagelijks leren en werken van studenten, medewerkers en externe relaties van de Universiteit Maastricht” Digitale diensten bestaan daarbij uit goed vindbare informatie, interne diensten en

toepassingen.

Leren en werken omvat tevens onderzoeken, communiceren en samenwerken.

1.2.1 Gebruikersperspectief De definitie van DLWO is nog erg algemeen en bevat in ultieme vorm de digitale ondersteuning voor alle leer- en werkactiviteiten. Het is daarom belangrijk om het begrip beter af te bakenen. De belangrijkste afbakening daarin is dat een DLWO alleen ondersteuning biedt voor generieke veelgebruikte functionaliteit. Ondersteuning voor taken van specifieke gebruikersgroepen maakt geen onderdeel uit van de DLWO. In onderstaande figuur wordt de DLWO verder uitgewerkt en gepositioneerd. Hierin worden de belangrijkste gebruikersgroepen en de behoeften die worden ondersteund weergegeven. Verder is in de figuur aangegeven dat de DLWO in de praktijk wordt ingevuld door een aantal specifieke DLWO applicaties die de noodzakelijke functionaliteiten bieden. Ondersteuning van specifieke taken wordt overgelaten aan taakspecifieke applicaties.

Architectuur

© 2014

Pagina 4 van 20


Mijn rooster en toetsresultaten makkelijk toegankelijk

Mijn vakken meer digitaal gaan verzorgen

Student

Docent

Mijn onderzoeken meer in samenwerking met anderen

Onderzoeker

Makkelijker gegevens en ideeën kunnen uitwisselen met de UM

Externe

Mijn personeelszaken direct zelf regelen

Medewerker

DLWO applicaties Mijn specifieke taak zo optimaal mogelijk ondersteunen

Taakspecifieke applicatie Student

Taakspecifieke applicatie Medewerker

Figuur 1 De DLWO gepositioneerd 1.2.2 Informatiesysteemperspectief De DLWO is in eerste instantie vooral een concept. In de praktijk bestaat een dergelijke omgeving uit een verzameling van applicaties die samen alle noodzakelijke functionaliteit bieden. In Figuur 2 zijn deze applicaties in drie categorieën ingedeeld. De belangrijkste applicatie is het “enterprise portaal” dat wordt aangeboden door de universiteit en dat het ingangspunt voor gebruikers is om alle DLWO functionaliteiten te benaderen. Daarnaast kun je ook externe portalen en applicaties als onderdeel zien van de DLWO. Dit is niet zo vreemd als je je bedenkt dat er op Internet veel bruikbare applicaties beschikbaar zijn (in veel gevallen zelfs gratis), bijvoorbeeld voor het ondersteunen van samenwerking. Ook zie je dat gebruikers bij voorkeur zelf kiezen hoe ze hun eigen werkzaamheden ondersteunen. Mobiele applicaties kunnen ook worden gezien als onderdeel van de DLWO; zij ondersteunen ook belangrijke informatiebehoeften van veel gebruikers. Om meer zicht te krijgen hoe de UM het beste mobiele applicaties kan ontwerpen, bouwen, ontsluiten en beheren, wordt nog een vooronderzoek hieromtrent uitgevoerd. Dit moet onder meer leiden tot een streefarchitectuur voor mobiele applicaties.

Figuur 2 DLWO applicaties in meer detail

Architectuur

© 2014

Pagina 5 van 20


1.3

Wat is een portal suite ?

Deze paragraaf biedt een algemene inleiding tot portalen en hun positionering ten opzichte van andere technologie. Daarbij positioneert het termen als “portal server”, “portal suite” en “enterprise portaal” en schetst het hoe portalen in het algemeen zijn ingericht. 1.3.1 Algemene informatie Portalen zijn gepersonaliseerde werkomgevingen die een geïntegreerd beeld geven van informatie en functionaliteit in informatiesystemen van de organisatie. Hun kracht ligt dus zowel in personalisatie als in integratie. Personalisatie betekent dat de werkomgeving van de gebruiker wordt aangepast aan zijn rol, persoonlijke voorkeuren of gedrag waardoor het optimaal aansluit bij zijn/haar behoeften. Integratie gaat over het visueel samenbrengen van informatie en functionaliteit, bij voorkeur op een manier waarbij de samenhang ook wordt geborgd. Dit betekent dat informatie wordt samengevoegd en geaggregeerd met andere informatie of dat functionaliteit samenwerkt met andere functionaliteit. Zo ontstaat samengestelde functionaliteit (ook wel: samengestelde applicatie) die niet in individuele applicaties bestaat. Door alle informatie en functionaliteit ook op een goed navigeerbare en doorzoekbare manier te ontsluiten met een eenduidig uiterlijk wordt het portaal een belangrijk ingangspunt voor veel gebruikers. Met name als dit portaal er ook voor zorgt dat gebruikers maar één keer hoeven in te loggen en zich geen zorgen meer hoeven te maken over wachtwoorden voor allerlei applicaties. Portalen worden gepositioneerd als het toegangspunt voor informatie en functionaliteit. Zij worden ondersteund door specifieke softwareproducten, de zogenaamde portal servers. Een "portaal" is echter in eerste instantie een concept, dat niet per definitie met een “portal server” gerealiseerd hoeft te worden. In veel gevallen worden portal servers geleverd in combinatie met andere systemen, zoals een content management systeem en een document management systeem. In dat geval wordt ook wel gesproken over “portal suites”. Daarnaast is er een onderscheid tussen generieke portal servers (horizontale portalen) en portalen die worden meegeleverd met applicaties (verticale portalen). Tenslotte is er ook nog het concept “enterprise portaal” waarmee het algemene (horizontale) portaal in een organisatie wordt bedoeld. Het is de plaats waar gebruikers starten en waarvandaan naar meer specifieke portalen of applicaties kan worden genavigeerd. Figuur 3 geeft een overzicht van de functionaliteiten die standaard aanwezig zijn in een portal suite. De kern van de functionaliteit is de presentatielogica, waarbij het portaal verantwoordelijk is voor het visueel integreren van allerlei content op basis van de rol, voorkeuren en het gedrag van de gebruiker. Aanvullend biedt een typische portal suite ook allerlei contentbeheer functionaliteiten, waardoor content op allerlei manieren kan worden aangeboden aan gebruikers. Ook is samenwerkings-functionaliteit veelal aanwezig in een portaal suite, waarbij gebruikers op allerlei manieren informatie kunnen delen en samen kunnen werken aan documenten en kennis. Tenslotte zie je dat ook allerlei sociale functionaliteit wordt geboden, waardoor het portaal ook een soort sociaal netwerk wordt en mensen aan elkaar kan verbinden.

Architectuur

© 2014

Pagina 6 van 20


Figuur 3 Standaard functionaliteiten van een portal suite 1.3.2 Positionering Portal suites overlappen functioneel sterk met andere soorten systemen. Met name content management systemen en Elektronische Leer Omgevingen lijken veel overlap te vertonen. Zoals eerder aangegeven hebben veel leveranciers zelf een content management systeem toegevoegd aan hun portal suite. In een aantal gevallen is dat een beperkt systeem, maar in andere gevallen is dat een volwaardig content management systeem. Volwaardige content management systemen bieden onder meer specifieke functionaliteiten voor het doorzetten van content (staging), maar ook bijvoorbeeld uitgebreide content meta-datering, internationalisatie, gebruikersanalyse en zoekmachine-optimalisatie. Dit is met name relevant voor externe web-sites waarin het belangrijk is om vanuit marketingperspectief te kijken hoe de doelgroepen optimaal bereikt (kunnen) worden. Elektronische Leer Omgevingen (ELO’s) overlappen ook sterk met portal suites. Voor een belangrijk deel zijn het zelfs ook content management systemen (ook wel: Learning Content Management Systemen). ELO’s zijn met name gericht op samenwerken, waarbij er kan worden gediscussieerd over allerlei content zoals oefeningen die lerenden hebben gemaakt. Dit overlapt duidelijk ook met wat portal suites aanbieden. Waar ELO’s zich in onderscheiden is in allerlei onderwijsspecifieke functionaliteit, bijvoorbeeld voor het aanbieden van eLearning, het toetsen en beoordelen van studenten en het uitwisselen van onderwijsmateriaal conform de daarvoor geldende standaarden (SCORM, IMS, NLN). Portal servers onderscheiden zich met name op het gebied van personalisatie en integratie. Hierdoor kunnen ze content heel specifiek richten op de rol, voorkeuren en het gedrag van gebruikers. Daarnaast ondersteunen ze veel open standaarden waardoor het relatief eenvoudig is om andere systemen visueel te integreren. Hierdoor wordt het ook mogelijk om op een iGoogle-achtige wijze interne en externe functionaliteiten visueel te integreren. Figuur 4 geeft een visueel overzicht van de verschillende soorten systemen en de functionaliteit die deze bieden.

Architectuur

© 2014

Pagina 7 van 20


Portal server Personalisatie

Visuele integratie Content meta-data Contentbeheer eLearning

Elektronische Leeromgeving

Toetsen Beoordelen

Sociaal verbinden

Content Content staging management systeem Internationalisatie Gebruikanalyse

Samenwerking

Uitwisselen onderwijsmateriaal

Figuur 4 Positionering portal servers t.o.v. CMS en ELO 1.3.3 Referentie-architectuur Figuur 5 geeft een schets van de typische inrichting van een portaalomgeving. Zoals weergegeven in de figuur zijn portalen web-gebaseerde systemen, die gebruik maken van de algemene web servers en specifieke portal servers. Portalen zijn opgebouwd uit zogenaamde portlets; softwarecomponenten die specifiek zijn ontwikkeld om gebruikt te worden in de context van een portaal. Deze portlets worden alleen getoond als ze relevant zijn voor de specifieke gebruiker. Ze bevatten alleen presentatielogica en ontsluiten gegevens en functionaliteit uit achterliggende applicaties. Daarnaast kan een portaal ook delen uit andere portalen tonen. Ook zichtbaar in de figuur is de sterke relatie van de portaalomgeving met het identity management systeem waarin informatie over gebruikers is opgeslagen zoals zijn rol en profiel. Deze informatie is erg belangrijk voor de portaalomgeving omdat die deze gebruikt om de content en functionaliteit te personaliseren, zodat deze optimaal aansluit bij de rol en behoeften van gebruikers. Voor authenticatie sluit het portaal liefst ook zoveel mogelijk aan bij standaard authenticatiemechanismen, inclusief federatieve mechanismen zodat ook gebruikers van buiten de organisatie gebruik kunnen maken van het portaal.

Architectuur

© 2014

Pagina 8 van 20


Figuur 5 Typische inrichting van een portaalomgeving De portaalomgeving biedt allerlei faciliteiten voor visueel integreren van content en functionaliteit, wat ook wel “presentatie aggregatie” heet. Dit kan content in de portaalomgeving zelf zijn of content die afkomstig is van andere applicaties. Hiertoe kan de portaalomgeving op allerlei manieren integreren met andere applicaties. Zo kunnen applicaties alleen worden gestart vanuit het portaal, waarna ze volledig hun eigen gebruikersinterface tonen. Beter is als applicaties zelf portaal-specifieke presentatiecomponenten (portlets) aanbieden, die direct in de portaalomgeving gebruikt kunnen worden. In het algemeen zou integratie in de portaalomgeving gedreven moeten zijn door de noodzaak om bepaalde content of functionaliteit voor een brede doelgroep en/of geïntegreerd te presenteren. De reden daarvoor is dat alle integratie tijd en geld kost en dat gekeken moet worden wat de toegevoegde waarde van portaalintegratie is. Een portaal is nu eenmaal gericht op het integreren van informatie. Een interessante ontwikkeling is SURFconext; een initiatief van SURF om te onderzoeken hoe een toekomstige samenwerkingsomgeving er uit zou moeten zien. Deze samenwerkingsomgeving is de opvolger van SURFgroepen; een centrale SharePoint omgeving die gratis aan onderwijsinstellingen ter beschikking werd gesteld. De constatering is echter dat deze SharePoint omgeving niet goed aansluit bij de wens van onderwijsinstellingen om veel meer een mix van functionaliteiten aan te bieden, die zowel door SURF als door de onderwijsinstelling of door een derde partij worden aangeboden. Er is daarom gewerkt aan een portaalomgeving gebaseerd op de OpenSocial standaard die juist dit soort heterogeniteit goed ondersteunt. De voorstelde visie is ook uitgewerkt in een referentie-architectuur (CIFC). Deze schetst een infrastructurele voorziening die bemiddelt tussen gebruikers en aanbieders van diensten. Deze voorziening integreert en transformeert de diensten tot een consistente gebruikerservaring. Daarbij wordt aangesloten bij identity management zoals aanwezig in de SURFfederatie en instellingsoverstijgende groepsinformatie in SURFteams.

Architectuur

© 2014

Pagina 9 van 20


2

UM architectuur

Dit hoofdstuk beschrijft de gewenste architectuur van het enterprise portaal en is daarmee gericht op een brede doelgroep. Het beschrijft de architectuurprincipes voor de inrichting van de portaalomgeving en geeft daarnaast een schets van de gewenste technische inrichting van het enterprise portaal.

2.1

Architectuurprincipes

Deze paragraaf geeft een overzicht van de architectuurprincipes die de UM hanteert bij het inrichten en ontwikkelen van haar enterprise portaal. Elk architectuurprincipe is voorzien van een motivatie en implicaties die het architectuurprincipe verder toelichten en concreet maken. Afwijken van deze architectuurprincipes is alleen mogelijk als daar een goede motivatie voor is en deze is afgestemd met de architecten. Deze architectuurprincipes geven aan de (nog op te richten) Portal Governance Board de kaders waarbinnen het portaal wordt ontwikkeld. 1. Het enterprise portaal is user centric ingericht.

De UM wil dat haar processen studentgericht zijn (UM strategie) en vindt de tevredenheid van studenten erg belangrijk. Daarnaast wil de UM ook een aantrekkelijke werkgever zijn. Dit vraagt om een gebruikersvriendelijke informatievoorziening waarbij de gebruiker centraal staat. Dit gaat verder dan een geïntegreerde informatievoorziening. In het algemeen is de belevingswereld van gebruikers erg belangrijk (User Experience, UX); wat zij zien en ervaren van de informatievoorziening bepaalt in grote mate hun tevredenheid. Aangezien het enterprise portaal het belangrijkste interactiekanaal betreft tussen de eindgebruiker en de informatie voorziening van de UM is het van cruciaal belang dat bij alle inrichtingskeuzes van het portaal de eindgebruiker centraal staat. Implicaties : Het aanbod van informatie en toepassingen is afgestemd op het profiel (opleiding, interesse, rol in de organisatie, etc.) van gebruikers. Generieke publieke content wordt via het publieke doelgroepportaal (website) ontsloten en niet achter de inlog van het portaal. Gebruikers hoeven maar één keer in te loggen om gebruik te kunnen maken van alle informatie en toepassingen waar ze recht op hebben. De portal-accounts zijn gekoppeld aan de accounts bij SURF en die van het UM-netwerk, zodat op UM werkstations direct ingelogd kan worden. Eén zoekmachine geeft gebruikers toegang tot alle ongestructureerde content binnen het portaal m.u.v. de wetenschappelijke conctent waarvoor aparte gespecialiseerde zoekmachines beschikbaar zijn. Het enterprise portaal voldoet aan de webrichtlijnen voor toegankelijkheid. De vormgeving van alle informatie alsmede de user interface is constant en gebaseerd op de UX design principes. Er is één herkenbare look & feel voor de gehele enterprise portal. De eindgebruiker beschikt over een personal page welke hij volledig naar eigen wensen kan inrichten.

Architectuur

© 2014

Pagina 10 van 20

Architectuur enterprise portaal v 1.0 2. De enterprise portaal is toegankelijk any time, any place, any device

Gebruikers moeten eigen apparatuur kunnen gebruiken en altijd en overal toegang hebben tot hun gegevens en applicaties. Gebruikers beschikken over persoonlijke apparaten zoals mobiele telefoons, tablets en laptops waarmee ze graag toegang willen tot hun gegevens en applicaties. Applicaties en gegevens moeten ook toegankelijk zijn vanaf dit soort persoonlijke (niet-standaard) apparaten. Implicaties: De portal kan overal ter wereld worden benaderd via het internet tenzij er zwaarwegende redenen zijn om dit niet te willen. De portal is geoptimaliseerd voor die browsers waarmee minimaal 85 % van de doelgroep wordt bereikt. Het intranet is geoptimaliseerd voor lage bandbreedte, zodat ook mobiele gebruikers snel toegang hebben tot de beschikbare informatie en toepassingen. Het enterprise portaal is geoptimaliseerd (Responsive Webdesign) voor desktop, laptop, tablet en smartphone. De portal is 24x7 bereikbaar met inachtneming van het beschikbaarheidsniveau van de achterliggende bron applicaties. 3. De UI voor smartphones is specifiek ontworpen voor smartphones

De UI voor het kunnen uitvoeren van bepaalde taken (functies) via een smartphone wordt (of is) specifiek ontworpen voor smartphone gebruik en indien mogelijk gerealiseerd middels mobiele web technologie (web app). Slechts wanneer de web app technologie niet afdoende blijkt kan gebruik worden gemaakt van hybride of (near) native apps (zie voor meer informatie het UM app & mobility beleid). Implicaties: Voor elke functionaliteit/taak die de UM via een smartphone wil ontsluiten is een aparte app UI beschikbaar welke speciaal is ontworpen voor smartphone gebruik. Een officiele UM smartphone app voldoet aan de richtlijnen zoals verwoord in het UM app beleid. Er zullen twee portal ingangen zijn voor de smartphone, de geschaalde versie van de newMyUM portal en een portal app. 4. UI voor PC/laptop en tablets

Wanneer een nieuwe UI (portlet) wordt ontwikkeld voor een webportaal dient deze zodanig ontworpen te worden dat deze bruikbaar is op zowel een PC, een laptop als een tablet. Op deze manier hoeft de UM voor specifieke functionele portlets “slechts” twee verschillende UI te ontwikkelen en beheren namelijk een voor de PC/Laptop/Tablet en een voor de smartphones (zie voorgaand uitgangspunt). De portlets moeten portabel zijn zodat ze eenvoudig ook in andere portalservers gebruikt kunnen worden. Implicaties : Voor nieuw ontworpen portlets (UI) zal expliciet rekening gehouden moeten worden met de afmeting en mogelijkheden van een tablet. Voor bestaande portlets die zijn ontworpen voor een PC/laptop en welk daarom niet goed functioneren op een tablet en die vooralsnog niet worden herbouwd zal gelden dat de gebruiker een melding moet krijgen dat de gewenste functionaliteit enkel benaderbaar is middels een PC of laptop. Nieuw te ontwikkelen lokale portlets moeten ofwel voldoen aan de JSR-168/286 standaard (native java portlet) ofwel de HTML5 standaard (generiek). Nieuw te ontwikkelen portlets moeten schaalbaar zijn (van PC tot tablet mini).

Architectuur

© 2014

Pagina 11 van 20

Architectuur enterprise portaal v 1.0 5. De gehanteerde portal integratiemethode is afhankelijk van de complexiteit van de functionaliteit, de omvang van de gebruikersgroep, de gebruiksfrequentie en de mogelijkheden die de leverancier van het bronsysteem biedt.

Er zijn verschillende integratiemethoden om functionaliteit via een portaal te ontsluiten. De complexiteit en daarmee ook de kosten van deze methoden verschilt aanzienlijk. Voor elke functionaliteit die via de portal moet worden ontsloten zal daarom een afweging gemaakt moeten worden welke integratievorm het meest opportuun is. De meest gebruikersvriendelijke (user centric) integratiemethode ,een lokaal portlet in combinatie met een service, kan een dure oplossing zijn wanneer deze nog zelf moet worden ontwikkeld. Of dit opportuun is hangt af van de complexiteit van de gewenste portlet, het aantal gebruikers, de frequentie waarin de functionaliteit wordt gebruikt en de mogelijkheden die de leverancier van de bronapplicatie biedt m.b.t. het aanleveren van de benodigde data. Implicaties: Portlets worden alleen ontwikkeld voor die informatie of functionaliteit die voor een brede gebruikersgroep relevant is, frequent gebruikt en/of visueel geïntegreerd moet worden met andere functionaliteit en waarvoor de voordelen opwegen tegen de hogere kosten. Het is mogelijk dat de huidige SAP portlets die momenteel nog worden ontsloten via de SNP nog enige tijd zullen blijven bestaan. Er zal dan een andere integratievorm worden gezocht om deze functionaliteit toch op een zo gebruikersvriendelijke wijze via het portaal aan te bieden. 6. Het enterprise portaal manifesteert zich als een geïntegreerde omgeving naar gebruikers

Gebruikers hebben behoefte aan een voor hun geïntegreerde omgeving voor digitaal leren en werken. Dit zorgt ervoor dat gebruikers zich niet hoeven af te vragen welke applicaties zij precies nodig hebben; ze hebben alle belangrijke functionaliteiten direct beschikbaar. Daarnaast voorkomt het ook dat gebruikers allerlei gegevens moeten overtypen, wat ook tot irritaties leidt. Implicaties: Het ontwerp van de publieke website en het portaal is op elkaar afgestemd. De inlog voor het portaal is enkel te benaderen via www.maastrichtuniversity.nl Indien opportuun (zie uitgangspunt 4) zal veelgebruikte functionaliteit in applicaties als portlet in het enterprise portaal beschikbaar worden gesteld. De portaalsuite ondersteunt de JSR-286 en de WSRP 2.0 standaard waardoor portlet interoperabiliteit mogelijk is; Er wordt zoveelmogelijk één standaard look-and-feel gehanteerd in het enterprise portaal Applicaties of portlets die visueel zijn geïntegreerd in het enterprise portaal bepalen niet zelf hun opmaak, maar maken gebruik van de opmaak (stylesheet) die voor de portaalomgeving als geheel is gedefinieerd. Als functionaliteit van een portaal dient te worden getoond in een ander portaal dan wordt deze als remote portlet conform de WSRP 2.0 standaard beschikbaar gesteld. Er wordt slechts enkel in het uiterste geval gebruik gemaakt van IFRAMEs voor het integreren van applicaties in het enterprise portaal. 7. De portlets van het enterprise portaal bevatten alleen presentatielogica

Gegevens worden onderhouden in de bronapplicatie. Een portal server is zelf echter geen goede bron voor gegevens; het is gericht op het ontsluiten van gegevens. Het opnemen van logica voor het beheren van gegevens in de portaalomgeving zelf zou het ook lastig maken om deze te migreren (en upgraden) en om de gegevens te ontsluiten richting andere applicaties en kanalen. De portal server wordt daarmee enkel ingezet ten Architectuur

© 2014

Pagina 12 van 20

Architectuur enterprise portaal v 1.0 behoeve van zijn integratie en personalisatie mogelijkheden en zal zo min mogelijk eigen content bevatten. De portlets binnen de portal bevatten enkel presentatie logivca. Alle data en business logica wordt verwerkt in de services laag van de UM. Op deze wijze is deze data het beste te hergebruiken voor de verschillende kanalen. Op deze manier wordt de meest flexibele architectuur bereikt. Een moloch van een portal suite die buiten de integratie en personalisatie functie ook allerlei andere functies levert en content bevat kan erg moeilijk worden geüpgraded of vervangen hetgeen de UM wil voorkomen. Implicaties: Portlets bevatten alleen presentatielogica (gebruikersinteractie logica) en geen bedrijfslogica (dient in services verwerkt te worden) of gegevensbeheerlogica. Functionele blokken van de portaal suite waarvoor ook separate bronapplicaties te krijgen zijn (bv CMS, DMS, interactieve webformulieren, zoekmachine, collaboratie) zullen niet worden gebruikt indien zij ten kosten gaan van de flexibiliteit van de portaalsuite (eenvoudig upgraden, of overgaan tot andere portaalsuite). In die gevallen zullen aparte bronapplicaties, on premise of via de cloud, worden geïntegreerd in de portal. Voor de cloudoplossingen geldt dat deze enkel via SURFConext worden geïntegreerd in de UM portal. Portlets ontsluiten de gegevens en functionaliteit van applicaties via services c.f. de UM integratie architectuur. 8. Het enterprise portaal biedt toegang tot niet meer informatie dan in de bron

De integriteit en vertrouwelijkheid van informatie moet worden bewaakt. De portaalomgeving biedt een alternatieve ingang tot gegevens. Het is belangrijk om bij deze alternatieve ingang te bewaken dat de autorisaties in het bronsysteem gehandhaafd blijven en ongeautoriseerde toegang tot bepaalde gegevens wordt voorkomen. De rechten van de gebruiker bepalen welke inhoud getoond wordt. Implicaties: Toegang tot vertrouwelijke gegevens is geautoriseerd. De services die het portaal aanroept halen hun data op uit de bronsystemen op basis van de rechten behorende bij het account van de betreffende eindgebruiker voor wie de data wordt opgehaald. Er wordt dus geen gebruik gemaakt van “balie medewerker” accounts. Autorisatieregels worden daar waar relevant ook gerepliceerd naar de portaalomgeving. Het zoeken naar informatie houdt ook rekening met autorisatieregels. 9. Het enterprise portaal integreert portlets, applicaties en verticale portalen op basis van open standaarden

De UM wil applicaties zoveel mogelijk integreren op basis van open standaarden en services. Dit vereenvoudigt de integratie van applicaties en voorkomt leveranciersafhankelijkheden. Integratie is een kernaspect van het enterprise portaal en de ondersteuning van open standaarden is dan ook essentieel om snel en eenvoudig functionaliteiten te integreren in het portaal. Daarnaast wil de UM zoveel mogelijk de portabiliteit van haar portlets bevorderen. Wanneer de UM op termijn over zou gaan naar een andere portal server is het niet de bedoeling dat alle portlets weer opnieuw gebouwd moeten worden. Implicaties: Integratie van verticale portalen in het enterprise portaal vindt plaats op basis van de WSRP v2 standaard. Functionaliteiten die ook buiten de UM beschikbaar moeten zijn (bijv. zodat gebruikers deze zelf in iGoogle kunnen integreren) worden ontwikkeld als OpenSocial gadget.

Architectuur

© 2014

Pagina 13 van 20

Architectuur enterprise portaal v 1.0 Functionaliteiten die voldoen aan de OpenSocial standaard kunnen worden geïntegreerd in de portal. De portalserver (suite) moet de JSR-168/286, de WSRP 2.0 en de HTML5 standaard ondersteunen om de portabilitet van de portlets te kunnen waarborgen en om zoveel mogelijk gebruik te kunnen maken van standaard portlets zoals beschikbaargesteld door leveranciers van bronsystemen. De UM portlets die de UM zelf (laat) ontwikkelen voldoen aan de JSR-168/286 of de HTML5 standaard om de portabiliteit daarvan te kunnen waarborgen. De portal moet ten behoeve van het toegangsbeheer de OAuth standaard ondersteunen. De uitwisseling van gebruikersgegevens vindt plaats conform de UM I&AM architectuur. De ontsluiting van data uit bronsystemen richting het portaal vindt plaats conform de UM integratie architectuur. 10. Het enterprise portaal kan zowel on premise UM bronapplicaties als externe cloud applicaties ontsluiten

Gebruikers zijn steeds meer ervaren met IT en hebben zelf een sterke mening over de wijze waarop zij ondersteund willen worden. Zo heeft iedere gebruiker zijn persoonlijke voorkeuren in de applicaties die hij graag gebruikt. Anderzijds zijn er op Internet ook veel (gratis) applicaties te vinden waarmee gebruikers prima uit de voeten kunnen. Het is daarom belangrijk gebruikers niet te veel in een harnas te dwingen daar waar het niet noodzakelijk is. Implicaties: Er wordt gebruik gemaakt van de voorzieningen die worden aangeboden vanuit SURFconext voor identity management en samenwerking over instellingsgrenzen. De eindgebruiker kan enkel kiezen uit cloudapplicaties die via SURFConext zijn ontsloten. Deze worden geïntegreerd in de UM enterprise portal getoond. De applicatiekeuzevrijheid voor eindgebruikers geldt voor functionaliteit die studenten, docenten en onderzoekers van de instelling verwachten maar die niet strikt noodzakelijk is. De applicatiekeuzevrijheid voor eindgebruikers geldt niet voor de volgende gevallen : o Functionaliteit die noodzakelijk is voor de uitvoering van formele taken van de instelling o Functionaliteit die gegevens oplevert die door heel veel verschillende mensen moet kunnen worden gelezen o Functionaliteit die afhankelijk is van functionaliteit of gegevens in veel andere applicaties o Functionaliteit die gegevens beheert die in de burcht (door UM beheert systeemlandschap) zitten De applicatiekeuzevrijheid voor eindgebruikers geldt niet voor applicaties die gegevens bevatten waarvoor het volgende geldt : o Gegevens die archiefwaardig zijn of o Gegevens die noodzakelijk zijn voor verantwoording of o Gegevens die de basis zijn voor allerlei andere gegevens (masterdata) of o Gegevens die breed toegankelijk moeten zijn voor anderen of o Grote hoeveelheden gegevens die vertrouwelijk zijn of o Gegevens die noodzakelijk zijn voor de uitvoering van formele taken van de instelling 11. De UM maakt gebruik van een dedicated portaalsuite voor haar horizontale enterprise portaal.

Een horizontaal enterprise portaal kan gerealiseerd worden m.b.v. een dedicated portaal suite, een web content management systeem (WCMS) of een ander Web Application Framework (WAF). Voor de realisatie van haar horizontale enterprise portaal kiest de UM

Architectuur

© 2014

Pagina 14 van 20

Architectuur enterprise portaal v 1.0 echter voor een dedicated portaalsuite, oftewel een suite die specifiek ontworpen is om als portaalsuite te fungeren. Er zijn een tweetal belangrijke redenen voor deze keuze : Minder maatwerk- Het feit dat je in Excel kunt tekstverwerken wil nog niet zeggen dat je geen Word meer nodig hebt. Met andere woorden, gebruik een applicatie waarvoor het ontworpen is. Een WCMS is in de basis niet ontworpen als een portaal suite waardoor je als organisatie al veel sneller je toevlucht zult moeten nemen tot maatwerk. Vanwege dezelfde reden heeft de UM bv ook besloten om geen gebruik te maken van de WCMS functionaliteit die een portaalsuite eveneens biedt maar hiervoor een apart dedicated WCMS te gebruiken (bv Drupal). Meer flexibiliteit- Voor zowel de portaalsuite als het WCMS wil je als organisatie een zekere flexibiliteit hebben. In de webtechnologie gaan de veranderingen zo snel dat je als organisatie snel wil kunnen switchen naar een ander pakket. Door je WCMS en je portaalsuite in één pakket onder te brengen verlies je flexibiliteit. Wanneer je bv je WCMS wil vervangen (hetgeen je elke 3 tot 5 jaar moet overwegen) dan zou je tevens je hele portaalomgeving op zijn kop moeten zetten en andersom geldt hetzelfde. Implicaties : De technische basis voor het enterprise portaal wordt gevormd door een dedicated portaalsuite. Dit wil zeggen, een suite die specifiek is ontworpen als portaal suite in tegenstelling tot bijvoorbeeld een WCMS of WAF waarmee het technisch gezien ook mogelijk is om een portaal te creeeren.

2.2

Vormen van integratie met het enterprise-portaal

Een portal server biedt allerlei faciliteiten voor het visueel integreren van (taakspecifieke) applicaties. Hierbij kunnen verschillende vormen van integratie worden onderscheiden. 1. iFrame- Applicaties kunnen worden gestart vanuit het portaal, waarna ze volledig hun eigen gebruikersinterface tonen. Eigenlijk is hier helemaal geen sprake van integratie (anders dan een puur visuele), maar voor veel applicaties is het voldoende dat ze op één plaats (de portaalomgeving) kunnen worden gevonden. 2. Webproxy- Deze variant lijkt op de iFrame variant maar heeft iets meer mogelijkheden m.b.t. het aanpasen van de presentatie zodat deze meer in lijn is met het enterprise portaal. 3. Leveranciers portlet- Leveranciers van bronapplicaties kunnen zelf portaalspecifieke presentatiecomponenten (portlets) aanbieden, die direct in de portaalomgeving gebruikt kunnen worden. Dit is feitelijk een één op één koppeling welke geen gebruik maakt van de services integratielaag. Indien het een standaard component betreft kost dit weinig inspanning omdat de leverancier van de applicatie al functionaliteit specifiek voor portalen heeft ontwikkeld. Daarnaast levert het ook een rijke gebruikerservaring en functionaliteit. Bij dit soort directe portlets is er echter niet altijd een zuivere scheiding tussen de presentatie, bedrijfs en data logica zoals bv wel het geval is bij de “lokale portlet i.c.m service”. De leveranciers die voor hun applicatie dergelijke portlets op de markt brengen zorgen er doorgaans voor dat deze JSR-168 en 286 compliant zijn. Daarnaast is er de ontwikkeling dat de leveranciers hun portlets HTML5 compliant realiseren aangezien deze portlets onafhankelijk zijn van de technologie van de onderliggende bronsystemen. 4. Verticaal portaal/remote portlet- Applicaties kunnen zelf een portaalomgeving bevatten (verticaal portaal), die visueel geïntegreerd kan worden in de centrale

Architectuur

© 2014

Pagina 15 van 20

Architectuur enterprise portaal v 1.0 portaalomgeving. Dit geldt bijvoorbeeld voor SAP1 (maar ook Blackboard en CORSA), dat standaard zijn functionaliteit via een eigen portaal levert (SNP). Indien onderdelen van deze verticale portlets in de horizontale portlet wordt ontsloten wordt hiervoor de WSRP 2.0 standaard gehanteerd. 5. Lokaal portlet i.c.m service- Er kan ook een nieuwe portlet worden ontwikkeld voor het ontsluiten van content en functionaliteit in de enterprise portal. De functionaliteit van het portlet zou zich moeten beperken tot presentatie logica (gebruikersinteractie), waarbij eventuele bedrijfslogica en gegevens als services via de centrale UM services webserver worden ontsloten. Voor de realisatie van dergelijke portlets is de JSR168 en 286 of de HTML5 standaard van belang. Deze schrijft voor aan welke vereisten de portlet moet voldoen om de communicatie tussen de portlet en de portelserver mogelijk te maken. Voor elk van deze integratievormen is het mogelijk dat Single Sign On bestaat. In het algemeen zou integratie in de portaalomgeving gedreven moeten zijn door de noodzaak om bepaalde content of functionaliteit voor een brede doelgroep en/of geïntegreerd te presenteren. De reden daarvoor is dat alle integratie tijd en geld kost en dat gekeken moet worden wat de toegevoegde waarde van portaalintegratie is. Een portaal is nu eenmaal gericht op het integreren van informatie. Bij de initiële opzet van het portaal en de verdere doorontwikkelingen van de verschillende doelgroep portalen zal daarom steeds per functionele wens bepaald moeten worden welke vorm van integratie opportuun is.

2.3

Back office integraties UM portal

Om te kunnen bepalen welke informatie en functionaliteit voor elke doelgroep ontsloten moet worden zal vanuit de gebruiker moeten worden geredeneerd (user centric aanpak). De beste methode hiervoor is om binnen elke doelgroep samen met een paar eindgebruikers enkele persona’s en scenario’s uit te werken. Aan de hand hiervan kan vervolgens bepaald worden welke wensen (en prioritering) er zijn. Deze wensen zullen vervolgens moeten worden aangevuld met informatie/functionaliteit die vanuit de bedrijfsvoering geredeneerd noodzakelijk is. Aan de hand van al deze informatie kan vervolgens een ontwerp worden gemaakt conform de UX design principes. Vervolgens moet een technische impactanalyse worden uitgevoerd op dit UX design om te bepalen welke integraties hiervoor noodzakelijk zijn. Per wens zal tevens moeten worden bekeken of deze vanuit een UM bronapplicatie wordt geleverd of dat de eindgebruiker zelf mag kiezen welke cloudapplicatie hij hiervoor wenst te gebruiken. In het eerste geval moet daarna nog worden vastgesteld welke integratievorm het meest opportuun is. In het tweede geval kan de eindgebruiker een keuze maken uit de cloudapplicaties die via SURFConext worden aangeboden in het UM portaal. Onderstaande tabel geeft een beeld van welke UM bronapplicaties mogelijk in enige vorm geïntegreerd zullen worden met het portaal.

1

SAP modules hebben al portlets voor de SAP Netweaver Portal (SNP) waarin bepaalde intelligentie en een UI is gerealiseerd (dit zijn dus standaard portlets voor de SNP). Het kan zeer kostbaar zijn wanneer de UM deze zelf zou moeten herbouwen in haar enterprise portal (service portlet). Het is daarom zeer wel mogelijk dat de integratie van SAP modules deels via de SNP blijft verlopen. De SNP zal dan (met SSO) via de enterprise portal worden ontsloten.

Architectuur

© 2014

Pagina 16 van 20

Architectuur enterprise portaal v 1.0 Doelgroep Student (docent)

Taakspecifieke applicatie Elektronische Leeromgeving (ELO) Roosterapplicatie Student Admisions Student Volg Content Management Systeem FAQ applicatie Online betalen Zoekmachine Bibliotheeksysteem Wetenschappelijke zoekmachine Wetenschappelijke databanken E-mail / Kalender Office suite UM student desktop Webconferencing Digitaal toets systeem Digitaal portfolio systeem Virtual classroom

Product UM Blackboard Syllabus plus SAP SLcM SAP SLcM Drupal T5 Ogone (PSP) SOLR Worldshare platfrom SUMMON

MS Exchange MS Office Athena desktop

Blackboard Collaborate Webconference (Illuminate) Mediasite Mediasite SAP FiCo

Weblectures Multi mediale content Medewerkers Financiële administratie Salarisadministratie SAP Payroll Factuur Roulatie SAP Invoice systeem Management Personeelssysteem SAP HRM Personeels self service SAP ESS/MSS Smartcard Facilitair systeem Planon Inkoop systeem SAP SRM Customer Relation SAP CRM Systeem Document CORSA / Open Management Systeem Text / SAP DMS Corporate Learning CrossKnowledge Management System Profielpagina’s Afwezigheidsregistratie SAP HCM Tijdregistratie iMAR ITSM Topdesk Onderzoeker Promovendi volgsysteem Onderzoeksgegevens Dataverse repository Network (pilot) Onderzoekspublicatie UM Publications repository Onderzoeks Informatie PURE Systeem Tabel 1, Taakspecifieke applicaties die mogelijk ontsloten moeten worden via de enterprise portal

@ De systemen die voor studenten ontsloten moeten worden zullen ook voor medewerkers (in ieder geval docenten) beschikbaar moeten zijn. De systemen die voor medewerkers ontsloten moeten worden moeten ook voor onderzoekers ontsloten worden.

Architectuur

© 2014

Pagina 17 van 20


2.4

De “ any device” propositie

Een UM doelgroep portaal bestaat feitelijk uit een publiek beschikbaar gedeelte (website) en een afgeschermd gedeelte (portal). Op het publieke deel wordt alle generieke, publiekelijk beschikbare content getoond voor de betreffende doelgroep. Achter de inlog wordt enkel gepersonaliseerde content geboden inclusief voor het werk of de studie van belang zijnde functionaliteit. Uit de architectuurprincipes2 volgt dat het doelgroep portaal met elk device te benaderen moet zijn. De oplossingsrichting die hiervoor nodig is verschilt tussen het publieke deel en het afgeschermde deel van het portaal. Dit komt omdat de doelstelling van het publieke deel van het portaal afwijkt van het afgeschermde deel van het portaal. Doelstelling publieke deel doelgroep portaal“De doelgroep voorzien van alle algemene, generieke en publiek beschikbare informatie die zij nodig heeft voor zijn/haar werk en/of studie.” Dit deel van het portaal heeft dus vooral een zendende rol. Het marketing en communicatie aspect is hier het meest prominent aanwezig. De UM pusht deze informatie. Doelstelling afgeschermde deel doelgroep portaal“De eindgebruiker behorende tot de betreffende doelgroep voorzien van gepersonaliseerde informatie alsmede hem in staat stellen voor zijn werk of studie van belang zijnde taken te kunnen uitvoeren. Binnen de gepersonaliseerde informatie wordt onderscheid gemaakt tussen groepsniveaus en het individuele niveau. Het groepsniveau betreft content die elke gebruiker krijgt die behoort tot dezelfde subgroep. Het individuele niveau betreft content die enkel en alleen betrekking heeft op de betreffende persoon.” Met name doordat de gebruiker in het afgeschermde deel daadwerkelijk taken kan uitvoeren (i.p.v. enkel consumeren) maakt het dat hiervoor andere technische eisen gelden om de any device propositie gestalte te geven dan voor het publieke deel het geval is. 2.4.1 Any device voor publieke deel doelgroep portaal Op het publieke deel van het doelgroep portaal (website) wordt dus met name relatief statische content geleverd. Dit deel van het portaal bestaat vooral uit het zenden van informatie die door de gebruiker wordt geconsumeerd. De meest voor de hand liggende en kosten efficiënte oplossingsrichting om gestalte te geven aan de any device propositie is gelegen in Responsive Web Design (RWD) technologie. Door het webdesign van de publieke website van de UM responsive te maken is deze content optimaal beschikbaar op elk device terwijl slechts een enkele website beheerd hoeft te worden.

2 Zie het architectuur principe “De enterprise portaal is toegankelijk any time, any place, any device ” .

Architectuur

© 2014

Pagina 18 van 20

Architectuur enterprise portaal v 1.0 Voorbeeld RWD, UM homepage inclusief inlog (resp. PC, Tablet, Smartphone)

2.4.2 Any device voor afgeschermd deel doelgroep portaal Het afgeschermde deel van het doelgroep portaal bevat enkel gepersonaliseerde content (op verschillende niveaus) en biedt de gebruiker daarnaast mogelijkheden om taken uit te voeren. Voor het kunnen uitvoeren van deze taken zijn applicaties nodig. Succesvolle applicaties voor een tablet en zeker voor een smartphone zijn echter niet simpelweg geschaalde versies van de applicaties die draaien op een PC of laptop. Een eindgebruiker zal altijd bepaalde taken op een PC of laptop blijven uitvoeren en andersoortige taken op een tablet of smartphone. Zelfs wanneer met de smartphone eenzelfde taak wordt uitgevoerd als welke mogelijk is met een PC dan nog zal de manier waarop dit gebeurt beduidend anders zijn. Nog los van het feit dat je te maken hebt met veel kleinere schermen, andere invoermogelijkheden en minder processing power is het belangrijk te realiseren dat bij mobiele devices het vooral gaat om de context waarin de eindgebruiker zich bevindt. Een goed app speelt in en maakt gebruik van de context van de gebruiker en de extra informatie die mobiele devices hierover kunnen leveren (via sensoren). Het beschikbaar stellen van een portaal met functionaliteiten voor elk type device behelst daarom wat meer dan enkel het schalen van een portaal met de bijbehorende applicaties. Voor de oplossingsrichting kan een onderscheid gemaakt worden tussen tablets en smartphones. Tablet Comform principe 4 kiest de UM ervoor om bij haar ontwerp van portlets dit zodanig te doen dat de UI gebruikt kan worden op zowel een PC, laptop als tablet. In die gevallen is de RWD technologie dus afdoende om het afgeschermde deel van het portaal ook via een tablet te kunnen ontsluiten.Voor de huidige portlets die nog niet zijn ontworpen met het gebruik van een tablet in het achterhoofd geldt dat de eindgebruiker een melding moet krijgen dat de gewenste functionaliteit enkel de gebruiken is middels een PC of laptop. Smartphone Voor smartphones is het niet mogelijk (op zijn minst niet wenselijk) om de UI van bepaalde functies die gebouwd zijn voor een PC/laptop ook op een smartphone te gebruiken. Voor functies (taken) die de UM ook via de smartphone wil aanbieden zal daarom een aparte UI in de vorm van een app moeten worden aangeboden. Deze app UI past beter bij de mogelijkheden van de smartphone, is gebruikersvriendelijker en sluit beter aan bij de verwachtingen van de smartphone gebruiker. Om deze functionaliteit voor een zo breed mogelijk scala aan smartphones, tegen zo gering mogelijke beheerskosten, te kunnen aanbieden zal de UM hiervoor de volgende stelregel hanteren. Architectuur

© 2014

Pagina 19 van 20


Principe 3. De UI voor smartphones is specifiek ontworpen voor smartphones De UI voor het kunnen uitvoeren van bepaalde taken (functies) via een smartphone wordt (of is) specifiek ontworpen voor smartphone gebruik en indien mogelijk gerealiseerd middels mobiele web technologie (web app). Slechts wanneer de web app technologie niet afdoende blijkt kan gebruik worden gemaakt van (near) native apps. De hybride variant (bv Phonegap) kan enkel worden toegepast voor vrije APProved apps maar niet voor officiele UM apps (zie voor meer informatie het UM app beleid). De UM zal dus voor de smartphone de UI voor taken (functionaliteiten) apart ontwerpen en hierbij zoveel mogelijk gebruik maken van mobiele web technologie (web app). Daarnaast zullen er echter ook situaties zijn waarbij de UM een (near) native of hybride app wil aanbieden. In tegenstelling tot de op mobiele web technologie gebaseerde apps is het niet (of slechts ten dele) mogelijk om native en hybride apps direct te ontsluiten via de geschaalde versie van het newMyUM portaal. Native en hybride apps moeten namelijk eerst door de gebruiker zelf worden geinstalleerd op hun smartphone. Een en ander heeft tot gevolg dat de UM voor de smartphone twee ingangen zal aanbieden aan de eindgebruiker te weten : Geschaalde newMyUM portal App portal Geschaalde newMyUM portal De geschaalde newMyUM portal is feitelijk de newMyUM portal die ook wordt gebruikt voor PC/laptop en tablet geschaald naar het formaat van een smartphone. Echter wanneer een gebruiker een bepaalde functie aanklikt (bv inschrijven voor een course) wordt voor deze taak niet de UI van de PC/Laptop/Tablet portal getoond maar wordt de specifiek voor de smartphone ontworpen UI (app gebaseerd op web app technologie) getoond.

App portal De app portal is een app die de gebruiker zelf eenmalig moet installeren op zijn smartphone (eventueel ontsloten via een eigen UM app store en via publieke app stores). Via deze app portal heeft de eindgebruiker allerlei apps ter beschikking. Dit kunnen apps zijn gebaseerd op mobiele webtechnologie maar ook native apps. De aparte op mobiele webtechnologie gebaseerde apps (bv voor het inschrijven voor een course) die ook worden ontsloten via de geschaalde variant van de newMyUM portal kunnen in deze portal app als losse apps worden aangeboden. De look and feel van beide smartphone portals zullen op elkaar aansluiten. Tevens kan in de app portal een app icoontje worden opgenomen dat verwijst naar de geschaalde newMyUM portal. In plaats van te kiezen voor een app portal waarbinnen verschillende op zichzelf staande apps worden ontsloten kan tevens worden gekozen voor een optie waarbij één uitgebreide app wordt gecreeerd. Dit is een enkele app waarbinnen enkele functies/taken worden ondersteund. Daarnaast kunnen dan verschillende specifieke losse apps nog worden aangeboden. De kunst is echter te bepalen hoeveel functionaliteit in die uitgebreide app komt en voor welke functionaliteit de UM een aparte app maakt. Momenteel (aug-13) wordt nog onderzocht welke optie het beste is voor de UM studenten.

Architectuur

© 2014

Pagina 20 van 20

Architectuur. Enterprise Portal

Recommend Documents