Rabobank: Service Architectuur in de Praktijk
Bert Bastenhof, Pieter Fortuin Computable, 21 september 2006 Pagina
R
Inleiding 1. Rabobank omgeving 2. Architectuur binnen de Rabobank 3. Waarom Service Architectuur? 4. Structuur en Afspraken 5. Trends en Aanbod vanuit de Markt 6. Ervaringen met de Realisatie 7. ‘Lessons learned’ en Richting 8. Conclusies
Pagina
R
1.1 Merken van de Rabobank
Pagina
R
1.2 Introductie Rabobank w Aangesloten banken: w Kantoren Nederland: w w w w
1300 Geldautomaten: Kantoren Buitenland: Medewerkers:
Credit rating:
Triple A
220
3000
250 56.000
w Klanten: w Landen:
9 miljoen
37 w Marktaandeel sparen: 38% w Marktaandeel hypotheken: 25% Pagina
R
1.3. Technische indicatoren w • • • • • •
Pagina
18 z/OS lpars 27 Non-stop systems (HP) 400 unix systems/Lpars 2300 Windows servers Veel MQ koppelingen (meer dan 50.000 queues) Veel C:D koppelingen Veel applicaties (>500)
R
2.1 Belang van ICT en Architectuur w Informatie is essentieel voor Financiële
Dienstverlening Ÿ circa 20% van operationele kosten betreft ICT Ÿ honderden toepassingen per merk Ÿ meer dat 4000 ICT medewerkers
w Architectuur is noodzakelijk voor de Rabobank
Groep w Architectuur baseren op Ÿ kennis van de business en van oplossingen Pagina
R
2.2 Architectuur Rabobank Interactie
Fysieke Vestiging
Klant bezoek
Extranet
Telefoon
Internet
Automaat
Post
ALEX
DistributieAndere distributie- kanalen derden kanalen v.d. Rabo Groep
Pakkettering
Producten derden
Beleggen wholesale
Shared wholesale services
Verzekeren
Leasing
Beleggen Leasen retail
Finan cieren
Product
Sparen
Multi-label
Betaalinfrastructuur
Organisatiefuncties per eenheid
Organisatie DATA
Pagina
Besturing
Financiële administratie en Consolidatie
Aspecten Bedrijfsvoering (Personeel, inkoop, Juridisch, etc)
R
Externe Interfaces
…..
Rabobank International
Bedrijfszorg
Interpolis Direct
Pensioenen
Distributie
Robeco Direct
ABB
Betalen
Infrastructuur
Multi-channel
3.1 Drivers voor Service Architectuur w Procesondersteuning Ÿ integratie verleggen van gebruiker naar systeem
w Multichannel Ÿ klanten, medewerkers, leveranciers in één proces
w Multilabel Ÿ meerdere afnemers voor productadministraties
w Kanteling van product naar klant w Hergebruik/Integratie Ÿ verschillende platformen Ÿ verschillende talen Ÿ verschillende eenheden
Pagina
R
3.2 Definitie Servicearchitectuur w De Rabobank Servicearchitectuur is een set van
modellen en principes voor het realiseren van gedistribueerde functionaliteit. w Er wordt uitgegaan van een benadering waarbij deze
functionaliteit wordt gerealiseerd door een samenwerking van onafhankelijke componenten die via berichtuitwisseling services aan elkaar leveren.
Pagina
R
4.1 Scheiden van Functies Interactie Proces
Integratie
Communicatie infrastructuur
Applicatie Pagina
R
4.2 Intra en Inter Domeinverkeer
Domein b
Interactie Proces
Pakket
Integratie
Domein communicatie infrastructuur Adapter
Domein a
Applicatie
Centrale communicatie infrastructuur
Adapter Pakket
Transport Service registratie Protocol Beveiliging ServicebeschrijvingBeheer
Domein d
Interactie Proces
Integratie
Adapter
Communicatie infrastructuur
Domein c
Pagina
Adapter
Applicatie
Adapter
Pakket Adapter
Domein communicatie infrastructuur Adapter Pakket
Adapter Pakket
Adapter Pakket
R
4.3 De gemaakte Afspraken w Communicatie op basis van MQ en Http w Berichtstructuur op basis van SOAP/XML w Gebruik van de SOAP-header Ÿ eigen header voor beheer en sturing (circa 10 elementen) Ÿ beveiliging (circa 5 elementen) Ÿ migratie naar ‘marktstandaard header’
w Webservices Ÿ nog verder in te richten Ÿ meer aandacht bereiken voor beheer Ÿ meer aandacht bereiken voor semantiek Pagina
R
4.4 Integratieniveaus 5Optimaliserend (Feedback uit de operatie / BPM maximaal)
CRM levels
4 Proces (inclusief multichannel / BPM nog niet optimaal) 3
Operationele besturing (terugkoppeling resultaat)
2
Cockpit (link)
1
Huidig (losse toepassingen)
Pagina
R
5.1 Trends in de Markt Van ‘Built to last’ Waterval methoden
Naar ‘Built to change’ Incrementele bouw en invoering
Applicatie silo´s
Georkestreerde oplossingen
‘Tightly coupled’
‘Loosely coupled’
Object oriëntatie
Bericht oriëntatie
Pagina
R
5.1 Trends in de Markt Van ‘Built to last’ Waterval methoden
Naar ‘Built to change’ Incrementele bouw en invoering
Applicatie silo´s
Georkestreerde oplossingen
‘Tightly coupled’
‘Loosely coupled’
Object oriëntatie
Bericht oriëntatie
Pagina
R
5.1 Trends in de Markt Van ‘Built to last’ Waterval methoden
Naar ‘Built to change’ Incrementele bouw en invoering
Applicatie silo´s
Georkestreerde oplossingen
‘Tightly coupled’
‘Loosely coupled’
Object oriëntatie
Bericht oriëntatie
Pagina
R
5.1 Trends in de Markt Van ‘Built to last’ Waterval methoden
Naar ‘Built to change’ Incrementele bouw en invoering
Applicatie silo´s
Georkestreerde oplossingen
‘Tightly coupled’
‘Loosely coupled’
Object oriëntatie
Bericht oriëntatie
Pagina
R
5.1 Trends in de Markt Van ‘Built to last’ Waterval methoden
Naar ‘Built to change’ Incrementele bouw en invoering
Applicatie silo´s
Georkestreerde oplossingen
‘Tightly coupled’
‘Loosely coupled’
Object oriëntatie
Bericht oriëntatie
Pagina
R
5.1 Trends in de Markt Van ‘Built to last’ Waterval methoden
Naar ‘Built to change’ Incrementele bouw en invoering
Applicatie silo´s
Georkestreerde oplossingen
‘Tightly coupled’
‘Loosely coupled’
Object oriëntatie
Bericht oriëntatie
Pagina
R
5.1 Trends in de Markt Van ‘Built to last’ Waterval methoden
Naar ‘Built to change’ Incrementele bouw en invoering
Applicatie silo´s
Georkestreerde oplossingen
‘Tightly coupled’
‘Loosely coupled’
Object oriëntatie
Bericht oriëntatie
Pagina
R
5.2 Leveranciers met ‘ecosystemen’ ‘Verticals’ Specifiek
- bijv. bancaire productsystemen
Microsoft
CRM, ERP
Oracl e
SAP
Financiële administratie, HR Office, mail, content Ontwikkelingomgeving
Algemeen
Middleware -
applicatie server portal BPM, EAI messaging
Microsoft
IBM
Oracl e
SAP
Open Sourc e
Database Platform
- operating system Pagina
Beheeromgeving
HP
R
5.3 Uitgangspunten ecosystemen w Een ecosysteem is het geheel dat geleverd wordt door
‘multi-layer’ leverancier Ÿ dus niet elke leverancier van een pakket levert ecosysteem
w Integratie binnen een ecosysteem is een leveranciers
issue w Integratie tussen ecosystemen op basis van standaarden Ÿ webservices (SOAP, XML, WS-Security, WSDL)
w Bepaalde leveranciers van ecosystemen werken
samen Ÿ bijvoorbeeld in het definiëren van standaarden
w Advies: beperk het aantal ecosystemen Pagina
R
5.4.1 ‘ecosystemen’ en ESB ‘Verticals’ Specifiek
- bijv. bancaire productsystemen
Microsoft
CRM, ERP
Oracl e
SAP
Financiële administratie, HR Office, mail, content Ontwikkelingomgeving
Algemeen
Middleware -
applicatie server portal BPM, EAI messaging
Microsoft
IBM
Oracl esb e
SAP
Open Sourc e
Database Platform
- operating system Pagina
Beheeromgeving
HP
R
5.4.2 ‘ecosystemen’ en ESB ‘Verticals’ Specifiek
- bijv. bancaire productsystemen
Microsoft
CRM, ERP
Oracl e
SAP
Financiële administratie, HR Office, mail, content Ontwikkelingomgeving
Algemeen
Oracl e
SAP esb
IBM
esb
Microsoft
esb
applicatie server portal BPM, EAI messaging
esb
-
esb
Middleware
Open Sourc e
Database Platform
- operating system Pagina
Beheeromgeving
HP
R
5.4.3 ‘ecosystemen’ en ESB ‘Verticals’ Specifiek
- bijv. bancaire productsystemen
Microsoft
CRM, ERP
Oracl e
SAP
Financiële administratie, HR Office, mail, content Ontwikkelingomgeving
Algemeen
IBM
Oracl e
SAP esb
esb
esb
Microsoft
esb
applicatie server portal BPM, EAI messaging
esb
-
esb
Middleware
Open Sourc e
Database Platform
- operating system Pagina
Beheeromgeving
HP
R
6.1 Voorbeelden Rabobank Voorbeel Jaartal d 1995 w Fiatteren Betalen
Techniek
Ervaringe n Propriety NonStop -Robuust, maar
1999
Propriety http
1999
MQ
2000
MQ
w Klantservices
2004
SOAP over MQ
w Sparen
2004
w RaboWeb
Beveiliging
w BKR-toets (wrapping)
w GIM (Verzekeren) Pagina
geen scheiding met kanaal -Problemen met hergebruik -Robuust
-Uitgebreid, intensief gebruik, Webservices granulariteit - semantiek All Finance - URL+ schermen (level 3)-Robuust -Positieve pilot, R integratie is issue
6.2 Ervaringen in de Praktijk w Servicearchitectuur gestart in 1999 Ÿ standaarden en voorschriften zijn gegroeid
à verschillende implementaties (versies) in omloop
w Invoering in het begin lokaal Ÿ niet overal direct of volledig overgenomen
à zekere wildgroei (aantal queues), ontbreken van de bekendheid
w Weerstand in het begin Ÿ propriety versus standaard
à discussies over propriety oplossingen
w Aandacht en besef voor het beheer is gegroeid Ÿ aandacht voor ketenmanagement Pagina
R
6.2 Knelpunten w Ontbreken van eigenaar w Verantwoordelijkheden niet toegewezen w Ontbreken van Compliance w Geen centrale service repository
Soms lokaal aanwezig w Te snelle invoering van technische componenten w Toegankelijkheid richtlijnen w Gebruik MQ
Pagina
R
6.3. Invoering nieuwe technologie Stap 2: Begeleiden Eerste toepassing vernieuwing Showcase 1 Showcase 2 Showcase 3 Ondersteuning showcases
Stap 3 Invoering in Organisatie
BEHEE R
Stap 1: Onderzoek POC’s; Vaststellen consequenties
Pagina
Project matig
QA
Kennis man.
R
7.1 ‘Lessons Learned’ w Standaards Ÿ welke standaarden zijn rijp? Ÿ het lijkt mooier dan het is
w Bouwen: wat is een goede service? Ÿ bij ontwerp uitgaan van processen Ÿ opstellen handvatten/’best practices’ Ÿ aandacht voor kosten/performance/beheer
w Testen Ÿ gevaar voor lange testtrajecten Ÿ ketentesten t.o.v. point-to-point testen
w Beheren Ÿ veel partijen, versies (nieuw naast oud), explosie van queues Pagina
R
7.2
Richting
w Volgen van standaards w Beperken van het aantal ‘ecosystemen’ w Afspraken over semantiek Ÿ branchestandaard per domein Ÿ ‘Rabo Referentietaal’ bij interdomeinverkeer (gebaseerd
op standaard) w Centrale repository Ÿ gedistribueerd gebruik (op basis van WSDL) w Beperken aantal toegangspoorten per domein Ÿ terugdringen aantal queues (vergroten beheersbaarheid) w Ontsluiten legacy systemen op basis van SOAP w Invoeren ketenmanagement; beveiligen op berichtniveau w Aandacht voor Businessrules engines Pagina
R
7.3. SOA governance w Het proces dat er voor zorgt dat de juiste dingen
op de juiste wijze door de juiste personen worden uitgevoerd. Ÿ Ÿ Ÿ Ÿ
best practices architectuur principes regelgeving vertrouwen
w Drie stappen Ÿ Definieer SOA policies Ÿ Richt een SOA infrastructuur in die het afdwingen van deze
policies ondersteunt; Ÿ Regel een aantal processen en procedures in voor het toezien op het nakomen van deze policies (compliance) Pagina
R
7.4 SOA Governance
Pagina
Bron: Systinet
R
8. Conclusies w Service Architectuur is meer dan techniek w Geef aandacht aan SOA governance w Service Architectuur biedt een technische ontkoppeling w Service Architectuur nodig om de complexiteit te beheersen w Aansluiten bij marktstandaarden en bij ‘ecosystemen’ w Service Architectuur vergt lange adem w Invoering vereist een centrale sturing w Extra aandacht voor Beveiliging en voor Beheer is nodig Pagina
R
