De slides bij de publicatie technische infrastructuur voor e dienstverlening en keten samenwerking

1. Technische infrastructuur voor e-
dienstverlening en
ketensamenwerking
Paul Geurts

2. Huidige situatie

3. Gewenste situatie

4. Vrijheid in gebondenheid

5. Trends in samenwerken
• Via het digitale kanaal maken klanten steeds vaker direct gebruik van onze interne data
en voorzieningen (webformulieren, selfservice, extranet, afspraaksysteem, zaakregistratie, MijnNijmegen)
• Hetzelfde geldt voor ketenpartners, zoals uitvoeringsdiensten en woningcorporaties.
Eigen medewerkers werken steeds vaker buiten de eigen gebouwen, deels via een
externe infrastructuur zoals eigen apparatuur, een thuisnetwerk, internet e.d.
• We willen zelf ook extern samenwerken met anderen, bijvoorbeeld met regiogemeenten
of binnen projecten.
• Onze basisregistraties worden binnenkort gemigreerd naar centrale landelijke voorzieningen.
• Sommige backoffice systemen worden al volledig extern als SaaS afgenomen (GBA-V,
RAN, Permixx, Leerplicht, SuWiNet, Bekendmakingen)

6. Karelstad v.s. de wereld
Karelstad
• Alleen gebruikers die op karelstad zijn aangelogd
zijn op Karelstad kunnen bij informatie
• Client server toepassingen met een webschil
• Externe gebruikers kunnen alleen openbare
informatie bevragen ( open data en open
documenten)
• Communicatie met de derden vindt plaats via email
De wereld
• Met je gmail, linkedin of facebook account log je aan
op verschillende diensten
• Volledig webbased, gebouwd op een service
architectuur
• Door autorisatie kan elk niveau van informatie veilig
worden gedeeld.
• Communicatie vindt plaats via services.

7. Service Architectuur
Service register
ServicesGebruiker
Publish
Bind
Find

8. Kenmerken van een service
Een service is virtueel: de afnemer heeft geen weet van de implementatie van de dienst. De
dienst is onafhankelijk van de afnemer. Scheiding van verantwoordelijkheid is expliciet
vastgesteld. Voordeel hiervan is onafhankelijkheid van veranderingen van afnemer en
leverancier. Voldoen aan het contract staat immers centraal;
Een service is gestandaardiseerd: er is slechts één implementatie aanwezig van een
verantwoordelijkheid. De dienst wordt 'commodity' en eenvoudig te vervangen door een
andere leverancier of goedkoper door een efficiëntieslag;
Een service is modulair (vervangbaar) en compositioneerbaar. Standaard is niet flexibel.
Flexibiliteit wordt bereikt door combineren (componeren) van standaards tot een nieuwe
standaard;
Een service is abstract: generiek, niet afgestemd voor 1 specifieke afnemer, maar op een
doelgroep van afnemers;
Losgekoppeld: afnemer en leverancier zijn maximaal onafhankelijk van implementatie van beide.
Elke service is daarom autonoom. Er bestaat geen directe link of relatie tussen verschillende
services. Services zijn zich ook niet van elkaar bewust.

9. Technische architectuur

10. Nieuw: De ESB
Zorgt voor
• Identificatie
• Authenticatie
• Autorisatie
• Routeert service aanvragen
• Routeert berichten
• Nodig voor e-diensten
• Nodig voor het delen van gegevens uit de
kern en basisregistraties

11. Nieuw: De Private Service Cloud
Zorgt voor
• Samenwerk functionaliteiten met derden
en in de keten wordt mogelijk
• Plaats en tijd onafhankelijk werken
• Generiek, regionale toepassingen
Niet nodig
• Domein federatie
• Verlengde kabels ( Citrix ODRN)

12. Het hele verhaal:
http://www.slideshare.net/PaulGeurts4/technische-
infrastructuur-voor-e-dienstverlening-en-
ketensamenwerking