De weg naar SOA bij de Gemeente Rotterdam Een reisverslag OGH – Fusion Middleware SOA dag 19-5-2010 Lonneke Dikmans – Oracle Ace Director
Inhoud
2
Architectuur | Doelstellingen Rotterdam Veilig, betrouwbaar en transparant • Verbeteren van de dienstverlening • Van klant tot klant processen • Levensgebeurtenissen
• Efficiënte bedrijfsvoering • Eén concern tenzij • Shared service centers
Stimuleren bedrijvigheid • World port port city • Hoger opgeleiden naar de stad • “vierkante meters verkopen’”
3
Architectuur|Concern informatiearchitectuur • Doelstellingen gemeente • NORA (& GEMMA) • DyA • “Just enough architecture”
• Architectuur plannen • Strategisch • Tactisch • “Launching customer”
• Focus op dienstverlening • Hergebruik en flexibiliteit
4
Architectuur | SOA Veel onbeantwoorde vragen: • • • • • • • • •
Wat is een service? Wat voor typen services onderkennen we? Waaraan moet een service voldoen? Hoe identificeren we een service? Wie mag een service gebruiken? Hoe weten we welke services er zijn? Welke tooling gebruiken we voor services? Welke services hebben we nodig? Hoe zit het met events?
Hoe komen we tot de service gerichte architectuur?
5
Inhoud
6
Projecten | Technische omgeving Presentatielaag • Oracle Portal • Ebase (formulieren generator)
Middleware • BPEL • OESB • E-Base (workflow en opslag)
Database • Oracle 10g Database
Authenticatie & Autorisatie • Oracle Identity Management Suite • DigID
7
Projecten | WABO en Verhuizen WABO • • • • •
Webservices: Zaakgericht werken BPEL: Workflow / Orkestratie Schermen: Java schermen ESB: transformeren en routeren (binnen het project) Koppeling met backoffice (vergunningen) voorzien
Verhuizen • E-Base: schermen, workflow en zaaksysteem • Geen koppeling met backoffice voorzien • Services: DigID, adresservice etc.
8
Projecten | Voorbeeld – WABO & Backoffice
9
Projecten | Voorbeeld verhuizen • Demo MijnLoket
10
Projecten | SOA Hobbels • • • • • • • • • • • • •
Wanneer gebruik ik webservices? Schrijven we nog Java? Wanneer gebruiken we BPEL? Wanneer gebruiken we workflow? Hoe komen Welke services zijn er we al? tot de service gerichte architectuur? Service Bus: hoe zetten we die in? Wie gebruikt onze services? Waarom moet ik services gebruiken? Wie zegt dat? Verschil tussen service en operatie? Gebruik van standaarden (StUF)? Hoe weet ik dat die service goed is (“not invented here syndrom”) Hier hebben we geen tijd voor 11
Inhoud
12
Beheer | Technische infrastructuur loadballancer
Server 1
Server 2
soa_p1 non cluster
soa_p2 non cluster
HTTP
HTTP
oc4j_mijnloket
oc4j_mijnloket
oc4j_ebase_ex
oc4j_ebase_ex
oc4j_ebase_in
oc4j_ebase_in
oc4j_soa +esb / wsm
oc4j_soa +esb / wsm
oaisoa01
Wabo inrichting
oaidata
oaisoa02
Verhuizen inrichting 13
Beheer | Technische Infrastructuur
Persistentie laag
Identity management 14
Beheer | Resultaten Producten • • • • •
Release kalender OTA straat Ontwikkelomgeving met generieke voorzieningen SLA verrekeningsmodel
15
Beheer | SOA Hobbels • • • • • • • • • • • •
Releases gebaseerd op applicaties (Zakenmagazijn) Testen van services versus testen van applicaties Welke services zijn er? Welke processen maken gebruik van welke services? Hoein komen weafdelingen tot de service gerichte Services verschillende Beschikbaarheid services versus beschikbaarheid omgeving Welke technologieën staan we toe? Welke configuraties hebben we nodig Wie bepaalt wat? Upgraden van de omgeving HA omgeving opzetten Welke eisen stellen we?
architectuur?
16
Inhoud
17
Governance | Herijking Kaders voor services • • • • •
Een service is autonoom (onafhankelijk) Een service is welomschreven (Contract, interface/kanaal, implementatie) Een service voegt ‘functionele waarde’ toe aan het proces Een service heeft een eigenaar EenZo service wordt geversioneerd komen we tot de service gerichte architectuur!
Processen en rollen • Portfolio management, Change management, Programma management, Project management, etc • Kaders en architectuur: Identificeren, ontwikkelen, testen, release
Gouden gids • Afnemers en aanbieders • Beheer 18
Conclusie | Samenvatting Snel starten, levert veel informatie op • Technieken, wanneer gebruiken we wat • Processen, wat moeten we nu gaan • Service granulariteit, welke services onderkennen we
Service bus erg belangrijk, vanwege flexibiliteit en hergebruik
Zo komen we tot de service gerichte architectuur! • Dubbele services (consolidatie) • Services die nog vaak veranderen
Flexibiliteit bij beheer en release management • services versus applicaties • Versionering
Hergebruik bij ontwikkelaars stimuleren • Not invented here syndrome • Kwaliteit moet aantoonbaar zijn. 19
Conclusie | Learning by Doing Aanpak “Just enough architecture” werkt goed • Organisatie bouwt kennis op • Risico van just too little ligt op de loer
Voorkom een aantal valkuilen • BPEL ≠ silver bullet • Niet te veel aanschaffen voordat duidelijk is wat nodig is -> service catalogus kan later aangeschaft worden • Portaal en service omgeving tegelijkertijd vergt veel van organisatie
Administratie en communicatie is belangrijk • Services die er zijn • Doelstellingen en status service landschap 20
Vragen
21
